undefined | Better HN

0 pointsschoen8y ago0 comments

> (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-...

0 comments

4 comments · 1 top-level

jamiesonbecker8y ago· 3 in thread

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 ;)

pfg8y ago

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.

1 more reply

schoenOP8y ago

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.

jamiesonbecker8y ago

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.

j / k navigate · click thread line to collapse