On Fri, July 25, 2014 10:25 am, Robin Alden wrote: > That sounds like rot to me. > > You've portrayed the suggestion that Mozilla support a change so that a > CA would be required to more distinctly express it's policy (in the > matter of whether it considered the certificate DV, OV, EV) as an act of > the devil himself. > > It's a bit over the top. > > Robin
Because it's not DV, OV, EV It's DV 1.0, OV 1.0, EV 1.0 DV 1.1, OV 1.1, EV 1.1 DV 1.2, OV 1.2, EV 1.2 ... And then there's further permutations, if we get down to brass-tacks. It's now DV 1.2+Mozilla 2.1, OV 1.2+Mozilla 2.1, EV 1.2+Mozilla 2.1 But that's not quite sufficient now either, it's DV 1.2+Mozilla 2.1+Microsoft 9/2012 Of course, this staggering number of assertions isn't quite scalable in roots, so we fall back to anyPolicy. And for intermediates, it may have been *issued* under DV 1.2, but may have been *audited* under DV 1.4 (or DV 1.0). So which OID should it assert? Over time, the number of OIDs it's "valid" under scales as well. Unless this intermediate asserts the anyPolicy OID as well, it can't express the OIDs it's leafs expect. Don't get me wrong, I'd love to be able to programatically distinguish exactly what policies a given certificate claims to have been issued under, precisely because so many CAs have such liberal interpretations about things, it'd be nice to programatically detect violations of the BRs. That is, if BR 1.1.7 says the profile of a compliant certificate looks like X, and we see a certificate that doesn't look like X, is it a violation of the BRs? Right now, the data I have to go on is issuance date in relation to the CA's audit (and the type of audit used - e.g. which version of ETSI TS 102 042 did they use? Which version of WebTrust?), and that's a lot of painful work. But, at the end of the day, it's still more meaningful than a policy OID, since there are so many nuances that a single value "DV, OV, EV" doesn't express. To the point at hand, though, is if UAs can't and don't make any distinguishing marks between DV and OV - which, programatically, they don't, and from the security UX, such distinctions don't really matter - then it doesn't make sense to require CAs to disambiguate the two. Any security scheme that relies on the user manually inspecting something and confirming out of band that it's what they expect (and, among these, I count EV as a failed such experiment, because of the Same Origin Policy not treating it as distinct) is a bad security scheme. There's no need to pour that requirement on CAs if it's not actionable. Instead, I'd rather get them stop backdating certs and making reasonable progress on moving off SHA-1 :) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
