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.