|
|
| Line 17: |
Line 17: |
| '''Public:''' The subordinate CA issues certificates to entities not affiliated with the sub-CA organization. | | '''Public:''' The subordinate CA issues certificates to entities not affiliated with the sub-CA organization. |
|
| |
|
| | | Root certificate authorities should use a separate and distinct root to sign third-party private subordinate CAs, and such roots should not be submitted for inclusion in NSS. Then if the owner of the subordinate CA later decides to create a profit center and start signing site certificates of unaffiliated entities, those site certificates will not chain back up to a root in NSS. With a separate and distinct root not submitted for inclusion in NSS, there would be no need to disclose any information about those third-party private subordinate CAs. |
| There are four possible combinations:
| |
| # '''In-house public subordinate CAs:''' This is the case where a commercial CA establishes one or more internally-operated subordinates to offer certificates of a particular type (e.g., EV vs. non-EV certificates, or SSL certificates vs. email certificates) to the general public.
| |
| #* For this case, the standard [[CA:How_to_apply | root inclusion process]] applies, and it will be verified that the sub-CAs are sufficiently covered by the CP/CPS and audits.
| |
| # '''In-house private subordinate CAs:''' This case would cover CA organizations that establish subordinate CAs for internal testing or other internal purposes.
| |
| #* For this case, the standard [[CA:How_to_apply | root inclusion process]] applies, and it will be verified that the sub-CAs are sufficiently covered by the CP/CPS and audits.
| |
| # '''Third-party public subordinate CAs:''' In this case the root signs subordinate CAs for organizations who operate the sub-CA to sign certificates for other entities not affiliated with their organization. One example is a commercial CA which establishes one or more subordinate CAs to be operated by third-party organizations acting as Certificate Service Providers (CSP). Another example is a government-sponsored root CA where the organization running the root CA delegates to other organizations the task of issuing end entity certificates to the general public. For example, there might be a separate organization authorized to issue certificates for general business purposes, another organization issuing certificates specifically within a vertical industry sector like financial services, a third organization to issue certificates to individuals, and so on.
| |
| #* A typical Mozilla user is likely to encounter certificates issued by these third parties in the course of typical activities like web browsing. Hence we need assurances that these third parties are required to follow practices that satisfy the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy,] and we need to ensure that these third parties are under an acceptable audit regime.
| |
| #* The root CA is required to disclose the identity of these third parties, because they are essentially functioning as public CAs.
| |
| #* Please see the [[CA:SubordinateCA_checklist#Third-Party_Public_Subordinate_CAs|section below]] which outlines the additional information that must be provided for third-party public subordinate CAs.
| |
| # '''Third-party private (or enterprise) subordinate CAs:''' This is the case where a commercial CA has enterprise customers who want to operate their own CAs for internal purposes, e.g., to issue SSL server certificates to systems running intranet applications, to issue individual SSL client certificates for employees or contractors for use in authenticating to such applications, to issue SSL certificates for pre-approved domains that are owned/controlled by the customer, and so on.
| |
| #* These sub-CAs are not functioning as public CAs.
| |
| #* For these sub-CAs we need assurance that they are not going to start functioning as public CAs. Currently the only assurances available for this case it to ensure that these third parties are required to follow practices that satisfy the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy,] and that these third parties are under an acceptable audit regime.
| |
| #** In [https://bugzilla.mozilla.org/show_bug.cgi?id=394919 Bug #394919] NSS is being updated to apply dNSName constraints to the CN, in addition to the SANs.
| |
| #** We plan to update our policy to require CAs to constrain third-party private (or enterprise) subordinate CAs so they can only issue certificates within a specified domain. See section 4.2.1.10 of RFC 5280.
| |
| #* Please see the [[CA:SubordinateCA_checklist#Third-Party_Private_(or_Enterprise)_Subordinate_CAs|section below]] which outlines the additional information that must be provided for third-party private (or enterprise) subordinate CAs.
| |
| | |
| '''Recommendation:''' Root certificate authorities should use a separate and distinct root to sign third-party private subordinate CAs, and such roots should not be submitted for inclusion in NSS. Then if the owner of the subordinate CA later decides to create a profit center and start signing site certificates of unaffiliated entities, those site certificates will not chain back up to a root in NSS. With a separate and distinct root not submitted for inclusion in NSS, there would be no need to disclose any information about those third-party private subordinate CAs.
| |
|
| |
|
| == Third-Party Private (or Enterprise) Subordinate CAs == | | == Third-Party Private (or Enterprise) Subordinate CAs == |