Cryptography & Security Newsletter

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ć.

ACME CAA Extensions to Become Mandatory

The CA/Browser Forum has voted to make ACME CAA extensions mandatory starting in March 2027. This change is one of the last remaining pieces needed to support strong, cryptographically-validated domain validation in Web PKI. In this article, we discuss why Web PKI doesn't provide enough assurance for high-profile websites, and how DNSSEC, ACME, and CAA can be combined to achieve strong cryptographic validation of certificate issuance.

This article was originally published on the Red Sift blog. It's part of my bigger work on High-Assurance Certificate Transparency Monitoring, which monitors our progress towards strong cryptographic domain validation. We're nearly there!

Convergence of DNSSEC and Web PKI

Not everyone likes DNSSEC, but it provides important security functionality that we can't get anywhere else. Companies that enable it on their domain names achieve integrity of DNS resolution. Some people argue that Web PKI works just fine, and it does, but only for the common use case: protecting websites that are not under serious threat. High-profile websites need better security.

For a long time, proponents of DNSSEC argued that it could replace Web PKI. Their thinking was that once you achieve integrity of DNS resolution, you get a security property you can build on to make X.509 certificates work without CAs. This is true, but only in theory. In practice, DNSSEC has a variety of design and operational issues that make wide adoption difficult. As a result, after many years, support for it is nowhere near where it needs to be, but Web PKI and CAs are here to stay.

Still, organizations that need robust public X.509 security have no option but to deploy DNSSEC for its unique capabilities.

In 2025, the CA/Browser Forum, the body that governs certificate issuance, decided to incorporate DNSSEC validation into the domain validation process. The requirement became mandatory in March 2026 and, for the first time, enabled strong cryptographic validation of certificate issuance.

Weaknesses at the Root of Web PKI

Web PKI is the most strictly managed public PKI, with elaborate rules and controls. It's an ecosystem we've spent decades improving. However, at the core, it has two significant problems. They are making the system easier to use, but we pay for that with relaxed security requirements.

• First, there is no authentication of the certificate requester. Anyone in the world can request a certificate for any domain name; if the validation process succeeds, the certificate will be issued to the requester, even if the domain owner does not authorize them.
• Second, when a certificate is requested, the CA performs domain validation over unsecured BGP, DNS, and network traffic. Anyone who can interfere with any of these three can break the domain validation.

If we add DNSSEC to this mix, that helps to secure the DNS, but the remaining two aspects (BPG and plaintext network traffic) remain insecure. To secure this setup, we need a way to ensure our domain validation relies only on the secure parts.

Certification Authority Authorization

The weaknesses in Web PKI can be addressed by using a standard called Certification Authority Authorization (CAA), defined in RFC 8659. CAA is designed to enable domain owners to publish their certificate-issuance policies.

The baseline version of CAA has been mandatory since September 2017, but it's insufficient for our needs. There is another document (RFC 8657) that bridges the ACME protocol for automated certificate issuance and CAA, adding support for fine-grained permissions.

With ACME CAA extensions, we can solve both problems we outlined earlier, with the help of a single CAA resource record in our DNS that looks something like this:

example‌.com.  CAA  0  issue "letsencrypt‌.org; accounturi=https‌://acme-v02.api.letsencrypt‌.org/acme/acct/1726001367; validationmethods=dns-01"

What Does This Do?

On the left, we see the domain name for which we want to control certificate issuance, in this case, example‌.com. On the right, we have three controls:

• The first is the identity of a CA that's allowed to issue certificates for the domain name, in this case, letsencrypt‌.org.
• The second control is the accounturi instruction, which locks down issuance only to the named ACME account. Because ACME always uses encryption and strong cryptographic authentication, this section ensures that only authorized users can request certificates for this domain name.
• The third control is the validationmethods instruction, which locks down issuance to use only one DNS-based domain validation method. When DNSSEC is enabled for a domain name, this section ensures that all domain validation operations are cryptographically secure. With this, we no longer care about other insecure methods; the CA won't accept them in the first place.

Can We Use ACME CAA Extensions Now?

ACME CAA extensions have been around since 2019, and some CAs (e.g., Let's Encrypt, Google Trust Services, and others) already support them. So, in theory, you could have had stronger issuance controls since March 2026, when DNSSEC became mandatory for domain validation. In practice, until a feature is embedded in CA/Browser Forum’s Baseline Requirements, there is always hesitancy from CAs to commit fully. That's because every feature increases their workload and makes their job more complex. A failure, no matter how small, could lead to a certificate misissuance incident.

The Chrome team has been a long-time proponent of automation. Support for automation has been a central part of their Root Program Policy and, within it, requirements for ACME and ACME CAA extensions. In February 2026, the policy was changed to require support for ACME CAA for all CAs to support ACME.

In May 2026, CA/Browser Forum voted (in Ballot SC-098v2) to formally extend support for CAA and make the ACME CAA extensions mandatory for all CAs, starting from March 2027.

You can use the ACME CAA extensions today if you work with CAs that support it. From next year, this feature will be widely supported, and you will have a choice of CAs to work with.

Short News

Post-Quantum Cryptography

• NIST announces 9 Round 3 candidates for additional PQC digital signature schemes spanning isogeny (SQIsign), lattice (HAWK), MPC-in-the-head (MQOM, SDitH), multivariate (MAYO, QR-UOV, SNOVA, UOV), and symmetric-based (FAEST) approaches.
• Marin Ivezic analyzes NIST's nine third-round additional PQC signature candidates spanning four mathematical families (MPCitH, multivariate, isogeny, lattice), examines the five eliminated candidates, and covers migration implications and the crypto-agility imperative.
• Michael Jones (COSE WG co-chair) notes the publication of RFC 9964 specifying ML-DSA for JOSE and COSE, enabling post-quantum digital signatures for internet and device ecosystems including FIDO2 and prototype Yubikeys.
• Hans-Martin Lauridsen announces RFC 9965 finalizing ML-DSA for JSON Web Signatures, enabling post-quantum support for OAuth and OIDC, with KeyCloak already working on an implementation.
• Stephen Davidson notes Chrome 150 will add ML-DSA certificate support in TLS for enterprise private-trust PKI (stable June 30), while public WebPKI will instead adopt Merkle Tree Certificates.
• Root Causes Podcast episode 613 features NIST's Dustin Moody, Jason Soroko, and Tim Callan covering the current state of PQC contests, upcoming FIPS standards for Falcon (FN-DSA) and HQC, Round 4 algorithms, and the DSA On Ramp.
• Bas Westerbaan (Cloudflare) explains quantum downgrade attack risks for PQ certificates and mitigation strategies including PQ Lock, Certificate Transparency, and Merkle Tree Certificates in Root Causes Podcast episode 614.
• Marin Ivezic's Quantum Utility Map shows the CRQC threshold sits near the bottom of the quantum advantage ladder, meaning encryption becomes breakable before quantum computers deliver broad industrial value, compressing PQC migration timelines.
• Mark B. Cooper (The PKI Guy) announces Microsoft's KB5087539 enables ML-DSA support in ADCS, making PQC signature algorithms available in Windows Server 2025 PKI.
• JEP 527 proposes post-quantum hybrid key exchange for TLS 1.3 in JDK 27, combining ML-KEM with ECDHE (X25519, secp256r1, secp384r1), with X25519MLKEM768 enabled by default as the preferred scheme.
• PQStation analyzes TLS configurations across 8,000+ real-world Nginx deployments finding no PQC hybrid key exchange in the wild, then successfully deploys ML-KEM hybrid TLS at real termination points inside a PoC banking environment with OCBC, with zero application changes.
• How's My SSL? announces it will mark TLS connections without PQC as "Bad" starting December 2026, after first flagging them as "Improvable" from June 2026.

Cryptography

• The CrypTool project offers a free suite of educational cryptology tools, including browser-based experiments, desktop applications, and cryptological puzzle contests.
• Toyofumi Sawa and Kuniyasu Suzaki (IISEC) show that AES keys persist despite zeroization attempts across OS, library, and hardware layers, breaking the assumption of forward secrecy after process termination or reboot.
• J.C. Jones (ISRG) announces that OSCW 2026 sessions are now available from the Open Source Cryptography Workshop in Taipei, on the Internet Archive and the workshop site.
• Trail of Bits submits SequenceHash to C2SP, a new spec that generalizes TupleHash to work with any hash function (SHA-256, BLAKE2, etc.) for safely combining multiple inputs into a single hash.
• Guy Lewin (Meta) announces that Messenger now uses Cloudflare's Key Transparency to distribute HSM public keys for E2EE backups over-the-air, enabling independent public auditing of keys Meta publishes.
• Nadim Kobeissi announces CedarCrypt 2026, a new applied cryptography summer school and conference running July 13-16, 2026 in Paphos, Cyprus, covering PQC, ZKPs, FHE, threshold cryptography, and more, with scholarships available for students.
• Kate Kaye (World Privacy Forum) covers UMBC research finding C2PA's core components fail their cryptographic security goals in the first formal-methods analysis of the content provenance protocol.
• OpenSSL Corporation announces that OpenSSL Conference 2026 will be held in Prague (13-15 October), featuring speakers including Daniel J. Bernstein and Tanja Lange. Early bird tickets available through 31 May.
• Dirk Wetter announces a testssl.sh client simulation update adding Android 16, Safari 26.x with PQC key exchange, OpenSSL 4.0 with SM2 and SM2MLKEM768 hybrid support, and JA4/JA3 fingerprint-based client consolidation.

Privacy

• Apple and Google have announced that, starting with iOS 26.5, they support end-to-end encryption of messages exchanged among Android and iPhone users.
• Thomas Brewster (Forbes) reports how police identified a crypto robbery suspect via Bluetooth by matching car Bluetooth identifiers from a stolen getaway vehicle with data obtained via an Apple subpoena.
• Eva Leung (WhatsApp/Meta) announces Incognito Chat with Meta AI on WhatsApp, billed as the first AI chat at scale guaranteeing conversations are inaccessible to anyone, including Meta.
• Ken Macon (Reclaim The Net) reports that France's intelligence delegation backs weakening E2EE, endorsing a "ghost participant" approach that cryptographers have long argued undermines security for all users.
• EFF warns that Canada's Bill C-22 revives last year's failed Bill C-2, mandating year-long metadata retention, expanding foreign government data sharing, and empowering the Minister of Public Safety to demand encryption backdoors while banning companies from disclosing such orders.

PKI

• Leo Grove (SSL.com) announces bimi.sh, a public market intelligence dashboard providing transparency into BIMI, VMC, and CMC mark certificate issuance, CA activity, and adoption trends.
• Pim van Pelt details the operational setup of four CT logs at IPng Networks (Gouda, Halloumi, Rennet, Lipase) using TesseraCT and Sunlight, open-source Static CT implementations, in the final part of a three-part CT series.
• Let's Encrypt disclosed that their Gen Y cross-certified subordinate CAs were issued without serverAuth EKU, violating CCADB policy; issuance was temporarily suspended and a configuration fix deployed.
• Matthew McPherrin (Let's Encrypt) announces a phased reduction in certificate validity to 45 days by 2028, with authorization reuse shrinking from 30 days to 7 hours, and introduces a new DNS-PERSIST-01 validation method to ease automation.

Security

• Dave Kleidermacher (Google) announces expansion of Android Binary Transparency to production Google apps and Mainline OS modules, using public append-only ledgers for verifiable software integrity.
• Olena Kocherhina (Incrypted) reports on a social engineering DNS hijack of eth.limo, an ENS gateway serving ~2 million .eth domains, where DNSSEC prevented phishing by causing SERVFAIL errors instead of redirecting users to attacker-controlled pages.
• Cloudflare explains how 1.1.1.1 mitigated a DENIC DNSSEC failure that caused SERVFAIL for all .de domains on May 5, 2026, using serve stale and Negative Trust Anchors.
• Internet Cleanup Foundation launches SecurityBaseline.eu, revealing that 3,000 European government sites illegally place tracking cookies, over 1,000 phpMyAdmin panels are publicly accessible on government domains, and 99% of governmental email fails modern TLS encryption standards.
• Adam Janes details how North Korean attackers compromised the Axios npm package (100M weekly downloads) via a long-lived token that silently bypassed MFA, pushing a remote access trojan in two malicious versions within 39 minutes, alongside similar supply chain attacks on Vercel, tj-actions, and others.
• Vincent D'Angelo highlights research on "zombie" domain names that persist in DNS integrations after expiration, creating supply chain security risks especially relevant to AI ecosystems relying on third-party repositories and integrations.
• Sasha Romijn (Reliably Coded) demonstrates how XSS payloads in TLS SANs and DNS fields can chain through RIPE NCC's SSO session to modify RPKI ROAs and hijack RIPE Database objects from a