On Thu, Apr 28, 2022 at 11:29 AM 'Corey Bonnell' via [email protected] <[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/CAErg%3DHGmSehLgHHhd1JOzTrT60O8j8cWFrtQ4OfChP6OQ3D%3DEw%40mail.gmail.com.
