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 <ji...@it.auth.gr> 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 " > 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/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 "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%2B1gtabJsNMs%3DKu1Lv23qKKq-0ktOHN%3D1HqAkysHa9Yvw3Asew%40mail.gmail.com.
