Thanks, Ryan. On Sat, Oct 23, 2021 at 1:13 PM Ryan Sleevi <[email protected]> wrote:
> > > 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 > I will leave that sentence in - to make it clear that the anyEKU EKU shouldn't be used. > 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. > I did not intend to make it more restrictive. I will re-visit what I am trying to communicate here. The idea behind the cross-referencing wasn't to draw a distinction, but to create some consistency, but I also added that bit in there to spark conversation re: consistency with the BRs. I'll take a look at the proposal, your suggestions, and any others we receive as I work on the redlined version. Thanks again, 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%2B1gtaY0mW4zt0X_ZpkYAFfr25WcPpoiPcSe-rsMPPtQsQdHAg%40mail.gmail.com.
