I could a parenthetical - (For Subordinate CA Certificates that will be used to issue TLS certificates, the clientAuth EKU MAY be present.)
On Mon, Nov 1, 2021 at 1:37 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Mon, Nov 1, 2021 at 3:34 PM Corey Bonnell <corey.bonn...@digicert.com> > 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 "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/CA%2B1gtabAM36pYfP4nj_Fd6-e%2BF_AKunF%2B%3DO-qGemc1mu2%2BCj0A%40mail.gmail.com.
