The underlying context is the US government only wants to buy systems which support pure post-quantum cryptography for use on top-secret networks, as part of the requirements of (via its Commercial National Security Algorithm Suite 2.0 standard).
So all the companies who want to sell anything using TLS to the government want to standardize this, so they can be CNSA2 compliant.
Everyone already supports this in major libraries; but some folks feel they need an IETF RFC specifying it.
(I don't have to comply with CNSA2 so I might have details slightly off)
Yes, many of the problems from CT are fixed. I wouldn't call it a "broken mess" though, as it has been relatively effective at detecting various problems, and to my knowledge hasn't been compromised.
There are no SCTs, which were a compromise to get CT shipped. Each Merkle Tree Certificate has an actual inclusion proof in it.
CT has multiple independent logs, and requires certs to be logged to 2+ of them. With MTC, you have one issuing log, along with signatures from other "witnesses" which monitor and mirror log integrity. Those co-signatures are validated when checking the certificate.
Thus the witness network makes it much harder for logs to fork, as you can't present a forked view to just the client. You also need to present it to a witness. And it'll be much easier for folks to check all the witnesses are in sync.
Monitoring the MTC logs will be easier than CT, as they'll actually be smaller than CT for a few reasons. At least for the initial version, there won't be a better way to monitor for mis-issued certificates for a particular domain than linear scanning all certificates, but that's a problem being worked on for both CT and MTC, called "verifiable indexes".
On Linux and similar systems, I'm hoping github.com/rustls/upki will handle landmark distribution, and that non-browser clients can use that. Of course Rustls will support their own project, but I'm hopeful other TLS stacks do too. Ubuntu announcing they're deploying it should help with that.
On other OSes (like Mac OS and Windows), there's also OS-level services which could support this.
It would be a shame if we end up with a bunch of copies of this data, so I think a shared OS service is the only reasonable approach.
The hardest part is going to be smaller embedded systems.
Great question! Of course, we'll continue to provide more information as we firm up more details. This is an area that's not locked down yet, but I can give a sneak preview of what it might look like.
We expect batches to be produced quickly, on the same order of magnitude as current CT logs - somewhere in the 0.5s to 5 second range. This is an existing problem since (at least some) CT logs do the same batched behaviour.
Now, there is a catch with MTCA: That gets you a "standalone" certificate, which works just like a certificate does today. But it's big, still. To get the new, small certificates (landmark-relative), you will have to wait for the next landmark. Based on current planning and discussions with Chrome, we expect that to be hourly for short-lived certs, and 4 hours for longer-lived certificates.
So you'll get a big cert instantly, but you might have to wait an hour or 4 to get a certificate.
So your new website can be online quickly, but with some downsides until you get the small landmark-relative cert.
Even without DNSSEC, the CAA record approach can help, as it requires MITMing between the CA and the DNS server, which may be harder in some cases than just MITMing a target site.
CAA checking is mandatory, so you can always restrict to a given CA.
To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type).
Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.
The post seems to be down so I am not quite sure what it says, but Co-Authored-By trailer is what Claude does. I'm not quite clear what you're suggested that's different from what Claude does - just default to off instead of default on?
It doesn't matter what the network is doing; the phone needs to disable 2g. There's various ways to get the phone to downgrade to 2g otherwise, eg https://montsecure.com/files/2021_downgrade.pdf
Squash merge is the only reasonable way to use GitHub:
If you update a PR with review feedback, you shouldn’t change existing commits because GitHub’s tools for showing you what has changed since your last review assume you are pushing new commits.
But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise.
So sure, there’s workflows with Git that doesn’t need squashing. But they’re incompatible with GitHub, which is at least where I keep my code today.
Is it perfect? No. But neither is git, and I live in the world I am given.
It says: CAs MUST properly parse and interpret the integer timestamp value as a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds) and apply the expiration correctly.
https://keymaterial.net/2026/05/13/so-you-want-to-deploy-fn-... talks about FN-DSA and has a section about how it's require to hand-implement floats to get constant-time operations.