3 ms·

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

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

schoen 9y 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.
- jamiesonbecker 9y 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.
pfg 9y 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.
- deleted 9y ago
  [deleted]

schoen 9y 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.

jamiesonbecker 9y 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.

pfg 9y 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.

deleted 9y ago
[deleted]