[xg15]

What I don't quite get with all the certificate automation: Doesn't this all effectively just shift the "source of truth" to DNS?

Back when certificates were issued manually, a CA was also verifying that the requesting party was actually who they were claimed to be IRL - hence EV certificates and all that.

What LE and friends verify on the other hand is simply that the entity that requests a certificate also controls the DNS entry at that point in time - or at least controls some of the servers that are listed in the A/AAAA records.

For one of the infamous Authoritarian Governments, it should be no problem at all to obtain an LE certificate for any domain under their ccTLD. Just use the DNS challenge, then instruct the country's registrar to change the DNS record for the domain of interest.

Isn't that a massive centralisation compared to the old system?

[tialaramex]

> Back when certificates were issued manually, a CA was also verifying that the requesting party was actually who they were claimed to be IRL

I see. For say, the Bank of America, how did you imagine this working? The CA maybe has a guy fly to BoA headquarters, meet up with the CEO and chairman, and then sign off on the certificate? Wait, one guy isn't really much assurance is it. So I guess they'd need a whole team of people to be sure, jetting around the world, meeting up with the senior leadership of companies and checking their bonafides.

Do I need to tell you it wasn't actually like that?

> hence EV certificates and all that.

EV comes into existence as part of a deal between the Certificate Authorities and the Browser vendors back when desktop PCs were very important. They each want different things, and the resulting compromise leads to the Baseline Requirements and the CA/B Forum.

What the browsers want, and get, is actual validation for all certificates. I know, that sounds like a low bar, but that's how bad things had gotten. The CA/B BRs don't initially even specify how the validation should work, that takes until the "Ten Blessed Methods" a few years ago.

What the CAs want, and get, is desktop browser UI dressing that makes their most expensive certificates look cool under the name "Extended Validation". The browsers can't and don't promise this is a good idea, but it keeps CA bottom lines healthy which is important to them as markets open up and prices fall.

Now it turns out that the CA/B and BRs are a useful ratchet on overall validation and security practices and, probably, overall this benefits the Browsers (who by now are effectively the OS vendors, with Mozilla standing in for the Free Unixes) more than the CAs. But arguably it also benefits the CAs because with weak validation the whole thing is useless, and they go out of business anyway.

[xg15]

> The CA maybe has a guy fly to BoA headquarters, meet up with the CEO and chairman, and then sign off on the certificate?

I assume the BoA doesn't require their CEO to personally meet with every subcontractor that BoA gets into a business relationship with. You have employees for that?

Why would working with a CA be any different then, say, hiring an attorney or opening a bank account?

[tialaramex]

Well this is a fun game though isn't it. If a firm of lawyers sues you "on behalf of Bank of America", at what point do you feel like they didn't check properly who their client was and so they are responsible for the bogus lawsuit and the resulting costs not this enormous corporation?

If only the manager of a local BoA branch told them they were hired?

How about if it's an assistant manager?

How about if rather than meeting them in the branch, the supposed assistant manager was in the area and so dropped in to the law office in person?

The attorneys weren't available, so, they did a Zoom call?

Just a phone call?

Actually it was an email.

At some point, you realise, wait, they didn't actually validate anything of value here did they, anybody could be this supposed "Bank of America". And the reality is that PKIX certificates began that slide essentially immediately, before even the PKIX working group was set up.

And this is only half of the problem. It's easy for Bank of America because we're both thinking of the same entity, but "Big Bob's" might be a burger restaurant in your city, a private security firm in mine, and an LA law firm, so a certificate for "Big Bob's" doesn't even "validate" a name we're agreed on. That's why DNS ends up mattering, the DNS offers a single global namespace.

[xg15]

Come on, that's not how it works. There are specific, well-defined circumstances that define what a particular legal entity (such as a company or a corporation) is and who may or may not act on its behalf.

Otherwise, any kind of company could escape responsibility by simply pretending it doesn't exist and every employee just acted on their own.

[tialaramex]

But which one is "not how it works" ?

As I said, for the DNS validation we actually have pretty specific technical rules today, the "Ten Blessed Methods" (well, their modern successors) which is why we're talking about one of those methods here (tls-alpn-01 is method 3.2.2.4.20)

Today there are rules for EV but they're understandably vague, because they're talking about the problem we addressed above, eventually they get down this idea of a "Principal Individual" which can include "an employee" who is merely "authorised to conduct business" on behalf of (in our example) Bank of America and of course you're back to square one. How can we know they're authorised ?

The trick in the DNS validation is that we're asking a question machines could potentially have an authoritative answer to. Does this applicant control this DNS name. Not "Should they?". Not to "Are they authorised?" but specifically do they control it.

The non-DNS validation can't do that.

[Genbox]

You are right. The EV validation process (I am EV validated at 3 major authorities) does involve sending paystubs, identification with photos and an interview.

Let's Encrypt is not a solution for trust. It is an attempt at getting as many people to adopt HTTPS as possible. There used to be 3-4 free certificate authorities which all had their problems (processes, security, uptime etc.) and Lets Encrypt is outperforming them all.

We still need to understand issues around identity, which can only be solved with verification and trust. X509 is encryption keys + trust and LE has much weaker trust guarantee than an EV.

[pgporada]

What is the trust guarantee that an EV cert provides me?

[jfindley]

Absolutely none. It's great for issuers as they get to charge a bunch more money to provide you with exactly zero extra security, which is why some of them try to pretend there's a purpose. There is not. Even the old (ridiculous) argument about user trust doesn't work anymore as browsers have no meaningful display difference these days between normal and EV certs.

[Genbox]

I can totally understand your frustration. It is way too expensive for certificates and costs have gone off the rails.

Yes, browsers have removed the green trust bar.

Yes, ordinary users have to click on small buttons and manually check against different conventions used by CAs (naming, extensions, OID variants).

However, saying that EV provides no extra security not entirely true. At least if we look outside the end-users of a website.

It is also used for: - High security applications that have to ensure their services are trustworthy - As confidence/trust factors in cyber threat intelligence (if you don't want to get blocked on a false positive, EV is your friend) - In domain name research when trying to establish ownership - In machine learning models as an indicator of verifiable trust - Protects against website copying used in phishing campaigns

I'm focusing on HTTPS here as EV is much more relevant in PKI systems.

EV should be affordable, relevant, have good UX and provide identity security for end-users of browsers, but it is not. Until that changes, most website owners should not buy it.

[Genbox]

How would you otherwise know that xoom.com is really PayPal?

I believe it is PayPal because DigiCert say it is (with EV). That is much better than no validation - which is the default.

Domains are not identities. They are a reference to an organization. PayPal owns more than 100 domains. Not only did DigiCert validate the organisation through various procedures (e-mail, paystub, id), but the validation is also asserted through a X500 name, which is cryptographically signed in the X509 certificate. So there is no way for others to spoof the identity.

Attackers can easily copy the HTML/CSS/JS the website to look and feel exactly like PayPal. Then they can go to Lets Encrypt and get a certificate, which offers no assertion on their identity, other than "Attackers own the domain paypal.xom.com" (a domain they purchased to spoof PayPal).

In that case, the EV certificate is the _only_ way you can check if it is really PayPal.

[tialaramex]

If you actually read the EV certificate, you might be able to reasonably tie what you learned to a DNS name, which is what really matters for the circumstances where you're using TLS, as we'll see in a minute:

The Certificate can tell you the identity of a legal entity which the CA made some reasonable attempt to verify wanted to set in stone the association between their identity and the DNS names listed (and also a key but don't worry about that). You should examine not only the name of that entity, but also the country or locality in which it claims to exist (this may be a tax haven) and its ID# in that country or locality's records, such as tax records, which may enable you to distinguish it from other entities with similar (or in some cases the same) names. The latter is in a certificate element labelled "serial number" but is the serial number of the subject entity not the certificate's serial number, which today is mostly a large random number of no importance (it is serving as a cryptographic nonce but you don't need to care about that)

Anyway, once you've carefully examined these details, and determined which entity you've got a certificate for, like I said the main value is that it tells you the DNS names associated.

Almost all the software tools you use, such as a web browser don't care about any of that stuff, but they do care about DNS names. So transactions e.g. following an HTTP redirect which are done silently and automatically by the browser, won't care that this is (or is not) a EV certificate at all, but they do check the DNS names on a certificate.

So if you're able to determine from the certificate that mybank.example really is run by My Bank Inc. the bank you've got money in, that's a valid use for EV, but your browser doesn't care whether the HTTPS server it talks to shows it that EV certificate (or any other EV certificate) during HTTPS transactions, only whether the DNS names are right. It would not for example, stop during a 30x redirect and say "Oh! This is a 30x redirect from mybank.example but it didn't present that EV certificate you checked, maybe it's an imposter?" that 30x redirect is fine, the certificate was fine, and you'll never see it at all, it will never be shown to you, your data was transmitted long before you had a chance to have an opinion anyway so who cares.

[r1ch]

That "manual verification" back in the day was an email verification link, so again, back to relying on DNS. I don't think there's a way around it, but at least with certificate transparency we'll know if it happens.

[discreditable]

It was always DNS. Unless you are getting EV the CAs usually verify ownership via email. Email can go anywhere the current MX record in DNS says it goes.

[LeonM]

This is why for EVs most CAs also do phone validation.

For stuff like Verified Mark Certificates (which is used for BIMI), it goes much further than that. VMCs are like EVs on steroids.

HN crowd can sometimes react very hostile towards having to pay anything at all for certificates, but there are real costs in such validations.