Ryan Hurst wrote a blog post on this very topic not too long ago. His conclusion was that determining, programmatically, the difference was difficult. See http://unmitigatedrisk.com/?p=203.
This is mostly because there are some certs that still include a domain in the org field. Requiring a BR OID serves two purposes - 1) the OID is a positive assertion to the browser by the CA that the cert was issued under the BRs and intended for SSL and 2) the OID identifies the sections relied on for validation. The OID assists in auditing whether a CA is aware of its practices and how it is choosing to comply with the BRs. Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Robin Alden Sent: Wednesday, July 23, 2014 8:02 AM To: 'Gervase Markham'; [email protected]; [email protected] Subject: RE: [SPAM] Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory. > On 23/07/14 10:06, [email protected] wrote: > > The status quo today means that it is not possible to discriminate > > programatically between a DV and OV certificate in a standardized, > > reliable way. > Gerv said.. > This is because Mozilla's position is that, in security terms, there is no > relevant difference. > That is not the reason. That may be a contributory reason to Mozilla not proposing or supporting the proposition of language to change the BR's 9.3.1 which result in it not being compulsory to include a mandated policy OID in a certificate which would identify it unequivocally as being a DV or an OV certificate, but it is not the definitive reason why the BRs do not mandate it. If the BRs already mandated it I would not expect your opinion or your UI to change, but the OP's question would not have arisen as he would have easily programmatically been able to tell whether a certificate was OV or DV. > > This is unreasonable as the validation and assurance on such > > certificates are very different. > > They are different, but not in a way that is reasonably measurable and > auditable. > <snip> > > If a cert does not meet the EV standards for information validation, we > feel you cannot sufficiently trust the O field, and therefore from a > security perspective there is no difference between that certificate and > one where the O field is absent. Hence we make no UI distinction > between OV and DV. > Whilst I disagree with your sentiment, in your UI (browser, certificate viewer, mail client, etc.) it's your game, so it's your rules. The compulsory inclusion of a Policy Identifier OID in the certificate definitively stating DV or OV need not offend you, since you will probably continue to ignore it. As to the issue which presumably ignited the thread in the first place, I think that for a non-EV BR compliant certificate you probably can distinguish programmatically between OV and DV. According to section 9.2.4 of the BRs, if the certificate subject contains an organizationName field and also contains one or both of (stateOrProvinceName and localityName) then it is an OV certificate. If the certificate subject does not contain an organizationName field then it is an OV certificate. This begs the question of whether the certificate is claiming to be an EV certificate or claiming to be BR compliant. Regards Robin Alden Comodo _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
