Understanding Certificate Policies and Practice Statements
Public key infrastructure (PKI) is the sort of technology that most users take for granted. They use it every day in a variety of ways but most don’t even realize it. PKI manages the digital certificates that encrypt sensitive data, secures web browsing (SSL/TLS), validates the integrity of software and electronic devices through code signing, authorizes user access and much more.
The reason PKI is so seamless and transparent is that a lot happens behind the scenes—security professionals definitely don’t take it for granted. In fact, most mature organizations that work with PKI have a codified set of policies and practices around it, which are published as a certificate policy (CP) and a certification practice statement (CPS).
A Framework for Policies and Practice Statements
RFC 3647 established a framework for CP and CPS in 2003. A CP is used to establish the controls of the issuing party and the roles and responsibilities of its entities. A CPS is used to further detail the process of issuing and managing certificates. For example, if a CP states that it will validate domain ownership, then its CPS might state it will examine its DNS. If a CP is a strategy, a CPS is its tactics.
CP and CPS can serve as a competitive advantage for organizations to provide assurance to their partners (e.g. WebTrust, one of the largest PKI standards, requires CP and CPS), similar to the way an organization can prove it is trustworthy by attesting to cybersecurity standards like ISO and SOC. However, the process of detailing CP and CPS information can be just as time-consuming and arduous as an audit. For example, the Amazon Trust Services Certificate Policy and Certification Practice Statement total more than 125 pages.
CPs tend to be created for a couple of reasons. Some are designed for specific verticals or geographical locations, while others are designed for a specific set of applications with common security requirements. These application-specific CPs tend to include various assurance levels and their corresponding requirements.
An organization may establish multiple policies in a single document (e.g. some for SSL and others for validating code). For each use case, an organization may also establish multiple levels of assurance, from the most basic of security controls to the most advanced. As a result, a single document may branch into two, four, even eight or more types of certificates, depending on the application use case and the sophistication of the security assurance.
Next, a CPS details the technical and operational controls and processes an organization employs when issuing certificates. These may include certificate management, publication, archiving, revocation, renewal and re-keying. Most frequently, a CPS details all of these practices, but some PKIs may not need or want to be as detailed; in some cases they are already trusted by the certificate authority (CA) and in others they may want to avoid disclosing too much sensitive information.
RFC 3647 outlines a set of provisions organizations should use to articulate their practices and processes, including identification and authentication, certificate lifecycle operational requirements, operational security controls and technical security controls. Although many topics are covered, it is perfectly reasonable for an organization to detail “no stipulation” for any particular requirement. In this way, these provisions should be considered a checklist for creating a CP & CPS.
Establish Effective Certificate Policy and Practice Statements
Establishing an effective CP and CPS is as much of an art as it is a science. If the provisions for a certificate are too loose, then it may be a source of risk; if they are too tight, then it may be a source of management friction. If something proves too difficult to manage, then it is okay to develop new policies and practices. As new best practices emerge, an organization may want to revise their CP and CPS to include them. If new compliance regulations are introduced, an organization may be forced to include them.
CP and CPS are necessarily living documents and it takes experience to get them right. This can be a challenge for small and medium-sized enterprises that may lack the internal resources or know-how, but this is also an opportunity to move ahead of their competition if they get it right. Some PKI vendors recognize this challenge and are willing to lend their expertise to help smaller organizations develop CP and CPS, but other vendors take it for granted that their customers will figure it out on their own. As organizations consider their PKI needs, it would be wise to align with vendors that value their requirements for CP and CPS. And as more organizations develop more mature PKI CP and CPS, the industry as a whole will become more secure.