Next week, I will be closing discussion on this issue so that we can move on to others.
I intend to modify section 5.3.1. of the MRSP regarding technically constrained CAs by: 1 - Replacing "all extended key usages" with "the extended key usage(s) allowed for the type of end entity certificates that the subordinate CA is authorized to issue." (This provision begins with a "MUST"). 2 - Adding "CAs SHOULD NOT include more than a single KeyPurposeID in the EKU extension." (This is a recommendation, not a requirement.) 3 - Adding "The id-kp-clientAuth EKU MAY also be present." (To allow for the clientAuth EKU in server certificates. I realize that this is slightly contradictory with 2 above.) 4 - Adding "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 section 3.2.2.4 of the Baseline Requirements <https://cabforum.org/baseline-requirements-documents/>. 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." (I realize that this is slightly contradictory with 2 above.) I'll give everyone a week to make any additional comments. See https://github.com/BenWilson-Mozilla/pkipolicy/blob/Issue228-5/rootstore/policy.md (and please let me know if I've missed anything discussed). Thanks, Ben On Tue, Nov 2, 2021 at 7:24 AM Ben Wilson <[email protected]> wrote: > 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%2B1gtaYyDqCvrD0F5VKq%2BJm4NeBCh73O0mX48MoabxWS3rqWpA%40mail.gmail.com.
