Hi Ryan, Comments inline.
> I don't believe this change is correct. Well, the draft language seemingly doesn’t reflect the discussion on the associated policy thread [1]. I’d hope that even if there were a concrete prohibition (MUST NOT), it could be stated more clearly than a highly subtle “default deny” reading. > Having a multi-purpose server-auth certificate, even if technically > constrained, seems to be a significant step back. While this is permitted for > email, that is hopefully only temporary, to reflect the lack of maturity and > secure design in the id-kp-emailProtection CA ecosystem. I don’t quite follow why this is a step back, as it’s simply a restatement of the status quo (i.e., no steps taken). That’s not to say there can’t be further refinements in this area, but current language does not align with the discussion on the associated policy thread, namely [2], where it was stated there is a desire to align MRSP with the TLS BRs in this regard. [1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/n1vLLXwNbuM/m/D6oEqHXgBAAJ [2] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/n1vLLXwNbuM/m/atOa5QoFAQAJ Thanks, Corey From: Ryan Sleevi <[email protected]> Sent: Thursday, April 28, 2022 7:27 PM To: Corey Bonnell <[email protected]> Cc: [email protected]; [email protected] <[email protected]> Subject: Re: Policy 2.8: Final Review of MRSP v. 2.8 On Thu, Apr 28, 2022 at 11:29 AM 'Corey Bonnell' via [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > wrote: Hi Ben, In giving the draft 2.8 policy another read, I found a potential inconsistency that should be resolved. Section 5.3.1 [1] says: "If the intermediate CA 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. The id-kp-clientAuth EKU MAY also be present. The conformance requirements defined in section 2.3 of this policy also apply to technically constrained intermediate certificates. 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. The values id-kp-serverAuth and anyExtendedKeyUsage MUST NOT be present. id-kp-clientAuth MAY be present. Other values that the CA is allowed to use and are documented in the CA’s CP, CPS, or combined CP/CPS MAY be present." In particular, the sentence "Other values that the CA is allowed to use and are documented in the CA’s CP, CPS, or combined CP/CPS MAY be present." should also be added to the paragraph for id-kp-serverAuth. Without that sentence, a "default deny" interpretation of that paragraph may lead some readers to the conclusion that other EKU values are not allowed. I don't believe this change is correct. Having a multi-purpose server-auth certificate, even if technically constrained, seems to be a significant step back. While this is permitted for email, that is hopefully only temporary, to reflect the lack of maturity and secure design in the id-kp-emailProtection CA ecosystem. -- 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/DM6PR14MB218634C94BA18171F8B1295E92FC9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
