It has been a while since this issue was discussed. I made a few minor changes and would like to get some feedback.
https://github.com/BenWilson-Mozilla/pkipolicy/commit/092d546558718d3f792cd33b544b669fda8484d1 I added the words "intermediate certificate" in a couple of places to clarify what we're talking about in MRSP section 5.3.2. Ben On Mon, Nov 15, 2021 at 11:42 AM Ben Wilson <[email protected]> wrote: > Thanks, Dimitris. > I am trying to make as few changes as necessary to the current MRSP, and I > am still considering your suggested reformatting of MRSP section 5.3.1. > Meanwhile, I changed the "SHOULD" to "encourage," as you suggested. I also > deleted the "not inconsistent" language so that the sentence reads, "Other > values that the CA is allowed to use and are documented in the CA’s CPS MAY > be present." See > https://github.com/BenWilson-Mozilla/pkipolicy/compare/master...Issue228-6?expand=1. > Again, I'm open to feedback on Dimitris proposed revisions. > Thanks again, > Ben > > On Mon, Nov 15, 2021 at 5:47 AM Dimitris Zacharopoulos <[email protected]> > wrote: > >> >> >> On 11/11/2021 12:10 μ.μ., Dimitris Zacharopoulos wrote: >> >> >> I am having trouble understanding the following phrase under 4. >> >> *"**that are not inconsistent with id-kp-emailProtection" * >> >> and I'm not sure if it is because of a double negative or something else >> missing. Ben, or anyone, can you please share some examples of "consistent" >> and "inconsistent" EKUs with id-kp-emailProtection to make this requirement >> a bit more clear? >> >> 1. and 3. are already covered in 4. You use "encourage" to recommend >> something. I suggest we avoid using RFC 2119 specific terms like "SHOULD >> NOT" if it is just to "encourage" a practice. >> >> In order to have some symmetry between the email and server certificates, >> I made an attempt to consolidate the information. Here is a proposed change: >> >> Current section 5.3.1 text: >> >> *"We encourage CAs to technically constrain all intermediate >> certificates. For a certificate to be considered technically constrained, >> the certificate MUST include an **Extended Key Usage (EKU) >> <http://tools.ietf.org/html/rfc5280#section-4.2.1.12>** extension >> specifying all extended key usages that the subordinate CA is authorized to >> issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT >> appear within this extension.* >> >> *If the certificate includes the id-kp-serverAuth extended key usage, >> then to be considered technically constrained, the certificate MUST be Name >> Constrained as described in section 7.1.5 of version 1.3 or later of the >> **Baseline >> Requirements <https://cabforum.org/baseline-requirements-documents/>**. >> The conformance requirements defined in section 2.3 of this policy also >> apply to technically constrained intermediate certificates.* >> >> *If the 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/>**."* >> >> Suggested text: >> >> >> I realized that we should also consider the subCA Certificates that >> contain an EKU extension and have KeyPurposeIDs that are not the >> id-kp-emailProtection (for email certificates) or id-kp-serverAuth (for >> server certificates). Here's an updated text to support that. >> >> *"We encourage CAs to technically constrain all intermediate >> certificates. For a CA certificate to be considered technically constrained >> for email certificates, * >> *one of the following options must be fulfilled: * >> >> *Option A) The CA Certificate MUST include an Extended Key Usage (EKU) >> <http://tools.ietf.org/html/rfc5280#section-4.2.1.12> extension that SHALL >> NOT include the id-kp-emailProtection or the * >> *anyExtendedKeyUsage KeyPurposeID; or * >> >> >> *Option B) The CA Certificate - MUST include an **Extended Key Usage >> (EKU) <http://tools.ietf.org/html/rfc5280#section-4.2.1.12>** extension >> that SHALL include the id-kp-emailProtection KeyPurposeID. The values >> id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and >> anyExtendedKeyUsage MUST NOT be present. The value id-kp-clientAuth MAY be >> present. Other values that the CA is allowed to use, and that are >> documented in the CA’s CPS MAY be present, and* >> >> *; - MUST include a Name Constraints X.509v3 extension with constraints >> on rfc822Name values, 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/>**.* >> >> *For a CA certificate to be considered technically constrained for server >> certificates, * >> *one of the following options must be fulfilled: * >> >> *Option A) The CA Certificate MUST include an Extended Key Usage (EKU) >> <http://tools.ietf.org/html/rfc5280#section-4.2.1.12> extension that SHALL >> NOT include the id-kp-serverAuth or the **anyExtendedKeyUsage >> KeyPurposeID; or* >> >> Option B) The CA Certificate >> >> *- MUST include an **Extended Key Usage (EKU) >> <http://tools.ietf.org/html/rfc5280#section-4.2.1.12>* >> * extension that includes the id-kp-serverAuth KeyPurposeID. The values >> id-kp-emailProtection, id-kp-codeSigning, id-kp-timeStamping, and >> anyExtendedKeyUsage MUST NOT be present. The value id-kp-clientAuth MAY be >> present. Other values that the CA is allowed to use, and that are >> documented in the CA’s CPS MAY be present, and; * >> >> *- ** MUST **include a Name Constraints X.509v3 extension with >> constraints **as described in section 7.1.5 of version 1.3 or later of >> the **Baseline Requirements >> <https://cabforum.org/baseline-requirements-documents/>**.* >> >> *We encourage CAs not to include more than a single KeyPurposeID in the >> EKU extension."* >> >> -- >> 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/a8ca2462-41ce-34c0-f5bc-b1e6557dd355%40it.auth.gr >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a8ca2462-41ce-34c0-f5bc-b1e6557dd355%40it.auth.gr?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/CA%2B1gtaY_Ev11EmcD0_Js6cGG-BYLTNhscJ1iRc4WQa2Y7px6dw%40mail.gmail.com.
