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 <bwil...@mozilla.com> 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 <bwil...@mozilla.com> wrote: > >> Thanks, Ryan. >> >> On Sat, Oct 23, 2021 at 1:13 PM Ryan Sleevi <r...@sleevi.com> wrote: >> >>> >>> >>> On Tue, Oct 19, 2021 at 6:33 PM Ben Wilson <bwil...@mozilla.com> 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 "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHFB7CabQ0iFs0-hAJt7R958wwrwdZ3fQh42Syx5Duih4w%40mail.gmail.com.
