Try it now. The certificate profile validator and Markdown CPS generator are live at https://infrared.turbolightsolutions.com/profile. Pick an example, press Validate, and see a profile mismatch caught before issuance.

In the past year, one CA revoked tens of millions of certificates for one reason. Those certificates passed every industry-standard linter, but they still disagreed with the CA’s own policy document. A second CA hit the same class of defect twice in one month. A third CA was called out for this error in its distrust announcement. The linters that CAs run check certificates against the public standards, such as RFC 5280 and the Baseline Requirements. None of them read the CA’s own policy document. So nothing caught these cases until a third-party researcher filed a report and the five-day revocation clock started.

In Certificate Profiles Need a Single Source of Truth, I made the argument that the CP/CPS is a second copy of a CA’s certificate profile, written in prose. The Baseline Requirements make that copy normative. And keeping two copies in sync by hand simply does not work.

Recent incidents show this clearly. Microsoft mis-issued more than 75 million valid certificates because an edit to its CPS said keyEncipherment was absent, while issuance kept including it. HARICA did the same thing twice in one month, once on id-kp-clientAuth and once on the AIA OCSP URI. Both times, the document and the issuance system were edited separately. Entrust made a CPS edit meant for its EV profile, but it was made on the OV profile. This typo became a mis-issuance event, and it was later named in Entrust’s distrust announcement.

draft-ietf-lamps-pq-composite-sigs, the draft specification for composite signatures, is in the final stages of standardization at the IETF. A composite signature combines ML-DSA with a traditional signature algorithm such as RSA or ECDSA. The two are presented as a single public key, a single signature, and a single algorithm identifier. A verifier accepts the composite only if both component signatures verify.

The benefit to this approach is clear: if one component breaks, the other still provides security. But composite signatures are not a drop-in upgrade into existing infrastructure, and they are not a way to keep legacy clients working. This post covers the benefit, dispels a few misconceptions, and outlines the trade-offs, which are significant.

A CA’s certificate profile exists in at least three places: the policy documents (CP/CPS) that describes it in prose, the CA software configuration that actually produces certificates, and in user-facing product documentation. Those artifacts are maintained separately, usually by different teams, and nothing forces them to agree.

Software engineering named this problem decades ago. “Don’t Repeat Yourself” is the rule that every piece of knowledge must have a single, authoritative representation within a system. If information is duplicated, it will eventually be changed in one place and not the others, and the copies will silently disagree. But what happens when they do disagree?

The ACME protocol provides the ability to bind an ACME account with a pre-existing account registered with the CA using a secret HMAC key. However, the common way to feed that secret to popular ACME clients is to paste it straight onto the command line, where any user on the same machine can read it. Worse, several major CAs let you reuse the same EAB credential, so a single capture is enough to keep abusing it.

There is a new ACME validation method, dns-persist-01, being standardized at the IETF, and it has even been rolled out to Let’s Encrypt’s staging environment. However, an unresolved security concern is blocking progress on the standard and the roll-out in production for Let’s Encrypt.

dns-persist-01: DNS propagation delays begone!

While ACME has had a DNS-based validation method (dns-01) since the very beginning ¹, it requires real-time updates to DNS for every validation attempt. This creates two issues:

Big News

After several months of discussion, the CA/Browser Forum passed ballot SC-81 by a very comfortable margin (all YES or ABSTAIN votes), which is a stark contrast to the ballot for 398-day certificates a few years ago. The ballot establishes a maximum validity period of 47 days for publicly trusted TLS certificates, although almost all CAs will cap the validity period at 46 days to comply with the SHOULD-level requirement to not exceed 46 days (the same applies for the other steps of the validity period reduction in the ballot: 199 days for the 200-day maximum validity period, etc.). Additionally, the ballot reduces the reuse period for domain validations from 398 days to 10 days. With a 8.67x reduction in validity period and a whopping 39.8x reduction in validation lifetime, the message is quite clear: organizations need to automate the validation, issuance, and installation of their publicly trusted TLS certificates within the next few years to prepare.

Big News

Apple’s ballot that proposes a maximum validity period of 47 days for TLS certificates — among other things — is still in discussion period at the CA/Browser Forum, but the effective dates of several items have been pushed back. It is expected that this ballot will go to voting sometime in April.

X9 launched a forum for the newly created X9 Financial PKI. The X9 Financial PKI is intended to provide an alternative for using the WebPKI for financial applications. The migration in the WebPKI from SHA-1 was challenging for several financial use cases (such as payment terminals), and this PKI will be operated with those use cases in mind instead of prioritizing browser-based TLS as it is in the WebPKI. The Forum will solicit feedback and suggestions from interested parties to help guide the evolution of the PKI.

What is cryptography but some random numbers mixed with drama? February is the shortest month of the year, but you wouldn’t know it looking at the long list of news and happenings from the month.

Big News

The discussion on reduced certificate validity periods continues on at the CA/Browser Forum. The latest update to draft ballot SC-81 delays the rollout of the maximum certificate validity period of 47 days from 2028 to 2029. Meanwhile, a good, old-fashioned Internet flamewar continues in the comments section of the Github pull request for the ballot.