Except when CAs don't make the assertion themselves. We've already been over the fact that "intended for use in SSL" is so ambiguous that the BRs don't provide assurances over what the CA does. The OIDs are an assertion that the cert is intended for use in SSL. You can tell which BR version the cert complies with by looking at the issuance date, similar to how Google plans to whitelist certs for CT and how we are phased-in BR compliance.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Ryan Sleevi Sent: Friday, July 25, 2014 9:59 AM 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
