On Tue, Oct 19, 2021 at 6:33 PM Ben Wilson <[email protected]> wrote:
> 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. > I don't think you want to delete this sentence. Section 5.3 permits anyEKU for cross-certificates operated by a different entity, and thus it seems quite likely that some CA would mistakenly believe that anyEKU represents a "specific EKU", and thus argue that the cross-certificate is technically constrained, and thus doesn't need audits, because it as _an_ EKU. This may seem a tortured reading, but recall that CAs have misunderstand a critical extension for the (previous) definition of Test Certificate [1][2], and we continue to see CAs fail to properly encode DER [3] (a requirement since V1 of Mozilla Policy [4]), so it seems it's necessary to be unambiguously explicit where a CA may misunderstand a requirement. [1] https://groups.google.com/g/mozilla.dev.security.policy/c/Q2k_5eGXqmA/m/CHDrlZYPDgAJ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=555156#c129 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1735908 [4] https://wiki.mozilla.org/CA:CertificatePolicyV1.0 > 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]). > It would appear your proposal is to be explicitly stronger than the BRs requirement: the MAY/SHOULD NOT regarding multiple EKUs become a MUST NOT. This is definitely a good change that will improve security, but by cross-referencing the BRs here, it would arguably make that ambiguous, as it would suggest multiple constrained EKUs are permissible. Is the intent to allow multiple EKUs (for non-TLS) or not? If not, then it seems important to avoid introducing ambiguity by referencing the BRs, unless it's to highlight Mozilla Policy is intentionally (and for good reason) more restrictive. -- 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/CAErg%3DHG_107bzN7gzTpgh7spkk4VARraBJkAb1f1SHU3ohZxJQ%40mail.gmail.com.
