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 <[email protected]>; mozilla-dev-security-policy <[email protected]> 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- > [email protected]] 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- > [email protected]> > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
