The latest CA/B Forum meeting was held in late October in Berlin, and it was one of the first widely attended face to face meetings since before the pandemic, with over 70 people in person. Another benefit of being in Berlin was experiencing an organ recital by our German hosts, followed by traditional Bavarian food and beer — many thanks to our hosts!

In addition to sharing some cultural experiences in Germany, the CA/B Forum made progress on some key initiatives: discussing the first S/MIME Baseline Requirements one final time and subsequently passing them, discussing code signing token changes and discussing a proposal to move away from checking OCSP for revocation.

About five years ago, the CA/B Forum reorganized itself so it was not just about server certificates but could also handle code signing and S/MIME minimum requirements. Those groups are now up to speed and producing their own requirements, helping prepare the industry to be more agile. This is perfect timing given the upcoming post-quantum cryptography (PQC) transition, which will drastically change security and require more crypto-agility than ever to maintain digital trust in our industry. Below is a summary of the latest progress in those groups.

S/MIME Baseline Requirements pass

Most notably, the S/MIME Baseline Requirements (BRs) were passed, meaning that the first BRs for email signing and encryption certificates will soon be enforced. This is the result of a four-year process, which we have covered previously on the blog. DigiCert’s own Stephen Davidson has chaired the S/MIME working group for the past two years, and at DigiCert we are proud that the industry has agreed to move forward with the first standards for email signing.

The new S/MIME BRs provide auditable requirements to make sure that S/MIME certificates follow appropriate minimum validation standards and comply with an interoperable profile. Three different levels (legacy, multi-purpose and strict) are defined to allow existing practices to continue as companies work to transition to newer, higher-quality S/MIME certificates.

The requirements have an effective date of September 2023, but do not actually come into force until one or more email clients decide to mandate compliance. Various root programs have indicated a desire to mandate compliance with the S/MIME BRs, but no formal announcements have been made yet.

Server certificate moving away from OCSP checking

Additionally, browsers are moving away from checking OCSP for revocation, which has been a gradual move over the last several years, as Chrome has stopped already and Apple is moving in that direction. There are many privacy risks with using OCSP, and that’s why we expect this to go away completely in the near future. In order to use OCSP to check the revocation status for a website, the browser must send the domain name being visited across the internet, making that information vulnerable to snooping. Internet engineers have been working hard the last few years to make it more difficult for network operators to see which websites are being visited. At the same time, some browsers have been developing and deploying technology that allowed compressed revocation information to be sent directly to browsers so that they have it without needing OCSP.

Additionally, browsers are moving away from checking OCSP for revocation, which has been a gradual move over the last several years, as Chrome has stopped already and Apple is moving in that direction. There are many privacy risks with using OCSP, and that’s why we expect this to go away completely in the near future. In order to use OCSP to check the revocation status for a website, the browser must send the domain name being visited across the internet, making that information vulnerable to snooping. Internet engineers have been working hard the last few years to make it more difficult for network operators to see which websites are being visited. At the same time, some browsers have been developing and deploying technology that allowed compressed revocation information to be sent directly to browsers so that they have it without needing OCSP.

Code signing

Finally, the industry is continuing to figure out how to move from individually held tokens to signing services. However, the problem is figuring out what the minimum-security requirements for cloud signing services need to be. The majority of code signing certificate users still rely on physical tokens to protect their code signing keys. This often leads to the keys being mishandled and/or stolen. Tokens also negatively impact the ability to improve agility and key protection in the code signing ecosystem, and Microsoft is very interested in substantially improving key protection for code signing.

Agility with respect to signing key security will be especially relevant as we begin the transition to post-quantum cryptography. While short lifetime authentication certificates like TLS have plenty of time to transition to newer technologies, software libraries that are being signed today will be still in use when cryptographically relevant quantum computers arrive, so improvements to signing solutions need to start being put into place now.

Signing services provide centrally managed key management that can be upgraded more readily as solutions evolve. The challenge is to develop and maintain reasonable minimum standards for signing services that guarantee that they do provide strong authentication and key protection. Without good minimum requirements, some signing services will be little more than someone with a network connection and an HSM bought on e-Bay.

See you in February

The next CA/B Forum meeting will be in February in Ottawa, Canada, and will be hosted by Entrust. As always, follow the DigiCert blog at www.digicert.com/blog/category/ca-browser-forum for more CA/B Forum updates.