Trust Service Principles and
Criteria for Certification
Authorities
Version 2.0
March 2011
(Effective July 1, 2011)
(Supersedes WebTrust for Certification Authorities
Principles Version 1.0 August 2000)
Copyright ？ 2011 by
Canadian Institute of Chartered Accountants.
All rights reserved. The Principles and Criteria may be reproduced and distributed provided that reproduced materials are not in any way directly offered for sale or profit and attribution is given.
AICPA/CICA Public Key Infrastructure (PKI) Assurance Task Force
Donald E. Sheehy, Deloitte & Touche, LLP Chair
Michael Greene, Ernst & Young LLP
Mark Lundin, KPMG LLP
Jeffrey Ward, Stone Carlie & Company LLC
The AICPA and CICA would like to express gratitude to the members of the Task Force and its chair, Don Sheehy, for the knowledge they have contributed and time and effort expended to develop the Trust Services Prinicples and Criteria for Certification Authorities. Equally appreciated is the contribution of Reema Anand, KPMG LLP, who contributed greatly to the knowledge of the Task Force.
Staff Contact:
Bryan Walker, CICA
EFFECTIVE DATE
These Principles and Criteria are effective for years commencing on or after July 1, 2011 although earlier implementation is encouraged.
Page | 2
Table of Contents
Effective date ..............................................................................................................................2 INTRODUCTION ......................................................................................................................6 Introduction to Trust Service Principles and Criteria for Certification Authorities Version 2.0 .... 6 Importance of PKI ....................................................................................................................... 6 OVERVIEW ...............................................................................................................................7 What is a Public Key Infrastructure? ........................................................................................... 7 What is a Digital Signature? ........................................................................................................ 9 What are the Differences Between Encryption Key Pairs and Signing Key Pairs? ..................... 10 What is a Certification Authority? ............................................................................................. 11 What is a Registration Authority?.............................................................................................. 11 What is the Impact of an External RA?...................................................................................... 13 What is an Extended Validation Certificate? ............................................................................. 14 What is a Certification Practice Statement and a Certificate Policy? .......................................... 14 What are the Hierarchical and Cross-Certified CA Models? ..................................................... 14 What is the Impact of Subordinate CAs? ................................................................................... 15 What are Some of the Business Issues Associated with CAs? .................................................... 16 PRINCIPLES AND CRITERIA FOR CERTIFICATION AUTHORITIES ............................... 17 Certification Authorities Principles ........................................................................................... 17
CA Business Practices Disclosure...................................................................................... 17
Service Integrity ................................................................................................................ 17
CA Environmental Controls .............................................................................................. 18 Intended Use of the Trust Services Principles and Criteria ......................................................... 19 TRUST SERVICE PRINCIPLES AND CRITERIA FOR CERTIFICATION AUTHORITIES . 20 1. CA BUSINESS PRACTICES DISCLOSURE .......................................................................... 20 Page | 3
1.1 Certification Practice Statement (CPS) ................................................................ 20 1.2 Certificate Policy (if applicable) .......................................................................... 20 2. CA BUSINESS PRACTICES MANAGEMENT ................................................. 21 2.1 Certificate Policy Management (if applicable) ..................................................... 21 2.2 Certification Practice Statement Management ...................................................... 21 2.3 CP and CPS Consistency (if applicable) .............................................................. 22 3. CA ENVIRONMENTAL CONTROLS ............................................................... 23 3.1 Security Management .......................................................................................... 23 3.2 Asset Classification and Management .................................................................. 24 3.3 Personnel Security ............................................................................................... 25 3.4 Physical and Environmental Security ................................................................... 27 3.5 Operations Management ...................................................................................... 29 3.6 System Access Management ................................................................................ 30 3.7 Systems Development and Maintenance .............................................................. 33 3.8 Business Continuity Management ........................................................................ 34 3.9 Monitoring and Compliance ................................................................................ 36 3.10 Audit Logging ..................................................................................................... 37 4. CA KEY LIFE CYCLE MANAGEMENT CONTROLS ..................................... 41 4.1 CA Key Generation ............................................................................................. 41 4.2 CA Key Storage, Backup and Recovery............................................................... 43 4.3 CA Public Key Distribution ................................................................................. 43 4.4 CA Key Usage..................................................................................................... 44 4.5 CA Key Archival and Destruction ....................................................................... 45 4.6 CA Key Compromise .......................................................................................... 46 4.7 CA Cryptographic Hardware Life Cycle Management ......................................... 47 Page | 4
4.8 CA Key Escrow (if applicable) ............................................................................ 48 5. SUBSCRIBER KEY LIFE CYCLE MANAGEMENT CONTROLS ................... 50 5.1 CA-Provided Subscriber Key Generation Services (if supported)......................... 50 5.2 CA-Provided Subscriber Key Storage and Recovery Services (if supported) ........ 50 5.3 Integrated Circuit Card (ICC) Life Cycle Management (if supported) .................. 52 5.4 Requirements for Subscriber Key Management ................................................... 55 6. CERTIFICATE LIFE CYCLE MANAGEMENT CONTROLS ........................... 57 6.1 Subscriber Registration ........................................................................................ 57 6.2 Certificate Renewal (if supported) ....................................................................... 59 6.3 Certificate Rekey ................................................................................................. 60 6.4 Certificate Issuance ............................................................................................. 61 6.5 Certificate Distribution ........................................................................................ 62 6.6 Certificate Revocation ......................................................................................... 63 6.7 Certificate Suspension (if supported) ................................................................... 64 6.8 Certificate Validation .......................................................................................... 65 7. SUBORDINATE CA CERTIFICATE LIFE CYCLE MANAGEMENT
CONTROLS........................................................................................................ 67 7.1 Subordinate CA Certificate Life Cycle Management ........................................... 67 APPENDIX A ........................................................................................................................... 69 ?1 RFC 3647 69
?2 RFC 2527 76
?3 WebTrust for CAs v1 ........................................................................................................... 80 Page | 5
INTRODUCTION
Introduction to Trust Service Principles and Criteria for Certification Authorities Version 2.0 This document provides a framework for third party assurance providers to assess the adequacy and effectiveness of the controls employed by Certification Authorities (CAs). As a result of the technical nature of the activities involved in securing e-commerce transactions, this document also provides a brief overview of public key infrastructure (PKI) using cryptography and trusted third-party concepts. This document replaces Version 1.0 of the AICPA/CICA WebTrust Program for Certification Authorities
that was issued in August 2000. Unlike Version 1.0 that was intended to be used by licensed WebTrust practitioners only, this version is regarded as ―open-source‖ and can be used in the conduct of any
assurance engagement, internal or external, by any third-party service provider. It also represents an effective benchmark for CAs to conduct self-assessments. The public accounting profession has continued to play its role, with an intent to increase consumer confidence in the application of PKI technology by establishing a basis for providing third party assurance to the assertions made by CAs. This document was developed by a CICA/AICPA Task Force using ISO 21188 ―Public Key Policy and
Practices Framework‖ and Version 1.0 of the AICPA/CICA WebTrust Program for Certification
Authorities.
Input and approval was also obtained from the Certification Authority Browser Forum (CA/Browser Forum – see www.cabforum.org) for the content and control activities contained in this framework. The CA/Browser Forum was formed among certification authorities (CAs) and vendors of Internet browser software and other applications. This voluntary organization has worked collaboratively in defining guidelines and means of implementation for the Extended Validation (EV) SSL Certificate standard as a way of providing a heightened security for Internet transactions and creating a more intuitive method of displaying secure sites to Internet users.
The Principles and Criteria for Certification Authorities are consistent with standards developed by the American National Standards Institute (ANSI), International Organization for Standardization (ISO), and Internet Engineering Task Force (IETF). The Principles and Criteria are also consistent with the practices established by the CA Browser Forum (see www.cabforum.org).
Importance of PKI
PKI provides a means for relying parties (meaning, recipients of certificates who act in reliance on those certificates and/or digital signatures verified using those certificates) to know that another individual’s or
entity’s public key actually belongs to that individual/entity. CA organizations and/or CA functions have been established to address this need.
Cryptography is critical to establishing secure e-commerce. However, it has to be coupled with other secure protocols in order to provide a comprehensive security solution. Several cryptographic protocols require digital certificates (in effect, electronic credentials) issued by an independent trusted third party (the CA) to authenticate the transaction. CAs have assumed an increasingly important role in secure e-commerce. Although there is a large body of existing national, international, and proprietary standards and guidelines for the use of cryptography, the management of digital certificates, and the policies and practices of CAs, these standards have not been applied or implemented uniformly.
This version is titled the Trust Services Principles and Criteria for Certification Authorities Version 2.0. These Principles and Criteria are intended to address user (meaning, subscriber and relying party) needs and concerns and are designed to benefit users and providers of CA e-commerce assurance services by providing a common body of knowledge that is communicated to such parties.
OVERVIEW
What is a Public Key Infrastructure?
With the expansion of e-commerce, PKI is growing in importance and will continue to be a critical enterprise security investment. PKI enables parties to an e-commerce transaction to identify one another by providing authentication with digital certificates, and allows reliable business communications by providing confidentiality through the use of encryption, and authentication data integrity and a reasonable basis for nonrepudiation through the use of digital signatures.
PKI uses public/private-key pairs—two mathematically related keys. Typically, one of these keys is
made public, by posting it on the Internet for example, while the other remains private. Public-key cryptography works in such a way that a message encrypted with the public key can only be decrypted with the private key, and, conversely, a message signed with a private key can be verified with the public key. This technology can be used in different ways to provide the four ingredients required for trust in e-commerce transactions, namely: confidentiality, authentication, integrity, and nonrepudiation. Using PKI, a subscriber (meaning, an end entity (or individual) whose public key is cryptographically bound to his or her identity in a digital certificate) has an asymmetric cryptographic key pair (meaning, a public key and a private key). The subscriber’s private key must be kept secret, whereas the public key
may be made widely available, usually presented in the form of a digital certificate to ensure that relying parties know with confidence the identity to which the public key belongs. Using public key Page | 7
cryptography, the subscriber could send a message signed with his or her private key. The signature can be validated by the message recipient using the subscriber’s public key. The subscriber could also
encrypt a message using the recipient’s public key. The message can be decrypted only with the
recipient’s private key.
A subscriber first obtains a public/private key pair (generated by the subscriber or for the subscriber as a service). The subscriber then goes through a registration process by submitting their public key to a Certification Authority or a Registration Authority (RA), which acts as an agent for the CA. The CA or RA verifies the identity of the subscriber in accordance with the CA’s established business practices (that may be contained in a Certification Practice Statement), and then issues a digital certificate. The certificate includes the subscriber’s public key and identity information, and is digitally signed by the CA, which binds the subscriber’s identity to that public key. The CA also manages the subscriber’s digital
certificate through the certificate life cycle (meaning, from registration through revocation or expiration). In some circumstances, it remains important to manage digital certificates even after expiry or revocation so that digital signatures on stored documents held past the revocation or expiry period can be validated at a later date.
The following diagram illustrates the relationship between a subscriber’s public and private keys, and how they are used to secure messages sent to a relying party.
PrivatePublic
keykeyUnique
mathematical
relationship
Can only beMessage
opened withencrypted
private keywith public
key
A transaction submitted by a customer to an online merchant via the Internet can be encrypted with the merchant’s public key and therefore can only be decrypted by that merchant using the merchant’s private key—ensuring a level of confidentiality. Confidentiality can also be achieved through the use of Secure Socket Layer (SSL), Secure/Multipurpose Internet Mail Extensions (S/MIME), and other protocols, such as Secure Electronic Transaction (SET).
Page | 8
What is a Digital Signature?
Digital signatures can be used to provide authentication, integrity, and nonrepudiation. Generally speaking, if a customer sends a digitally signed message to a merchant, the customer’s private key is used to generate the digital signature and the customer’s public key can be used by the merchant to verify the
signature. The mathematical processes employed are somewhat different depending on the kind of asymmetric cryptographic algorithm employed. For example, the processes are slightly different for reversible algorithms (i.e., those which can be readily used to support digital signatures as well as encryption) such as Rivest Shamir Adleman (RSA) and irreversible algorithms such as the Digital Signature Algorithm (DSA).
The following example illustrates the digital signature generation and verification process for a reversible asymmetric cryptographic algorithm (such as RSA). Suppose a customer wants to send a digitally signed message to a merchant. The customer runs the message through a hash function (meaning, a mathematical function that converts a message into a fixed length block of data, the hash, in a fashion such that the hash uniquely reflects the message – in effect, it is the message’s ―fingerprint‖). The
customer then transforms the hash using the algorithm and the customer’s private key to create the digital
signature which is appended to the message. A header is also appended to the message, indicating the merchant’s email address, the sender’s email address, and other information such as the time the message is sent. The message header, the message itself, and the digital signature are then sent to the merchant. The customer can optionally send his/her public key certificate to the merchant in the message itself. All of this is usually done by the e-mail software in such a way that the process is transparent to the user. The following diagram illustrates the process of using a subscriber’s key pair to ensure the integrity and authenticity of a message sent by the customer (subscriber) to a merchant.
Customer’s Customer Merchant Customer’s Header Header private public + + key Creates hash and Transforms hash with key Message Message transforms with private public key, recreates
key to form digital hash and compares to + + signature validate digital signature
Digital Signature Digital Signature
To determine whether the message came from the customer (meaning, authentication) and to determine whether the message has not been modified (meaning, integrity), the merchant validates the digital signature. To do so, the merchant must obtain the customer’s public key certificate. If the customer did
not send his or her public key certificate as part of the message, the merchant would typically obtain the Page | 9
customer’s public key certificate from an online repository (maintained by the CA or another party acting
as the agent of the CA, or any other source even if unrelated to the CA). The merchant then validates that the customer’s digital certificate (containing the customer’s public key) was signed by a recognized Certification Authority to ensure that the binding between the public key and the customer represented in the certificate has not been altered. Next, the merchant extracts the public key from the certificate and uses that public key to transform the digital signature to reveal the original hash. The merchant then runs the message as received through the same hash function to create a hash of the received message. To verify the digital signature, the merchant compares these two hashes. If they match, then the digital signature validates and the merchant knows that the message came from the customer and it was not modified from the time the signature was made. If the hashes do not match, then the merchant knows that the message was either modified in transit or the message was not signed with the customer’s private key.
As a result, the merchant cannot rely on the digital signature.
Digital signatures can also be used to provide a basis for nonrepudiation so that the signer cannot readily deny having signed the message. For example, an online brokerage customer who purchases one thousand shares of stock using a digitally signed order via the Internet should have a difficult task if he or she later tries to deny (meaning, repudiate) having authorized the purchase.
What are the Differences Between Encryption Key Pairs and Signing Key Pairs?
As stated earlier, establishing a reasonable basis for nonrepudiation requires that the private key used to create a digital signature (meaning, the signing private key) be generated and stored securely under the sole control of the user. In the event a user forgets his or her password or loses, breaks, or destroys his/her signing private key, it is acceptable to generate a new signing key pair for use from that point forward with minimal impact to the subscriber. Previously signed documents can still be verified with the user’s old signature verification public key. Documents subsequently signed with the user’s new signing private key must be verified with the user’s new signature verification public key.
Extra care is required to secure the Certification Authority’s signing private key, which is used for signing user certificates. The trustworthiness of all certificates issued by a CA depends upon the CA’s protecting its private signing key. CAs securely back up their private signing key(s) for business continuity purposes to allow the CA to continue to operate in the event that the CA’s private signing key is accidentally destroyed (but not compromised) as a result of hardware failure, for example. Except for CA business continuity purposes, there are generally no technical or business reasons to back up a signing private key. On the other hand, and as cited earlier, it is often desirable that a key pair used for encryption and decryption be securely backed up to ensure that encrypted data can be recovered when a user forgets his Page | 10