On 05/12/16 12:43, Brian Smith wrote: > Let's consider the cases: > > A root CA: It is in scope if it has the SSL trust bit. > > An intermediate CA: It is in scope unless all the trusted certificates > issued for it have an EKU that excludes id-kp-serverAuth.
No; it's in scope unless it has constraints which prevent the issue of (or rather, the trust of) certificates which contain id-kp-serverAuth. > This is true regardless of whether you require an explicit id-kp-serverAuth > in the end-entity certificates, and/or if you base it on the subjectAltName > entries like I suggest, right? Because, at any time, the CA could issue an > end-entity certificate with id-kp-serverAuth in its EKU and/or a > certificate with a dNSName or iPAddress in its subjectAltNames. Right, so your initial formulation is not correct. It's in scope whether or not "all the trusted certificates issued for it [so far] have an EKU that excludes id-kp-serverAuth". > However, I do think that if a CA certificate is name constrained to not > allow any dNSName or iPAddress names, and/or it EKU that doesn't contain > id-kp-serverAuth, then it shouldn't be in scope of the proposal. Either > condition is sufficient. Are there not other relevant name types, such as svrName (or whatever it's called)? Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
