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]> 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]> 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]> wrote: >> >>> 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%2B1gtaa4J_N_hp9yDye9ows9M09qu_JeErQivykVOrvEhSGQDw%40mail.gmail.com.
