March 2025
Three new requirements from the CA/B Forum coming into effect on the Ides of March, and more
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.
PQC Isn’t Your Migration from SHA-1
NIST announced HQC as the second key encapsulation algorithm for standardization. The announcement was somewhat of a surprise, as there was an expectation that Classic McEliece would be selected.
The LAMPS working group at the IETF finally came to “rough” (an adjective fitting for describing both the discussion and the final level of agreement) consensus on the PKCS #8 private key formats for ML-DSA and ML-KEM. Team Seed and Team Semi-expanded both won and lost, with the format allowing either the seed, semi-expanded value, or both.
IETF 122 was held two weeks ago in Bangkok, with the Hackathon being held the weekend before. The PQC interoperability hackathon group primarily focused on interoperability with the new private key formats.
For the PKI Propellerheads
Feisty Duck gives a breakdown of CRLite and how it leverages revocation information provided by CAs in Firefox.
The requirement for CAs to perform domain validation and CAA checks from multiple network perspectives came into effect on March 15th. The current requirement allows CAs to still issue certificates even if there are inconsistent validations across network vantage points (“soft fail”). This will change on September 15th, as CAs will need to refuse to issue if inconsistent information is retrieved (“hard fail”). The OpenMPIC project provides an open-source implementation of domain validation and CAA checks from multiple network vantage points.
A proposal to require CAs to perform DNSSEC validation when querying DNS for domain validation challenges and CAA authorization checks was presented at the CA/Browser Forum Face-to-Face meeting in Tokyo last week. Adding this validation is likely not challenging from a implementation standpoint, as many popular DNS resolvers support DNSSEC validation. Instead, the challenges will likely arise when TLS certificate holders with broken DNSSEC configuration attempt to renew certificates. They will discover that they now have two problems: an expiring (or expired) TLS certificate, and a broken DNSSEC configuration that prevents fixing the first problem.
For the Policy Wonks
The requirement for CAs to check CAA issuemail records prior to the issuance of S/MIME certificates came into effect on March 15th. Initial adoption may be slow due to limitations in DNS solutions allowing the creation of CAA issuemail tags. However, it appears that several DNS providers such as DNSimple, easyDNS, and Hetzner Cloud already provide support.
The requirement for CAs to perform TLS certificate “pre-linting” came into effect on March 15th. Certificate “pre-linting” is a process where prior to issuance of a certificate, a dummy certificate with the exact same contents of the to-be-issued certificate is created with a bogus signature and fed to one or more “linters”, or programs that check the dummy certificate for conformance with various technical standards and policies (such as RFC 5280 or the CA/B Forum TLS Baseline Requirements). If any errors are found, then the issuance process is stopped. Linting has been instrumental in stomping out deviations in certificate formats, making it easier for applications to interoperate with the WebPKI.
The Chrome Root Program gives an overview of some of the changes that were introduced in the TLS Baseline Requirements last year.
The Mozilla Root Program outlines the changes introduced in version 3.0 of their root program policy.