On Thu, Dec 8, 2016 at 10:46 AM, Gervase Markham <[email protected]> wrote: > We want to change the policy to make it clear that whether a cert is > covered by our policy or not is dependent on whether it is technically > capable of issuing server certs, not whether it is intended by the CA > for issuing server certs.
I'll quote part of the proposed change here: > 2. Intermediate certificates which have at least one valid, unrevoked chain up > to such a CA certificate and which are not technically constrained such > that they are unable to issue server or email certificates. Such technical > constraints could consist of either: > * an Extended Key Usage (EKU) extension which does not contain either of the > id-kp-serverAuth and id-kp-emailProtection EKUs; or: > * name constraints which do not allow SANs of any of the following types: > dNSName, iPAddress, SRVName, rfc822Name > > 3. End-entity certificates which have at least one valid, unrevoked chain up > to > such a CA certificate through intermediate certificates which are all in > scope, such end-entity certificates having either: > * an Extended Key Usage (EKU) extension which contains one or more of the > id-kp-serverAuth and id-kp-emailProtection EKUs; or: > * no EKU extension. Again, it doesn't make sense to say that the forms of names matter for name constraints, but don't matter for end-entity certificates. If an end-entity certificate doesn't contain any names of the forms dNSName, iPAddress, SRVName, rfc822Name, then it shouldn't be in scope. Also, the way that the text is worded the above means that an intermediate certificate that contains anyExtendedKeyUsage in its EKU would be considered out of scope of Mozilla's policy. However, you need to have such certificates be in scope so that you can forbid them from using anyExtendedKeyUsage. Cheers, Brian -- https://briansmith.org/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
