Here is a concrete proposal that addresses the concerns than have been raised:
Add the following statement to Mozilla policy section 5.3 (Intermediate Certificates): Intermediate certificates created after January 1, 2019: * MUST contain an EKU extension; and, * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate. Another argument in favor of (eventually) eliminating unconstrained intermediates is that I've seen a number of CAs who believe (incorrectly) that unconstrained intermediate CA certificates not used to issue TLS certificates are exempt from the BRs. Are there other arguments for or against this change? On Tue, Apr 17, 2018 at 1:33 PM, Jeremy Rowley <jeremy.row...@digicert.com> wrote: > If you don't specify by EKU, the exercise of determining intent becomes > impossible as illustrated by our (many) attempts to define a server cert in > CAB Forum. Better to list the EKUs allowed and not allowed in the same cert > than rely on another intent requirement. > > -----Original Message----- > From: dev-security-policy > <dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org> > On Behalf Of Doug Beattie via dev-security-policy > Sent: Tuesday, April 17, 2018 1:37 PM > To: Wayne Thayer <wtha...@mozilla.com>; mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: RE: Policy 2.6 Proposal: Require separate intermediates for > different usages (e.g. server auth, S/MIME) > > > > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of > > Wayne Thayer via dev-security-policy > > Sent: Tuesday, April 17, 2018 2:24 PM > > To: mozilla-dev-security-policy <mozilla-dev-security- > > pol...@lists.mozilla.org> > > Subject: Policy 2.6 Proposal: Require separate intermediates for > > different usages (e.g. server auth, S/MIME) > > > > This proposal is to require intermediate certificates to be dedicated > > to specific purposes by EKU. Beginning at some future date, all newly > > created intermediate certificates containing either the > > id-kp-serverAuth or id-kp- emailProtection EKUs would be required to > contain only a single EKU. > > We'll need to support a list of EKUs if this becomes a requirement. Server > Auth certificates should be able to support lots of different EKUs, for > example: > id-kp-serverAuth > id-kp-clientAuth > id-kp-ipsecEndSystem > id-kp-ipsecTunnel > id-kp-ipsecUser > KDC Authentication > Smart Card Logon > iPSec IKE > IKE Intermediate > > > Arguments for this requirement are that it reduces risk of an incident > > in which one type of certificate affecting another type, and it could > > allow some policies to be restricted to specific types of certificates. > > > > It was pointed out that Microsoft already requires dedicated > > intermediates [1]. > > I agree with using dedicated intermediates, but I'd prefer that they should > not be required to be EKU constrained. > > > I would appreciate everyone's input on this topic. > > > > I suspect that it will be tempting to extend this discussion into > > intermediate rollover policies, but I would remind everyone of the > > prior inconclusive discussion on that topic [2]. > > > > This is: https://github.com/mozilla/pkipolicy/issues/26 > > > > [1] https://aka.ms/rootcert > > [2] > > https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM- > > TQ8/hgVsCofcAgAJ > > ------- > > > > This is a proposed update to Mozilla's root store policy for version 2.6. > > Please keep discussion in this group rather than on GitHub. Silence is > consent. > > > > Policy 2.5 (current version): > > https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
