On 10/12/16 21:25, Brian Smith wrote: > 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.
Why would it have id-kp-serverAuth or id-kp-emailProtection and not have any names of those forms? > 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. Well, there are two responses to that. Firstly, no. The certs in scope are: "Intermediate certificates ... which are not technically constrained such that they are unable to issue working server or email certificates." If an intermediate certificate has an EKU with anyEKU, it is able to issue working server or email certificates. So it's in scope. (This utilises my use of "working" rather than "trusted", as noted in my previous email.) But secondly, I'm not banning the use of anyEKU, because Firefox doesn't trust cert chains that rely on it, so there's no need to ban it. Is there? Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
