Comment by toast0
11 hours ago
WebPKI can't eject the bad actors that would cause trouble in DANE either. If your TLD conspires against you, they can certainly establish domain control and get a properly issued WebPKI cert.
Visibility through Certificate Transparency logs would at least make it a matter of record that it occurred, though.
The WebPKI semi-routinely kills certificate authorities. The point is that you can't kill a TLD operator.
> The point is that you can't kill a TLD operator.
I agree, you can't kill a TLD operator. But WebPKI relies on TLD operators to establish identity, so I don't see what we gain from WebPKI, other than mandatory CT logs, and not having to faff about with DNSSEC :P ... both of those are pretty valuable, of course.
I'll put it another way: why do we want a CA to tell us that someone controls a domain, when the TLD could tell us? The TLD is authoritative with regard to who controls a domain; CAs can only report on what they have observed.
Today's incident isn't a domain binding issue; it's a key mishandling issue. Elevating the role of TLD operators here just increases the number of organizations we have to trust to handle keys properly; worse, as we agree, those new keyholders can't have their authority revoked.
In the main, attacks on the DV process aren't protocol attacks; they're simple ATO attacks on registrars. The DV part of the WebPKI is certainly gross and could be improved, but evidence from the last 20 years says pretty clearly that the DV process itself is not the most urgent risk in the system.
My first hope is that we continue to ratchet security requirements for CAs upwards, and in doing so wash more and more incompetent operators out.
6 replies →