Chapter 5

PKI Roles and Responsibilities

As discussed in Chapter 4, “PKI Management and Security,” the certificate policy (CP) and the certificate practice statement (CPS) addresses controls for the public key infrastructure participants—the certificate authority (CA), the registration authority (RA), the relying party, and the subscriber. We also introduced the policy authority (PA). This chapter continues the discussion for the various PKI roles and responsibilities. We first consider Table 5.1 that provides a high-level description of responsibilities for each primary role.

Chapter 10, “Advanced PKI,” addresses the audit process for the annual or ad hoc security and risk assessments of any or all PKI components. The remainder of the chapter maps the primary roles to the various PKI components, namely, the certificate authority, registration authority, policy authority, subscriber, and relying party. Additional roles are introduced as needed per each PKI component and italicized to indicate their specialty. We also discuss the issues for managing a PKI for small, medium, and large organizations.

5.1 Certificate Authority

The primary role of any certificate authority is to sign digital objects using its private key, which includes signing certificates and certificate revocation list (CRL) for subordinate CA. Root CA systems also sign certificates and CRL for itself since it is the apex authority within a given PKI system. In addition to publishing CRL for public access by validation processes, the CRL might be used as status information to Online Certificate Status Protocol (OCSP) services. Therefore, OCSP services are included in our discussion on CA. First, we take a look at Table 5.2.

5.1.1 Root CA

Initially, the root CA system is installed by administrators and subsequently updated as needed for new hardware or software. Since the root CA system is offline, updates are performed manually. Software upgrades are carried into the PKI room using portable media in cooperation with technicians for physical access. Installations and upgrades do not require the presence of any cryptographic keys so custodians are not involved. As newer equipment replaces older equipment, the older hardware can be decommissioned after PKI custodians ensure that all cryptographic materials have been properly terminated.

Preceding any root CA operations, security managers ensure that all physical security controls are in place and effective. Any incidents are immediately reported to the technicians since a security breach might indicate a key compromise. Likewise, any abnormalities with the root CA physical security controls are immediately reported to the security managers. Otherwise, no news is often assumed to be good news; however, the two primary roles need to periodically synchronize information and status of the overall physical security controls.

Before the root CA event begins, auditors are present to ensure technicians and custodians follow documented procedures. Each procedure is a custom set of stepwise processes with assignments allocated per role and responsibility. The security officer or auditor follows the procedures, checking that each step is correctly performed by the appropriate role, initialed by each participant, with a final sign-off sheet. Root CA procedures include the following scenarios.

Significant CA events that should be observed by an auditor include the following events:

• Generation of root CA keys
• Generation of root CA certificates
• Generation of subordinate CA certificates by the root CA
• Signing CRL updates with revoked CA certificates
• Termination of root CA keys

Regular CA events that need only be observed by a security officer and not necessarily by an auditor include the following events:

• Signing any empty CRL updates for any CA including the root CA
• Signing CRL updates with revoked subscriber certificates

Prior to any cryptographic operations being performed by technicians, the root CA private keys need to be enabled by the custodians. Offline root CA systems are typically powered down, such that when powered up, the root CA private keys remain unavailable. Depending on the system architecture, the private keys might be stored as N of M shares on separated smart cards, each activated by individual custodians. Alternatively, the private keys might be stored encrypted, and the decryption key might be stored as N of M shares on separated smart cards, each activated by individual custodians. There are many methods to securely manage the CA private keys including keeping them inside an HSM under dual custodian control. Regardless of the private key protection practices, once the root CA private keys are available, the procedures can be completed. Figure 5.1 shows the relationships between the various participants and the components.

The offline CA is an application running on a dedicated computer that interfaces to the offline HSM and neither has any network connection. PKI custodians import the CA private keys using smart cards with a smart card reader connected to the HSM. PKI technicians or administrators log on to the CA application using keyboard–video–mouse (KVM) local access. All three PKI participants follow the documented PKI procedures, and auditors or security officers observe the event to ensure the procedures are followed. At the completion of a PKI event, the CA private keys are returned to their original unavailable state and the CA application is powered off. As discussed for our ABC Corporation scenario, the offline CA and HSM reside in the PKI room in the office building.

Maintenance and reporting operations that are noncryptographic in nature such as configuring the root CA applications do not require access to the root CA private keys. Therefore, only technicians are needed for maintenance, so auditors and custodians are not involved. Reporting includes reviewing or pulling audit logs, checking ad hoc statistics, or running analytical reports.

Smaller organizations might find staffing a challenge. Maintaining proper separation of duties among a small group is problematic. For example, having a primary and backup PKI technician, a primary and backup PKI administrator, 7 PKI custodians (assuming a key split three of seven schemes), at least one security officer, and an auditor as 13 separate roles might not be practical. In general, the main goal is to avoid any one person accessing the root CA private keys. Accordingly, the key split scheme provides dual control but only if properly implemented as neither the HSM nor the offline CA is omniscient and cannot recognize if the same person is using all three smart cards.

Consequently, the PKI technicians and the PKI administrators might also be PKI custodians; however, neither the technicians nor the administrators can be a security officer or an auditor as that would compromise the audit independence. The person checking the procedures cannot be the same person executing the procedures. Furthermore, the security officer might also be a PKI custodian; however, to maintain independence auditors must not be PKI custodians.

5.1.2 Online CA

We will now turn our attention to the online CA systems. Obviously, the fundamental difference between the root CA and others is that the root CA is operated in an offline mode, while the others are available on a network. This affects the overall security controls and the related PKI procedures. Next, we will take a look at Table 5.3.

Initially, the online CA systems are installed by administrators and subsequently updated as needed for new hardware or software. Unlike root CA systems, software upgrades are possible over the network using remote access controls, so technicians need not be involved. Similar to root CA systems, installations and upgrades do not require the presence of any cryptographic keys so custodians need not be involved. And like root CA systems, as newer equipment replaces older equipment, the older hardware can be decommissioned after technicians, custodians, and auditors ensure that all cryptographic materials have been properly terminated. Figure 5.2 shows the relationships between the participants and components.

The online CA is an application running on servers that interfaces to the online HSM and both have network access. Note that the online CA might also communicate to the HSM over the network through a secure connection. PKI custodians initially import the CA private keys remotely over the network through a secure connection, and once the CA private keys are installed, the keys remain active in the HSM. PKI technicians or administrators log on to the CA application or the HSM over the network per the documented PKI procedures, and auditors or security officers observe the event to ensure the procedures are followed. As discussed for our ABC Corporation scenario, the offline CA and HSM reside in the PKI racks in the data center building.

Preceding any online CA operations, security managers ensure that all physical security controls are in place and effective. Any incidents are immediately reported to the technicians since a security breach might indicate a key compromise. Likewise, any abnormalities with the online CA physical security controls are immediately reported to the security managers. And similar to root CA systems, no news is good news, but periodically the two primary roles need to synchronize information and status of the overall physical security controls.

Before key generation begins, auditors are present to ensure technicians and custodians follow documented procedures and all documentation and video evidence is recorded of the proceedings. For online CA systems, technicians generate keys inside HSM and generate a CSR to obtain CA certificates from the superior CA (e.g., root CA). As part of the key generation procedures, technicians and custodians might back up keys for subsequent recovery in the event of an HSM failure or deployment of additional HSM. Otherwise, auditors need not be involved in the normal automatic operations.

Significant CA events that should be observed by an auditor include the following events:

• Generation of subordinate CA keys
• Generation of subordinate CA certificates by a superior (nonroot) CA
• Termination of subordinate CA keys

Regular CA events that need only be observed by a security officer and not necessarily by an auditor include the following events:

• Signing any empty CRL updates for any CA including the root CA
• Signing CRL updates with revoked subscriber certificates
• Manually install CRL updates

Maintenance and reporting operations that are noncryptographic in nature such as configuring the CA applications do not require access to the CA private keys. Therefore, only technicians are needed for maintenance, so auditors and custodians need not be involved. Reporting includes reviewing or pulling audit logs, checking ad hoc statistics, or running analytical reports.

Similar to offline CA issues, smaller organizations might find staffing a challenge for managing online CA systems. Again, PKI technicians or PKI administrators might also be PKI custodians; however, it is easier to demonstrate dual controls if the roles are separate. Likewise, neither the technicians nor the administrators can be a security officer or an auditor, but the security officer can be a PKI custodian. To maintain independence, auditors must not be PKI custodians.

5.1.3 OCSP Systems

We now consider the OCSP systems. Whereas CRLs are signed by the issuing CA and publically posted for certificate validation by any relying party, OCSP responders accept certificate status requests and return signed responses. Therefore, OCSP responders have their own digital signature keys. These responders operate in an online mode and have both automatic and manual processes, which affect the overall security. Let’s look at Table 5.4.

Initially, the OCSP systems are installed by administrators and subsequently updated as needed for new hardware or software. Similar to online CA systems, software upgrades are possible over the network using remote access controls, so technicians need not be involved. Installations and upgrades do not require the presence of any cryptographic keys so custodians need not be involved. And like any CA system, as newer equipment replaces older equipment, the older hardware can be decommissioned after technicians, custodians, and auditors ensure that all cryptographic materials have been properly terminated.

Preceding any OCSP operations, security managers ensure that all physical security controls are in place and effective. Any incidents are immediately reported to the technicians in the event of a security breach that might indicate a key compromise. Likewise, any abnormalities with the OCSP physical security controls are immediately reported to the security managers. And similar to any CA system, no news is good news, but the two primary roles need to periodically synchronize information and status of the overall physical security controls.

Before key generation begins, auditors are present to ensure technicians and custodians follow documented procedures. For OCSP systems, technicians generate keys inside HSM and generate a CSR to obtain CA certificates from an online CA. As part of the key generation procedures, technicians and custodians might back up keys for subsequent recovery in the event of an HSM failure or deployment of additional HSM. Otherwise, auditors are not involved in the normal manual or automatic operations.

Significant OCSP events that should be observed by an auditor include the following events:

• Generate OCSP keys
• Obtain OCSP certificates

Regular OCSP events that need only be observed by a security officer and not necessarily by an auditor include the following events:

• Manual installation of OCSP updates
• Request OCSP certificate revocation

Maintenance and reporting operations that are noncryptographic in nature such as configuring the OCSP applications do not require access to the OCSP private keys. Therefore, only technicians are needed for maintenance, so auditors and custodians need not be involved. Reporting includes reviewing or pulling audit logs, checking ad hoc statistics, or running analytical reports.

5.2 Registration Authority

The primary role of a registration authority (RA) is to be the front end to the CA services. The RA provides requestor authentication and authorization such that the CA can reliably perform its functions. Requests include certificates and revocations along with status information. The RA might also support CRL and OCSP services. Furthermore, the RA might be anything from a simple web interface dependent on network authentication to a stand-alone affiliated application. Consider Table 5.5.

Initially, the online RA systems are installed by administrators and subsequently updated as needed for new hardware or software. Like any online system, software upgrades are possible over the network using remote access controls, so technicians need not be involved. Installations and upgrades do not require the presence of any cryptographic keys so custodians need not be involved. And similar to any CA systems, as newer equipment replaces older equipment, the older hardware can be decommissioned after technicians, custodians, and auditors ensure that all cryptographic materials have been properly terminated.

Preceding any online RA operations, security managers ensure that all physical security controls are in place and effective. Any incidents are immediately reported to the technicians since a security breach might indicate a key compromise. Likewise, any abnormalities with the online RA physical security controls are immediately reported to the security managers. And similar to any CA systems, no news is good news, but the two primary roles need to periodically synchronize information and status of the overall physical security controls.

Before key generation begins, auditors are present to ensure technicians and custodians follow documented procedures. For online RA systems, technicians generate keys inside HSM and generate a CSR to obtain RA certificates from the corresponding CA. As part of the key generation procedures, technicians and custodians might back up keys for subsequent recovery in the event of an HSM failure or deployment of additional HSM. Otherwise, auditors need not be involved in the normal automatic operations.

Significant RA events that should be observed by an auditor include the following events:

• Generate online RA keys
• Obtain RA certificates

Regular RA events that need only be observed by a security officer and not necessarily by an auditor include the following events:

• Manual authentication and authorization of subscriber certificate request
• Request RA certificate revocation

Maintenance and reporting operations that are noncryptographic in nature such as configuring the RA applications do not require access to the RA private keys. Therefore, only technicians are needed for maintenance, so auditors and custodians need not be involved. Reporting includes reviewing or pulling audit logs, checking ad hoc statistics, or running analytical reports. Reports might be automatic or manually run by technicians, and provided to auditors or PKI administrators.

5.3 Policy Authority

The primary role of the policy authority (PA) is the management of the certificate policy (CP) and certificate practice statement (CPS) for the CA. Each CA instance might have its own CP and CPS, or the organization might combine all CA instances into a single CP and CPS. Other CP and CPS separation might be by root CA hierarchies. For example, with our hypothetical ABC Corporation, there might a CP and CPS for the internal CA and another for the external CA, and consequently, there might be separate PA for each. However, as we will discuss, there must be common practices and participates for consistency and continuity of the overall PKI systems.

As discussed in Chapter 4, the CP and CPS reserve a section for the policy authority to provide contact information and the administrative processes. In this section, we discussed the various roles for the PA and their respective responsibilities. For the PA, we add two special roles, attorneys to represent the legal group and business managers to represent the organization’s lines of business (LOBs), as shown in Table 5.6.

The PA is a committee of individuals representing different areas of the organization. As introduced in Chapter 1, the concept is to include critical support areas such as cryptography, information technology, business, and legal. Depending on the organization’s structure, risk and compliance managers might also be part of the PA if the business or legal members cannot address these areas. For the purposes of this book, we assume attorneys and business managers can speak to risk and compliance issues.

Technicians operate and manage various PKI systems and therefore provide a viewpoint with experience and knowledge. An understanding of the assorted CA, RA, and OCSP applications, features, functions, limits, and bugs is invaluable. In addition, having a basic comprehension of cryptography and key management is likewise important. Technicians also are responsible for following the CP, CPS, and associate procedures.

Administrators install, maintain, and decommission hardware and software elements for network and system components. An understanding of general information technology, infrastructure, and network architectures provides another experienced viewpoint. Administrators are also responsible for reliability, capacity planning, and software vulnerability management lifecycle.

Attorneys provide a legal perspective of liabilities, warranties, and interpret law, regulatory, and contractual obligations that affect the PKI systems. Other business matters include fees, privacy issues, and intellectual property concerns such as patents, trademarks, and copyrights. Outside counsel might be needed specializing in PKI technology and cryptographic jurisdictions.

Business managers are responsible for managing business applications, dealing with vendors and third-party service providers, and confirming functional requirements. Managers provide a business and risk viewpoint of PKI-enabled applications, security needs, and information flows. Other areas include business continuity and disaster recovery issues.

There also needs to be a committee chair to facilitate the meetings, provide meeting minutes, track issues, and manage assignments. The committee mixture might need to be refreshed from time to time, and ad hoc participation might be needed for specific topics. However, for consistency and continuity, the chair is typically held by senior management in the PKI team.

5.4 Subscribers

The primary role of the subscriber is to use its private key for cryptographic operations including digitals signatures, encryption, and key management. The subscriber might be an individual using a PKI-enabled application, a network device with an embedded cryptographic module, or an application using a cryptographic module. The subscriber’s identity and corresponding public key are encapsulated within the subscriber’s digital certificate. Subscribers can also be relying parties when using other subscribers’ certificates. But subscribers do not operate in isolation; consider Table 5.7.

Initially, applications and network devices are installed by application or network managers and subsequently updated as needed for new software or hardware. Software upgrades are possible over the network using remote access controls. Installations and upgrades do not require the presence of any cryptographic keys so the PKI custodians are not involved. As newer equipment replaces older equipment, the older hardware can be decommissioned after PKI custodians ensure all cryptographic materials have been properly terminated.

Preceding any subscriber operations, security managers ensure that all physical security controls are in place and effective. Any incidents are immediately reported to the subscriber or security manager since a security breach might indicate a key compromise. Likewise, any abnormalities with the subscriber physical security controls are immediately reported to the security managers.

Subscribers generate keys using cryptographic hardware or software modules and might back up keys for subsequent recovery. For PKI-enabled applications and PKI-capable network devices, custodians might be involved in the key generation, key backup, certificates request, or revocation request processes. Otherwise, PKI custodians are not involved in the normal automatic cryptographic operations, including:

• Generate subscriber keys
• Obtain subscriber certificates
• Digitally sign data or messages
• Authenticate via digital signatures
• Establish data encryption keys
• Request subscriber certificate revocation

Maintenance and reporting operations that are noncryptographic in nature such as configuring PKI-enabled applications do not require access to the subscriber private keys. Therefore, only application or network managers are needed for maintenance. Reporting includes reviewing or pulling audit logs, checking ad hoc statistics, or running analytical reports. Reports might be automatic or manually run by technicians, and provided to auditors or PKI administrators.

5.5 Relying Party

The primary role of the relying party is to use subscriber’s certificates for cryptographic operations including signature verification and key management. The relying party might be an individual using a PKI-enabled application, a network device with an embedded cryptographic module, or an application using a cryptographic module. But relying parties do not operate in isolation; consider Table 5.8.

Preceding any relying party operations, security managers ensure that all physical security controls are in place and effective. Any incidents are immediately reported to the relying party in the event of since a security breach might indicate a system compromise. Likewise, any abnormalities with physical security controls are immediately reported to the security managers.

From a cryptography viewpoint, relying parties work in concert with subscribers to implement security controls. Relying parties employ applications for normal automatic operations:

• Validate certificate chains
• Verify signed data or signed messages
• Authenticate subscribers via signature verification
• Establish data encryption keys

Maintenance and reporting operations that are noncryptographic in nature such as configuring PKI-enabled applications do not require access to the subscriber private keys. Therefore, only application or network managers are needed for maintenance. Reporting includes reviewing or pulling audit logs, checking ad hoc statistics, or running analytical reports. Reports might be automatic or manually run by technicians, and provided to auditors or PKI administrators.

5.6 Agreements

An agreement is essentially an understanding between two or more parties with respect to their relative rights and duties. In Chapter 4, we discussed certificate policy (CP) and practices (CPS) and introduced the concept of agreements between the CA and the various PKI participants. From a CA perspective, agreements are primarily for entities that are involved in certificate request processes (subscribers and RA) or certificate validation processes (relying parties). Another agreement area is cross-certification with another CA.

Agreements might be incorporated into the CP or CPS; however, it is a common practice to maintain separate documents. In this manner, warranties and liabilities can be managed without having to constantly update and republish the policy and practices. This allows legal, regulatory, and contractual issues to be addressed in a timely manner as changes occur within different industries that affect the PKI operations, warranties, or liabilities.

It is a good practice to maintain agreements as separate documents to remain flexible and minimize the publication impacts to the CP and the CPS.

In addition to managing the CP and CPS, the policy authority (PA) is also responsible for reviewing and approving agreements. Since agreements contain mostly business and legal considerations, attorneys and business managers are the primary authors. Attorneys address warranty and liability constraints, and business managers address the various application needs and restrictions. The PA needs to synchronize the agreements with the CP and CPS to ensure there are no contradictions and that they share common language for ease of reading.

5.6.1 Certificate Authority Agreements

From a technical perspective, the CA is responsible for managing its private keys and corresponding certificates. From a functional viewpoint, the CA exists to generate other CA certificates or, depending on the CA hierarchy, subscriber certificates. Within the same PKI hierarchy, CA agreements are not normally needed as the business, information technology, legal, and cryptography have shared infrastructures.

Conversely, when different PKI hierarchies interact, the relationships and certificate chains can become rather complex making the CA agreement an essential component. Let’s consider several CA interactions beginning with Figure 5.3, which shows three separate organizations (A, B, and C) each with their own PKI hierarchy. Each hierarchy consists of a root CA and two subordinate CA. The subordinate CA issues subscriber certificates, but for the purposes of this discussion, we need only to consider the CA certificates. Furthermore, each PKI system is independent of each other with separate certificate chains:

• Root A, subordinates A1 and A2, so we have chains A ⇒ A1 and A ⇒ A2
• Root B, subordinates B1 and B2, so we have chains B ⇒ B1 and B ⇒ B2
• Root C, subordinates C1 and C2, so we have chains C ⇒ C1 and C ⇒ C2

Now let’s look at two very different PKI intersections: root certification and subordinate (sub) certification. For either of these two scenarios, there are many legitimate business reasons to interconnect two PKI hierarchies. As examples, perhaps one organization has acquired another, maybe one organization is outsourcing its services to another, or possibly two different applications need to interoperate. Regardless of the business reason, let’s first consider the root certification scenario, where organization A needs to merge its PKI with organization B.

Figure 5.3 shows a root certification where root A is issued a certificate from root B, essentially making root A a subordinate to root B. However, root A now has two certificates, its own self-signed certificate and another signed by root B. So, for subordinates A1 and A2, we have created two new possible certificate chains:

• Root B, subordinate root A, so we have chains B ⇒ A ⇒ A1 and B ⇒ A ⇒ A2

Depending on how organization A configures its browsers, applications, servers, routers, and whatever other components rely on certificates, both sets of certificate chains are valid and can interoperate. However, misconfigurations might inadvertently force certificate validation resolving to the wrong root CA and organization. Thus, an application accepting and using a certificate validated to root B, which should have been validated to root A, might not be covered by organization B’s warranties and consequently take on unacceptable liability and risk. The CA agreement might address such an issue and protect both organizations. Figure 5.3 also shows a subordinate (sub) certification where subordinate C1 is issued a certificate from root B, making C1 a subordinate of both root B and root C. Thus, C1 now has two certificates, creating two new possible certificate chains:

• Root C, subordinates C1, so we have chains C ⇒ C1
• Root B, subordinates C1, so we have chains B ⇒ C1

Depending on how organization C configures its browsers, applications, servers, routers, and whatever other components rely on certificates, both sets of certificate chains are valid and can interoperate. Yet again, misconfigurations might inadvertently force certificate validation resolving to the wrong root CA and organization (i.e., root B instead of root C). And again, the CA agreement might address a similar issue and protect both organizations. Figure 5.4 shows the same three organizations, where organization A and organization C independently cross-certify with organization B. Root A issues a certificate for root B, and conversely root B issues a certificate for root A. Likewise, root B issues a certificate for root C, and equally root C issues a certificate for root B. Depending on how the business rules define interoperability for certificate validation between organizations and how each organization needs to configure its PKI-enabled applications, a CA agreement might define bilateral arrangement.

Our last CA interaction example is shown in Figure 5.5, which is different than cross-certification. In this scenario, organization B acts as a PKI bridge between organization A and organization C. Unlike the previous diagrams, organization B only needs to operate a bridge CA with no internal subordinate CA. An example of a real-world bridge certification is the federal bridge CA,* which was established to facilitate trusted electronic business transactions for federal organizations. The functional purpose of a PKI bridge is to provide interoperability and functionality between disparate PKI hierarchies. Consequently, a CA agreement can enhance the bridge CA policy and practices by specifying business rules.

We conclude that when different PKI hierarchies interact, a CA agreement (CAA) might be beneficial to outline the differences, commonalities, and business rules. System configurations and certificate validation processes might also be specified, along with warranties and other legal and pertinent business information.

5.6.2 Registration Authority Agreements

From a technical perspective, the RA is responsible for authenticating and authorizing subscriber requests. From a functional viewpoint, the RA processes various types of requests, acting as the CA portal. When the RA is part of the CA, an agreement is rarely needed. When the RA is a separate application that interfaces with the CA but part of the same organization, an RA agreement (RAA) is akin to a service level agreement that establishes RA responsibilities such as response times. An RAA can be beneficial for managing internal services when the RA application is operated as a separate application.

When the RA is an affiliate, a third-party service provider, to the CA and operates independently as a separate legal entity, an RAA is needed. The RAA provides the foundation of an affiliate contract, describing the RA role and responsibilities. The contract might contain the RAA in an appendix or exhibit or refer to it as a separate document. In addition, the same policy authority (PA) legal representative should be engaged in the RA contract negotiations.

5.6.3 Subscriber Agreements

From a technical perspective, the subscriber is responsible for managing its private keys and corresponding public key certificates. From a functional viewpoint, the subscriber might use its private key to sign messages, sign documents, authenticate itself via digital signatures, decrypt data encrypted with its public key, or for key management to establish symmetric keys for other cryptographic processes.

Subscriber agreements (SAs) need to address the CA expectations regarding the subscriber controls over the key lifecycle. The SA also needs to clearly delineate the warranties provided by the CA and the liabilities accepted by the CA. Since there are many types of certificates used for a wide variety of reasons with various applications, either the SA needs to address each use case or the PA might provide different SA for each scenario. For example, a TLS certificate is different from a code sign certificate, which is very different than an e-mail certificate. Each use case has different risks and liabilities, which affect the CA warranties.

5.6.4 Relying Party Agreements

From a technical perspective, the relying party is responsible for validating and properly using subscribers’ public key certificates. From a functional viewpoint, the relying party simply utilizes the subscriber certificate according to the use case represented by the certificate. However, if the subscriber misuses the asymmetric keys, the relying party might inadvertently misuse the subscriber certificate. Thus, the subscriber agreement (SA) and relying party agreement (RPA) need to be synchronized in their definitions and terms. From a legal viewpoint if the RPA does not provide sufficient warranty or lacks acceptable liabilities, the relying party might not accept the subscriber certificate regardless of whether the certificate is valid or the subscriber is legitimate.

---