Kyle,
I agree with much of what you wrote.
But a couple of areas of disagreement:1) The versioning problem of policy OIDs This is a Ryan's red herring. Firstly, a lot (and I'll take a guess at 50%) of the publicly trusted SSL certificates already have policy OIDs in them which indicate whether they are DV or OV. This has not made the sky fall. I don't think that standardizing the OIDs they use would make it fall either. Secondly, of user agents that are interested in the policy under which a certificate was issued, I suggest that there are more of them that find the distinction between DV and OV useful than there are that find the distinction between BR1.1.5 and BR1.1.6 to be useful. I understand that it is Mozilla's position that the OV/DV distinction is worthless and I note that position and disagree with it. It is not a position which is universally held outside Mozilla. This is, of course, a Mozilla security policy list, so perhaps I've just placed myself OT! I take your point that X.509 works best in a hyperspecified environment but, as you tangentially allude to, we do not live in a hyperspecified world. CAs have policies which are directed to some extent by such things as the WebTrust and ETSI standards, CABF BRs (which are themselves Certification Policies through the looking glass), and we have the NIST IR policy looming too, and all of these things are imperfect and subject to change, in the way of the world. I can see that capturing the exact version of every policy element and representing it in the certificate might be ideal but it seems an expensive ideal with relatively little practical use, and certainly not a plausible reason for failing to make more coarse-grained consistent policy statements. 2) ... the lack of an enforcement mechanism by a strong central enforcement body. I think you have to be careful what you wish for. The CABF's model is of consensus-driven policy making and offering the resultant policy to other parties (standards bodies & browsers) who can measure and enforce them and that lack of 'power' in the CABF certainly puts limits on what it can achieve, but I think creating a 'King of the (certification policy) World' who can set rules and meet out punishments for all PKI users is probably a step too far in the authoritarian direction. We know that a national authority could not take on that role and I think it might be hard to identify an international authority that was agreeable to all (or most) concerned. I can think of some entities that I think should not be the 'King of the (certification policy) World', but I can't see any contenders that might take the role on while having any chance of being trusted to do so. Did you have anyone in mind? Regards Robin Alden Comodo > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > [email protected]] On Behalf Of Kyle > Hamilton > Sent: 27 July 2014 02:01 > To: Robin Alden; [email protected] > Subject: Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate > Policy Identifiers) made mandatory. > > 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
