At the last CA/Brower Forum meeting, Chrome outlined its vision for future web PKI policies titled Moving Forward, Together. Notably, Chrome’s vision included 90-day certificate validity periods, which we addressed in-depth in a separate post. However, there are other proposed policies in Chrome’s vision that are relevant for customers to be aware of, including the proposal for a term limit for root Certificate Authorities (CAs) and a maximum validity period for Intermediate Certificate Authority certificates (ICAs).

Chrome states in their announcement that they are exploring future policy requirements related to the following:

• Encouraging modern infrastructures and agility
• Focusing on simplicity
• Promoting automation
• Reducing mis-issuance
• Increasing accountability and ecosystem integrity
• Streamlining and improving domain validation practices
• Preparing for a post-quantum world

At DigiCert, we support Chrome’s objective to “make the Internet a safer place.” However, we also recognize that there is a balance between security and manageability. As we mentioned in our post on 90-day certificates, while we have supported shorter certificate lifecycles in the past, 90 days is too long for a compromised certificate to exist but too short for industry transitions and domain registrations. Exploring other options that would encourage and enable customers to move to true short-lived certificates would make more sense.

Similarly, Chrome has proposed rotating root CAs every seven years and other ICAs for a maximum validity period of three years. Currently, root CAs are rotated every 25 years and ICA lifetimes are unlimited. While we have supported shorter ICA lifetimes in the past, the exact period should meaningfully balance security with practicality. Let’s dive into it.

What are roots & ICAs?

A root is a self-signed certificate that binds the identity of a CA to its root public key, which is the public key it uses to sign all the other ICAs it distributes. ICA certificates contain a public key used to sign either other ICAs or end-entity certificates, as well as other metadata about what policies the CA adheres to, what kinds of certificates it signs, the root it was issued under, the associated identity and so on.

End-entity certificates and ICA certificates get their trust from their signer, who attests that all the information in them is valid and correct and can be trusted. Root certificates cannot prove their own trustworthiness and gain trust via inclusion in a browser root program’s list of trusted root certificates.

Root certificates need to be available in all root programs and distributed to the vast majority of platforms before they can be relied on by customers. This process, commonly known as gaining ubiquity, can easily take several years. Thus, root certificates often have the longest lifetimes, while SSL certificates have the shortest.

Why rotate them?

The reason to rotate ICAs is to ensure compliance with modern standards, which is the same reason rotating end-entity certificates is a good idea. Policies change and improve from time to time, and for compatibility reasons, the industry usually makes policy changes on a going-forward basis. ICA rotation can ensure these policy improvements propagate to all ICAs within a reasonable time frame. Thus, shorter ICA periods are not always a bad thing, especially considering the current limitation is forever.

For roots, the benefits of rotation are less clear. As noted above, roots intentionally contain very little information, as they are intended to provide a long-term means of verifying a particular ICA indeed belongs to a particular trusted CA in a root program. While some historical roots were produced in a much laxer compliance environment and some may have even had gaps in audit coverage, and it is good for the ecosystem that they are going away, root transitions are complicated, and the benefits need to be weighed against the risks. In particular, inclusion of new roots by root programs has historically been slow, and this will need to improve substantially for Google’s vision of only two years from root creation to ubiquity to be achieved. With root embedment currently taking three years and root ubiquity taking another three years, a maximum root lifetime of seven years is unrealistic. Although Google might be able to make root embedment faster, one value of the web PKI is the distribution of roots across the ecosystem. You don’t need a separate root for users accessing your site through Chrome vs. Apple vs. Mozilla. This means that root rotation only happens as fast as the slowest member of the user agent root store. Some of these user agents haven’t participated in the CA/B Forum nor expressed a need for rapid root rotation.

There is a way around the long process of root embedment: extra chains in the package. Effectively, you’d need at least a four-chain root to make the plan work. First, a master root that chains to everything, granting ubiquity. Second, a root embedded in Chrome and other rapidly updating browsers. Third, an issuing CA that issues the end-entity certificate. The problem with this design is that it disadvantages all user agents in favor of Chrome. Anyone using the long chain will experience slower speeds than those with the rapid root replacement. Note that this wouldn’t actually speed up TLS connections; it would just slow it down for every agent that doesn’t participate in the program.

Rotating roots & ICAs is disruptive, especially for those using pinning

Rotation of roots and ICAs significantly affects customers, and can be very disruptive to the industry, as it often involves manual updates to affected servers. In addition, despite the fact that DigiCert strongly recommends against pinning, many customers pin roots and ICAs. Certificate pinning is extremely risky and can make certificates impossible to replace in the event of key compromise, enable hackers to do long-term damage to a website and make it difficult to respond to certificate issues. Google was actually among the first to use certificate pinning in 2011, but it didn’t take long for the risks of certificate pinning to become apparent. Customers using certificate pinning should stop the practice as soon as possible anyways, but the discussion of roots and ICAs rotating more frequently is another reminder for those currently pinning to stop.

DigiCert can help customers stay ahead of evolving requirements

However, customers should be aware that DigiCert’s roots are ubiquitous, and we have extensive experience in rotating ICAs. Furthermore, our solutions like DigiCert^® Trust Lifecycle Manager can make it easier for customers to stay ahead of evolving compliance requirements and threats. DigiCert Trust Lifecycle Manager, which integrates CA-agnostic certificate management, across public and private trust, and PKI services to deliver centralized visibility and control, prevent business disruption and secure identity and access. DigiCert Trust Lifecycle Manager is a full stack solution that can help enterprises remain compliant with ever-evolving industry standards.

Conclusion

Finally, keep in mind that these policies are not guaranteed and there is no ballot in place at the CA/B Forum to vote on them. Furthermore, any industry changes will be communicated in advance to allow companies time to adapt. However, Chrome’s vision does warrant an industry discussion now around these matters. Chrome is also accepting feedback on their proposals at chrome-root-program [at] google [dot] com and through CCADB surveys from CA owners. We will continue to champion our customers’ best interests in ongoing discussions at the CA/B Forum and elsewhere as we work with Chrome and other members of the CA/B Forum to make the internet a safer place.

Stay tuned to the DigiCert blog or social for any relevant updates on the matter.