Continuing the discussion from Roadmap request (redux): Post-quantum cryptography:
Looks like this blog post is now up:
Very excited about MTCs! A huge change for the entire PKI, probably the biggest migration ever for authentication in HTTPS?
One of the things that is still quite blurry to me is how the landmarks are going to work: Is there one huge tree for all CAs, or does each CA have its own tree? Are the browsers planning on doing the CRLite-strategy of browser vendors pulling data from the CAs and then sending it to browsers via common distribution channels, or are we somehow pulling directly from the CA?
Another thing that I like to consider is what non-browser applications can do. They'll also need PQ, and they have the same problem of not wanting to carry 5+ sigs per handshake. So the tooling may want to copy the browsers approach of using MTCs again, but this is more tricky as there is less centralized vendor infrastructure (so no preexisting common distribution channel for landmarks). I've already seen a few months ago that there is work underway/planned in this area, for instance the rustls upki library/tooling wants to provide the same infrastructure the browsers have in a vendor/application independent way.
Lots of work is needed in this area, and many things will need to be rewritten and improved to make this work. At the same time, this could be a good opportunity to modernize the ecosystem and get rid of many old/bad practices (never updating your trust stores for instance).
All certificates are issued by putting them into a log. Each CA organization will have multiple keys, and each of those corresponds to one or more logs.
Yes, the browsers or OSes will pull and distribute landmarks, just like CRLite. upki, for example, will support this on Linux. I expect TLS stacks will integrate with that or something similar.
How will this affect issuance flow in practice? Like right now we can order a certificate and in practice serve it one or two seconds later most of the time. This is useful for On-Demand TLS when sites don't control the domains (like white labeled SaaS, "bring your own domain" features etc): they just get a certificate at the first handshake that requires it.
It sounds like MTC certs will be issued in batches so it could take unknown amount of time for the cert to be obtained and for clients to start trusting it?
The batches will be issued every second or so, which is similar to the delay of waiting for CT logs today.
That’ll get you a standalone certificate which can be used immediately. However, it’ll be big - two ML-DSA signatures.
There will be a new landmark issued hourly, so ACME clients will have to wait until then to get a landmark-relative cert, which is the size-optimized thing that MTC enables. There’s ongoing debate about how to bolt that onto ACME. And then it’ll take a further amount of time for clients to get their landmarks updated, and signalling what they have in the TLS handshake.
So yeah, on-demand TLS will still work, but probably won’t get the size optimizations until maybe a few hours later.
But you're not required to start using the new cert immediatly - you can wait until the next day or so before deploying it?
yes, if you're not in a hurry (you still have an old cert or something) you can wait. But if you're bootstrapping (this is the first cert for the FQDN), you may not want to wait that long.
Right. It’s actually the same cert, just without the signatures, with inclusion proof hashes up to a landmark the client knows about.
You don't even need the CA to do the standalone -> landmark-relative optimization, though we'll expose that over ACME to simplify the details. You can use the log directly to compute it.
TLS servers will always need the standalone certificate though: Clients might not have a landmark for you to serve them a landmark-relative certificate.
So that means two things need to change to take advantage of landmark-relative certs:
- The acme client (or some other tool) needs to wait up to an hour and then get the landmark-relative cert
- The TLS server needs to parse the information the client hands it, and decide which cert to serve.
This is going to probably be a lot easier for programs that look like a TLS server with a built-in ACME client.
Nobody's talking about this too much yet, but there's a further compatibility trick we can do: Put the whole MTC as an extension into another certificate. That'll allow TLS servers that don't know anything about MTC to use them, but at the expense of being even bigger.
Separate from MTC's, will you support issuance of "regular" ML-DSA EE's (from YR* or YE*) once CA/B rules allow it? (for experimentation or non-web use)
We don’t currently have plans to do so, but it is possible that may happen at some point.
Ah, okay, thank you for clarifying. That's great news.