As a practical matter, revocation on the Web is handled mostly by centrally distributed revocation lists (CRLsets, CRLite, etc. [0]), so all you really need is:

(1) A PQ-secure way of getting the CRLs to the browser vendors. (2) a PQ-secure update channel.

Neither of these require broad scale deployment.

However, the more serious problem is that if you have a setting where most servers do not have PQ certificates, then disabling the non-PQ certificates means that lots of servers can't do secure connections at all. This obviously causes a lot of breakage and, depending on the actual vulnerability of the non-PQ algorithms, might not be good for security either, especially if people fall back to insecure HTTP.

See: https://educatedguesswork.org/posts/pq-emergency/ and https://www.chromium.org/Home/chromium-security/post-quantum...

[0] The situation is worse for Apple.

Indeed, in an open system like the WebPKI it's fine in theory to only make the central authority PQ, but then you have the ecosystem adoption issue. In a closed system, you don't have the adoption issue, but the benefit to making only the central authority PQ is likely to be a lot smaller, because it might actually be the only authority. In both cases, you need to start moving now and gain little from trying to time the switchover.

> In both cases, you need to start moving now and gain little from trying to time the switchover.

There are a number of "you"s here, including:

- The SDOs specifying the algorithms (IETF mostly)

- CABF adding the algorithms to the Baseline Requirements so they can be used in the WebPKI

- The HSM vendors adding support for the algorithms

- CAs adding PQ roots

- Browsers accepting them

- Sites deploying them

This is a very long supply line and the earlier players do indeed need to make progress. I'm less sure how helpful it is for individual sites to add PQ certificates right now. As long as clients will still accept non-PQ algorithms for those sites, there isn't much security benefit so most of what you are doing is getting some experience for when you really need it. There are obvious performance reasons not to actually have most of your handshakes use PQ certificates until you really have to.

Yeah, that's an audience mismatch, this article is for "us." End users of cryptography, including website operators and passkey users (https://news.ycombinator.com/item?id=47664744) can't do much right now, because "we" still need to finish our side.

If your HSM vendor isn't actively working on/have a release date for GA PQ, you should probably get a new vendor.

I do not understand the fixation on authentication/signatures. They have different threat characteristics:

You cannot retroactively forge historical authentication sessions, and future forgery ability does not compromise past data, and it only matters for long-lived signed artifacts (certificates, legal documents, etc.), yet the thread apparently keeps pivoting to signature deployment complexity?

I do not get it.

The argument is that deploying PQ-authentication mechanisms takes time. If the authenticity of some connections (firmware signatures, etc…) is critical to you and news comes out that (")cheap(") quantum attacks are going to materialize in six months, but you need at least twelve months to migrate, you are screwed.

There is also a difference between closed ecosystems and systems that are composed of components by many different vendors and suppliers. If you are Google, securing the connection between data centers on different continents requires only trivial coordination. If you are an industrial IoT operator, you require dozens of suppliers to flock around a shared solution. And for comparison, in the space of operation technology ("OT"), there are still operators that choose RSA for new setups, because that is what they know best. Change happens in a glacial pace there.

You can't do software updates securely, but it strikes me that compromising the revocation process is a good thing. Suppose you can use a key to sign a message saying "stop using this". If someone else breaks that key and falsely signs that message, what are the downsides?

You revoke a cert because you lose control of it; if someone else can falsely revoke that cert, doesn't that truthfully send the exact same signal? That you lose control of it?

Can you explain a bit more what you mean by "secure" in the context of "actual revocations"? The oxymoronic nature isn't self-evident enough for me to catch your intended meaning before my first cup of coffee.

How can you falsely revoke a certificate? If an attacker can revoke a certificate, either by falsifying the signature or possessing the necessary key material, it is by definition not a trustworthy certificate anymore, and the revocation is therefore correct.

In the public CA PKI, it is the CA which has the power to revoke their issued certificates. In other systems, it can be the private key for the certificate itself. In either case, the certificate is not to be trusted anymore.

Revocation is the least of your worries should your signature algorithm be broken in the future.

> How can you falsely revoke a certificate?

If you don't have the private key on hand to issue a revocation, your next best bet is to find a parser bug that convinces some subset of user agents that the valid certificate you don't hold the private key for is actually invalid. (Hence, a false revocation.)

And then, get those users into the habit of accepting invalid/revoked certificates if they want to access the site. And then after weeks of battling against their patience or endurance, then you offer an invalid cert for a MitM.

That's how I was thinking of it, anyway.

If you receive a forged crl, in the worst case it will revoke certificates that you can't trust anyway. Even if it says "certificate X is still good", that's equivalent to receiving no crl.

Use PSK signature.