Request for Comments: 3647 Orion Security Solutions, Inc.
Obsoletes: 2527 W. Ford
Category: Informational VeriSign, Inc.
R. Sabett
Cooley Godward LLP
C. Merrill
McCarter & English, LLP
S. Wu
Infoliance, Inc.
November 2003
Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
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. In particular, the framework provides
a comprehensive list of topics that potentially (at the writer’s
discretion) need to be covered in a certificate policy or a
certification practice statement. This document supersedes RFC 2527.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Purpose. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Certificate Policy . . . . . . . . . . . . . . . . . . . 9
3.2. Certificate Policy Examples. . . . . . . . . . . . . . . 11
3.3. X.509 Certificate Fields . . . . . . . . . . . . . . . . 12
3.3.1. Certificate Policies Extension . . . . . . . . . 12
3.3.2. Policy Mappings Extension. . . . . . . . . . . . 13
3.3.3. Policy Constraints Extension . . . . . . . . . . 13
3.3.4. Policy Qualifiers. . . . . . . . . . . . . . . . 14
3.4. Certification Practice Statement . . . . . . . . . . . . 15
3.5. Relationship Between CP and CPS. . . . . . . . . . . . . 16
3.6. Relationship Among CPs, CPSs, Agreements, and
Other Documents. . . . . . . . . . . . . . . . . . . . . 17
3.7. Set of Provisions. . . . . . . . . . . . . . . . . . . . 20
4. Contents of a Set of Provisions. . . . . . . . . . . . . . . . 21
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Overview . . . . . . . . . . . . . . . . . . . . 22
4.1.2. Document Name and Identification . . . . . . . . 22
4.1.3. PKI Participants . . . . . . . . . . . . . . . . 23
4.1.4. Certificate Usage. . . . . . . . . . . . . . . . 24
4.1.5. Policy Administration. . . . . . . . . . . . . . 24
4.1.6. Definitions and Acronyms . . . . . . . . . . . . 24
4.2. Publication and Repository Responsibilities. . . . . . . 25
4.3. Identification and Authentication (I&A). . . . . . . . . 25
4.3.1. Naming . . . . . . . . . . . . . . . . . . . . . 25
4.3.2. Initial Identity Validation. . . . . . . . . . . 26
4.3.3. I&A for Re-key Requests. . . . . . . . . . . . . 27
4.3.4. I&A for Revocation Requests. . . . . . . . . . . 27
4.4. Certificate Life-Cycle Operational Requirements. . . . . 27
4.4.1. Certificate Application. . . . . . . . . . . . . 28
4.4.2. Certificate Application Processing . . . . . . . 28
4.4.3. Certificate Issuance . . . . . . . . . . . . . . 28
4.4.4. Certificate Acceptance . . . . . . . . . . . . . 29
4.4.5. Key Pair and Certificate Usage . . . . . . . . . 29
4.4.6. Certificate Renewal. . . . . . . . . . . . . . . 30
4.4.7. Certificate Re-key . . . . . . . . . . . . . . . 30
4.4.8. Certificate Modification . . . . . . . . . . . . 31
4.4.9. Certificate Revocation and Suspension. . . . . . 31
4.4.10. Certificate Status Services. . . . . . . . . . . 33
4.4.11. End of Subscription. . . . . . . . . . . . . . . 33
4.4.12. Key Escrow and Recovery. . . . . . . . . . . . . 33
4.5. Facility, Management, and Operational Controls . . . . . 33
4.5.1. Physical Security Controls . . . . . . . . . . . 34
4.5.2. Procedural Controls. . . . . . . . . . . . . . . 35
4.5.3. Personnel Controls . . . . . . . . . . . . . . . 35
4.5.4. Audit Logging Procedures . . . . . . . . . . . . 36
4.5.5. Records Archival . . . . . . . . . . . . . . . . 37
4.5.6. Key Changeover . . . . . . . . . . . . . . . . . 38
4.5.7. Compromise and Disaster Recovery . . . . . . . . 38
4.5.8. CA or RA Termination . . . . . . . . . . . . . . 38
4.6. Technical Security Controls. . . . . . . . . . . . . . . 39
4.6.1. Key Pair Generation and Installation . . . . . . 39
4.6.2. Private Key Protection and Cryptographic
Module Engineering Controls. . . . . . . . . . . 40
4.6.3. Other Aspects of Key Pair Management . . . . . . 42
4.6.4. Activation Data. . . . . . . . . . . . . . . . . 42
4.6.5. Computer Security Controls . . . . . . . . . . . 42
4.6.6. Life Cycle Security Controls . . . . . . . . . . 43
4.6.7. Network Security Controls. . . . . . . . . . . . 43
4.6.8. Timestamping . . . . . . . . . . . . . . . . . . 43
4.7. Certificate, CRL, and OCSP Profiles. . . . . . . . . . . 44
4.7.1. Certificate Profile. . . . . . . . . . . . . . . 44
4.7.2. CRL Profile. . . . . . . . . . . . . . . . . . . 44
4.7.3. OCSP Profile . . . . . . . . . . . . . . . . . . 44
4.8. Compliance Audit and Other Assessment. . . . . . . . . . 45
4.9. Other Business and Legal Matters . . . . . . . . . . . . 45
4.9.1. Fees . . . . . . . . . . . . . . . . . . . . . . 46
4.9.2. Financial Responsibility . . . . . . . . . . . . 47
4.9.3. Confidentiality of Business Information. . . . . 47
4.9.4. Privacy of Personal Information. . . . . . . . . 48
4.9.5. Intellectual Property Rights . . . . . . . . . . 48
4.9.6. Representations and Warranties . . . . . . . . . 48
4.9.7. Disclaimers of Warranties. . . . . . . . . . . . 49
4.9.8. Limitations of Liability . . . . . . . . . . . . 49
4.9.9. Indemnities. . . . . . . . . . . . . . . . . . . 49
4.9.10. Term and Termination . . . . . . . . . . . . . . 50
4.9.11. Individual notices and communications
with participants. . . . . . . . . . . . . . . . 50
4.9.12. Amendments . . . . . . . . . . . . . . . . . . . 50
4.9.13. Dispute Resolution Procedures. . . . . . . . . . 51
4.9.14. Governing Law. . . . . . . . . . . . . . . . . . 51
4.9.15. Compliance with Applicable Law . . . . . . . . . 51
4.9.16. Miscellaneous Provisions . . . . . . . . . . . . 51
4.9.17. Other Provisions . . . . . . . . . . . . . . . . 53
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 53
6. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 53
7. Comparison to RFC 2527 . . . . . . . . . . . . . . . . . . . . 60
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10. Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12. List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . 91
13. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 92
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 94
1. Introduction
1.1. Background
In general, a public-key certificate (hereinafter "certificate")
binds a public key held by an entity (such as person, organization,
account, device, or site) to a set of information that identifies the
entity associated with use of the corresponding private key. In most
cases involving identity certificates, this entity is known as the
"subject" or "subscriber" of the certificate. Two exceptions,
however, include devices (in which the subscriber is usually the
individual or organization controlling the device) and anonymous
certificates (in which the identity of the individual or organization
is not available from the certificate itself). Other types of
certificates bind public keys to attributes of an entity other than
the entity’s identity, such as a role, a title, or creditworthiness
information.
A certificate is used by a "certificate user" or "relying party" that
needs to use, and rely upon the accuracy of, the binding between the
subject public key distributed via that certificate and the identity
and/or other attributes of the subject contained in that certificate.
A relying party is frequently an entity that verifies a digital
signature from the certificate’s subject where the digital signature
is associated with an email, web form, electronic document, or other
data. Other examples of relying parties can include a sender of
encrypted email to the subscriber, a user of a web browser relying on
a server certificate during a secure sockets layer (SSL) session, and
an entity operating a server that controls access to online
information using client certificates as an access control mechanism.
In summary, a relying party is an entity that uses a public key in a
certificate (for signature verification and/or encryption). The
degree to which a relying party can trust the binding embodied in a
certificate depends on several factors. These factors can include
the practices followed by the certification authority (CA) in
authenticating the subject; the CA’s operating policy, procedures,
and security controls; the scope of the subscriber’s responsibilities
(for example, in protecting the private key); and the stated
responsibilities and liability terms and conditions of the CA (for
example, warranties, disclaimers of warranties, and limitations of
liability).
A Version 3 X.509 certificate may contain a field declaring that one
or more specific certificate policies apply to that certificate
[ISO1]. According to X.509, a certificate policy (CP) is "a named
set of rules that indicates the applicability of a certificate to a
particular community and/or class of applications with common
security requirements." A CP may be used by a relying party to help
in deciding whether a certificate, and the binding therein, are
sufficiently trustworthy and otherwise appropriate for a particular
application. The CP concept is an outgrowth of the policy statement
concept developed for Internet Privacy Enhanced Mail [PEM1] and
expanded upon in [BAU1]. The legal and liability aspects presented
in Section 4.9 are outcomes of a collaborative effort between IETF
PKIX working group and the American Bar Association (ABA) members who
have worked on legal acceptance of digital signature and role of PKI
in that acceptance.
A more detailed description of the practices followed by a CA in
issuing and otherwise managing certificates may be contained in a
certification practice statement (CPS) published by or referenced by
the CA. According to the American Bar Association Information
Security Committee’s Digital Signature Guidelines (hereinafter
"DSG")(1) and the Information Security Committee’s PKI Assessment
Guidelines (hereinafter "PAG")(2), "a CPS is a statement of the
practices which a certification authority employs in issuing
certificates." [ABA1, ABA2] In general, CPSs also describe practices
relating to all certificate lifecycle services (e.g., issuance,
management, revocation, and renewal or re-keying), and CPSs provide
details concerning other business, legal, and technical matters. The
terms contained in a CP or CPS may or may not be binding upon a PKI’s
participants as a contract. A CP or CPS may itself purport to be a
contract. More commonly, however, an agreement may incorporate a CP
or CPS by reference and therefore attempt to bind the parties of the
agreement to some or all of its terms. For example, some PKIs may
utilize a CP or (more commonly) a CPS that is incorporated by
reference in the agreement between a subscriber and a CA or RA
(called a "subscriber agreement") or the agreement between a relying
party and a CA (called a "relying party agreement" or "RPA"). In
other cases, however, a CP or CPS has no contractual significance at
all. A PKI may intend these CPs and CPSs to be strictly
informational or disclosure documents.
1.2. Purpose
The purpose of this document is twofold. First, the document aims to
explain the concepts of a CP and a CPS, describe the differences
between these two concepts, and describe their relationship to
subscriber and relying party agreements. Second, this document aims
to present a framework to assist the writers and users of certificate
policies or CPSs in drafting and understanding these documents. In
particular, the framework identifies the elements that may need to be
considered in formulating a CP or a CPS. The purpose is not to
define particular certificate policies or CPSs, per se. Moreover,
this document does not aim to provide legal advice or recommendations
as to particular requirements or practices that should be contained
within CPs or CPSs. (Such recommendations, however, appear in
[ABA2].)
1.3. Scope
The scope of this document is limited to discussion of the topics
that can be covered in a CP (as defined in X.509) or CPS (as defined
in the DSG and PAG). In particular, this document describes the
types of information that should be considered for inclusion in a CP
or a CPS. While the framework as presented generally assumes use of
the X.509 version 3 certificate format for the purpose of providing
assurances of identity, it is not intended that the material be
restricted to use of that certificate format or identity
certificates. Rather, it is intended that this framework be
adaptable to other certificate formats and to certificates providing
assurances other than identity that may come into use.
The scope does not extend to defining security policies generally
(such as organization security policy, system security policy, or
data labeling policy). Further, this document does not define a
specific CP or CPS. Moreover, in presenting a framework, this
document should be viewed and used as a flexible tool presenting
topics that should be considered of particular relevance to CPs or
CPSs, and not as a rigid formula for producing CPs or CPSs.
This document assumes that the reader is familiar with the general
concepts of digital signatures, certificates, and public-key
infrastructure (PKI), as used in X.509, the DSG, and the PAG.
2. Definitions
This document makes use of the following defined terms:
Activation data - Data values, other than keys, that are required to
operate cryptographic modules and that need to be protected (e.g., a
PIN, a passphrase, or a manually-held key share).
Authentication - The process of establishing that individuals,
organizations, or things are who or what they claim to be. In the
context of a PKI, authentication can be the process of establishing
that an individual or organization applying for or seeking access to
something under a certain name is, in fact, the proper individual or
organization. This corresponds to the second process involved with
identification, as shown in the definition of "identification" below.
Authentication can also refer to a security service that provides
assurances that individuals, organizations, or things are who or what
they claim to be or that a message or other data originated from a
specific individual, organization, or device. Thus, it is said that
a digital signature of a message authenticates the message’s sender.
CA-certificate - A certificate for one CA’s public key issued by
another CA.
Certificate policy (CP) - A named set of rules that indicates the
applicability of a certificate to a particular community and/or class
of application with common security requirements. For example, a
particular CP might indicate applicability of a type of certificate
to the authentication of parties engaging in business-to-business
transactions for the trading of goods or services within a given
price range.
Certification path - An ordered sequence of certificates that,
together with the public key of the initial object in the path, can
be processed to obtain that of the final object in the path.
Certification Practice Statement (CPS) - A statement of the practices
that a certification authority employs in issuing, managing,
revoking, and renewing or re-keying certificates.
CPS Summary (or CPS Abstract) - A subset of the provisions of a
complete CPS that is made public by a CA.
Identification - The process of establishing the identity of an
individual or organization, i.e., to show that an individual or
organization is a specific individual or organization. In the
context of a PKI, identification refers to two processes:
(1) establishing that a given name of an individual or organization
corresponds to a real-world identity of an individual or
organization, and
(2) establishing that an individual or organization applying for or
seeking access to something under that name is, in fact, the
named individual or organization. A person seeking
identification may be a certificate applicant, an applicant for
employment in a trusted position within a PKI participant, or a
person seeking access to a network or software application, such
as a CA administrator seeking access to CA systems.
Issuing certification authority (issuing CA) - In the context of a
particular certificate, the issuing CA is the CA that issued the
certificate (see also Subject certification authority).
Participant - An individual or organization that plays a role within
a given PKI as a subscriber, relying party, CA, RA, certificate
manufacturing authority, repository service provider, or similar
entity.
PKI Disclosure Statement (PDS) - An instrument that supplements a CP
or CPS by disclosing critical information about the policies and
practices of a CA/PKI. A PDS is a vehicle for disclosing and
emphasizing information normally covered in detail by associated CP
and/or CPS documents. Consequently, a PDS is not intended to replace
a CP or CPS.
Policy qualifier - Policy-dependent information that may accompany a
CP identifier in an X.509 certificate. Such information can include
a pointer to the URL of the applicable CPS or relying party
agreement. It may also include text (or number causing the
appearance of text) that contains terms of the use of the certificate
or other legal information.
Registration authority (RA) - An entity that is responsible for one
or more of the following functions: the identification and
authentication of certificate applicants, the approval or rejection
of certificate applications, initiating certificate revocations or
suspensions under certain circumstances, processing subscriber
requests to revoke or suspend their certificates, and approving or
rejecting requests by subscribers to renew or re-key their