> I'm accepting your suggestion and phrasing it, "CAs SHOULD NOT include more > than a single KeyPurposeID in the EKU extension."
This is quite a bit more onerous than the current BRs, which explicitly allow for id-kp-clientAuth to be included alongside id-kp-serverAuth. Is the deprecation of id-kp-clientAuth KP in serverAuth TLS certificates intentional? Thanks, Corey From: [email protected] <[email protected]> On Behalf Of Ben Wilson Sent: Monday, November 1, 2021 3:31 PM To: Ryan Sleevi <[email protected]>; [email protected] <[email protected]> Subject: Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs I'm accepting your suggestion and phrasing it, "CAs SHOULD NOT include more than a single KeyPurposeID in the EKU extension." On Mon, Nov 1, 2021 at 1:10 PM Ryan Sleevi <[email protected] <mailto:[email protected]> > wrote: I guess I still struggle a bit to understand the goal here? Recall that the original comment from Actalis [1], which lead to that issue [2], was as follows: Since the plural is used in that sentence (all extended key usages), this sounds like – in the case of a Technically Constrained CA – it is allowed for the EKU to contain more than one key usage, otherwise the use of the plural seems weird. We see that this interpretation conflicts with the provisions of the BR (from v1.7.1), however we believe that the current wording of the MRSP 5.3.1 may have been a source of confusion, contributing to the occurrence of the problem. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1717357#c6 [2] https://github.com/mozilla/pkipolicy/issues/228 The suggestion I made at that time was: It seems that it would be useful to clarify the language, in both the BRs and Mozilla Policy, to consistently discourage multiple usages within technically constrained sub-CAs. Which seems consistent with Actalis' remark. Going back to your original proposal, you proposed two functional changes: 1. Require the use of a specific EKU (good; turns SHOULD NOT -> MUST NOT, which is net positive for users and security) 2. Remove a prohibition on anyEKU The concern I raised was just making sure 1 was intentional, and highlighting how without 2, 1 can be misinterpreted. With the new proposal, however, I'm struggling to see how it addresses the original issue? The original issue was one caused by discussing a plurality of EKUs; the new language ("specifying the extended key usage(s)") still seems to suffer from that plurality leading to misinterpretation. It seems there are several possible paths forward here: A. Explicitly, unambiguously prohibit multiple EKUs for CAs. The presence of multiple EKUs on a CA implies that there will be subscriber certificates (even if not TLS certificates) that combine multiple EKUs, and since each EKU is meant to prevent cross-protocol attacks, such a scenario would still be harmful to users. For example, combining an id-kp-emailProtection EKU with another EKU undermines the security of the email protection, the same way combining TLS and emailProtection facilitates cross-protocol attacks. - "For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying a single KeyPurposeID allowed for the type of end entity certificates that the subordinate CA is authorized to issue. The anyExtendedKeyUsage KeyPurposeID MUST NOT appear within this extension." B. Explicitly reiterate that CAs SHOULD NOT include multiple EKUs for CAs. This is already present in the BRs, and is just reiterating in Mozilla Policy that Mozilla is not "weakening" the BRs with its policy. - "For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying the extended key usage(s) that the subordinate CA is authorized to issue certificates for. CAs SHOULD NOT include more than a single KeyPurposeID. The anyExtendedKeyUsage KeyPurposeID MUST NOT appear within this extension." Hopefully this finds the right balance? The SHOULD NOT is already part of the BRs, so Option B should be uncontroversial. The prohibition on "anyEKU" is still relevant here, because Mozilla allows it for cross-certificates, and so it's possible to construct a case where a TCSC is seen as a Cross Certificate and that it's acceptable to Mozilla. It's almost certain that A is the desired end state, and so it's just a question of whether to clarify by using B until then, or to attempt to move to that end state now and address via A. On Mon, Nov 1, 2021 at 2:22 PM Ben Wilson <[email protected] <mailto:[email protected]> > wrote: What if we just changed the second sentence of MRSP section 5.3.1 <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained> to read, "For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying the extended key usage(s) allowed for the type of end entity certificates that the subordinate CA is authorized to issue."? On Mon, Oct 25, 2021 at 11:19 AM Ben Wilson <[email protected] <mailto:[email protected]> > wrote: Thanks, Ryan. On Sat, Oct 23, 2021 at 1:13 PM Ryan Sleevi <[email protected] <mailto:[email protected]> > wrote: On Tue, Oct 19, 2021 at 6:33 PM Ben Wilson <[email protected] <mailto:[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] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa4J_N_hp9yDye9ows9M09qu_JeErQivykVOrvEhSGQDw%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa4J_N_hp9yDye9ows9M09qu_JeErQivykVOrvEhSGQDw%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- 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/DM6PR14MB2186BB400DFBF59FC89934F0928A9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
