Depending on the browser and operating system that you use, anywhere from 50 to over 100 different organizations across the world are trusted to ensure that your browsing experience on the internet is a secure one. These organizations operate certificate authorities (CAs) that issue TLS/SSL server authentication certificates. These certificates are used by billions of users every day to verify the identity of websites you visit and ensure that any information to you send to that website is encrypted and safe from prying eyes. Given the critical importance of this task of providing identity on the internet, it is imperative that CAs operate under a set of clear requirements to ensure security and compliance. In this blog post, we provide an overview of how requirements for CAs are developed and how it is critically important that they are clear and well defined.

A common baseline of security and compliance

The CAs that are trusted today by browsers to issue TLS certificates to secure websites are truly global; each CA has the technical capability to issue a certificate for any website. From a security standpoint, each CA is equal: overall security on the internet is only as strong as the weakest CA. For this reason, a minimum standard must be established that ensures a common baseline of security and compliance to which all CAs must adhere.

Major browsers require that trusted CAs must operate according to the policies outlined in the CA/Browser Forum’s Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates. These requirements are defined and agreed upon by a group of CAs and browsers, and they represent a common set of minimum requirements for the industry.

Browser vendors also define their own policies specific to their needs. These policies may include restrictions on the types of certificates that may be issued. For example, the Mozilla Root Program prohibits CAs from issuing certificates that contain ECC P-521 public keys, as the Mozilla Root Program believes allowing P-521 public keys in certificates is not beneficial to the ecosystem and would like to curb its use.

Browsers may also include requirements that were originally proposed at the CA/Browser Forum but were not supported by most participants, so they were unilaterally included in their policies. One such example is the reduction of the maximum validity period of TLS certificates from 825 days to 398 days: this proposal failed at the CA/Browser Forum but was later mandated by Apple. Given that CAs must include their root certificates in all major browsers and operating systems to gain ubiquity on all devices that connect to the internet, a single root program introducing a requirement in its own policies has the net effect of requiring adherence from all CAs. Thus, the effective maximum validity period for TLS certificates became 398 days when Apple announced the policy change.

Ensuring compliance to standards

After changes to the CA/Browser Forum Baseline Requirements are agreed upon and finalized, these changes are incorporated into audit criteria that are used by auditors to ensure that CAs are adhering to the requirements. This step of translating Baseline Requirement changes into specific items that auditors check during their audit engagement is a critical part of ensuring security and compliance in the industry. Given that there is no outside visibility into the internal operations and controls in a CA, the periodic audits and auditors’ expertise and knowledge of the relevant standards play a major role in securing the certificate ecosystem. If any requirements are not clear or are not fully defined, then different auditors may arrive at different interpretations of the requirements.

When old words take on new meaning

When requirements are not fully clear and potentially ambiguous, is it inevitable that different people will arrive at different interpretations. While someone may be able to infer the meaning of a particular unclear policy by understanding the underlying intent or rationale for the existence of such a policy, other times the intent is unclear. This is especially true when each interpretation is supported by information or background that lends credence towards that interpretation. Additionally, the discussions and context surrounding a particular policy change may not have been well-documented, which makes determining which interpretation is the correct one even more complex. Oftentimes, when there is little historical context or when intent cannot be easily inferred, discussions arise later to clarify what a particular policy means. Given the initial lack of clarity which prompted the discussion, the prevailing interpretation may be surprising or unexpected. Sometimes, these clarifications are included in ballots that replace the unclear language with better text, but often, browser representatives unilaterally state that their interpretation is the correct one, effectively changing the application of the Baseline Requirements without a ballot or transition period.

Driving the industry forward with clear guidance

The policy documents which publicly trusted CAs must adhere to provide the underpinning on which internet trust is built. Given their critical role in security, clear requirements are a must. To raise the bar of the common baseline of security, stakeholders must be able to openly discuss potential ambiguities in the requirements so that they can be addressed. But for such discussion to occur, an environment that values open dialogue and sharing of ideas must be fostered. Recognizing the role of policy documents such as the CA/Browser Forum’s Baseline Requirements as the cornerstone of internet security, we are highly supportive of open discussion and continuous improvement to provide clear guidance to publicly trusted CAs.