All, This email introduces a second issue in a series of issues selected to be addressed in the next version of the Mozilla Root Store Policy (MSRP), version 2.8, to be published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8)
Github Issue #228 <https://github.com/mozilla/pkipolicy/issues/228> proposes that we amend MRSP section 5.3.1, which currently says, "For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying *all *extended key usages that the subordinate CA is authorized to issue certificates for.” The problem with the sentence is that the word "all" seems to imply that CAs should include numerous EKUs in Technically Constrained Intermediate CAs, whereas the opposite should be communicated. (While the simultaneous presence of serverAuth and clientAuth EKUs in an intermediate CA should be allowed, the emailProtection EKU and other incompatible EKUs are prohibited by section 7.1.2.2 g. of the CA/Browser Forum's Baseline Requirements.) I am proposing that we replace the sentence above with, "A technically constrained intermediate CA certificate uses a specific Extended Key Usage (EKU) [hyperlink to RFC 5280] to limit the scope of certificates that the CA may issue." I'm open to suggestions on alternative wording. I am also thinking that we can delete the subsequent sentence that reads, "The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension" because MRSP section 5.3 already says this. It states, “Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate: MUST contain an EKU extension; and, MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate.” Also, in MRSP section 5.3.1, we should cross-reference section 7.1.2.2.g. of the Baseline Requirements, which says: For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection [RFC5280], id-kp-codeSigning [RFC5280], id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be present. For Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent key purposes (e.g. including id-kp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]). Finally, for your additional reference and consideration, the remainder of MRSP section 5.3.1 currently says, If the certificate includes the id-kp-serverAuth extended key usage, then to be considered technically constrained, the certificate MUST be Name Constrained as described in section 7.1.5 of version 1.3 or later of the Baseline Requirements <https://cabforum.org/baseline-requirements-documents/>. The conformance requirements defined in section 2.3 of this policy also apply to technically constrained intermediate certificates. If the certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2.4 of the Baseline Requirements <https://cabforum.org/baseline-requirements-documents/>. Thoughts? Thanks, Ben -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZmXjdN4hLCp0HBbbNyma_BzLkdL-YE0ovVFomupX_KtQ%40mail.gmail.com.
