[peterwwillis]

And if a non-authorized CA ignores it and creates a cert anyway, that cert will still work. It's basically a kind of robots.txt file for CAs.

I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

[bdamm]

It turns out that making someone's job easier is in fact the foundation of good security.

One way this is true is that people won't use security if it isn't usable or easy to use. For almost two decades we had CA workflows that sucked. Certificate use has spiked in the last couple of years. Why? Witness the outstanding work by LetsEncrypt which is now allowing Chrome to flag insecure login forms.

Other examples; DDoS defense as a service, facial recognition that unlocks your phone every time you pick it up, cars that lock when driving, and fobs that make passwords almost irrelevant.

Good security and making someone's job easier are one and the same.

[jacobparker]

No, it's still about security, in a defense-in-depth sense. Even if your trusting CA's in this context they all count as attack surface: CAA helps minimize it. For example, it's possible that a CA's validation process has a flaw. A CAA record may isolate you from that.

Even the "corporate policies" is a security thing, not "making someone's job easier". Presumably Facebook handles their certificates carefully: if any engineer could obtain certificates the odds that they would and that the certificates would be passed around in email attachments is 100%.

[dcbadacd]

Speaking of defense-in-depth. I don't understand why do certificates released by public CAs not add an extension to the cert if the cert was given to a DNSSEC validated host.

As browsers are unwilling to validate DNSSEC directly it would allow browsers to just check the certificate. This could be complemented with a relevant HTTP header that forces the browser to only accept the certificate if it has been given out to DNSSEC validated host.

[shittyadmin]

> I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, auditable log of every certificate officially issued could can be used to validate certs, Chrome enforces this with new EV certs and Symantec certs.

[peterwwillis]

We still have to depend on CAs to 'follow the rules', and the client has to support it (does your mail client verify Cert Transparency? does your backend microservice?) and be connected to the Internet, and Google, etc.

There are better ways to handle it, I think, but they may involve changing how we both sign and verify certs.

[hannob]

> Chrome enforces this with new EV certs and Symantec certs.

Chrome enforces this for all new certs since earlier this year.

[tialaramex]

More specifically: Log servers can be shown either a normal X.509 certificate or a "pre-certificate" which is proof that a Certificate Authority intends or intended to issue some particular certificate. Right now these are actually X.509 certs that were "poisoned" to make them useless, but in future they will probably be some other format.

Anyway, when shown a new certificate or pre-certificate, the log server gives you a Signed Certificate Timestamp proving when it saw the document.

Chrome (and eventually Safari and Firefox) require suitable SCTs when shown any modern public certificate or they may conclude the certificate should not exist and fail the connection or mark it insecure, or even report it to Google/ Apple/ Mozilla for investigation.

SCTs get to the browser in one of three ways:

1. Most popular. The site's CA made pre-certificates, logged those, got back SCTs and baked the SCTs inside the real certificate. This changes nothing for a site operator, if you use Let's Encrypt and have never heard of SCTs, don't worry, all your current Let's Encrypt certs are done this way.

2. Less popular: The CA doesn't put SCTs inside the certificate, but it DOES staple them inside OCSP responses. Then you staple an OCSP response into your certificate responses and everything works.

3. Also less popular: The SCTs go in a separate TLS extension when a client connects, saying "Hey, I want SCTs" and they get them back only if they ask for them.

[detaro]

And if it is a publicly trusted CA, it now gets to explain to browser and OS vendors how it managed to fail to comply with a required policy. (although there's of course difficulty in proving that a DNS entry existed)