Here is wording to address the email trust bit in MRSP section 5.3.1 - If the intermediate CA certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section3.2.2.4 of the Baseline Requirements. The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage MUST NOT be present. id-kp-clientAuth MAY be present. Other values that the CA is allowed to use, that are not inconsistent with id-kp-emailProtection, and that are documented in the CA’s CPS MAY be present
On Mon, Nov 1, 2021 at 2:10 PM Ben Wilson <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> wrote: >> >>> >>> >>> On Mon, Nov 1, 2021 at 3:34 PM Corey Bonnell <[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]" 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%2B1gtab9F_4Oah65NtOGh3HHD8W%2B6bngjQkpkH0JwFnnXxv_9A%40mail.gmail.com.
