|
|
| Line 70: |
Line 70: |
|
| |
|
| Furthermore, for '''externally operated subordinate CAs''', and in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas MRSP Section 8.4], please refer to '''[[CA/External_Sub_CAs|this wiki page]]'''. | | Furthermore, for '''externally operated subordinate CAs''', and in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas MRSP Section 8.4], please refer to '''[[CA/External_Sub_CAs|this wiki page]]'''. |
|
| |
| == Non-disclosable Intermediate Certificates ==
| |
| In order to best ensure the safety and security of Mozilla users, Mozilla has a single consistent [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy policy] that describes the expectations for all CAs that will be trusted within its program. Mozilla requires that all participating root CAs fully disclose their hierarchy, including CP, CPS, and audits, when said hierarchy is capable of issuance.
| |
|
| |
| If you have intermediate certificates for which you cannot disclose this information, whether it be for personal, operational, or legal reasons, then an appropriate solution, consistent with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#53-intermediate-certificates Mozilla Root Store Policy], is to use Technically Constrained Subordinate CAs (TCSCAs) - as defined within the CA/Browser Forum's Baseline Requirements and as reflected within Mozilla's policy. Such TCSCAs are technically limited from the issuance of TLS server or email certificates. For example, if these subCAs are not used for the production of TLS/SSL or email certificates, then you can make use of the Extended Key Usage extension on the sub-CA to ensure it is present, and that it *lacks* the id-kp-serverAuth, id-kp-emailProtection, and anyExtendedKeyUsage extensions. (CAVEAT: Public disclosure in the CCADB might still be required by other root store programs. See [https://www.ccadb.org/policy#4-intermediate-certificates Section 4 of the CCADB Policy].)
| |
|
| |
| Alternatively, you can consider restructuring a CA hierarchy such that you have
| |
|
| |
| :::/-Private Sub CA 1
| |
| ::/--Private Sub CA 2
| |
| :Root
| |
| ::\
| |
| :::\-BR-compliant Public Intermediate {This is the cert you would request Mozilla include as a Trust Anchor.}
| |
| ::::\
| |
| :::::\----BR-compliant SubCA1
| |
| ::::::\---BR-compliant SubCA2
| |
| :::::::\--BR-compliant SubCA3
| |
|
| |
| That is, in this structure, an additional intermediate is inserted into your PKI which distinguishes the "private" (confidential) sub-CAs, and the publicly audited, publicly disclosed set of sub-CAs. In this scenario, rather than all chaining directly to the Root, they transit a newly introduced intermediate. It is this newly introduced intermediate that you would 'apply' for inclusion to Mozilla as the root, even if operationally, your government might use and rely on "Root" for the broader purpose of digital signature identification or operational management.
| |
|
| |
| The point of this is that Mozilla Policy requires that all nodes signed by the trust anchor (using the RFC5280 terminology, since it doesn't need to be a self-signed cert), whether it's 'root' or 'BR-compliant Public Intermediate', MUST be operated and disclosed in a way consistent with Mozilla Policy. If you have a 'private' PKI (even if it's publicly operated for the benefit of citizens and/or customers), then it MUST be a sibling-or-parent node in the PKI tree, and MUST NOT be a child node.
| |