Chapter 4

PKI Management and Security

In Chapter 1, “Introduction,” we mentioned that this book addresses public key infrastructure policies, standards, practices, and procedures. We also discussed industry standards organizations, including ANSI, IETF, ISO, NIST, RSA Labs, W3C, and X9 who have all published PKI-related standards. While some businesses rely entirely on industry standards, others feel compelled to develop and maintain their own internal standards. Regardless whether a business depends on external standards, internal standards, or both, standards play a special role between policies and practices.

Policy statements are basically high-level requirements, essentially goals that define “what” needs to be achieved. Practices are fundamentally statements of fact that identify “how” the goals are met. However, in order for the practices to be effective, detailed requirements are typically needed, which can be addressed by standards. Standards can fulfill the middle ground between policy and practices. For example, a policy statement might be the following:

• Example policy statement: Cryptographic keys shall be managed in a secure manner.

Attempting to write a corresponding practice statement from such a high level, rather generic policy statement gives a relatively meaningless, unsubstantiated claim:

• Example practice statement: Cryptographic keys are managed in a secure manner.

Another approach might be to write practice statements at a more detailed level using the key lifecycle introduced in Chapter 2, “Cryptography Basics”:

• Example 1: Keys are generated in compliance with approved methods.
• Example 2: Keys are distributed in compliance with approved methods.
• Example 3: Keys are used in compliance with approved methods.
• Example 4: Keys are backed up in compliance with approved methods.
• Example 5: Keys are revoked in compliance with approved methods.
• Example 6: Keys are terminated in compliance with approved methods.
• Example 7: Keys are archived in compliance with approved methods.

However, even these practice statements are still too high level to be meaningful as the “approved methods” remain undefined. Attempting to write more detailed practice statements would rapidly become tedious and difficult to manage. Consider the first example key generation methods:

• Example A: Key generation methods include approved random number generation (RNG) algorithms.
• Example B: Key generation methods include approved pseudorandom number generation (PRNG) algorithms.
• Example C: Key generation methods include approved prime number generation (PNG) algorithms.
• Example D: Key generation methods include approved domain parameter generation (DPG) algorithms.
• Example F: Key generation methods include approved key derivation function (KDF) algorithms.

Clearly, this approach is rather unwieldy as it still contains somewhat vague claims with regard to algorithms and approvals. If the seven high-level practice statements listed earlier are expanded into several detailed practice statements such as the five listed, then the single example policy statement might have 35 or more practice statements. Furthermore, if the overall policy has dozens of high-level statements, then there might be thousands of detailed practice statements. Obviously, developing and maintaining such documentation would be complicated and costly, and likely apathy would allow staleness and its eventual demise.

A more succinct approach might be for the policy statements to reference industry standards whose requirements (“shall”) and recommendations (“should”) can consequently be referenced in the practice statements, which subsequently provide the basis for procedures. Conversely, the procedures support the practices, which in turn are based on standards, which provide a foundation for the policies. Figure 4.1 shows the relationships between policy, standards, practices, and procedures. However, there is often a standard gap between what standards require or recommend, what the vendor product offers, and what the product deployment provides, such that the management of the system frequently needs to compensate by means of the procedures.

Product gaps might occur when an implementation ignores the relevant standard recommendations or misinterprets the requirements such that the product lacks complete capabilities. Deployment gaps can occur when the product implementation does not conform to the guidelines resulting in misconfigurations, inadequate controls, or inappropriate use. Management gaps may occur when applications are improperly operated, including insufficient staffing, inadequate monitoring, and/or lack of maintenance. Adequate policies, relevant standards, good practices, and appropriate procedures can overcome various security gaps. For the purposes of this book, we focus on the policy, practices, and procedures for operating a public key infrastructure, and for this chapter, we refer to standards for X.509 v3 certificates, certificate revocation list (CRL), Online Certificate Status Protocol (OCSP), certificate policy (CP), and certificate practice statement (CPS).

In Chapter 3, “PKI Building Blocks,” we discussed various PKI-related standards defining X.509 certificates, certificate revocation lists, and Online Certificate Status Protocol, including ITU-T standards X.509, international standards ISO/IEC 9594, and IETF specifications RFC 2560, RFC 3280, RFC 5280, and RFC 6960. In addition, the IETF specifications define the certificate policy and certificate practice statement in the original RFC 2527 and the revision RFC 3647. In this chapter, we focus on developing the CP and provide CPS examples for small, medium, and large organizations.

It is important for the reader to recognize that industry standards for security procedures do not exist. Security procedures are specific to the application architectures, information technologies, and cryptographic products such that it is not practicable to develop a generic procedure. It is likewise not feasible to develop customized procedures for hundreds, thousands, or perhaps millions of possible combinations for vendors, products, releases, technologies, architectures, and business services. Certification programs have similar problems in that an evaluation can only address the specific hardware, firmware, and software components. Consequently, procedures need to be tailored to each particular instance. Furthermore, it is difficult to discuss policies or practices in a vacuum, so for the purposes of this book, we offer a series of scenarios, which begin with Figure 4.2.

In our example, the ABC Corporation campus consists of two facilities, an office building and a separate data center, surrounded by a perimeter fence with access from a public road. Access to the campus is from a public road to a private road with a gated entrance. The building entrances are located opposite of each other; the office building entrance is on the west side, and the data center building is on the east side. There are “invisible” barriers in front of each entrance and between the two buildings consisting of mounds populated with trees and large rocks. Along the sides of both buildings are employee and guest parking. The gate has one “in” lane and one “out” lane. The “in” gate is badge activated for employees and has a guard available during working hours for visitors. The “out” gate automatically opens for any departing vehicle. Next, let’s zoom in to the office building shown in Figure 4.3.

As mentioned earlier, there is an invisible barrier in front of the entrance doors, which are badge activated after hours but unlocked during working hours. The internal doors to the office area are badge activated 24 × 7, but the front desk is attended during working hours. Visitors are required to have employee escorts. The office area is separated from the eastern adjacent area by another set of doors that are kept unlocked during working hours but badge activated after hours. The restrooms, conference rooms, executive offices, and special rooms are located in the adjacent office space. One of the special rooms is the PKI room. There are also two emergency exits located in the eastern adjacent area. Now let’s zoom into the data center building shown in Figure 4.4.

The primary data center is the building located east to the office building. It has the same invisible barriers, front entrance, guard desk, restrooms, and emergency exits. Unlike the office building, however, the front door is badge activated 24 × 7, but the guard is only present during working hours. The data center is a typical open area with equipment racks lined up in the middle of the room for optimal air circulation and HVA units along the outer walls. The PKI racks are individually locked cabinets containing dedicated PKI cryptographic modules, servers, databases, switches, uninterrupted power supplies (UPS), and other equipment. There are two offices located on the eastern side of the building and two storage rooms located on the western side. This is a 24 × 7 manned facility so at least one person is on-site.

Conversely, the backup data center is hosted by the XYZ Company, a third-party hosting provider with a data center located in another city. The backup facility is a multitenant environment that provides power and environmental controls but operates as a “lights-out” facility. Equipment installation and maintenance is performed by the individual tenants who must coordinate physical access with the vendor and otherwise rely on remote network access. There is few staff on-site and only during normal working hours.

Now let’s explore the security policies and practices for the scenarios. As mentioned earlier, we will refer to various standards as needed, but we will not present nor dissect any individual standards within this chapter. Some security information might be intended for public consumption. Other security information might be proprietary and limited to controlled distributions such as under a memo of understanding (MOU), nondisclosure agreement (NDA), or some other relevant agreement. Yet certain security information is always confidential and kept secluded within the organization. In some cases, the security information is managed on a need-to-know basis with restricted access to authorized personnel.

In the late 1990s, technical interoperability between organizations’ PKI was possible, but from an operational and business perspectives, it was yet problematic. To that end, the IETF published RFC 2527 in 1999 as a framework to assist the writers of certificate policies or certification practice statement for certification authorities and public key infrastructures. The idea of a common data structure to automatically evaluate policies was embraced by government agencies and other organizations. In fact, policy engines were developed to match commonalities and identify differences. Several models were proposed, allowing for low, medium, and high assurance PKI systems, and there were even ideas of rudimentary PKI with little or no security controls. Many of the certificate class levels available today arose from these early low, medium, and high concepts. However, without a common “policy” language, the interpretation of human readable sentences was problematic.

Regardless, the concept was for two previously unknown PKI systems to exchange policies with the intent to determine their respective levels of trust before accepting certificates. At the onset, when a sender and receiver exchange digital certificates, the respective PKI systems would also inspect each other’s policies. For example, if the PKI systems operate at significantly different assurance levels, then the higher-assurance PKI might reject the lower one. Alternatively, the higher-assurance PKI might accept the lower-assurance PKI but limit the certificate use to low-risk transactions. For this level of sophistication, the policies would need to be unambiguous, contain sufficient information for automation, and use consistent terminology.

The IETF specification was updated as RFC 3647 in 2002 with coordination with the American Bar Association (ABA) Information Security Committee (ISC) within the Section of Science and Technology Law. The ISC wrote the PKI Assessment Guidelines [B.7.14] that embodies a great deal of technical, business, and legal experience in PKI operations. Some of the sections were restructured; however, many of the sections remained unchanged, with the significant addition of §9, “Other Business and Legal Matters,” which contains business and legal topics including fees, financial responsibility, confidentiality, intellectual property, and privacy. Meanwhile, we make an important observation between the RFC 2527 and RFC 3647 abstract statements:

RFC 2527: This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures.

RFC 3647: This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates.

Notice that RFC 2527 includes CA and PKI within its scope, but RFC 3647 refers to PKI with the CA as an example. This is a significant focus change in that a CP (or CPS) is not just for an operational CA that issues certificates but necessary for a more general PKI-enabled application that might use its own certificates, certificates issued from another PKI, or assist in the certificate issue process such as a registration authority (RA). RFC 3647 rapidly became the PKI de facto standard across numerous industries. Security professionals and auditors alike depend on CA policies and practices written in this format:

• §1. Introduction
• §2. Publication and Repository Responsibilities
• §3. Identification and Authentication
• §4. Certificate Lifecycle Operational Requirements
• §5. Facility, Management, and Operational Controls
• §6. Technical Security Controls
• §7. Certificate, CRL, and OCSP Profiles
• §8. Compliance Audit and Other Assessment
• §9. Other Business and Legal Matters

Each section addresses a specific set of topics that are numbered as subsections. If the topic is not relevant, then the expected statement is “no stipulation” rather than deleting the subsection to avoid renumbering, which would affect the document’s overall structure. Additional topics can be added as new subsections, but care must be taken to avoid renumbering. Again, the idea is to keep the document format consistent for readability and comparison with other policies. Some organizations insist on restructuring the certificate policy according to corporate standards; however, this is a bad practice. The numbering scheme and content must be kept consistent in order for security assessment and audits to be performed.

Renumbering or changing the certificate policy structure adversely affects its usefulness—consistency is mandatory for security assessments and audits.

According to the RFC 2527, the concept of separate documents for the certificate policy versus the practice statement was never intended. In fact, the original concept was a single document that contained both policy and practice statements. However, experience has shown that publicly available practice statements, if too detailed, can inadvertently reveal too much information about the organization’s security processes. Yet today, most certificate authorities publish only a CPS, many with combined policy and practice statements. Conversely, insufficient details in a general CPS are not very useful during an audit. Some organizations have developed two CPS, one for public consumption and another for internal use. In any case, the organization will still need to have detailed operational procedures. Table 4.1 shows the recommendations advocated by this book.

The X.509 v3 structure includes the certificate policy extension. This extension allows the CP or CPS to be uniquely labeled using an object identifier (OID) and possibly a web page link to download the document. The RFC specification recommends for interoperability purposes that the extension only contains a standard OID as defined in the specification. However, it is more common to see a proprietary OID and a uniform resource identifier (URI) in this extension, which allows the CP or CPS to be uniquely identified and discoverable. It is important to recognize that providing a URI in this extension implicitly makes the document publicly available. Interestingly, the extension is named certificate policies and not certificate practice statements, so pointing to a CPS is inconsistent with the extension’s purpose. Furthermore, the RFC specification does not recognize an extension for CPS.

Regardless whether a CP or CPS is made public, an obvious but necessary item is a cover sheet with a meaningful title. At a minimum, the title should contain the document purpose, organization name, date, and version number. The cover sheet should also include the data classification and any other pertinent information such as the company logo, copyright date, corporation division name, or application name. For a graphic depiction, see Figure 4.5.

4.1 Introduction

A typical approach for any technical specification is an introduction section that sets the stage for the remainder of the document. The CP is no different, and its first segment is §1 “Introduction,” which is composed of six subsections. Depending on the chosen format style, the RFC 3647 §1 might contain introductory text or exist as only a placeholder for the subsections. For example, the ISO style does not permit text between two subsequent headings. Organizations can write the CP in almost any style as long as the section numbering and content remains consistent with the RFC 3647 specification as provided in its §6 “Technical Security Controls.”

The RFC 3647 §1.1 “Overview” subsection is intended to provide general information about the PKI such as a graphical representation of the PKI components or certificate assurance levels. The PKI elements for our hypothetical ABC Corporation are shown in Figure 4.6. There are two separate hierarchies, one for internal use and the other for external entities. The diagram shows the various hierarchical levels of each CA structure. The highest level is called a root CA and is operated in an offline mode, physically isolated from any network connection. The lower levels are called subordinate or intermediary CA and are operated in an online mode, connected to the organization’s network. In our example, the internal CA uses an “A” numbering scheme, and the external CA uses a “B” number scheme:

• The internal CA root is “A” with the next level consisting of A.2 for e-mail certificates and A.3 for VPN certificates. In this example, there is no A.1 per se but merely a placeholder to keep the numbering scheme consistent. The lowest online level consists of A.1.1 for TLS certificates, A.2.1 and A.2.2 for e-mail certificates, and A.3.1 and A.3.2 for VPN certificates. The e-mail certificates are further divided into those for verifying signed e-mails and those for encrypting e-mails. The VPN certificates, which are used for remote access into the network are separated into those issued to employees and contractors. The TLS certificates are used for internal application communications.
• The external CA root is “B” with the next level consisting of a B.1 external CA. The lowest online level consists of B.1.1 for TLS certificates, B.1.2 for VPN certificates, and B.1.3 for code sign certificates. The code sign certificates are used to verify executable code which has been digitally signed. The VPN certificates are used for remote access into the network. The TLS certificates are used for external application communications.

Note that the number scheme could have been anything, such as A2, A2, A11, and A21. The important aspect is that each CA needs a unique identification. This is needed not only for the certificate chain validation but also for accuracy in the CP and CPS. The CA certificates must be clearly referenced in the policy such that no ambiguity exists. If the CA names in the certificates do not match the names in the policy, then there is uncertainty which controls apply to which CA system. Exactness in the language is paramount for clarity and consistency. A well-articulated CA hierarchy diagram adds tremendous value to the policy document.

Certificate assurance levels are a reflection of the original aforementioned low-, medium-, and high-security PKI models. The assurance level conveys the overall trustworthiness of the certificate to the relying party or any other third party. Each assurance level indicates that certain conditions are or were true. To explore this further, let’s reexamine the key management lifecycle introduced in §2.4, “Key Management,” from the perspective of an asymmetric key pair as shown in Figure 4.7. All of the state nodes and transitions occur but not always by the same party. The key owner actions are represented in the red zone, and the relying party actions are shown in the green zone.

The key owner (Party A) is the legitimate proprietor of the asymmetric key pair and whose name is represented in the public key (digital) certificate. The owner holds the private key and basically “advertises” out the use of the public key by means of the digital certificate. In general, the key owner takes the following key management actions with regard to the key lifecycle:

• Key generation: The key owner generates the asymmetric key pair, or a trusted third party generates the key pair and obtains the corresponding digital certificate from a CA.
• Key distribution: The key owner installs the private key on the system that houses the application, which will use the private key. Note that the system used to generate the key pair might very well be the same system to use the private key.
• Key usage: The key owner might use the private key to generate digital signatures on messages or data, decrypt data that were encrypted using the public key, or establish a symmetric key.
• Key backup: The key owner might backup the private key for recovery purposes if the private key is lost due to system failure or might simply generate a new key pair.
• Key revocation: The key owner might need to revoke the certificate before its valid expiration for a variety of reasons, including a private key compromise, cessation of operations (the key owner goes out of business), or due to a merger or acquisition that renders the certificate information invalid.

The relying party “borrows” the key owner’s certificate and, therefore, depends on the certificate assurance level as indicated by the CA. Thus, the relying party is an end user of the certificate with certain expectations that the key owner is managing the corresponding private key over the key lifecycle using adequate controls and that the certificate has been issued with respect to the conditions laid out in the CPS. However, the relying party is involved in the key lifecycle and takes the following actions:

• Key distribution: The relying party gets a copy of the digital certificate. Depending on the application environment and the certificate scheme, how the relying party obtains the certificate will vary. For example, if the relying party is using a browser to connect to an application server that supports TLS, the key owner’s TLS certificate is exchanged during the protocol handshake, but the CA certificates are preinstalled by the browser manufacturer. As another example, if the relying party is also using a client server to connect to the application server, the application server’s TLS certificate is likely exchanged between the two organization’s engineering staff and preinstalled on the client server. For e-mail certificates, the sender might attach their certificate to the e-mail. For VPN certificates, the registration process might automatically collect and publish the certificate to a corporate repository.
• Key usage: The relying party might use the public key certificate to verify a digital signature, encrypt data, or encrypt a shared secret for key transport, or be used as part of a key agreement scheme with other certificates.
• Key revocation: The relying party, as part of its certificate validation process, checks not only the certificate validity dates but the revocation status. Once a certificate has been revoked, the relying party ceases to use the certificate.
• Key archive: The relying party might archive the certificate past its expiration date for validation of older information. Revoked certificates might be also archived, but if the revocation was due to a key compromise, the reliance of the certificate is questionable.

Certificate assurance levels provide an overview of the security controls imposed by the CA and those presumably followed by the key owner as the certificate subject. Some controls are needed regardless of the assurance levels, some can be relaxed for lower assurance levels, while others are only required for higher levels.

Key generation: The key owner needs to use certified or at least recognized random number, prime number, and key generation algorithms. Predictable numbers or non–prime numbers can affect the key generation process, as can invalid procedures. If a key pair can be duplicated by another party other than the key owner, then the private key has become unknowingly compromised. The cryptographic module used to generate the key pair is an important aspect of the overall assurance levels. Refer to Table 4.2 for control illustrations.

Once the asymmetric key pair has been properly generated, the key owner can then begin the process of obtaining a digital certificate for the public key. The key owner submits a certificate signing request (CSR) to a CA by signing the public key with the private key to demonstrate ownership. The signature does not authenticate the key owner; rather it only provides cryptographic proof that the requestor had access to the corresponding private key. The CA authenticates the requestor to the extent that the name in the certificate represents the key owner or the key owner’s agent. Refer to Table 4.3 for control illustrations.

For the high and medium assurance levels, if the CA has never established authentication credentials with the requestor, then the CA must conduct an initial authentication to confirm the requestor’s identity and authority to request the certificate. The initial authentication process will vary depending on the certificate type and the CA responsibilities. For example, a commercial CA that issues extended validation (EV) certificates for TLS or code signing must follow the WebTrust for EV audit guidelines [B.7.15] now managed by the CA Browser Forum.

Key distribution: The key owner must install the private key for usage. If the key pair is generated by a different system than the usage system, then the key owner must ensure the confidentiality, integrity, and authenticity during its distribution to avoid a compromised key or a man-in-the-middle (MITM) attack as discussed in Chapter 2, “Cryptography Basics.” Refer to Table 4.4 for control illustrations.

For the high and medium assurance levels, the key owner also enlists the aid of an independent auditor to oversee that the key transport was accomplished per documented procedures. Without documented procedures or an audited ceremony, the assurance level is basically an unsubstantiated claim with no material evidence as reasonable proof.

Key usage: The key owner must use the private key only for its intended purpose, protect it from disclosure, maintain access control to prevent unauthorized access, and monitor its usage for availability and accountability purposes. Refer to Table 4.5 for control illustrations.

For the high assurance level, the private key never appears as cleartext outside the cryptographic hardware model. For the medium and low assurance levels, the private key is stored locally on the application system either as an encrypted (ciphertext) key or as a cleartext object using system access controls. If the private key is stored as ciphertext, then a key encryption key (KEK) must exist. The KEK is then either stored as a cleartext object using system access controls or dynamically recreated based on an end user entering a key encryption password.

Key backup: The key owner might maintain a copy of the private key for recovery purposes in the event that an application component has a malfunction, which causes a key erasure. Recovery is only viable when the private key has not been compromised and the failure can be attributed to a benign event. Refer to Table 4.6 for control illustrations.

Key recovery using spilt knowledge methods discussed in §2.4 “Key Management” is similar to key distribution methods mentioned earlier. The private key can be stored as M key shares on various form factors such as smart cards or USB devices that must be PIN activated but only requires N participants to recover the private key. Alternatively, a lost private key can be replaced with a new key pair and certificate; however, this depends on the nature of the application and the ease of distributing the certificate to relying parties.

Key termination: At the end of the key lifecycle, the key owner must destroy all instances of the private key, including any recovery copies. This is a common control as any remaining copies might be misused in an unauthorized manner. There are no control differences for any of the assurance levels, so the key destruction is equally applicable to each of the assurance levels.

Another valuable topic within §1.1 not mentioned in the RFC 3647 specification is a scoping statement. For example, the ABC Corporation might have separate CP for its internal CA and another for its external CA. In this scenario, the CP would identify the existence of both CA but clearly indicate its scope was limited to the internal CA and explicitly state that the external CA was out of scope. Also, the title of the coversheet might be revised to reflect the narrower scope—for example, Certificate Policy of the Internal CA for the ABC Corporation.

The RFC 3647 §1.2 “Document Name and Identification” subsection is meant to provide pertinent names and relevant identifiers. An important piece of information would be the complete names of each PKI component within the scope of the CP. Names occurring within certificates are based on the X.500 attribute types:

• CN is the common name
• L is the locality name
• ST is the state or province name
• O is the organization name
• OU is the organization unit name
• C is the country name
• STREET is the street address
• DC is the domain component
• UID is the user identifier

For example, if the CP scope was the internal CA depicted in Figure 4.6, then the names of each CA can be listed. Table 4.7 shows the eight CA systems and their common names, organizational names, and domain component names.

Another important bit of information is the organization’s object identifier arc registered with the Internet Assigned Numbers Authority (IANA). For example, the ABC Corporation might have the following OID arc: joint ISO ITU (2), country (16), United States (840), organization (1), and ABC Corporation (nnnnnn), which is often written as the following:

2.16.840.1.nnnnnn

Note that since the ABC Corporation is hypothetical, no actual organization OID has been registered with the IANA. The CP might be assigned an OID for the policy identifier, which is contained in the certificates issued by the internal CA. However, the policy identifier is often assigned to the certificate practice statement (CPS) and not the CP. If assigned, the CP should also include its policy identifier. Other OID arcs or identifiers that are important to the organization and its PKI can also be listed.

The RFC 3647 §1.3 “PKI Participants” subsection is expected to describe the various roles and responsibilities that occur within the PKI including at a minimum the certification authorities, the registration authorities, subscribers, and relying parties. Each participant should be defined and although these four entities are well known by PKI enthusiasts, the reader might not be so knowledgeable. Table 4.8 provides the PAG [B.7.14] and ISO 21188 [B.4.11] definitions for each entity. Additionally, if other PKI participants do not fall clearly into one of these four categories, then they need to be identified and articulated.

In addition to the list of general participants and definitions, RFC 3647 §1.3 should also identify specifics for each category. For example, the CA components previously identified in §1.2 can be expanded upon in §1.3 to include any local, remote, or third-party RA instances. A more detailed list of subscribers reflects the types of certificates, such as what entities are issued TLS certificates, who gets e-mail certificates, and who gets VPN certificates, from the internal CA. If possible, the various types of relying parties should also be identified, if known. The mappings between participants, types of certificates, and actual certificate usage for subscribers and relying parties is defined in the next §1.4 subsection.

The RFC 3647 §1.4 “Certificate Usage” subsection is intended to provide descriptions of the applications in scope and the relevant certificate assurance levels. Certificates might be issued to individuals, devices, or applications; however, regardless of the owner name, certificates are processed by PKI-enabled applications. For the CP, it is sufficient to identify the types of applications, the certificate types, and the relative certificate usage. As an example, the internal CA components from Figure 4.6 are mapped to the applications and certificates types in Table 4.9.

In our example, the TLS CA designated A.1.1 issues TLS certificates to web application servers and firewalls located in a network demilitarized zone (DMZ). Certificates are issued to e-mail clients by the e-mail CA identified as A.2.1 for encryption certificates and by other e-mail CA tagged A.2.2 for signature certificates. VPN certificates are issued to VPN client and server applications by the VPN employee CA marked A.3.1 and the VPN contractor CA labeled A.3.2 for VPN certificates. This level of detail reduces ambiguity and enhances the CP usefulness.

The RFC 3647 §1.5 “Policy Administration” subsection is meant to provide contact information and the policy administrative processes. The CP captures information at a point in time such that it needs periodic reviews and occasional updates. The various PKI entities that depend on the CP need the ability to contact the policy authority (PA) management team for a variety of reasons including queries, feedback, or disputes. Dispute resolution is discussed in §9 “Other Business and Legal Matters.” As shown in this example, the contact information should include all of the relevant communication channels such as mailing address, phone number, and e-mail address. Note that no individual’s name is provided since the membership changes over time:

PKI Policy Authority

ABC Corporation

One Private Road

City, State, Zipcode

800-ABC-nnnn phone

[email protected]*

As discussed in Chapter 1, “Introduction,” the PKI complexity includes cryptography, IT, business, and legal. The CP reviews and updates are not trivial and need to be conducted in a formalized manner. A policy authority management team that represents all four areas needs to be established to maintain the CP. At a minimum, knowledgeable individuals representing cryptography, information technology, business groups, and legal counsel need to be members of the policy authority (PA) management team:

• Cryptography: Representation from the organization’s cryptography group is critical to address key management lifecycle controls. The PKI team might be part of the crypto group or function as a separate operational division.
• Information technology (IT): Representation from the organization’s IT group is important to address system and network capacity and planning. In our examples for the internal CA, the IT department supports the e-mail and VPN systems.
• Business: Representation from the organization’s various lines of business (LOBs) is important to address different application needs. In our examples for the internal CA, the LOB would include the applications running on the web application servers.
• Legal: Representation from the organization’s legal group is essential to the success of the PKI systems. Legal can address privacy, intellectual property, representations, warranties, disclaimers, liabilities, indemnities, terms, termination, notices, dispute resolution, national and international governing law, and compliance issues.

In addition to scheduled periodic reviews by the PA team, ad hoc updates might be necessary when there are significant changes. Technology changes can originate internally from IT or business issues or externally due to new vulnerabilities or market influence. Operational changes can originate internally due to cryptography, business, or legal issues or externally due to law, regulatory, or contractual requirements. Therefore, the CP needs to provide contact information for receiving comments and communicating to other groups within the organization. The PA processes need to be described in the CP and should include the following:

• PA management: This includes the makeup of the PA membership, how members are added or rotated, roles and responsibilities, and review schedules.
• CP management: This includes the review, editing, voting, and dispute processes, including publication and notification processes for the CP.
• CPS management: This includes the review, editing, voting, and dispute processes, including publication and notification processes for the CPS.

Depending on the organization’s structure, risk and compliance managers might also be part of the PA if business or legal members do not address those areas. Furthermore, business application owners or system managers might be included as part the CP review process but not necessarily regular members of the PA. The PA membership also needs to be consistent for continuity.

For small and medium organizations, the PA membership can be problematic as staffing might not be available or insufficiently aware of PKI technology. For staffing, some roles might be outsourced—for example, PKI expertise or legal counsel can be hired. For awareness, smaller organizations should consider continual PKI training to build and maintain knowledge.

The RFC 3647 §1.6 “Definitions and Acronyms” subsection is expected to provide definitions of terms, abbreviations, and acronyms used within the policy. Terms can include individual words or phrases. Abbreviations used within the CP should be defined. And of course, acronyms are pronounceable abbreviations so the phonetic transcription [tranˈskripSHən] might also be included. When providing definitions, care must be taken to avoid contradicting common industry terms unless absolutely necessary.

4.2 Publication and Repository Responsibilities

The second segment RFC 3647 §2 “Publication and Repository Responsibilities” is intended to address roles and responsibilities, publication frequency, and access controls for various entities that manage information repositories.

The RFC 3647 §2.1 “Repositories” subsection identifies the various repositories and corresponding entities that own the content or operate the repositories within the PKI systems. Table 4.10 provides a summary of repositories. While some of the content is owned by different groups, ultimately the repositories are operated by the CA or its associated RA subsidiary. Audit logs are typically not included within the repository scope.

The CP might provide a general declaration that the repositories are made available online, whereas the CPS would provide the specific uniform resource locator (URL). For example, the ABC Corporation’s repository might be accessed at either site:

• https://www.ABCcorp.TLD/pki
• https://pki.ABCcorp.TLD

Notice in our examples, the Hypertext Transfer Protocol Secure (HTTPS) is used to authenticate the website. In addition, the site might be operated by the ABC Corporation or hosted by a third party.

The RFC 3647 §2.2 “Publication of Certification Information” subsection addresses the various PKI participants and their corresponding responsibilities. Table 4.10 provides a summary of possible information, entities, and access controls. The certificate policy and certificate practice statement are managed by the policy authority. As discussed in Table 4.1, the CP might be public, the CPS is proprietary, and procedures (PXP) are confidential. The access controls correspond to the same distribution model. The CP requires PA authorized write access but has public read access. The various agreements, such as subscriber and relying party agreements, are typically managed by a legal group with authorized write access but equivalent CP public read controls. The CPS requires PA authorized write access but has limited read access. The security procedures have restricted read access on a need-to-know basis but are managed by a security group with authorized write access.

The RFC 3647 §2.3 “Time or Frequency of Publication” subsection addresses when information must be published and the frequency of publication. As an example of industry standards, consider the external CA depicted in Figure 4.6 which issues TLS and code sign certificates. The CA Browser Forum† created the extended validation (EV) guidelines to provide generally accepted authentication practices for issuing TLS and code sign certificates. The EV guideline requires that online CRL and OCSP services be available 24 × 7 and specific publication frequencies:

• For EV certificates, the CRL must be updated at least every 7 days, the OCSP service at least every 4 days, and both can only be valid for a maximum of 10 days.
• If the subordinate CA is not controlled by the same organization as the root CA, then the subordinate CA certificates are managed the same as the EV certificates, 7 days for the CRL, 4 days for the OCSP service, and a maximum of 10 days of expiration.
• Otherwise, if the subordinate CA is controlled by the same organization as the root CA, then for subordinate CA certificates that have not been revoked, the CRL and OCSP services must be updated at least every 12 months. Revocations must be published within 24 hours such that the 12-month clock begins anew.

As an example of the organization’s practices, the CP and CPS might be reviewed and published annually by the policy authority (PA). Conversely, the various agreements might be reviewed and published by legal on an as-needed basis such that their publication frequency may be very different from the policies and practices. And, procedures managed by the security might only change when cryptographic equipment or products change.

The RFC 3647 §2.4 “Access Controls on Repositories” subsection addresses access controls on the repositories. Some repositories are online and publicly available 24 × 7 such as CP and CRL postings or OCSP responders. Others are online but with limited external access such as CPS postings; however, since many organizations rely on a combined CP and CPS where the X.509 certificate policy extension contains a uniform resource locator (URL) pointer, the CPS is by necessity publicly available. Other repositories might be online and publicly accessible but with lesser availability needs, such as agreements or certificates, since many relying parties get certificates directly from the certificate owners. Furthermore, some repositories might be online but restricted to internal network access such as key management procedures. Table 4.11 provides a summary of possible information, entities, access, and availability.

Since certificates, certificate revocation lists (CRLs), and Online Certificate Status Protocol (OCSP) responders need to be publicly available to any relying party, they all have public read access but require CA or registration authority authorized write access. The publication frequency for each information type is typically dependent on industry standards and the organization’s policy and practices.

For smaller organizations with staffing limitations, managing publications and repositories can be problematic. Creating and managing content is difficult if legal, security, or PKI knowledge or experience is lacking. Maintaining publication dates and service level agreements (SLAs) is not easy with limited resources, as are access controls to maintain separation of duties.

4.3 Identification and Authentication

The third RFC 3647 §3 “Identification and Authentication” segment addresses subscribers policies for keys and certificates. The RFC 3647 specification explicitly includes subsections for subscriber naming conventions, initial authentication for certificate requests, and subsequent authentication for rekey requests and revocation requests. As shown in Figure 4.7, the subscriber is also the asymmetric key pair owner that maps to the following topics:

• Key generation includes the initial certificate request and subsequent certificate rekey requests. Initial authentication is important for initial certificate requests, and authentication is important for subsequent certificate rekey requests. Subscriber naming conventions are important for certificates requests.
• Key usage includes the relying party use of the subscriber’s certificate and the subscriber use of the corresponding private key. Subscriber naming conventions are important for certificate and key usage.
• Key revocation includes subsequent certificate revocation request. Authentication is important for subsequent certificate revocation requests.

The RFC 3647 §3.1 “Naming” subsection focuses on subscriber identity conventions such as X.500 distinguished names or RFC 822 e-mail addresses. Note that the X.500 attribute names discussed for subsection §1.2 “Document Name and Identification” are for the PKI components and the corresponding CA certificates, whereas this subsection discusses names for the subscriber certificates. The RFC 3647 specification also refers to anonymity, name uniqueness, and trademarks:

• Anonymity: This is when the subject name in the certificate does not identify the subscriber by using a generic name (e.g., John Doe, Somebody, Anyone) or pseudonym. However, a PKI system issuing a certificate to an unconfirmed identity, pseudonyms notwithstanding, assumes unnecessary liability. Consider the man-in-the-middle attacks discussed in Chapter 2, “Cryptography Basics.” If the interloper can obtain a certificate in the sender’s name, then an MITM signature attack is possible. If the interloper can obtain a certificate in the receiver’s name, then an MITM key transport attack is possible. A legal dispute might find the CA at fault for not verifying the certificate requestor’s identity.
• Name uniqueness: This is when each certificate has a relatively unique name. Since one PKI system typically does not have access to the certificate repository of others, global uniqueness is not very practical. However, a PKI system, which issues more than one certificate, each with unique public keys but with duplicate names, also assumes unnecessary risk. Again, if a relying party accepts the wrong certificate due to a duplicate name, an MITM attack and ensuing legal dispute are possible, affecting the CA.
• Business names: These include trademarked or registered names, so when a PKI system issues a certificate to an unconfirmed business identity, the CA assumes liability. For example, when the now bankrupted Dutch CA DigiNotar was compromised in 2011, fraudulent certificates were issued for Google, Yahoo, Mozilla, and others. Issuing certificates to business names involves different authentication practices and methods than when issuing certificates to individuals.

However, there is also the aspect of issuing certificates to an individual when their name is associated with a business name. For example, issuing a certificate to “John Doe” and including a generic e-mail address (e.g., [email protected]), where “e-mail” is one of many service providers, is different than using [email protected], which indicates employment. When dealing with business names, care must be taken to avoid unwanted implications of warranties, liabilities, or indemnifications. In addition to these topics, this book considers several relevant topics, which are not addressed by the RFC 3647 specification:

• Device names: These include applications, servers, and network appliances. Similar to individual names being associated with a business name, devices are owned and operated by an organization. However, the organization might be external to the PKI system issuing the certificate, and the device ownership might be different than the management organization. Issuing certificates to devices involves different authentication practices and methods than when issuing certificates to individuals.
• Public key verification: This is the process of mathematically verifying the public key based on algorithm-specific attributes, including length, number of bits, and structure. An improperly constructed public key for some algorithms can enable certain cryptanalytic attacks. Consequently, a PKI system issuing a certificate for a defective public key might put the subscriber or the relying party at risk, and in the case of a legal dispute, the CA may be found at fault for not verifying the subscriber’s public key.
• Public key uniqueness: This is when the CA checks its certificate repository for a duplicate public key. Since the public and private keys are mathematically related, the same public key in a certificate request means that both key owners have generated the same key pair. However, this is a highly unlikely scenario. The CA cannot notify the new requestor as that would compromise the existing key owner. However, the CA can refuse to issue a new certificate with the same public key as an existing certificate.

The RFC 3647 §3.2 “Initial Identity Validation” subsection considers initial authentication methods for each participate identified in the §1.3 “PKI Participants” subsection. Topics include why the various PKI participants are authenticated and authorized, what information is verified, and who performs the verification, authentication, and authorization processes. As discussed in §1 “Introduction,” if certificate assurance levels are supported, then they also need to be addressed in this subsection. Table 4.12 provides CP and CPS examples for the internal CA shown in Figure 4.6.

Once the initial authentication has been accomplished and authentication credentials have been established, subsequent authentication can be relied upon. While the RFC 3647 §3.2 “Initial Identity Validation” subsection focuses on initial authentication, subsequent authentication needs to be likewise addressed. Table 4.13 provides CP and CPS examples for the internal CA. The RFC 3647 §3.3 and §3.4 subsections only address subscriber interactions for rekey and revocation, but other entities (e.g., CA, RA, or relying parties) and other communications (e.g., CRL updates, CRL downloads, OCSP updates, OCSP responses, RA certificate requests) also need to be authenticated. We recommend that additional subsections be added to the RFC 3647 segment §3 “Identification and Authentication” as needed.

The RFC 3647 §3.3 “Identification and Authentication for Rekey Requests” subsection considers subsequent authentication for rekey requests, both before and after revocation. Rekey requests can also be submitted before the current certificate expires and after the certificate expires:

• If the current certificate is still valid, then the certificate rekey request for a new key pair might be authenticated via a digital signature per the key owner’s current keys. Note that the certificate rekey request still needs to include a digital signature for the key owner’s new key pair as evidence that the requestor is the owner of the new private key.

  Note that the certification request as defined in RFC 2986 [B.6.8] only provides one digital signature field for the new keys and does not provide a digital signature field for the current keys. However, the Certificate Management Protocol (CMP) messages defined in RFC 4210 provide an optional PKI protection field, which can contain a digital signature for the current keys. In order for the current keys to provide authentication via a digital signature, the PKI system must support CMP.

• If the current certificate is expired, then the certificate rekey request for a new key pair might need initial authentication if no other authentication credentials have been established. Note that the digital signature only provides evidence that the requestor is the owner of the new private key and does not authenticate the requestor.
• If the current certificate is revoked, then the certificate rekey request for a new key pair needs initial authentication. Revocation might occur for many reasons, including key compromise, cessation of operations, or an individual’s demise. Most of the revocation reasons likely negate any other existing authentication credentials.

The RFC 3647 §3.4 “Identification and Authentication for Revocation Requests” subsection considers subsequent authentication for revocation requests. Certificates can be revoked for any entity and for a variety of reasons, and even be requested by various PKI participants, including the CA, the RA, the subscriber, or other parties. The RFC 5280 specification provides numerous certificate revocation codes, including

• Key compromise
• CA compromise
• Affiliation change
• Superseded by another certificate
• Cessation of operations
• Privilege withdrawal

Revoking a certificate is serious business and should not be taken lightly. However, there are many other reasons a certificate might be revoked and who should be authenticated and authorized to request a revocation. The RFC §4.9 “Certificate Revocation and Suspension” subsection addresses these issues.

CA certificates: The CA can revoke any of its own certificates; however, this will negate all of the downstream certificates during validation. Consider the scenarios in Figure 4.6. If the A.3.2 VPN contractor CA certificate is revoked by the A.3 VPN internal CA, then all contractor VPN certificates will fail validation, but the employee VPN certificates are still valid. Alternatively, if the A.3.1 VPN employee CA certificate is revoked, then all employee VPN certificates will fail, but the contractor VPN certificates are still good. Due to the gravity of revoking any CA certificate, the following controls are recommended for the CP:

• Review and approval by the policy authority (PA). The PA membership is the only group with sufficient understanding to evaluate the relative risks and impacts. Likely, senior management will also be engaged to confirm the PA recommendation; however, the CP needs to clearly articulate the importance of the PA role.
• Dual controls to prevent a single individual from revoking a CA certificate. Documented procedures will be needed to execute the revocation, but the CP only needs to stipulate the separation of duties. Audit logs will capture the event, along with a copy of the stepwise procedures, to fully document the event.

RA certificates: The RA might be intrinsic to the CA system, a stand-alone internal application that communicates to the CA, or an external service acting as an agent for the CA. In the event of key or system compromise, the RA can request that its own certificate be revoked and request a new certificate once the incident has been remediated. The RA should likewise request a revocation when it ceases operations. Conversely, the CA might revoke the RA certificate in the event of an agreement dispute. The revocation of a RA certificate does affect any previous subscriber certificates issued by the CA and only prevents any future requests from the RA:

• Revocation requests from the RA need to be authenticated by the CA; however, the RA is inherently authorized to revoke its own certificate. Ironically, in the event that the RA is compromised and an interloper submits a revocation request as a denial of service attack, the request is actually valid since the RA was compromised.
• Revocations initiated by the CA need to be authenticated and authorized to prevent RA services from being prematurely disabled.

Subscriber certificates: The subscriber can request that its own certificate be revoked for a variety of reasons including key compromise, system compromise, service termination, or certificate replacement. The CA might also revoke a subscriber certificate due to an agreement dispute. A family member, guardian, or legal representative might request revocation when the subscriber is debilitated, disabled, or deceased. An employer might request revocation in the event of job transfer, privilege withdrawal, or termination. Thus, a third party other than the subscriber or CA might have legitimate reasons for requesting a certification revocation. The CP needs to address all three scenarios:

• Revocation requests from the subscriber need to be authenticated by the RA or CA; however, the subscriber is inherently authorized to revoke its own certificate.
• Revocations initiated by the CA need to be authenticated and authorized to prevent subscriber services from being disrupted.
• Revocation requests from third parties need to be authenticated and authorized to prevent subscriber services from being disrupted.

It is important to recognize that it is not practical to identify every possible revocation scenario as the various types of certificate and variety of application environments would make for a very large list. Furthermore, as new applications and certificate usages are added to the CA capabilities, the legitimate revocation reasons will continue to grow. Also, since application are divested or decommissioned, the revocation reasons will change. Therefore, the CP need only list the more significant revocation reasons, possibly list ones not supported, and provide the authentication, authorization, and accountability requirements for each PKI participant.

4.4 Certificate Lifecycle Operational Requirements

The fourth segment of RFC 3647 §4 “Certificate Life Cycle Operational Requirements” addresses controls for the various PKI participants including the CA, the RA, certificate subscribers, and relying parities, or others with regard to the key and certificate lifecycles. The RFC 3647 lifecycle terminology differs from the X9.79 key management lifecycle introduced in Chapter 2, “Cryptography Basics.” Whereas X9.79 is a state transition diagram with nodes and transitions, the RFC 3647 specification uses a mixture of actions, processes, and protocols. Table 4.14 provides a comparison between the two lifecycles.

The RFC 3647 §4.1 “Certificate Application” subsection deals with the PKI operational rules for generating key pairs, preparing the certificate signing request (CSR), and submitting the CSR application for a certificate to the RA for processing. Table 4.15 provides CP and CPS examples for the internal CA.

The RFC 2986 specification defines a certification request; commonly called the certificate signature request (CSR) originally defined in PKCS #10. The CSR includes four basic fields that provide sufficient information for the CA to generate a digital certificate:

• Subject: This is the name provided by the requestor that will typically appear in the certificate. The CA might enhance the subject name.
• PKI Information: This is the public key and associated algorithm information that will appear in the certificate. The algorithm information is replicated for the signature.
• Attributes: This includes additional information provided by the subject, some of which might appear in the certificate. The RFC 2985 specification provides a list of attributes for PKCS #10 originally defined in PKCS #9. Some attributes might be used for identification or authentication by the RA or CA, while others might not be supported and subsequently ignored.
• Signature: This is a digital signature generated by the requestor using the corresponding private as proof of ownership for the key pair. The signature is verified using the public key contained in the CSR.

The CSR syntax is defined in the various standards and should be supported by the RA and CA systems; however, the semantics supported by the RA and CA depends on the applications, the environments, and certificate types. Considering the internal CA in Figure 4.6 the applications include web servers using TLS certificates for internal connections, signature and encryption certificates for internal and external e-mails, and VPN certificates for remote access by employees and contractors.

The RFC 3647 §4.2 “Certificate Application Processing” subsection describes the actions taken by the RA when a CSR is received from a requestor. The RA typically checks the syntax to ensure a well-formed request and the semantics to corroborate that the operating rules are being followed. In addition, the RA performs authentication and authorization of the requestor. This includes verification of the CSR signature to confirm that the requestor is the key owner. However, it is important to note that the CSR is a self-signed object and therefore vulnerable to an MITM attack. Figure 4.8 shows how an interloper might usurp a CSR application.

The requestor constructs the certificate request (e.g., name, public key, and attributes), signs it with the corresponding private key, and submits it to the RA system. However, in this scenario, the interloper intercepts the CSR application, steals the requestor’s name and attributes, and replaces the requestor’s public with its own public key. When the RA system receives the modified CSR, it mistakenly uses the interloper’s public key to verify the signature, presuming it is the requestor’s public key, but because the signature verifies, the RA is fooled. Therefore, the CSR application process requires additional authentication of the requestor.

The RA authenticating and authorizing the requestor is a necessary control because the CSR is a self-signed object that only confirms the signer is the private key owner.

Furthermore, the CA needs to authenticate the RA. Since the RA sends unsolicited certificate requests to the CA for certificate issuance, the CA needs the ability to validate the requests received from the RA. The RA might be an embedded function within the CA system, it might be a separate internal application, or the RA might be an independent external service. For the latter two scenarios having the RA sign, the CSR with its own private key allows the CA to validate the RA request. For the former, the additional RA signature might not be explicitly needed as the combination RA/CA clearly trusts itself. However, from a continuity viewpoint, having the RA always sign the request provides consistency, integrity of the request, and reliability. Table 4.16 provides CP and CPS examples for the RA.

The RFC 3647 §4.3 “Certificate Issuance” subsection describes the actions taken by the CA when a CSR is received from the RA. The CA authenticates and authorizes the RA request including syntax, semantic, and rules checks before generating a new certificate. Once generated, the CA updates its certificate repository, logs the events, and returns the certificate to the RA. Note that the CA process might incur an error and not always generate a certificate. Table 4.17 provides CP and CPS examples for the CA.

The RFC 3647 §4.4 “Certificate Acceptance” subsection describes the actions taken by the RA after the CA has issued the certificate. The RA returns a certificate response back to the requestor, and depending on the nature of the interaction the subscriber might receive, the certificate in the response, a link to the posted certificate, or an indicator to check later on its status. Some certificate requests might be automatically approved based on operating rules, while others might require human intervention. Regardless, subscriber acceptance might vary by the certificate type, the RA, or the CA support infrastructure such as web or e-mail services. Table 4.18 provides CP and CPS examples for the RA.

Small organizations might issue certificates from common RA system and therefore use a single certificate issuance method. Medium organizations might have multiple RA solutions and consequently use different issuance methods. Large organizations might need to support different issuance methods for various lines of business (LOBs) and accordingly need to operate multiple RA solutions. Furthermore, as any organization migrates from one RA solution to another, there is typically a migration period when multiple systems need to be operated.

The RFC 3647 §4.5 “Key Pair and Certificate Usage” subsection refers to key usage for subscribers and relying parties; however, the CP should also include CA and RA. As discussed earlier in §1, “Introduction,” subscribers use their private keys and relying parties use the subscriber’s public keys, as shown in Figure 4.7. RFC 3647 §4.5 needs to include not only key usage but also key backup, key revocation, and key archive. Table 4.19 provides CP and CPS examples for subscribers and their private keys.

This is twice so far we have made a forward reference to the RFC §4.9 “Certificate Revocation and Suspension” subsection, which raises an interesting topic. When writing a CP, there are two mutually exclusive approaches—either have information stated in one place using references throughout the document or duplicate the information in multiple places. The former approach makes for easier maintenance, but the reader often needs to flip back and forth. Conversely, the latter makes for easier reading but requires more work keeping the various parts of the document synchronized. This book recommends the former, having information only appearing once to avoid conflicting statements and using cross-references where needed.

Information in the CP should only occur once to avoid conflicting statements, and other parts of the document should cross-reference to the appropriate place.

The relying party uses the subscriber’s public key in the digital certificate. Table 4.20 provides CP and CPS examples for the relying party.

Regarding RA and CA key usage, both entities are subscribers using their private keys, and with respect to the RA, the CA is also a relying party using the RA’s certificate. Table 4.21 provides CP examples for the RA and CA.

The RFC 3647 §4.6 “Certificate Renewal” subsection describes circumstances under which renewal takes place, entities who can request a certificate renewal, and the related RA and CA actions including application, issuance, and acceptance processes. RFC 3647 describes renewal as the issuance of a new certificate without changing the public key or other information. For example, renewal is a method for extending the lifetime of a key pair by updating the certificate validity period. However, there are no industry standards or common practices defining which X.509 fields are permitted for renewal and which ones are not. Therefore, the PKI operational rules need to address renewal conditions and options. Table 4.22 provides CP examples for various PKI entities.

However, validity dates reflect the allocated lifecycle for a specific key pair and arbitrarily extending the operational period for a given key pair increases the likelihood of a key or system breach. As discussed in Chapter 2, “Cryptography Basics,” cryptographic keys do not last forever and need to be changed periodically based on their operational periods. Lengthening the key lifecycle affects the RA, the CA, the subscriber, and the relying party. The RA needs to enforce the PKI operation rules for renewal, and the CA needs to support the various certificate fields that are updated. Analogous to reusing the same password for too long, renewing the certificate increases the probability of the subscriber’s private key being compromised. A renewed certificate has a new serial number, but it contains the same subscriber name and public key, which might cause operational issues for the relying party. This book recommends that PKI systems do not support certificate renewal and always rekey new certificates.

Certificate renewal extends the key lifecycle beyond its original operational period, which is a risky practice; certificates should not be renewed; they should always be rekeyed.

The RFC 3647 §4.7 “Certificate Rekey” subsection describes circumstances under which rekey takes place, entities who can request a certificate rekey, and the related RA and CA actions including application, issuance, and acceptance processes. Rekey is described as the issuance of a new certificate for a new key pair when a previous certificate already exists. If the previous certificate is still valid, then it might be used for subsequent authentication; otherwise, initial authentication is needed as if it was the original certificate request. Table 4.23 provides CP examples for various PKI participants.

The RFC 3647 §4.8 “Certificate Modification” subsection describes circumstances under which modification takes place, entities who can request a certificate modification, and the related RA and CA actions including application, issuance, and acceptance processes. RFC 3647 describes modification as the issuance of new certificate due to changes in the information in the certificate other than the subscriber public key. Unlike renewal, the validity dates remain unchanged, but again there are no industry standards or common practices defining which X.509 fields are permitted for modification and which ones are not. Therefore, the PKI operational rules need to address modification conditions and options. Table 4.24 provides CP examples for various PKI participants.

However, a modified certificate has a new serial number with an existing public key but with newer information, which might cause operational issues for the relying party. Either the original validity dates remain unchanged in which case the lifecycle is shortened for the modified certificate or the validity dates are reset in which case the lifecycle is extended as for renewed certificate. Furthermore, the RA needs to enforce the PKI operation rules for modification, and the CA needs to support the various certificate fields that are updated. This book recommends that PKI systems do not support certificate modification and always rekey new certificates.

Certificate modification changes the key lifecycle from its original operational period, which is a risky practice; certificates should not be modified; they should always be rekeyed.

The RFC 3647 §4.9 “Certificate Revocation and Suspension” subsection describes circumstances under which revocation or suspension takes place, entities who can request a certificate revocation or suspension, and the related RA and CA actions including application, issuance, and acceptance processes. Suspension occurs when a certificate is temporarily put on hold to prevent its use and eventually is either reinstated or revoked. Revocation occurs when a certificate is permanently canceled. Table 4.25 provides CP examples for various PKI entities.

Revocation and suspension are treated synonymously in the RFC 3647; however, since suspension is reversible and revocation is irreversible, the circumstances are different. Table 4.26 provides a contrast between the two. Suspension might inadvertently leak sensitive information such as merger or acquisition to third parties that could financially affect an organization. The complexities of managing suspension privileges between various authorized individual possibly from different organizations far exceeds the benefits of certificate suspension. For these reasons, this book recommends that certificate suspension not be supported and only offers certificate revocation.

Certificate suspension should not be supported due to the complexities and side effects of managing authorized individual possibly from different organizations. Many CA software products do not support certificate suspension.

It is not feasible to list all possible revocation circumstance (or suspension if supported), but the CP should list at least the most critical revocation categories (e.g., key compromise, system compromise). The revocation circumstances in RFC 3647 §4.9 need to be synchronized with RFC 3647 §4.5 and with RFC 3647 §3.4; however, neither of the other two subsections include suspension so the CP needs to be aligned with the relevant topics.

The RFC 3647 §4.10 “Certificate Status Services” subsection addresses the characteristics for the certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP) services. As other methods become available, they would be included in this subsection. Table 4.27 provides sample CRL and OCSP statements.

The certificate status rules need to be aligned with the RFC 3647 §2 “Publication and Repository Responsibilities” segment. As discussed in §2 “Publication and Repository Responsibilities,” the CRL and OCSP might be based on industry standards.

The RFC 3647 §4.11 “End of Subscription” subsection addresses subscribers terminating services with the PKI system. Certificate expiration or revocation does not necessarily terminate the subscriber’s relationship but is a necessary condition. Table 4.28 provides CP examples for subscriber termination.

The RFC 3647 §4.12 “Key Escrow and Recovery” subsection is intended to address asymmetric private key and symmetric key recovery processes. However, the RFC 3647 specification incorrectly regards key escrow as equivalent to key recovery. As discussed in Chapter 2, “Cryptography Basics,” key escrow is the practice of storing keys for the explicit purpose of providing them to a third party. Regarding key recovery, Table 4.29 provides CP and CPS examples for various PKI entities.

The organization size tends to be proportional to the number of certificates. More employees, applications, network appliances, and vendors will need more certificates that must be issued, managed, renewed, and possibly revoked. More certificates typically require both additional staffing and more automated tools. More certificates also need better management tools. For a small organization managing hundreds of certificates, manual processes are possible. For medium organizations that might manage thousands or tens of thousands certificates, manual methods are no longer a viable option. Large organizations that managed hundreds of thousands or even millions of certificates need distributed management processes that provide reporting and constant monitoring tools.

RA and OCSP private keys might also be backed up; however, that is an operational risk decision for the organization as sometimes it is easier to rekey other PKI systems. Regarding third-party data escrow, if the topic needs to be included, it should be in its own subsection. Regarding key escrow, if the topic needs to be included, it would have many of the same characteristics as key backup and recovery.

4.5 Facility, Management, and Operational and Physical Controls

The fifth RFC 3647 §5 “Management, Operational, and Physical Controls” segment addresses what the specification calls nontechnical security controls for physical, procedural, and personnel areas. Note that this segment seems to have two dissimilar titles—the table of contents and the framework uses facility, management, and operational controls, but the actual segment uses management, operational, and physical controls. Regardless, the subsections address physical security, procedures, personnel security, audit logging, records archival, key changeover, disaster recover, and operational termination.

The RFC 3647 §5.1 “Physical Security Controls” subsection deals with campus and building security, including physical access controls. This subsection also deals with environmental controls including heating, ventilation, and air conditioning (HVAC), power, fire detection, alarms, suppression systems, waste disposal, and on-site and off-site storage. The purpose for declaring physical controls is to demonstrate reasonable operational processes. Refer back to Figure 4.2, Figure 4.3, and Figure 4.4 for an overview of the ABC Corporation. Table 4.30 provides sample statement for various facility types.

Small organizations might only have a single server room that contains all computer and network equipment, including PKI systems. Alternatively, small organizations might outsource all of its IT to management services and use external hosting services, including cloud. A medium to large organization might use both internal and external IT services. Physical controls need to address both internal and external scenarios, internal controls managed directly by the organization, and external controls provided by the service providers.

The RFC 3647 §5.2 “Procedural Controls” subsection deals with trusted PKI roles and separation of duties, including identification and authentication for each role. Based on the relative risks, each role might require different authentication levels using one, two, or three factors depending on the associated responsibility. Table 4.31 provides sample statements for various PKI roles and responsibilities.

The RFC 3647 §5.3 “Personnel Security Controls” subsection addresses hiring processes, additional background checks, education and training, and other considerations including similarities or differences between employees and contractors. An organization’s human resources (HR) processes will establish an individual’s identity and initial authentication. However, an organization’s HR processes are for employees and not necessarily for contractors. The resource agency will have its own HR processes. The PKI roles might require additional background checks above and beyond the organization’s HR processes or the agency’s HR processes if contractors are permitted to fulfill PKI roles. Note that HR policy and practices will vary among countries according to local laws and regulations. Table 4.32 provides sample additional authentication controls for various PKI roles.

Regarding education and training, academic degrees in technology might be helpful, industry security credentials are also useful, and either might be mandated by HR policy. However, academia and industry credentials tend to be generic. Specific training on the actual systems, applications, and cryptographic products in use is extremely beneficial. Initial training, refresher courses, and updates are important. Table 4.32 provides sample education and training controls for various PKI roles.

The RFC 3647 §5.4 “Audit Logging Procedures” subsection addresses audit log management, which includes the events, access controls, confidentiality and integrity controls, and analysis. Minimally, sufficient information needs to be captured such that if a security incident occurs, there are adequate data to determine the sequence of events, identify the root cause, and determine an appropriate remediation. Ideally, information is captured and analyzed in a timely manner to detect and prevent a potential security incident. Table 4.33 provides CP and CPS examples for various PKI entities.

A basic audit control is the comparison of two interrelated but independent events. Thus, the RA and CA can reconcile the certificate and revocation requests as a comparison check for system reliability. For audit logs to be available, they must be managed in an appropriate manner. Table 4.34 provides a sample audit log management statement for various PKI entities.

The RFC 3647 §5.5 “Records Archival” subsection addresses audit log archive processes including access controls, confidentiality and integrity controls, backup, and recovery. Audit logs are typically kept online for a short-term access, perhaps months, and then transferred to a log repository for long-time archive. Since many root CA certificates are issued for 20 or more years, the log archive needs to avoid hardware deterioration or software obsolescence. Table 4.35 provides CP examples for various PKI entities.

The RFC 3647 §5.6 “Key Changeover” subsection deals with replacing the current CA public key with a new public key, essentially a CA rekey. Consider the internal CA in Figure 4.6 and all of the VPN employee certificates signed by the A.3.1 VPN employee CA private key. Operationally, the CA generates a new key pair and gets a new certificate from its superior A.3 VPN internal CA before its current certificate expires. The A.3.1 VPN employee CA begins issuing all new VPN employees using the new private key, which changes the CA certificate chain. As the current VPN employee certificates expire, they eventually get rekeyed using the newer CA certificate and alternate CA certificate chain. Table 4.36 demonstrates the current chain and the newer chain.

The old top to bottom certificate chain consists of the certificates #22 ⇒ #12 ⇒ #15 and the newer chain consist of the certificates #22 ⇒ #12 ⇒ #16, but both chains represent the same CA hierarchy. The old A.3.1 VPN employee CA certificate #15 is rekeyed and replaced by the newer A.3.1 VPN employee CA certificate #16, where both are issued by the A.3 VPN internal CA. So, for example, the VPN certificate #1003 issued by the old A.3.1 CA has the bottom to top chain #1003 ⇒ #15 ⇒ #12 ⇒ #22 and the VPN certificate #1006 issued by the newer A.3.1 CA has the chain #1005 ⇒ #16 ⇒ #12 ⇒ #22. Table 4.37 provides CP and CPS examples for various PKI entities.

The RFC 3647 §5.7 “Compromise and Disaster Recovery” subsection addresses business continuity and disaster recovery including facility, application, system, and key compromise. Each PKI entity has different reliability requirements depending on its criticality. Some systems and keys are backed up with full redundancy, while others have lesser needs. Table 4.38 provides CP examples for various PKI entities.

The RFC 3647 §5.8 “CA or RA Termination” subsection addresses the conditions and processes for decommissioning PKI systems or its components. Depending on the situation, a termination might be graceful or abrupt. A graceful termination is when the certificates expire with no rekey for conditions such as a minor security incident, decommissioning an application, ending a service, or ceasing operation due to a merger or acquisition. An abrupt termination is when the certificates are revoked with no rekey for circumstances such as a major security incident, court order for immediate cease and desist, lawsuit, or ceasing operation due to bankruptcy. Table 4.39 provides CP examples for various PKI entities.

4.6 Technical Security Controls

The sixth segment RFC 3647 §6 “Technical Security Controls” addresses requirements and rules for protecting system and network components including hardware, software, applications, and information objects. Various aspects of key management not discussed in the fourth RFC 3647 segment §4 “Certificate Life Cycle Operational Requirements” are included in this segment:

• Cryptographic keys include asymmetric key pairs and any symmetric keys.
• Hardware includes servers, workstations, laptops, mobile devices, network appliances, wireless access points, and even cables and power cords.
• Software encompasses source code, firmware, executable code, scripts, data structures, message formats, protocols, and configuration data.
• Applications include access controls and audits logs for system administrators, application administrators, application managers, and application users.
• Information consists of data in any format or media that might be generated, distributed, transmitted, stored, printed, or processed.

Any size organization might use third-party services, including cloud services. Thus, since one or more of the PKI services might be hosted or provided by third parties, the technical security controls also need to address reviews of third-party controls. For an overview of security basics, refer to Chapter 1 and for a discussion of key management and cryptographic basics, see Chapter 2.

The RFC 3647 §6.1 “Key Pair Generation and Installation” subsection deals with the first two key lifecycle stages presented in Figure 4.7—key generation and key distribution. Each key pair might be generated by the key owner or another party, and if done by another party, then the keys need to be security transferred to the owner. Each certificate needs to be generated by a CA such that the public key needs to be sent to the CA and the certificate needs to be sent to the key owner. If the keys or certificates are used in a different location than where they are generated, then they need to be distributed from the generation to the usage locations. Table 4.40 provides CP and CPS examples for various PKI entities.

The RFC 3647 §6.2 “Private Key Protection and Cryptographic Module Engineering Controls” subsection deals with the third, fourth, and sixth key lifecycle stages presented in Figure 4.7—key usage, key backup, and key termination. As noted in §4 “Certificate Life Cycle Operational Requirements,” the RFC 3647 specification incorrectly regards key escrow as equivalent to key recovery. Regardless, this subsection addresses with key protection controls after keys have been generated and installed. Table 4.41 provides CP and CPS examples for various PKI entities.

The RFC 3647 §6.3 “Other Aspects of Key Pair Management” subsection deals with the remaining fifth and seventh key lifecycle stages presented in Figure 4.7—key revocation and key archive. Another topic is the operational crypto period of the key pair; however, the RFC 3647 specification presumes the private and public keys have the same crypto periods. For example, if the private key is used to generate digital signatures up to the last minute of the certificate validity period, the relying party only has seconds to validate the digital signature. Table 4.42 provides CP examples for various PKI entities.

The RFC 3647 §6.4 “Activation Data” subsection is actually about authentication data used to verify either a person or a nonperson entity using noncryptographic methods. For persons, this includes knowledge factors such as passwords, possession factors such as smart cards, and biometric factors such as fingerprints. For nonperson entities, this includes possession factors such as passphrases and device recognition methods. Another authentication method is one-time passcodes (OTP) valid for a temporary period of time. These authentication methods are typically used to enhance controls over asymmetric keys:

• CA might back up and recover its private keys using key shares stored on smart cards that are password activated.
• RA might send an OTP to a subscriber to download and activate a new certificate.
• Subscribers might activate their private keys using a password, smart card, or biometric.

In addition to protecting cryptographic keys, RA and CA have system administrators, application administrators, and application managers that likewise require authentication. Some functions might only require single-factor authentication such as password log-on, while others might need multifactor authentication. Table 4.43 provides CP and CPS examples for various PKI entities.

The RFC 3647 §6.5 “Computer Security Controls” subsection addresses system hardware and software management including access controls, application development and maintenance, product assurance, certifications, and evaluation programs. The CP needs to contain sufficient information to convince the reader that computer security controls are in place but not provide too many details valuable to an attacker. Table 4.44 provides CP examples for various PKI entities.

The RFC 3647 §6.6 “Life Cycle Security Controls” subsection addresses the software development lifecycle (SDLC) and corresponding security management controls. Functional requirements and designs need to incorporate security controls, development needs to include software assurance mechanisms, and test cases need to confirm security controls exist and are effective. Table 4.45 provides CP examples for various PKI entities.

The RFC 3647 §6.7 “Network Security Controls” subsection focuses on network components including firewalls, routers, switches, and other appliances. Configuration management is an important network security control that addresses specifications, review and approvals, and roles and responsibilities. Table 4.46 provides CP examples for various PKI entities.

The RFC 3647 §6.8 “Time Stamping” subsection addresses time stamps for messages, transaction processing, and audit logs. The Network Time Protocol (NTP) supports local and regional time servers synchronized to a national time source such as the National Institute of Standards and Technology (NIST) or the United States Naval Observatory (USNO), which are calibrated to the International Timing Authority (ITA). Table 4.47 provides CP and CPS examples for various PKI entities.

4.7 Certificate, CRL, and OCSP Profiles

The seventh RFC 3647 §7 “Certificate and CRL Profiles” segment addresses data structure formats and field options for certificates, CRL, and OCSP profiles. The different formats are defined in various standards that have data elements that are expected to be supported and optional fields that might be supported by the PKI organization. The assorted protocols used to exchange the data structures are likewise defined in several standards. This segment allows a PKI organization to define its profile support including messaging handling, error codes, and default values.

The RFC 3647 §7.1 “Certificate Profile” subsection addresses digital certificates. Public keys can be encapsulated in a variety of data structures, which generally we call a PKI credential. The most recognizable PKI credential is an X.509 certificate, originally defined in the ITU-T X.509 standard and subsequently described in the RFC 5280 specification and the ISO/IEC 9594—Part 8 standard. The CP should identify at least the following information:

• List of supported PKI credentials, including at a minimum X.509 certificates
• List of relevant standards for the associated PKI credentials

Details regarding the individual data elements for each supported PKI credential do not belong in a CP but rather in a CPS for interoperability with subscribers and relying parties. Protocol specifications do not belong in a CP or CPS but rather fit and are more usable in procedures for developers and testing guidelines. Table 4.48 provides CP examples for various PKI entities.

The RFC 3647 §7.2 “CRL Profile” subsection addresses certificate revocation list (CRL) for managing certificate status. Per RFC 5280 specification, a complete CRL contains all unexpired certificates that have been revoked within the CA scope. Thus, each CA maintains its own CRL such that a relying party needs to deal with more than one CRL. The various CRL are posted on an accessible site where relying parties can download the certificate status information. Table 4.49 provides CP examples for various PKI entities.

The RFC 3647 §7.3 “OCSP Profile” subsection addresses the use of an Online Certificate Status Protocol (OCSP) responder. The RFC 6960 specification proposes that OCSP is useful in determining the current status of a digital certificate without requiring certificate revocation lists (CRLs). However, it is more likely that a PKI system needs to support both CRL and OCSP methods for backward compatibility. Furthermore, the certificate status for OCSP is typically based on the issuance of a CRL. Table 4.50 provides CP examples for various PKI entities.

Note that the certificate, CRL, and OCSP profiles need to be synched with each other to avoid discrepancies or incompatibilities. For example, if other PKI credentials besides X.509 certificates are supported then credential status methods need to be provided and identified in the CP and details need to be specified in the CPS. As noted earlier, protocol specifications can be provided in procedures for developers and testing guidelines.

4.8 Compliance Audits and Other Assessments

The eighth RFC 3647 §8 “Compliance Audit and Other Assessment” segment addresses internal and external security audits, assessments, and evaluations. External audits are performed by licensed professionals and depending on the jurisdiction might be governed by legal or regulatory rules. Internal audits, assessments, or evaluations are done by employees or outsourced to third-party service providers or private consultants. Evaluations target specific PKI components, products, or controls. Table 4.51 provides CP examples for various PKI entities.

Chapter 9, “PKI Governance, Risk, and Compliance,” discusses the management and security organizational hierarchies needed to support an independent audit capability for maintaining compliance. The chapter also addresses various audit standards and programs. A competent audit process needs to address internal and external audits, assessments, and evaluations. Qualified internal and external resources need to demonstrate knowledge, experience, and competence.

The RFC 3647 §8.1 “Frequency or Circumstances of Assessment” subsection addresses the frequency of assessments and other circumstances that might trigger an assessment. For example, in the United States, some state laws require commercial CAs to be licensed service providers and undergo annual audits. Private CAs do not operate under the same restrictions. Other countries and industries might have their own CA audit programs. Unscheduled assessment might occur when a security incident is detected, as part of an investigation or remediation.

The RFC 3647 §8.2 “Identity/Qualifications of Assessor” subsection addresses the qualifications of the assessors and the assessment program. External assessments or evaluations should be performed by security professionals with credentials or demonstrated experience. Internal audits, assessments, or evaluations done by employees or outsourced staffing need to have sufficient training and knowledge to be meaningful.

The RFC 3647 §8.3 “Assessor’s Relationship to Assessed Entity” subsection addresses the independence of the assessor. External assessments performed by security professionals or auditors are independent, despite being under contract with the organization. Internal assessments done by employees, contractors, or outsourced staffing are inherently influenced by the organization.

The RFC 3647 §8.4 “Topics Covered by Assessment” subsection addresses the scope of the assessment and the methodology employed. For example, our hypothetical ABC Corporation operates an internal CA and an external CA, so an assessment might be for either. In addition, each PKI system consists of multiple CA systems (root, intermediary, and issuing) so an assessment might be for one system. The methodology depends partially on the jurisdiction and the scope of the assessment, such as one CA hierarchy or another, or one CA system or another.

The RFC 3647 §8.5 “Actions Taken as a Result of Deficiency” subsection addresses appropriate remediation as a result of deficiencies or assessment gaps. Assessments might provide a rating similar to network vulnerability scans—low, medium, high, or critical issues. For example, critical problems would require a shorter remediation timeline than lesser problems.

The RFC 3647 §8.6 “Communication of Results” subsection addresses the distribution of the assessment report. Regardless whether the assessment is external or internal, any censorship lessens the reliability of the report. An independent copy needs to be shared with the highest authority of the organization, such as the board of directors.

4.9 Other Business and Legal Matters

The ninth RFC 3647 §9 “Other Business and Legal Matters” segment deals with financial and user agreements when operating a PKI either as a private or commercial enterprise. The CA and RA are components of the PKI enterprise, although some RAs might be affiliated third parties, whereas the subscribers are customers and relying parties are indirect users. The CP and CPS might include contractual language or alternatively terms and conditions applicable to different parities might be in separate documents. Regardless, the organization needs to engage legal counsel for developing this segment of the CP.

The RFC 3647 §9.1 “Fees” subsection is allocated for the discussion of applicable fees, such as issuing or renewing certificates, additional charges for revocation, or costs relation to other services provided by the PKI system. Pricing schedules, when applicable, are often better managed as separate documents rather than having to update a CP or CPS when changing general fees or providing special arrangements or discounts. However, instead of defaulting to the “no stipulation” clause, providing a URL or contact information for pricing is more useful.

The RFC 3647 §9.2 “Financial Responsibility” subsection is for the discussion of financial information such as the types of insurance, coverage. Actual listings of assets or other financial instruments are better managed in separate documents rather than having to update a CP or CPS annually to reflect current information. Again, instead of defaulting to the “no stipulation” clause, providing a URL or contact information for financial information is more useful.

The RFC 3647 §9.3 “Confidentiality of Business Information” subsection contains provisions for data protection controls. Chapter 1, “Introduction,” describes data confidentiality with a more detailed discussion in Chapter 9, “PKI Governance, Risk, and Compliance,” on data classification. Any enterprise is expected to maintain a data classification policy as part of its overall security governance. Consequently, it is better to manage data classification definitions in a separate policy document, but the CP needs to be aligned with the confidential data definitions. one company’s confidential data might not be another’s, so any intercompany communications need to be coordinated for mutual data protection, such as a mutual nondisclosure agreement.

The RFC 3647 §9.4 “Privacy of Personal Information” subsection contains provisions for privacy controls. Privacy laws and data elements vary among jurisdictions so the CP needs to identify which laws are applicable. However, privacy is an important topic that is better managed in a separate policy document, but the CP needs to be aligned with the privacy data definitions and corresponding practices. Further privacy details might be provided in the CPS; however, again, privacy is better managed in a separate policy and practices document not linked specifically to the PKI policy and practices.

The RFC 3647 §9.5 “Intellectual Property Rights” subsection deals with intellectual property (IP) including patents, copyrights, trademarks or trade secrets. However, intellectual property rights are better managed in a separate policy document, but the CP needs to be aligned with the IP policy and corresponding practices. Per the IP policy, the CP needs to state its process for dealing with IP claimed by a subscriber for any certificate-related information.

The RFC 3647 §9.6 “Representations and Warranties” subsection deals with contractual issues relating to PKI entities. A representation is statement made by one of two contracting parties to the other, before or at the time of making the contract, in regard to some fact, circumstance, or state of facts pertinent to the contract, which is influential in bringing about the agreement, whereas a warranty is the promise a company makes to ensure the conditions of a contract are fulfilled.‡ In some cases, the CP might be included as part of a contract or contain CA, RA, subscriber, or relying party agreements.

The RFC 3647 §9.7 “Disclaimers of Warranties” subsection deals with limiting contractual conditions relating to PKI entities. A disclaimer might identify restrictions that may otherwise be presumed, restrictions from other agreements not applicable to PKI entities, or restrictions from applicable law. In some cases, the CP might be excluded from contracts with non-PKI participants involved with other parts of the organization.

The RFC 3647 §9.8 “Limitations of Liability” subsection deals with limiting contractual obligations within the CP relating to CA, RA, subscriber, or relying party agreements. Liability caps include limits on the types and amounts of recoverable damages. The CP might be included as part of a contract or contain CA, RA, subscriber, or relying party agreements.

The RFC 3647 §9.9 “Indemnities” subsection deals with provisions by which one party (such as the PKI organization) makes a second party (such as a subscriber or relying party) whole for losses or damage incurred by the second party, typically arising out of the first party’s conduct. Again, in some cases, the CP might be included as part of a contract or contain CA, RA, subscriber, or relying party agreements.

The RFC 3647 §9.10 “Term and Termination” subsection deals with the time period the CP or other agreements remain valid and subsequent termination conditions. Term includes when the document becomes effective and when it expires. Termination includes circumstances under which the document terminates earlier, and consequences of its termination. The CP might be included as part of a contract or contain CA, RA, subscriber, or relying party agreements.

The RFC 3647 §9.11 “Individual Notices and Communications with Participants” subsection deals with interactions between PKI participants. This subsection differs from the second segment RFC 3647 §2 “Publication and Repository Responsibilities,” which addresses information to a wide audience. And while individual messages need to align with confidentiality considerations in the RFC 3647 §9.3 subsection and privacy considerations in the RFC 3647 §9.4 subsection, for some communications to be legally effective, they might need to employ an electronic signature. While many jurisdictions have various electronic signature laws, for the purposes of this discussion, we refer to the U.S. public law 106-229 Electronic Signatures in Global and National Commerce Act (the ESign Act)§ for a definition of an electronic signature.

Electronic signature—The term “electronic signature” means an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record.

Thus, while a digital signature is an electronic process that satisfies the definition of an electronic signature, there are many other techniques recognized by law. This is an important legal and technology concept since logically a relying party cannot validate a digital signature using the signer’s certificate until after the subscriber has obtained the certificate in the first place. But the process for the subscriber to obtain the certificate might require the legal equivalent of an electronic signature, which includes many other methods such as clicking on a link to accept the newly generated certificate and thereby accepting the terms and conditions of the CP or CPS and subscriber agreement. Likewise, the relying party accessing the certificate chain, CRL, or OCSP responder during the certificate validation might also require an electronic signature signifying acceptance of the relying party agreement.

The RFC 3647 §9.12 “Amendments” subsection deals with substantive changes to the CP or other agreements that materially affect the acceptable use of certificates. As discussed earlier, the RFC 3647 §1.5 subsection provides guidance on the roles and responsibilities of the policy authority (PA), but this subsection addresses change control procedures for amending a document, notification procedures for alerting various PKI entities, and to some reasonable extent, the conditions that require an amendment. Consider the hypothetical situation for the A.2.1 e-mail signature CA in Figure 4.6.

In this scenario, previously issued certificates were used by employees to sign e-mails and software, and per the CA policy this was an acceptable practice. But the decision was made to stand up a new CA for issuing code signing certificates such that separate certificates were now needed, one for e-mail signing and another for code signing. An amended CP with a new version number might be published with the new rules, and the previous policy identifier in the certificates would likewise be updated to two different identifiers, one for e-mail signing and the other for code signing. Employees would be notified that effective per some future date, code signing required a different certificate, and per some later date, any signed code could no longer be validated using the old e-mail certificates. Eventually, all of the existing e-mail certificates with the old policy identifier would expire and be replaced with the newer identifier.

The RFC 3647 §9.13 “Dispute Resolution Procedures” subsection deals with processes for addressing disagreements and possibly challenges to the CP. Contact information for general queries and feedback was discussed in §1 “Introduction.” The same contact information might be used for dispute resolution. Regardless, the PKI system needs the ability to receive, review, process, and respond to a dispute. This is a consensual process in which the parties attempt to reach agreement. In the event the resolution is further disputed, then adjudicative processes, such as litigation or arbitration, might be necessary.

The RFC 3647 §9.14 “Governing Law” subsection identifies the jurisdictions that govern the interpretation and enforcement of the subject CP or CPS or agreements. In our scenario, the applicable laws include the jurisdiction in which the ABC Corporation is incorporated. In the event of an adjudicative processes as discussed in RFC 3647 §9.13, the legal jurisdiction would prevail over dispute resolution.

The RFC 3647 §9.15 “Compliance with Applicable Law” subsection deals with legal, regulatory, and contractual requirements impacting the various PKI entities. For example, many jurisdictions or other organization impose their own requirements when operating within their domains. These requirements might affect how each PKI entity manages their cryptographic keys. Examples of legal and contractual requirements include the following:

• Many U.S. states require that commercial CA be licensed and undergo a Statement on Standards for Attestation Engagements (SSAE) No. 16 Reporting on Controls at a Service Organization audit.
• Browser manufacturers require that a PKI system undergo a Trust Service Principles and Criteria for Certification Authorities (WebTrust for CA) audit in order to have their root CA certificate included within the product.
• Payment card brands require that smart cards be compliant to the EMV Integrated Circuit Card Specification for Payment Systems and mobile payment be compliant to the EMV Payment Tokenization Specification.

Each PKI system needs to determine which legal, regulatory, and contractual requirements are applicable its operations and include them in its CP and relevant documents.

The RFC 3647 §9.16 “Miscellaneous Provisions” subsection deals with common provisions typically found in contract law. The CP might include various clauses that would be aligned with various agreements or other contracts with vendors and other suppliers.

The RFC 3647 §9.17 “Other Provisions” subsection is for any other legal statements addressing roles and responsibilities not covered in the other “Business and Legal Matters” subsections.

---