Thinking about this more, we will need to address this for SMIME, too. I might need to put more detail down in the other two paragraphs of MRSP seciton 5.3.1 that explain what it means to technically constrain issuing CAs for TLS server certificates and for SMIME certificates.
On Mon, Nov 1, 2021 at 1:43 PM Ben Wilson <bwil...@mozilla.com> wrote: > 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%2B1gtaY_9oFtePAL5_gPFnWcAbS5fD_cBm59vAcfAsek19WM9Q%40mail.gmail.com.
