April 2025
Roughly 8.63x more work for your local PKI admin and PQC drama
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.
PQC Isn’t Your Migration from SHA-1
As the specifications for using ML-KEM and ML-DSA with X.509 and CMS make their way through the final stages of the publication process at the IETF, cryptographer D.J. Bernstein filed an appeal with IETF leadership over the specifications using ML-KEM. The concern is that the patent situation regarding ML-KEM is rather complex, and the proper intellectual property disclosures may not have been made as required by IETF policy. HQC, which is another key encapsulation mechanism algorithm (i.e., a replacement for ML-KEM) that will be standardized by NIST, may enjoy widespread adoption as the intellectual property situation for that algorithm is clearer.
A longtime IETF participant laments his inability to mute the mailing list thread about the above appeal before another message arrives.
NIST hosted a workshop on crypto agility last month, with a strong focus on algorithm agility. The presentations from the workshop are available here. Similarly, NIST is calling for papers for the 6th PQC Standardization Conference that will be held at the end of September.
The OpenSSL 3.5 release on April 8th adds several new features to this widely used cryptography library. In particular, support for ML-KEM, ML-DSA, and SLH-DSA has been added. OpenSSL developers were very vocal participants in the argument over private key formats for ML-KEM and ML-DSA, which I covered a few weeks ago here.
A draft ballot that allows ML-DSA and ML-KEM in publicly trusted S/MIME certificates has been floated in the S/MIME working group of the CA/Browser Forum.
For the PKI Propellerheads
A IETF draft that specifies a “security” CAA property tag was recently adopted by the LAMPS working group of the IETF. The draft specifies that the “security” property tag is always critical, so CAs must refuse to issue certificates if they do not implement support for the property tag as defined in the draft. With the CA/Browser Forum already contemplating a requirement for CAs to validate DNSSEC when performing domain validation as well as a requirement for CAs to process “validationmethods” CAA parameters as defined in RFC 8657, the purpose of this draft is not quite clear.
A security researcher uncovered a severe flaw in SSL.com’s domain validation system. The researcher created a TXT record containing an “aliyun.com” email address on their domain and then requested a certificate from SSL.com for their domain. The SSL.com validation system then queried for the TXT record and sent a challenge email (with a secret token) to the email address in the TXT record. The researcher then provided the secret token to SSL.com, thus proving control of their domain according to method 14 of the Baseline Requirements. However, instead of recording the requested domain as validated, the CA’s system instead recorded the domain name of the email address in the TXT record (“aliyun.com”) as validated. This allowed the researcher to successfully request a certificate for “aliyun.com”.
For the Policy Wonks
Apple announced that their Certificate Transparency program will start accepting static logs. This announcement mirrors a similar announcement made by the Chrome team in February. With these two announcements, it is now possible for CAs to begin logging pre-certificates to static logs to fulfill the technical requirements of certificate transparency for Chrome and Apple. However, no announcement has yet been made by Mozilla in regards to Firefox’s treatment of certificate transparency for static logs.
Ballot SMC-11 recently passed in the S/MIME working group, which provides some updates to the organization identifier syntax for organizations registered in Europe, and in particular, Germany. The intricacies of how organizations are registered in Germany has been the topic of debate at the CA/Browser Forum in years past and it’s not yet clear that the concerns that have been raised have yet been resolved.