Introduction
Public Key Infrastructure (PKI) relies on a framework of policies and practices to establish trust. Two key documents in any PKI are the Certificate Policy (CP) and the Certification Practice Statement (CPS). These documents help define the security assurances a certificate provides and how a Certificate Authority delivers them. In this article, we delve into CP and CPS in detail, differentiate between the two, and reference relevant standards (RFC 3647, RFC 6484, RFC 7382), audit criteria (WebTrust), and industry guidelines (CA/Browser Forum).
In a PKI, a Certificate Policy (CP) is essentially a high-level specification of security requirements and certificate usage rules. CP outlines what a certificate is intended for and the level of trust or assurance it provides. It describes the “boundaries and acceptable uses of certificates from a given PKI.” For example, a CP might specify that a certain class of certificates is suitable for securing TLS web servers and define the requirements (e.g., identity verification steps) for issuing those certificates.
A Certification Practice Statement (CPS), on the other hand, is a detailed description of how the Certificate Authority (CA) meets the requirements of the CP. It is “a statement of the practices that a certification authority employs in issuing, managing, revoking, and renewing certificates.” The CPS documents the operational procedures and security controls implemented by the CA. It covers aspects such as how the CA performs identity verification, how it protects its private keys, how certificates are generated, how revocations are handled, etc.
The CPS must be consistent with the CP; in fact, “the CPS describes in more detail how a CA implements a given Certificate Policy, and cannot contradict what is stated in the CP.” For example, if the CP permits issuing only email encryption certificates, the CPS cannot describe procedures for issuing TLS server certificates outside that scope.
In practice, the CP and CPS together represent the CA’s business practice disclosures; they serve as the governance framework for the CA’s operations. It is considered a best practice (and often a requirement) that the CP be publicly available to all relying parties, and most CAs also publish their CPS publicly. Some organizations choose to combine these into a single CP/CPS document for simplicity, whereas others maintain them separately.
Key aspects of a Certificate Policy
The types of certificates and their uses (e.g., authentication, digital signature, encryption), and the level of identity verification or security required for certificate issuance (often called assurance levels). Many CPs define multiple levels of assurance or certificate classes. For instance, the Government of Canada’s PKI certificate policy defines four assurance levels (Rudimentary, Basic, Medium, High) for each of two broad applications (digital signature and confidentiality), resulting in eight distinct policy OIDs within a single CP document.
Each level has increasingly stringent requirements and corresponds to a unique policy Object Identifier (OID) included in certificates. Including the policy OID in a certificate’s “Certificate Policies” extension ties the certificate to the CP’s rules, so that software or auditors can identify which policy the certificate claims to adhere to.
Importantly, a CP is often used to facilitate trust decisions and comparisons. Different organizations or CAs can map their certificates to standardized CP OIDs to indicate they meet certain common criteria. For example, the CA/Browser Forum’s Baseline Requirements document serves as a de facto Certificate Policy for publicly trusted TLS server certificates; it defines the minimum requirements that all such certificates and CAs must adhere to. Each publicly trusted CA must publicly disclose a CP/CPS that incorporates the Baseline Requirements as its policy for TLS issuance.
Certification Practice Statement (CPS) – Implementing the Policy
If a CP is the “what” and “why,” the Certification Practice Statement is the “how.” The CPS is a detailed, technical document describing the practices and procedures a CA uses to implement the requirements of one or more CPs. It is defined as “a statement of the practices which a Certification Authority employs in issuing and managing certificates.” This includes how the CA performs identification and authentication of applicants, how it generates and protects keys, how it issues and delivers certificates, how it publishes revocation information, and other operational details.
A CPS is typically written from the perspective of the Certification Authority’s operations and is used by auditors, internal security teams, and policy authorities to verify that the CA’s actual practices are consistent with the policy.
Unlike CPs, which are often set by a policy authority or industry group, a CPS is usually authored by the CA itself (or the organization running the CA) to document its concrete measures. Many CAs do make their CPS public (especially public trust CAs for transparency), though in some private or internal PKIs a CPS might be kept internal and only shared with relying parties, auditors or partners.
Typical content of a CPS includes:
The organizational responsibilities (roles like CA, Registration Authority, etc.), procedures for identity verification, certificate lifecycle management, facility and personnel controls, technical security controls (cryptographic module standards for HSMs, key generation ceremonies, key protection, backup and recovery, etc.), certificate and CRL/OCSP profiles, and compliance/audit requirements. The RFC 3647 framework, as we will discuss, provides a standardized outline of these topics that most CPS documents follow.
One key rule is that the CPS must not contradict the CP. It can be more specific or restrictive, but it cannot loosen a requirement stated in the CP. For example, if the CP requires identity verification in-person with a government ID, the CPS cannot allow verification via email alone, that would conflict with the CP. Conversely, a CPS might add extra practices that go beyond the CP (as long as they don’t undermine the CP’s requirements).
CP vs. CPS: Differences and Relationship
It’s clear that CP and CPS are closely related and complementary. A simple way to remember the difference is: the CP is the strategy, and the CPS is the tactics. The CP focuses on what objectives or assurances must be met (and for whom), while the CPS focuses on how to achieve them in practice. Below is a comparison of key aspects of CPs and CPS documents:
| Aspects | Certificate Policy (CP) | Certificate Practice Statement (CPS) |
|---|---|---|
| Purpose | Defines what the certificate is intended for, and what security assurances or requirements apply. It’s a high-level set of rules or criteria for certificate usage. | Describes how the CA meets the policy’s requirements. It is a detailed statement of the practices, detailing operational procedures for issuing and managing certificates. |
| Focus & Audience | Focuses on the needs of relying parties and the trust community. Allow users or CAs to determine whether to trust certificates issued under this policy. Often set by a Policy Authority or industry group. | Focuses on the CA’s internal operations and controls. Used by auditors and internal PMAs to ensure the CA is following required practices. Authored by the CA (or operating organization) itself, aligning with the CP’s demands. |
| Content | High-level requirements, scope, and applicability. Includes certificate uses and applicability (e.g., “client auth for healthcare providers”), assurance level definitions, and broad requirements (e.g., “identity must be verified in-person by a notary”). Each policy is identified by an OID in issued certificates. | Detailed procedures and technical controls. Covers day-to-day operational details: identity proofing steps, cryptographic practices (HSM details, key lengths), physical security, personnel security, incident response, etc. Often structured in sections like: I&A (Identity & Authentication), Certificate Life-cycle operations, Facility/Personnel controls, Technical security controls, etc. |
| Multiplicity | One CP can govern multiple CAs or a whole PKI, and one document can contain multiple related policies (for example, multiple assurance levels or certificate types). Also, a CA may assert multiple CP OIDs in a certificate if it meets all those policies. | Typically, one CPS per CA (or CA family). However, a single CPS document can cover multiple CPs if the CA issues under each, the CPS will note any differences in processes for each policy. Sometimes, organizations merge CP and CPS into a single document for simplicity. |
| Governance & Changes | Changes to CP might require approval by a Policy Management Authority (PMA) or external body, especially if it’s an industry or cross-certification policy. Often versioned and controlled at a higher level (e.g., CA/Browser Forum for Baseline Requirements). | Changes to CPS are usually made by the CA (with PMA oversight) and must be reflected in practice. Public CAs are required to review and update CP/CPS at least annually. Significant CPS changes might be reported to auditors or root programs to ensure continued compliance. |
Standards and Frameworks for CP and CPS
RFC 3647 – A Framework for CP and CPS
To bring consistency to how CPs and CPSs are written, the IETF published RFC 3647: “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework” in 2003. RFC 3647 provides a standardized outline (framework) of topics that a CP or CPS document should cover. The goal was to make it easier for policy writers and readers (including auditors and cross-certifying entities) to find and compare information across different CP/CPS documents.
RFC 3647’s framework is organized into several major sections (often nine or ten sections, with further sub-sections) that can be used for both CP and CPS documents. The main headings include:
- Introduction (and scope, document identification, etc.),
- Publication and Repository Responsibilities,
- Identification & Authentication (i.e., how identities are vetted),
- Certificate Life-Cycle Operational Requirements (covering certificate application, issuance, acceptance, revocation, renewal, etc.),
- Facility, Management, and Operational Controls (physical security, personnel security, audit logging, etc.),
- Technical Security Controls (key management, cryptographic controls, computer security, lifecycle security controls),
- Certificate, CRL, and OCSP Profiles (the technical certificate format details),
- Compliance Audits and Other Assessments,
- Other Business and Legal Matters (disclaimers, financial responsibility, privacy, confidentiality, etc.).
By following this common structure, a CP and a CPS for the same CA will cover the same categories of information, making it straightforward to see how the CA’s practices (CPS) satisfy each policy requirement. It also greatly aids policy mapping – for example, the U.S. Federal Bridge CA’s CP and an external entity’s CP can be compared section by section to determine equivalence before cross-certification.
Most modern CPs and CPSs are written in alignment with RFC 3647. In fact, industry bodies have mandated this. The CA/Browser Forum (which governs publicly trusted CAs) updated its Baseline Requirements in 2015 to “include all sections of the RFC 3647 framework” and required that CAs structure their CP/CPS documents according to RFC 3647. The Baseline Requirements (v1.3.0 and later) themselves were converted into RFC 3647 format (essentially treating the Baseline Requirements as a giant CP) to facilitate easy comparison and compliance checking.
Section 2.2 of the Baseline Requirements explicitly states: “The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647.” It also requires CAs to clearly indicate which parts of their CP/CPS apply to which roots or subordinate CAs, and to include statements of compliance with the Baseline Requirements in their CP/CPS.
Similarly, the WebTrust for CAs audit criteria (used by auditors to assess public CAs) recommends the use of RFC 3647. The latest WebTrust Principles and Criteria for CAs (v2.2.2) notes that CAs should “structure their CP and CPS documents in accordance with IETF RFC 3647”, and advises CAs still using the older RFC 2527 framework to transition to RFC 3647. In practice, following RFC 3647 means a CP and a CPS will have aligned sections. It’s common to see CPS documents with section numbering mirroring the CP.
If a particular section is not applicable or the policy imposes no requirements, the documents often explicitly say “No Stipulation” (per industry guidance) rather than leaving it blank. This tells readers that the omission is intentional. For instance, if a CA does not allow certificate suspension, the CPS section on “Suspension” would state “Not applicable, the CA does not suspend certificates”
RFC 6484 – Certificate Policy for the RPKI
RFC 6484 is a specific Certificate Policy: “Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)”. The RPKI is a specialized PKI used to secure Internet routing (by issuing certificates for IP address blocks and AS numbers). RFC 6484 serves as a common, agreed-upon CP for all participants in the RPKI, such as the Regional Internet Registries (RIRs). Notably, RFC 6484 was structured using the RFC 3647 template (as is common).
This means it has the familiar sections for Introduction, Identification & Authentication, etc., tailored to the RPKI context. For example, it will include sections on what identification is required for an entity to get an IP address certificate, operational requirements like how quickly revocations must be published, and so on.
RFC 7382 – CPS Template for the RPKI
To complement the RPKI’s CP (RFC 6484), the IETF also provided RFC 7382: “Template for a Certification Practice Statement (CPS) for the RPKI”. This document, published in 2015, is essentially a boilerplate CPS tailored to the RPKI environment. It takes the RFC 3647 structure and fills in guidance or examples specific to RPKI operations. For instance, it covers how an RPKI CA (like an RIR) should handle key rollovers, how they should make repository data available, etc., in line with the RPKI’s needs.
WebTrust Principles and CAB Forum Guidelines
Beyond the IETF, industry auditors and forums have their own requirements related to CP/CPS:
- WebTrust for Certification Authorities: As mentioned, WebTrust criteria strongly encourage (and effectively require for public CAs) that a CA has a CP/CPS and that it conforms to the standard framework. WebTrust auditors will check that the CA discloses its key and certificate lifecycle practices, typically via a CP/CPS document, and that the CA actually follows those disclosed practices.
- In WebTrust audits, any external Registration Authorities (RAs) that a CA uses are expected to comply with the relevant provisions of the CA’s CP/CPS, underscoring that the CP/CPS is the authoritative source for what an RA is allowed to do. WebTrust explicitly defines CP and CPS in its guidance: “A CP is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application… and describes the boundaries and acceptable uses.”“A CPS is a statement of the practices which a CA employs in issuing and managing certificates.”
- CA/Browser Forum (CABF): For publicly trusted CAs (the ones included in browsers and OS trust stores), the CA/Browser Forum’s guidelines are paramount. The Baseline Requirements (BR) can be viewed as an overarching CP that all such CAs must incorporate. The BRs require CAs to have a CP/CPS and to make them public. Specifically, Section 2.2 of the BRs mandates 24/7 online availability of the CP/CPS and that these documents be in a text-based format (like PDF) and in English (or an English translation).
- The BRs also require that the CP/CPS clearly identify which certificates (roots, sub-CAs) they apply to. As noted earlier, the BRs require CP/CPS to follow RFC 3647 format. They even provide a mapping table to align older BR versions to the new RFC 3647 sections, and guidelines that every subsection should be filled (even if just with “No Stipulation”) to ensure nothing is overlooked.
- Additionally, CABF guidelines like the EV (Extended Validation) Guidelines require specific content in the CP/CPS – for example, EV certificate issuers must include a specific policy OID in EV certificates and assert in their CP/CPS that they follow the EV Guidelines.
- The Mozilla Root Store Policy (which incorporates CABF requirements) also checks that the CP/CPS contains certain statements, such as a commitment to comply with the CABF Baseline Requirements and details on how the CA processes CAA DNS records (this is actually a BR requirement that must be reflected in CP/CPS). Moreover, the CABF BRs require that CAs review and update their CP/CPS at least annually (even if no changes are made, they must increment a version number and date). This ensures that the documents stay current with evolving requirements and practices.
In summary, the combination of RFC 3647 and industry requirements has made the structure and maintenance of CP/CPS fairly uniform across the industry. This uniformity greatly improves transparency and interoperability: a relying party or auditor can navigate any CP/CPS and find where it talks about, say, identity proofing (section 3 of RFC 3647) or key management (sections 6) and compare it to another CA’s documents or to the expected standards.
How can EC Help?
Encryption Consulting LLC (EC) supports the development of the CP/CPS draft and PKI compliance:
Encryption Consulting LLC offers specialized expertise in developing Certificate Policy (CP) and Certification Practice Statement (CPS) documents to ensure a client’s Public Key Infrastructure (PKI) is compliant, secure, and aligned with industry standards. Their consultants leverage the RFC 3647 as a template for CP/CPS documentation, ensuring all required sections and controls are addressed in accordance with best practices.
This means the CP/CPS documents follow the internationally recognized format (covering areas such as identification, authentication, operational controls, and technical security controls) and meet guidelines such as the CA/Browser Forum baseline requirements and the WebTrust criteria for CAs. Importantly, Encryption Consulting tailors these policy documents to the organization’s unique environment, aligning with internal governance needs and specific compliance obligations.
Gap Analysis and PKI Compliance Assessments
Beyond document drafting, Encryption Consulting assists clients through comprehensive PKI assessments and gap analyses to achieve compliance readiness. Their PKI Assessment services include a detailed gap analysis that examines cryptographic practices, operational procedures, and existing policies. This process identifies any gaps between the current state and industry best practices or required standards, uncovering vulnerabilities or non-compliant areas that could jeopardize the PKI.
As part of these assessments, Encryption Consulting performs a focused policy assessment – reviewing the organization’s existing CP and CPS documents to ensure they align with relevant industry standards. Any misalignments with standards like NIST guidance, ISO 27001, or other regulatory frameworks are flagged for remediation. By pinpointing weaknesses in governance, certificate practices, or technical controls, Encryption Consulting prepares organizations to pass audits (whether internal, external, or WebTrust for public CAs) with confidence.
Their reports and guidance serve as a roadmap to strengthen PKI security and ensure continuous compliance, rather than just a one-time audit pass. This proactive approach means clients can address issues before they lead to audit findings or security incidents, thereby maintaining a trustworthy and compliant PKI over time.
Conclusion
CPs and CPSs embody the principle of “trust, but verify.” They are the documents that let us verify why we should trust a digital certificate and how that trust is being managed. In a world increasingly dependent on PKI from HTTPS and code signing to smart grid and IoT device identity, these policies and practice statements will continue to play a critical (if often behind-the-scenes) role in cybersecurity.
