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.
NIT: The issue isn't whether it is technically capable of *issuing* a cert, but what certificates it issues are trusted by Firefox (or, more abstractly, TLS certificates trusted by a TLS client or email certificates trusted by an S/MIME-capable email client). In particular, I suggest replacing "unable to issue server or email certificates" with "unable to issue *trusted* server or email certificates" or similar. Cheers, Brian > Until we change Firefox to require id-kp-serverAuth, the policy will > define "capable" as "id-kp-serverAuth or no EKU". This would allow anyExtendedKeyUsage in a way that isn't what you intend, AFAICT. I suggest "without an EKU constraint that excludes id-kp-serverAuth." This suggested new wording doesn't explicitly allow anyExtendedKeyUsage to be used, not does it exclude a cert with anyExtendedKeyUsage from being in scope, but otherwise accomplishes the same thing. More generally, I suggest you use the wording in my latest message in the id-kp-serverAuth thread. In particular, id-kp-serverAuth doesn't apply to email certificates; id-kp-emailProtection does. Thus, you need to consider which EKU, which trust bit, and which types of names are relevant separately for email and TLS. Cheers, Brian _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
