Hacker News Reader

> (Of course, with DV certs being treated the same as OV certs, someone with a DV cert could just forge all of the metadata, as long as they control the domain; DV CA's don't verify the metadata, by definition.)

The Baseline Requirements require certificate authorities to be able to verify the correctness of the information that they include in each certificate -- including for DV. See the first subsections of section 3.2.2 of

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...

Good link, but you should read it more carefully. That metadata (i.e., Organization) is only verified if the certificate is purchased for that purpose. In other words, would you like us to do extra organization validation? pay more. otherwise, it's cheaper if we only validate the domain.

It's kind of crazy, actually: it's more expensive for you to prove who you are than it is for the attacker to NOT prove who they are. Security should be about raising costs for the attacker, not lowering them!

And, as you know, neither Let's Encrypt or any other DV CA's check or verify any information except control of the domain itself.

That's why those certs are called Domain Validated instead of Org Validated ;)

This is not what the Baseline Requirements state and it's also not how issuance works in practice. The validation requirements for things like "Organization" always apply "[if] the Applicant requests a Certificate that will contain the countryName field and other Subject Identity Information."

If you submit a CSR with any of these fields, and you're requesting a DV certificate, the CA will discard those fields. Any sane CA implementation will cherry-pick only a whitelisted set of fields from the CSR, make sure the values have been validated according to the Baseline Requirements and root policies, assemble the certificate from that data and sign the result, ignoring all other fields (or discarding the request).

CAs that run something like sign(user_submitted_csr) would not last long in any of the major root programs.

The BRs don't have any requirements about charging or not charging applicants money for certification functions, and I don't see an exemption allowing unverified information to be included in a certificate if the applicant isn't charged for it.

It looks like you were speaking to my comment above regarding forging details, and now I see what you're saying (that a DV provider like LE will just discard extra details or reject cert, rather then signing them). Thanks for the correction.

The broader point is that whether that metadata is visible or not is what renders the OV to be the same literal value as a DV; even to a security-minded audience, an OV provides literally no extra value over a DV to the website's audience/customers, because it's effectively invisible. And EV does, on some browsers, but the positive benefits of EV are diminishing.

And because OV ~ DV to its users, the security value of OV over DV is nil; they are interchangeable for the purposes of protecting a website.

They might have more value, depending on the app, on other protocols, but for HTTPS, browsers have effectively rendered them identical.

> (Of course, with DV certs being treated the same as OV certs, someone with a DV cert could just forge all of the metadata, as long as they control the domain; DV CA's don't verify the metadata, by definition.)

I don't know if every DV CA does this, but I got a couple of StartSSL's free certs a while back (before LE was around, and before the WoSign acquisition and subsequent debacle), and I recall the documentation saying "because this is a DV cert, we're just going to ignore all the metadata in your CSR and generate a certificate with those fields blank", or something along those lines.

>the only thing they've got to hold onto now is EV, and that's of diminishing value now as well.

Value in terms of cost, or in terms of utility? And if the latter, care to explain why? I know almost nothing on the business/political side of certificates.

Just pointing out that browsers are de-emphasizing the "green bar" (and, on mobile, almost non-existent), so it's of decreasing visibility/value to the website customer (and also the certificate purchaser).