> I'm not sure I follow? A SHOULD NOT is not any more onerous, as it's not a > prohibition.
BR 7.1.2.2 (g) currently reads: “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 current proposed Mozilla Policy text essentially changes the MAY to a SHOULD NOT. While not a concrete prohibition, it is certainly more onerous/strict than the BRs. As you know and from the RFC 2119 text you quoted, “SHOULD NOTs” are indicative of some practice that Root Programs generally frown upon, which is why I brought this up. Thanks, Corey From: [email protected] <[email protected]> On Behalf Of Ryan Sleevi Sent: Monday, November 1, 2021 3:38 PM To: Corey Bonnell <[email protected]> Cc: Ben Wilson <[email protected]>; Ryan Sleevi <[email protected]>; [email protected] <[email protected]> Subject: Re: Policy 2.8: MRSP Issue #228: Clarify technically-constrained sub-CA EKUs On Mon, Nov 1, 2021 at 3:34 PM Corey Bonnell <[email protected] <mailto:[email protected]> > wrote: > 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? I'm not sure I follow? A SHOULD NOT is not any more onerous, as it's not a prohibition. >From RFC 2119, which Mozilla policy incorporates by reference SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. -- 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/CAErg%3DHG_uZACuiDQNM9ubqctOv5er9h3Y3nQQy7CaoanTwBF1Q%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG_uZACuiDQNM9ubqctOv5er9h3Y3nQQy7CaoanTwBF1Q%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/DM6PR14MB2186BF306ACA5C95816A426B928A9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
