Robin (and everyone), I'm not so sure it's over the top. The fact is, CAs essentially try to do this by issuing through particular certification paths, but expect everyone to have already taken the time to reach out and individually engage with their CAs and read their policies and figure out how to interpret them.
And, I've seen (though cannot find the specific examples enough to cite or name names) Class 1 (DV) certificates issued from Class 3 issuers. So, simply relying on the certification path has been broken by the action "of the devil himself", as you so eloquently put it. X.509 works best in a hyperspecified environment. It doesn't work well on the open Internet, partly because of the confusion as to how to deal with the various policies. It doesn't work well on the open Internet because there's no standardization of what various terms even mean, and there is no means to mandate the use or lack of use of any given client with any given version of a standard it accepts. And it doesn't even support versioning well -- as Ryan Sleevi points out with the statement "the idea that a single OID is suitable for this is laughable". If Mozilla had actually created its own cross-certification CA, we would have had cross-certificates from Mozilla to its root program member CAs that included policy mapping. Thus, we would have already had this as a fait accompli, at least with EV. We would have been able to do policy lookups with the information that Mozilla made available as part of its cross-certificates and known whether Mozilla considered it acceptable for EV treatment without having to have a blessed table built into every last Firefox release. But no, Mozilla didn't want to. Mozilla didn't want to put together anything that would have provided instant unilateral CA suspension (via OCSP lookup pushed to the edges of its CDN), or policy mapping lookups, or anything that would have been helpful in advancing the state of the interface as an experimental matter. It was "good enough", and so it decided that it wasn't going to make it any better. Since we can't rely on Mozilla (an organization that's supposed to be doing good) to do this kind of thing (remember that Mozilla hasn't even tried to differentiate between DV and OV in its interface), the only other option we have is to request that the CAs make these assertions in an unvetted, unauditable manner. Remember that CAs don't just create products for Mozilla to consume, there are all sorts of other potential consumers that are frankly left in the cold because of this cancerous multilateral symbiosis. But if I'm going to wish for a unicorn, I might as well also express what I want to see. 1) I want CABF (not IETF, and not Mozilla) to be the owner of these new policy OIDs, and I want them well-specified to the same degree (but not necessarily to the same contours) that ANSI X9 specified Classes 1, 2, 3, and 4. 2) I want these new policy OIDs trademarked and/or servicemarked, with unilateral contracts for member and non-member usage. 3) I want usage guidelines for these new policy OIDs, both for how software should interpret them and as prescriptions for anyone else making use of them. 4) I want CABF to aggressively pursue action against anyone who improperly uses them. But none of it will ever happen. There's no chance at all that CABF members will put any enforcement mechanism in place, be it either for CABF's own membership or anyone else. This is what libertarianism leads to: lack of a strong central enforcement body, and lack of effective and enforceable regulation, so everyone who's not part of the group must duplicate resource spending to get something that doesn't work as well. THIS is the reason, beyond all others, that nobody seriously believes that the CAs or the browsers have any capacity to further the goals of strong Internet authentication. They're too busy with their own politicking, the same way IETF has become, and there's no way to expand their horizons to see what damage they're actually doing to the world at large because of their myopia in their own political shell game. -Kyle H On 7/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 > > >> -----Original Message----- >> From: dev-security-policy [mailto:dev-security-policy- >> [email protected]] On Behalf Of Ryan Sleevi >> Sent: 25 July 2014 16:59 >> To: [email protected] >> Cc: [email protected] >> Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved > Certificate >> Policy Identifiers) made mandatory. >> >> On Thu, July 24, 2014 8:59 pm, [email protected] wrote: >>> So, based off of the comments that have been made, please can >> Mozilla >>> support such a change? >>> >>> If not, what would Mozilla's objections be that are in scope to the >>> question/issue? Presently, none appear to have been articulated. >>> >>> The immediate benefit to Mozilla would be consistency and >> conformity >>> among the OV certificates that get issued. This is because, as > Jeremy >>> mentions, they will be bound by the requirements that inclusion of >>> the OID brings as it is an assertion of compliance. >> This is a tautology. There is no benefit except consistency, and there > is >> no benefit to consistency. >> >> There is no need for an assertion of compliance - CA's make those >> assertions themselves. >> >> Further, the idea that a single OID is suitable for this is laughable, > in as >> much because there's no "single" version of the BRs that's fixed and >> immutable. >> >> As you can see from https://cabforum.org/baseline-requirements- >> documents/ >> , there are many versions. What you, minimally, want if you wish to >> programatically express some value (and if it's not programatically >> expressible, then there's no way there's value in manual inspection, >> since there's no algorithm that people can use), is that the exact > version >> of conformance to the BRs is expressed in the cert. >> >>> As has been said but probably needs to be reiterated, we all need > to >>> be careful not to conflate, confuse and overload the issue with the >>> entirely separate and distinct questions that surround handling of >>> the certificate in code and what appropriate UX is. These are > clearly >>> far more contentious, perhaps political in nature, and should be >>> considered and discussed independently to this. >> I think we need to be careful in suggesting arbitrary and capricious >> requirements that fail to move the security needle further in a > particular >> direction. >> >> Do I wish everyone would include the u in favourite and colour? Sure. > Do >> I think it should be mandatory to get a secure UI? No. >> >> What's still missing is an articulation of value beyond the mere value > of >> consistency (which itself is not met). >> >> And, of course, let's not forget that it would require CAs to re-do > their >> entire cert hierarchy - policy OIDs flow down from the root; this is, > for >> example, how EV is validated. Requiring this would require redoing the >> cert hierarchy semi-regularly, and would still fail to accomplish the > goals >> the next time a new version of the BRs that tangibly altered the >> requirements came out and a new OID had to be assigned. >> >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy >> >> >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
