I dunno why you say it isn't useful. It is inherently plaintext, but still worth authenticating. If you just used an AEAD but didn't put e.g. the session identifier or connection ID or sequence number in the AD, it would be entirely unauthenticated, but the decryption of, say, the message body would still succeed.
Yeah, but this also offers a clear exit opportunity (during the raise), and limits the "blast radius" to time-since-last-raise, rather than progress against the first four years of the company.
There is literally a code-signing working group in the CA/BF. However, the browsers don't really participate in it, since it's irrelevant to browsers. This is the entire point of moving to dedicated hierarchies per use-case---each PKI (web, code signing, etc) can evolve independently.
If they actually integrate this into randomness on their TLS servers, the only risk is that the system for getting the entropy from the lamps and waves somehow screws up, fails to parse an HTTP request or something, and accidentally seeds the whole system with no entropy. Whereas doing literally nothing and just letting Linux boot correctly on metal would be perfectly secure.
It's not clear to me that HTTP/3 is relevant to anyone who isn't already using it. It's most useful for large-scale hosting providers and video. And these people have already adopted it, and don't necessarily use out-of-the-box web servers for their infrastructure.
No, eIDAS 2.0 was an attempt to address the fact that the EU is not one market in ecommerce, because EU citizens don't like making cross-border orders. The approach to solving this was to attach identity information to sites, ala EV certificates. The idea for this model came from the trust model for digital document signatures in PDFs.
The main limitation is the incredibly opaque and brittle nature of putting keys in DNS.
We've spent a decade and a half slowly making the Web PKI more agile and more transparent by reducing key lifetimes, expanding automation support, and integrating certificate transparency.
The Tor service model is equivalent to if every site used a self-signed certificate, which doesn't scale.
The more feasible CA-free architecture is to have the browser operator perform domain validation and counter-sign every sites key, but that has other downsides and is arguably even less distributed.
Mozilla’s list is built to reflect the needs of Firefox users, which are not the same as the needs of most non-browser programs. The availability/compatibility vs security tradeoff is not the same.
Non-browser clients shouldn't be expected to crib browser trust decisions. Also, the (presumably?) default behavior for a non-browser client consuming a browser root store, but is unaware of the constraint behavior, is to not enforce the constraint. So they would effectively continue to trust the CA until it is fully removed, which is probably the correct decision anyway.
I'm with you, but the government (at least in the US and UK) should definitely be spending more time figuring out how to patch reliably, and little less on PQC.
I'd also add that the legality of law enforcement exploiting a server-side bug is much more of a gray area (or actually illegal), whereas there is a standard process for law enforcement or the intelligence community to get a court order that enables them to exploit devices that belong to a specific target (phone, laptop, etc).
If Government A and Government B are not equally "good" for the world, then the world is _not_ better off if everyone disclosed, since the main users of CNE are LE/IC.