[tialaramex]

> is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever

So, the fun thing about historical claims is that you can do Science (insert sound effect) by assuming they're right to make a prediction from that baseline and comparing what actually happened against that prediction.

Moxie gave that talk in August 2010, hence the "DEF CON 19" background. So almost 16 years ago. Over that time of course there have been numerous incidents that would give you good cause to distrust companies such as DigiNotar, StartCom and Symantec. Moxie's prediction tells us that we were "stuck trusting them forever" but er... nope, DigiNotar went bankrupt, StartCom exists only as some branding for the (now distrusted) Chinese company which bought it, and Symantec "pivoted" away from the CA business and now exists largely as branding as well.

> I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.

This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.

[cyphar]

> Moxie's prediction tells us that we were "stuck trusting them forever" but er... nope, DigiNotar went bankrupt, StartCom exists only as some branding for the (now distrusted) Chinese company which bought it, and Symantec "pivoted" away from the CA business and now exists largely as branding as well.

Yes, he did say "forever" and (to borrow a phrase) nothing lasts forever so you do have a point there. But the original point still does stand, even in the modern world with a very active CAB, do you honestly think they would blacklist Lets Encrypt if they had some hack or violated some CAB policy that would normally result in expulsion? The fact that trust decisions are very hard to revoke (even though it is possible in practice) is still a problem with the design of PKI.

(It's also a little funny you didn't mention Comodo -- they are still kicking around, despite their history.)

> This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.

Yes, because that usage was the intended usage that is how the scheme must be interpreted. But that doesn't mean that it couldn't have been made to be interpreted differently -- in our modern world of short-lived certificates it would've been very easy to tweak it so that it would've allowed you to specify historical CAs during the (short) transition period.

The issue with CAA is that (as formulated) it is an incredibly weak protection mechanism -- it relies on CAs to obey it and if a CA gets hacked (or forced via legal threats) there is no mechanism for users to be protected from them issuing certificates for sites that did not wish for that. Google is well aware of this issue, which is why Chrome has proper CA certificate pinning but only for Google-owned domains. Non-Google website owners have no access to a similar mechanism, and even if CAA was not as good as some theoretical alternative, for the vast majority of websites it would be a strict improvement if clients validated against CAA -- which is why I'm disappointed that it is explicitly not permitted with MUST NOT (not even a SHOULD NOT -- which is a stance I would understand).

[tialaramex]

I'm not sure you could consider Let's Encrypt "too big to fail" but if you can it seems like Moxie's position doesn't help? The "too big to fail" afflicts basically everybody in that case.

Comodo / Sectigo is actually useful to illustrate how these decisions are made because we actually care whether you can stop having problems. Think like air safety or medical safety. Things go wrong, our job is to avoid scenarios where they keep going wrong for the same reasons. The first guy who trips and plummets off a bridge into the river below is enough, OK, yeah, barriers, we need to prevent you accidentally falling off the bridge. When you build the next bridge and somebody falls off because you didn't add barriers now that's a failure to learn and do better.

Outfits like StartCom and Symantec the problem wasn't "A thing went wrong" it was "Things kept going wrong and either you lied to us about preventing them, or you're incompetent and your attempts failed utterly". There are a lot of boring "Brown M&M" record keeping steps, and for WoSign and Symantec the evidence available strongly suggested they were deliberately lying to us, but even if they weren't lying they were spectacularly incompetent, and that's not OK. As I've explained previously I strongly prefer to not care whether you're incompetent or lying, I want either explanation to have the same consequences.

If we thought there was a problem with Let's Encrypt and it must be distrusted I think a transition plan like for Symantec is a lot more plausible than the sort of "Everybody makes their own correct decisions" fantasy Moxie promoted which, frankly, I think sounds like Libertarian claptrap. Such an approach requires that almost everybody cares and that's just not true about anything at all.

> But that doesn't mean that it couldn't have been made to be interpreted differently

But now you're talking about a different protocol. Feel free to go design your own protocol, like Moxie's. I doubt yours will fare better than his did, but "Why didn't everybody else focus on my preferences?" is silly.