On Mon, October 27, 2014 12:14 am, John Nagle wrote: > (Resend, after error "The message could not be delivered to the > following recipient:") > Here's a nice example of Mozilla not fully understanding Organization > information in certificates: "www.facebook.com". > > Firefox says, for "https://www.facebook.com";, > > "This web site does not supply ownership information". > > But, in fact, not only does it supply ownership information > (the Subject contains O, L, ST, and C), DigiCert, which generated > the certificate, promises in their CPS that the info is valid. DigiCert > attached Policy OID 2.16.840.1.114412.1.1, promising > valid organization data. > > Remember, there are three levels of certs now: DV, OV, and EV. > The CA/Browser Forum has established (finally) standard policy > OIDs for them, but these are still optional. They are > > OID 2.23.140.1.2.1 - DV (domain validated only) > OID 2.23.140.1.2.2 - OV (organization validated) > OID 2.23.140.1.1 - EV (extended validation) > > These standard Policy OIDs are relatively new, though, and not > widely used yet. > > Originally, each CA had its very own EV Policy OID. > (There's a list in Wikipedia, painfully put together.) > > Without much notice, the same thing was done for > OV certs. DigiCert's Certification Practice Statement > (https://www.digicert.com/docs/cps/DigiCert_CP_v406-May-14-2014.pdf) > lists the values DigiCert uses. > > OID 2.16.840.1.114412.1.2 - DV (DomainâValidated SSL) > OID 2.16.840.1.114412.1.1 - OV (OrganizationallyâValidated SSL) > OID 2.16.840.1.11441 - EV (Extended Validation SSL Certificates) > > These are in wide use; I'm finding lots of them in the certificate > dumps. (Does anyone have the full list? Is there any reason not > to make it public? The info is in the Certification Practice > Statements of each CA.) > > Firefox understands the EV values for each CA, but not, apparently, > the OV values. That, I think, is a bug. One which affects > high-profile sites. > > John Nagle > SiteTruth > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy >
John, I'm sorry, but you're overstating the value of OV, which is not something that any browser recognizes, nor is it, as you suggest, something standardized by the CA/Browser Forum. The CA/Browser Forum does state how the O field should contain, *IF* present, along with several other *optional* fields, but these are neither strong requirements nor are they mandatory in the same sense that EV is. Mozilla's position on OV is well documented - the "bug" you described is INVALID WONTFIX. You know this, because you've participated in past discussions - https://groups.google.com/d/msg/mozilla.dev.security.policy/al0GUnprZuI/3e28Iv08WdAJ , but it's also been discussed at https://groups.google.com/d/msg/mozilla.dev.security.policy/al0GUnprZuI/3e28Iv08WdAJ , https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/hEOQK-ubGRcJ . This was also affirmed again by Mozilla (and other browsers) during the most recent China CA/Browser Forum F2F (unfortunately, the minutes have not been posted yet, AFAICT). I would say Mozilla understands very well what the organization information is, how it's vetted, and why that information is not meaningfully worthwhile to communicate to users as an effective security measure. In a world where "EV" provides no positive technical security benefits (due to the same origin policy), it would be a pretty nasty mistake to think "OV" (which does not formally exist as a consistent standard as it does either EV or DV) provides some actionable value. I suspect that you will continue to have issue with certain policy decisions, as it seems you are opposed to DV. That's unfortunate, because DV is the single-largest driver for SSL/TLS, and rightfully so. That is, a certificate exists as a binding between a key and a domain. Whether that domain is operated by a CDN such as CloudFlare, a hosting service such as AWS, Azure, or Appspot, a user with a shared server, a user with a VPS, or a user with a dedicated server is irrelevant, and neither misleading nor wrong for the browser to express a secure icon regardless. Multi-san certs are perfectly compliant with the BRs, as are wildcard certs, and both are extremely important to encouraging the adoption of TLS. If you're trusting certificates to assert information about either the identity of the entity behind the key or that the CA has done due diligence, well, you're using certificates for something they're neither intended for nor well suited for, so you'll have a bad time. Cheers, Ryan _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
