On 04/12/16 19:11, Brian Smith wrote: > If certificates without an EKU have dNSName or iPAddress subjectAltName > entries, then they should be considered in scope. Otherwise they don't need > to be considered in scope as long as Firefox doesn't use the Subject CN as > a dNSName. You've already started down the path of fixing the Subject CN > issue in https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 and maybe > elsewhere.
That would be an alternative way to do it. The problem is that if you try and do it this way, the issuing CA is always in scope for all its issuances, because whether the certs it issues have these features is inevitably a matter of CA policy, and could change at any time. Therefore, the issuing CA has to be run in a BR-compliant way all the time. Doing it based on the technical capabilities of the issuing CA allows us to say "we don't care about any certs this CA issues", rather than "we might care about some of the certs this CA has issued; we now have to find and examine them all to see". >> Requiring that every issuance under the publicly-trusted roots which is >> using no EKU and which is not intended for server auth change to use an >> EKU which explicitly does not include id-kp-serverAuth would have >> unknown ramifications of unknown size. > > This is a textbook instance of FUD. No; FUD is where someone raises uncertainties about a process or move where the ramifications are actually pretty certain. Is my statement false? Do you know what kind of impact it would have on the 60+ CAs in our root program to tell them that they have to reissue every intermediate in their publicly-trusted hierarchies to contain non-server-auth name constraints? > AFAICT almost all Mozilla software except for Firefox and Thunderbird, > would still trust the EKU-less certificates for id-kp-serverAuth. Thus > requiring an explicit id-kp-serverAuth in Firefox wouldn't even have the > intended ramifications for all of Mozilla's products. Are you talking about Firefox for iOS? Or something else? > Also, pretty much all non-Mozilla software is using RFC 5280 semantics > already. So, such a change wouldn't do anything to help non-Mozilla > software nor even all of Mozilla's products. Well, our policy doesn't take explicit account of non-Mozilla software :-) I want the scope of what our software trusts to match the scope of what our policy controls, and I want that united scope to both incorporate all or the vast majority of certificates people are actually using for server-auth, and to have clear and enforceable boundaries which are administratively convenient for CAs and us. I think requiring id-kp-serverAuth does that. Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
