agreement, or an agreement that combines subscriber and relying party
terms may also serve as a CPS. In other PKIs, however, a subscriber
or relying party agreement may incorporate some or all of the terms
of a CP or CPS by reference. Yet other PKIs may distill from a CP
and/or CPS the terms that are applicable to a subscriber and place
such terms in a self-contained subscriber agreement, without
incorporating a CP or CPS by reference. They may use the same method
to distill relying party terms from a CP and/or CPS and place such
terms in a self-contained relying party agreement. Creating such
self-contained agreements has the advantage of creating documents
that are easier for consumers to review. In some cases, subscribers
or relying parties may be deemed to be "consumers" under applicable
law, who are subject to certain statutory or regulatory protections.
Under the legal systems of civil law countries, incorporating a CP or
CPS by reference may not be effective to bind consumers to the terms
of an incorporated CP or CPS.
CPs and CPSs may be incorporated by reference in other documents,
including:
* Interoperability agreements (including agreements between CAs for
cross-certification, unilateral certification, or other forms of
interoperation),
* Vendor agreements (under which a PKI vendor agrees to meet
standards set forth in a CP or CPS), or
* A PDS. See [ABA2]
A PDS serves a similar function to a CPS Summary. It is a relatively
short document containing only a subset of critical details about a
PKI or CA. It may differ from a CPS Summary, however, in that its
purpose is to act as a summary of information about the overall
nature of the PKI, as opposed to simply a condensed form of the CPS.
Moreover, its purpose is to distill information about the PKI, as
opposed to protecting security sensitive information contained in an
unpublished CPS, although a PDS could also serve that function.
Just as writers may wish to refer to a CP or CPS or incorporate it by
reference in an agreement or PDS, a CP or CPS may refer to other
documents when establishing requirements or making disclosures. For
instance, a CP may set requirements for certificate content by
referring to an external document setting forth a standard
certificate profile. Referencing external documents permits a CP or
CPS to impose detailed requirements or make detailed disclosures
without having to reprint lengthy provisions from other documents
within the CP or CPS. Moreover, referencing a document in a CP or
CPS is another useful way of dividing disclosures between public
information and security sensitive confidential information (in
addition to or as an alternative to publishing a CPS Summary). For
example, a PKI may want to publish a CP or CPS, but maintain site
construction parameters for CA high security zones as confidential
information. In that case, the CP or CPS could reference an external
manual or document containing the detailed site construction
parameters.
Documents that a PKI may wish to refer to in a CP or CPS include:
* A security policy,
* Training, operational, installation, and user manuals (which may
contain operational requirements),
* Standards documents that apply to particular aspects of the PKI
(such as standards specifying the level of protection offered by
any hardware tokens used in the PKI or standards applicable to the
site construction),
* Key management plans,
* Human resource guides and employment manuals (which may describe
some aspects of personnel security practices), and
* E-mail policies (which may discuss subscriber and relying party
responsibilities, as well as the implications of key management,
if applicable). See [ABA2]
3.7. Set of Provisions
A set of provisions is a collection of practice and/or policy
statements, spanning a range of standard topics for use in expressing
a CP or CPS employing the approach described in this framework by
covering the topic appearing in Section 5 below. They are also
described in detail in Section 4 below.
A CP can be expressed as a single set of provisions.
A CPS can be expressed as a single set of provisions with each
component addressing the requirements of one or more certificate
policies, or, alternatively, as an organized collection of sets of
provisions. For example, a CPS could be expressed as a combination
of the following:
(a) a list of certificate policies supported by the CPS;
(b) for each CP in (a), a set of provisions that contains statements
responding to that CP by filling in details not stipulated in
that policy or expressly left to the discretion of the CA (in its
CPS) ; such statements serve to state how this particular CPS
implements the requirements of the particular CP; or
(c) a set of provisions that contains statements regarding the
certification practices on the CA, regardless of CP.
The statements provided in (b) and (c) may augment or refine the
stipulations of the applicable CP, but generally must not conflict
with any of the stipulations of such CP. In certain cases, however,
a policy authority may permit exceptions to the requirements in a CP,
because certain compensating controls of the CA are disclosed in its
CPS that allow the CA to provide assurances that are equivalent to
the assurances provided by CAs that are in full compliance with the
CP.
This framework outlines the contents of a set of provisions, in terms
of nine primary components, as follows:
1. Introduction
2. Publication and Repository
3. Identification and Authentication
4. Certificate Life-Cycle Operational Requirements
5. Facilities, Management, and Operational Controls
6. Technical Security Controls
7. Certificate, CRL, and OCSP Profile
8. Compliance audit
9. Other Business and Legal Matters
PKIs can use this simple framework of nine primary components to
write a simple CP or CPS. Moreover, a CA can use this same framework
to write a subscriber agreement, relying party agreement, or
agreement containing subscriber and relying party terms. If a CA
uses this simple framework to construct an agreement, it can use
paragraph 1 as an introduction or recitals, it can set forth the
responsibilities of the parties in paragraphs 2-8, and it can use
paragraph 9 to cover the business and legal issues described in more
detail, using the ordering of Section 4.9 below (such as
representations and warranties, disclaimers, and liability
limitations). The ordering of topics in this simple framework and
the business and legal matters Section 4.9 is the same as (or similar
to) the ordering of topics in a typical software or other technology
agreement. Therefore, a PKI can establish a set of core documents
(with a CP, CPS, subscriber agreement, and relying party agreement)
all having the same structure and ordering of topics, thereby
facilitating comparisons and mappings among these documents and among
the corresponding documents of other PKIs.
This simple framework may also be useful for agreements other than
subscriber agreements and relying party agreements. For instance, a
CA wishing to outsource certain services to an RA or certificate
manufacturing authority (CMA) may find it useful to use this
framework as a checklist to write a registration authority agreement
or outsourcing agreement. Similarly, two CAs may wish to use this
simple framework for the purpose of drafting a cross-certification,
unilateral certification, or other interoperability agreement.
In short, the primary components of the simple framework (specified
above) may meet the needs of drafters of short CPs, CPSs, subscriber
agreements, and relying party agreements. Nonetheless, this
framework is extensible, and its coverage of the nine components is
flexible enough to meet the needs of drafters of comprehensive CPs
and CPSs. Specifically, components appearing above can be further
divided into subcomponents, and a subcomponent may comprise multiple
elements. Section 4 provides a more detailed description of the
contents of the above components, and their subcomponents. Drafters
of CPs and CPSs are permitted to add additional levels of
subcomponents below the subcomponents described in Section 4 for the
purpose of meeting the needs of the drafter’s particular PKI.
4. Contents of a Set of Provisions
This section expands upon the contents of the simple framework of
provisions, as introduced in Section 3.7. The topics identified in
this section are, consequently, candidate topics for inclusion in a
detailed CP or CPS.
While many topics are identified, it is not necessary for a CP or a
CPS to include a concrete statement for every such topic. Rather, a
particular CP or CPS may state "no stipulation" for a component,
subcomponent, or element on which the particular CP or CPS imposes no
requirements or makes no disclosure. In this sense, the list of
topics can be considered a checklist of topics for consideration by
the CP or CPS writer.
It is recommended that each and every component and subcomponent be
included in a CP or CPS, even if there is "no stipulation"; this will
indicate to the reader that a conscious decision was made to include
or exclude a provision concerning that topic. This drafting style
protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions.
In a CP, it is possible to leave certain components, subcomponents,
and/or elements unspecified, and to stipulate that the required
information will be indicated in a policy qualifier, or the document
to which a policy qualifier points. Such CPs can be considered
parameterized definitions. The set of provisions should reference or
define the required policy qualifier types and should specify any
applicable default values.
4.1. Introductions
This component identifies and introduces the set of provisions, and
indicates the types of entities and applications for which the
document (either the CP or the CPS being written) is targeted.
4.1.1. Overview
This subcomponent provides a general introduction to the document
being written. This subcomponent can also be used to provide a
synopsis of the PKI to which the CP or CPS applies. For example, it
may set out different levels of assurance provided by certificates
within the PKI. Depending on the complexity and scope of the
particular PKI, a diagrammatic representation of the PKI might be
useful here.
4.1.2. Document Name and Identification
This subcomponent provides any applicable names or other identifiers,
including ASN.1 object identifiers, for the document. An example of
such a document name would be the US Federal Government Policy for
Secure E-mail.
4.1.3. PKI Participants
This subcomponent describes the identity or types of entities that
fill the roles of participants within a PKI, namely:
* Certification authorities, i.e., the entities that issue
certificates. A CA is the issuing CA with respect to the
certificates it issues and is the subject CA with respect to the
CA certificate issued to it. CAs may be organized in a hierarchy
in which an organization’s CA issues certificates to CAs operated
by subordinate organizations, such as a branch, division, or
department within a larger organization.
* Registration authorities, i.e., the entities that establish
enrollment procedures for end-user certificate applicants, perform
identification and authentication of certificate applicants,
initiate or pass along revocation requests for certificates, and
approve applications for renewal or re-keying certificates on
behalf of a CA. Subordinate organizations within a larger
organization can act as RAs for the CA serving the entire
organization, but RAs may also be external to the CA.
* Subscribers. Examples of subscribers who receive certificates
from a CA include employees of an organization with its own CA,
banking or brokerage customers, organizations hosting e-commerce
sites, organizations participating in a business-to-business
exchange, and members of the public receiving certificates from a
CA issuing certificates to the public at large.
* Relying parties. Examples of relying parties include employees of
an organization having its own CA who receive digitally signed e-
mails from other employees, persons buying goods and services from
e-commerce sites, organizations participating in a business-to-
business exchange who receive bids or orders from other
participating organizations, and individuals and organizations
doing business with subscribers who have received their
certificates from a CA issuing certificates to the public.
Relying parties may or may not also be subscribers within a given
PKI.
* Other participants, such as certificate manufacturing authorities,
providers of repository services, and other entities providing
PKI-related services.
4.1.4. Certificate Usage
This subcomponent contains:
* A list or the types of applications for which the issued
certificates are suitable, such as electronic mail, retail
transactions, contracts, and a travel order, and/or
* A list or the types of applications for which use of the issued
certificates is prohibited.
In the case of a CP or CPS describing different levels of assurance,
this subcomponent can describe applications or types of applications
that are appropriate or inappropriate for the different levels of
assurance.
4.1.5. Policy Administration
This subcomponent includes the name and mailing address of the
organization that is responsible for the drafting, registering,
maintaining, and updating of this CP or CPS. It also includes the
name, electronic mail address, telephone number, and fax number of a
contact person. As an alternative to naming an actual person, the
document may name a title or role, an e-mail alias, and other
generalized contact information. In some cases, the organization may
state that its contact person, alone or in combination with others,
is available to answer questions about the document.
Moreover, when a formal or informal policy authority is responsible
for determining whether a CA should be allowed to operate within or
interoperate with a PKI, it may wish to approve the CPS of the CA as
being suitable for the policy authority’s CP. If so, this
subcomponent can include the name or title, electronic mail address
(or alias), telephone number, fax number, and other generalized
information of the entity in charge of making such a determination.
Finally, in this case, this subcomponent also includes the procedures
by which this determination is made.
4.1.6. Definitions and Acronyms
This subcomponent contains a list of definitions for defined terms
used within the document, as well as a list of acronyms in the
document and their meanings.
4.2. Publication and Repository Responsibilities
This component contains any applicable provisions regarding:
* An identification of the entity or entities that operate
repositories within the PKI, such as a CA, certificate
manufacturing authority, or independent repository service
provider;
* The responsibility of a PKI participant to publish information
regarding its practices, certificates, and the current status of
such certificates, which may include the responsibilities of
making the CP or CPS publicly available using various mechanisms
and of identifying components, subcomponents, and elements of such
documents that exist but are not made publicly available, for
instance, security controls, clearance procedures, or trade secret
information due to their sensitivity;
* When information must be published and the frequency of
publication; and
* Access control on published information objects including CPs,
CPS, certificates, certificate status, and CRLs.
4.3. Identification and Authentication
This component describes the procedures used to authenticate the
identity and/or other attributes of an end-user certificate applicant
to a CA or RA prior to certificate issuance. In addition, the
component sets forth the procedures for authenticating the identity
and the criteria for accepting applicants of entities seeking to
become CAs, RAs, or other entities operating in or interoperating
with a PKI. It also describes how parties requesting re-key or
revocation are authenticated. This component also addresses naming
practices, including the recognition of trademark rights in certain
names.
4.3.1. Naming
This subcomponent includes the following elements regarding naming
and identification of the subscribers:
* Types of names assigned to the subject, such as X.500
distinguished names; RFC-822 names; and X.400 names;
* Whether names have to be meaningful or not;(3)
* Whether or not subscribers can be anonymous or pseudonymous, and
if they can, what names are assigned to or can be used by
anonymous subscribers;
* Rules for interpreting various name forms, such as the X.500
standard and RFC-822;
* Whether names have to be unique; and
* Recognition, authentication, and the role of trademarks.
4.3.2. Initial Identity Validation
This subcomponent contains the following elements for the
identification and authentication procedures for the initial
registration for each subject type (CA, RA, subscriber, or other
participant):
* If and how the subject must prove possession of the companion
private key for the public key being registered, for example, a
digital signature in the certificate request message;(4)
* Identification and authentication requirements for organizational
identity of subscriber or participant (CA; RA; subscriber (in the
case of certificates issued to organizations or devices controlled
by an organization), or other participant), for example,
consulting the database of a service that identifies organizations
or inspecting an organization’s articles of incorporation;
* Identification and authentication requirements for an individual
subscriber or a person acting on behalf of an organizational
subscriber or participant (CA, RA, in the case of certificates
issued to organizations or devices controlled by an organization,
the subscriber, or other participant),(5) including:
* Type of documentation and/or number of identification
credentials required;
* How a CA or RA authenticates the identity of the organization
or individual based on the documentation or credentials
provided;
* If the individual must personally present to the authenticating
CA or RA;
* How an individual as an organizational person is authenticated,
such as by reference to duly signed authorization documents or
a corporate identification badge.
* List of subscriber information that is not verified (called "non-
verified subscriber information") during the initial registration;
* Validation of authority involves a determination of whether a
person has specific rights, entitlements, or permissions,
including the permission to act on behalf of an organization to
obtain a certificate; and
* In the case of applications by a CA wishing to operate within, or
interoperate with, a PKI, this subcomponent contains the criteria
by which a PKI, CA, or policy authority determines whether or not
the CA is suitable for such operations or interoperation. Such
interoperation may include cross-certification, unilateral
certification, or other forms of interoperation.
4.3.3. Identification and Authentication for Re-key Requests
This subcomponent addresses the following elements for the
identification and authentication procedures for re-key for each
subject type (CA, RA, subscriber, and other participants):
* Identification and authentication requirements for routine re-key,
such as a re-key request that contains the new key and is signed
using the current valid key; and
* Identification and authentication requirements for re-key after
certificate revocation. One example is the use of the same
process as the initial identity validation.
4.3.4. Identification and Authentication for Revocation Requests
This subcomponent describes the identification and authentication
procedures for a revocation request by each subject type (CA, RA,
subscriber, and other participant). Examples include a revocation
request digitally signed with the private key whose companion public
key needs to be revoked, and a digitally signed request by the RA.
4.4. Certificate Life-Cycle Operational Requirements
This component is used to specify requirements imposed upon issuing
CA, subject CAs, RAs, subscribers, or other participants with respect
to the life-cycle of a certificate.
Within each subcomponent, separate consideration may need to be given
to subject CAs, RAs, subscribers, and other participants.
4.4.1. Certificate Application
This subcomponent is used to address the following requirements
regarding subject certificate application:
* Who can submit a certificate application, such as a certificate
subject or the RA; and
* Enrollment process used by subjects to submit certificate
applications and responsibilities in connection with this process.
An example of this process is where the subject generates the key
pair and sends a certificate request to the RA. The RA validates
and signs the request and sends it to the CA. A CA or RA may have
the responsibility of establishing an enrollment process in order
to receive certificate applications. Likewise, certificate
applicants may have the responsibility of providing accurate
information on their certificate applications.
4.4.2. Certificate Application Processing
This subcomponent is used to describe the procedure for processing
certificate applications. For example, the issuing CA and RA may
perform identification and authentication procedures to validate the
certificate application. Following such steps, the CA or RA will
either approve or reject the certificate application, perhaps upon
the application of certain criteria. Finally, this subcomponent sets
a time limit during which a CA and/or RA must act on and process a
certificate application.
4.4.3. Certificate Issuance
This subcomponent is used to describe the following certificate
issuance related elements:
* Actions performed by the CA during the issuance of the
certificate, for example a procedure whereby the CA validates the
RA signature and RA authority and generates a certificate; and
* Notification mechanisms, if any, used by the CA to notify the
subscriber of the issuance of the certificate; an example is a
procedure under which the CA e-mails the certificate to the
subscriber or the RA or e-mails information permitting the
subscriber to download the certificate from a web site.
4.4.4. Certificate Acceptance
This subcomponent addresses the following:
* The conduct of an applicant that will be deemed to constitute
acceptance of the certificate. Such conduct may include
affirmative steps to indicate acceptance, actions implying
acceptance, or a failure to object to the certificate or its
content. For instance, acceptance may be deemed to occur if the
CA does not receive any notice from the subscriber within a
certain time period; a subscriber may send a signed message
accepting the certificate; or a subscriber may send a signed
message rejecting the certificate where the message includes the
reason for rejection and identifies the fields in the certificate
that are incorrect or incomplete.
* Publication of the certificate by the CA. For example, the CA may