Cryptography & Security Newsletter

130

30 October 2025

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It’s designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.

In February 2025, Chrome updated its root store policy to version 1.6. Among the changes was a move to dedicated CA hierarchies for TLS server authentication, which meant that a root certificate included in Chrome’s root store can’t be used for any other purposes, anywhere. As a result, use cases such as client authentication, S/MIME, and code signing won’t be allowed, effective June 15, 2026. Although we’re still far from the deadline, CAs are already implementing the changes. For example, DigiCert and Sectigo both stopped issuing client certificates earlier this month. Let’s Encrypt will follow in February 2026. Effectively, by the end of May 2026, Web PKI will be used exclusively for authentication of TLS servers.

Now, in itself, this isn’t a bad change, because multipurpose PKI hierarchies are inherently less secure: To start, all software that handles certificates must correctly examine the certificate permissions. Every certificate embeds information called Extended Key Usage (EKU), which carries the permissions. If the EKUs are not correctly validated, a certificate issued for one purpose could be used for another. This is obvious, but we have a poor record of implementing these things correctly. Further, a serious problem in one hierarchy can spill into another. The most famous example of this happening was the 2012 Flame/Stuxnet attack against Microsoft, in which a previously unknown chosen-prefix attack against MD5 was executed against Windows Terminal Services to create a rogue certificate that can be used to issue certificates for Windows Update code signing. The attack was only possible because of the dual purpose of the same PKI hierarchy.

In reality, the Chrome team was probably more interested in being able to operate and move fast in the TLS server authentication space without being constrained by problems that were spilling from other uses of the root CA certificates in their root store.

How Many Public PKIs Are There?

All of this is good for Chrome and its users, but it also highlights the lack of sufficient public PKIs. We have Web PKI, which is by far the most well-managed, largely driven by Apple, Chrome, and Mozilla. You can sometimes dislike the decisions they make, but there is a clear direction that’s being followed: automation, simplicity, short lifetimes, and transparency. We also often talk about Internet PKI, but that’s a PKI that’s not always easy to define, with some overlap with Web PKI as well. Perhaps with this change, a stronger line of separation will be drawn. Microsoft, in particular, needs a root store for its operating system; mutual TLS authentication (mTLS) from one server to another is a use case that the company supports and actively uses.

The likely outcome is that CAs will start to operate new roots, which won’t be in Chrome, but will be in operating systems and elsewhere as needed. For example, a post on LinkedIn from Filipp Seljanko, a Microsoft program manager, talks about how Microsoft Teams (which relies on mTLS) is affected by the PKI hierarchy changes. DigiCert is indicated as one CA that will offer certificates that can be used for client authentication. Some Zoom customers are also affected. For now, the advice seems to be to refresh certificates while client authentication is still allowed—and figure out what to do in the long term later.

Speaking of DigiCert, for some time it’s been working with ASC X9 on establishing a new PKI that operates independently from Web PKI. The signing ceremony for the new X9 Financial PKI took place earlier this year. Although initially marketed to financial institutions, DigiCert has since added other use cases to its website and focused on interoperability.

Impact on Certificate Transparency

Although you can argue that these changes will result in stronger PKIs over time, there will also be negative impacts—in particular, on Certificate Transparency (CT). This is because CT is a requirement of Web PKI and not, for example, part of a wider standard, such as CA/Browser Forum’s Baseline Requirements. Even before these changes, it was generally possible to get a certificate that’s not logged to CT and use it, for example, for an SMTP server. CT has been a tremendous success as it enabled domain owners to monitor for misissuance, but if there is now a rise of new Internet PKI—without CT—we may see an increase in certificates that are not logged and thus can’t be monitored. If it’s easy to get a certificate that’s not in CT, criminals will do just that.

Although browser traffic would remain protected, other uses such as SMTP and APIs may end up being less secure. Chrome won’t impose CT as a requirement on Internet PKI, but perhaps Apple and Microsoft could? The world needs a public root program whose work can be reused for a variety of operating systems and programming libraries. Such a program would have sufficient power to impose CT as a requirement as well as drive other improvements over time.

Subscribe to the Cryptography & Security Newsletter

This subscription is just for the newsletter; we won’t send you anything else.

Red Sift’s Guide to Certificate Lifecycle Management

With the imminent reduction of certificate lifetimes, there is more and more talk about Certificate Lifecycle Management (CLM). It seems clear that automation is the only way to survive 47-day certificates, but, before you can automate, you have to find where the certificates are used. That’s not easy for any business past a certain size. Red Sift’s Guide to Certificate Lifecycle Management will help you take the first steps toward visibility, automation, and issuance control. I wrote this guide for my employer, Red Sift, who is also this month’s sponsor.

Short News

• Cloudflare reports on the state of post-quantum Internet in 2025.
• Chrome 156, due for release in October 2026, will use HTTPS by default.
• Cloudflare has a new blog post describing Merkle Certificates, which is—potentially—what post-quantum certificates will look like in Web PKI.
• Financial Times reports that the UK government has issued another Technical Notice to Apple—this time demanding access only to the data belonging to Apple’s UK customers, not anyone in the world.
• Signal has further improved its communication protocol to improve its resilience against quantum computers—specifically, its post-compromise security attributes.
• The German government has decided to adopt passkeys.
• Reminder: The Real World Crypto 2026 conference will take place in Taipei, Taiwan, March 9–11, 2026.
• In the EU, the fight over Chat Control is still ongoing. For a while, Germany reverted to “undecided” and caused panic, but it’s back to opposing the measures. Diego F. Aranha and Nikolas Melissaris write about the conflict between end-to-end encryption and the establishments’ desire to monitor.
• Android apps are allowed to run in the background and capture information from the screen; this means that two-factor authentication is at risk, among other other data. The researchers have called this the Pixnapping Attack.
• The plaintext of the fourth and final passage of the famous Kryptos sculpture has been discovered, albeit not via cryptanalysis.
• Let’s Encrypt celebrated ten years of its community forums.
• Government IDs of about 70,000 Discord users have been exposed via a breach of a third-party identity validation service.
• RFC 9861: KangarooTwelve and TurboSHAKE standardizes four new expendable-output functions (XOFs).
• RFC 9794 establishes terminology for post-quantum traditional hybrid schemes.
• Homebrew, a package manager for MacOS, continues to be spoofed.
• Read about practical seed-recovery for the PCG pseudo-random number generator.
• Daniel Stenberg, better known as the developer of cURL, has been awarded a royal gold medal.
• The 2025 IEEE Cybersecurity Award for Practice recognized Josh Aas, Richard Barnes, Peter Eckersley, J. Alex Halderman, and Eric Rescorla for “democratizing the availability of encryption certificates with Let’s Encrypt.”
• In September, Apple rolled out support for post-quantum key exchange. The changes made an impact, according to Cloudflare’s global metrics.
• It turns out that large amounts of satellite communications are sent out as plaintext.
• If you ever wondered why transition to post-quantum cryptography might take more than a decade, Marin Ivezić shares a template plan for an imaginary large organization.
• The OpenSSL Conference 2025 was held in Prague; the agenda and presentation materials are available online.
• Google announced another significant quantum step with Quantum Echoes.
• Jan Sebastian Götte writes about the security of Germany’s medical record database.
• Pascal Tippe and Michael P. Berner write about the adoption of Argon2.
• The Internet Research Task Force (IRTF) launched ARMOR, an open mailing list to discuss maintaining resilient end-to-end protocol connectivity when traffic is tampered with or blocked.
• BIND and Unbound were found to be vulnerable to DNS cache poisoning attacks due to the use of a predictable random number generator.
• With ballot SC-088v3, The CA/Browser forum has adopted a new domain validation method that establishes a permanent permission for a CA to issue.