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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
