certificates. RAs, however, do not sign or issue certificates (i.e.,
an RA is delegated certain tasks on behalf of a CA). [Note: The term
Local Registration Authority (LRA) is sometimes used in other
documents for the same concept.]
Relying party - A recipient of a certificate who acts in reliance on
that certificate and/or any digital signatures verified using that
certificate. In this document, the terms "certificate user" and
"relying party" are used interchangeably.
Relying party agreement (RPA) - An agreement between a certification
authority and relying party that typically establishes the rights and
responsibilities between those parties regarding the verification of
digital signatures or other uses of certificates.
Set of provisions - 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.
Subject certification authority (subject CA) - In the context of a
particular CA-certificate, the subject CA is the CA whose public key
is certified in the certificate (see also Issuing certification
authority).
Subscriber - A subject of a certificate who is issued a certificate.
Subscriber Agreement - An agreement between a CA and a subscriber
that establishes the right and responsibilities of the parties
regarding the issuance and management of certificates.
Validation - The process of identification of certificate applicants.
"Validation" is a subset of "identification" and refers to
identification in the context of establishing the identity of
certificate applicants.
3. Concepts
This section explains the concepts of CP and CPS, and describes their
relationship with other PKI documents, such as subscriber agreements
and relying party agreements. Other related concepts are also
described. Some of the material covered in this section and in some
other sections is specific to certificate policies extensions as
defined X.509 version 3. Except for those sections, this framework
is intended to be adaptable to other certificate formats that may
come into use.
3.1. Certificate Policy
When a certification authority issues a certificate, it is providing
a statement to a certificate user (i.e., a relying party) that a
particular public key is bound to the identity and/or other
attributes of a particular entity (the certificate subject, which is
usually also the subscriber). The extent to which the relying party
should rely on that statement by the CA, however, needs to be
assessed by the relying party or entity controlling or coordinating
the way relying parties or relying party applications use
certificates. Different certificates are issued following different
practices and procedures, and may be suitable for different
applications and/or purposes.
The X.509 standard defines a CP as "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" [ISO1]. An X.509 Version 3 certificate may identify a
specific applicable CP, which may be used by a relying party to
decide whether or not to trust a certificate, associated public key,
or any digital signatures verified using the public key for a
particular purpose.
CPs typically fall into two major categories. First, some CPs
"indicate the applicability of a certificate to a particular
community" [ISO1]. These CPs set forth requirements for certificate
usage and requirements on members of a community. For instance, a CP
may focus on the needs of a geographical community, such as the ETSI
policy requirements for CAs issuing qualified certificates [ETS].
Also, a CP of this kind may focus on the needs of a specific
vertical-market community, such as financial services [IDT].
The second category of typical CPs "indicate the applicability of a
certificate to a . . . class of application with common security
requirements." These CPs identify a set of applications or uses for
certificates and say that these applications or uses require a
certain level of security. They then set forth PKI requirements that
are appropriate for these applications or uses. A CP within this
category often makes sets requirements appropriate for a certain
"level of assurance" provided by certificates, relative to
certificates issued pursuant to related CPs. These levels of
assurance may correspond to "classes" or "types" of certificates.
For instance, the Government of Canada PKI Policy Management
Authority (GOC PMA) has established eight certificate policies in a
single document [GOC], four policies for certificates used for
digital signatures and four policies for certificates used for
confidentiality encryption. For each of these applications, the
document establishes four levels of assurances: rudimentary, basic,
medium, and high. The GOC PMA described certain types of digital
signature and confidentiality uses in the document, each with a
certain set of security requirements, and grouped them into eight
categories. The GOC PMA then established PKI requirements for each
of these categories, thereby creating eight types of certificates,
each providing rudimentary, basic, medium, or high levels of
assurance. The progression from rudimentary to high levels
corresponds to increasing security requirements and corresponding
increasing levels of assurance.
A CP is represented in a certificate by a unique number called an
"Object Identifier" (OID). That OID, or at least an "arc", can be
registered. An "arc" is the beginning of the numerical sequence of
an OID and is assigned to a particular organization. The
registration process follows the procedures specified in ISO/IEC and
ITU standards. The party that registers the OID or arc also can
publish the text of the CP, for examination by relying parties. Any
one certificate will typically declare a single CP or, possibly, be
issued consistent with a small number of different policies. Such
declaration appears in the Certificate Policies extension of a X.509
Version 3 certificate. When a CA places multiple CPs within a
certificate’s Certificate Policies extension, the CA is asserting
that the certificate is appropriate for use in accordance with any of
the listed CPs.
CPs also constitute a basis for an audit, accreditation, or another
assessment of a CA. Each CA can be assessed against one or more
certificate policies or CPSs that it is recognized as implementing.
When one CA issues a CA-certificate for another CA, the issuing CA
must assess the set of certificate policies for which it trusts the
subject CA (such assessment may be based upon an assessment with
respect to the certificate policies involved). The assessed set of
certificate policies is then indicated by the issuing CA in the CA-
certificate. The X.509 certification path processing logic employs
these CP indications in its well-defined trust model.
3.2. Certificate Policy Examples
For example purposes, suppose that the International Air Transport
Association (IATA) undertakes to define some certificate policies for
use throughout the airline industry, in a PKI operated by IATA in
combination with PKIs operated by individual airlines. Two CPs might
be defined - the IATA General-Purpose CP, and the IATA Commercial-
Grade CP.
The IATA General-Purpose CP could be used by industry personnel for
protecting routine information (e.g., casual electronic mail) and for
authenticating connections from World Wide Web browsers to servers
for general information retrieval purposes. The key pairs may be
generated, stored, and managed using low-cost, software-based
systems, such as commercial browsers. Under this policy, a
certificate may be automatically issued to anybody listed as an
employee in the corporate directory of IATA or any member airline who
submits a signed certificate request form to a network administrator
in his or her organization.
The IATA Commercial-Grade CP could be used to protect financial
transactions or binding contractual exchanges between airlines.
Under this policy, IATA could require that certified key pairs be
generated and stored in approved cryptographic hardware tokens.
Certificates and tokens could be provided to airline employees with
disbursement authority. These authorized individuals might then be
required to present themselves to the corporate security office, show
a valid identification badge, and sign a subscriber agreement
requiring them to protect the token and use it only for authorized
purposes, as a condition of being issued a token and a certificate.
3.3. X.509 Certificate Fields
The following extension fields in an X.509 certificate are used to
support CPs:
* Certificate Policies extension;
* Policy Mappings extension; and
* Policy Constraints extension.
3.3.1. Certificate Policies Extension
A Certificate Policies field lists CPs that the certification
authority declares are applicable. Using the example of the IATA
General-Purpose and Commercial-Grade policies defined in Section 3.2,
the certificates issued to regular airline employees would contain
the object identifier for General-Purpose policy. The certificates
issued to the employees with disbursement authority would contain the
object identifiers for both the General-Purpose policy and the
Commercial-Grade policy. The inclusion of both object identifiers in
the certificates means that they would be appropriate for either the
General-Purpose or Commercial-Grade policies. The Certificate
Policies field may also optionally convey qualifier values for each
identified policy; the use of qualifiers is discussed in Section 3.4.
When processing a certification path, a CP that is acceptable to the
relying party application must be present in every certificate in the
path, i.e., in CA-certificates as well as end entity certificates.
If the Certificate Policies field is flagged critical, it serves the
same purpose as described above but also has an additional role.
Specifically, it indicates that the use of the certificate is
restricted to one of the identified policies, i.e., the certification
authority is declaring that the certificate must only be used in
accordance with the provisions of at least one of the listed CPs.
This field is intended to protect the certification authority against
claims for damages asserted by a relying party who has used the
certificate for an inappropriate purpose or in an inappropriate
manner, as stipulated in the applicable CP.
For example, the Internal Revenue Service might issue certificates to
taxpayers for the purpose of protecting tax filings. The Internal
Revenue Service understands and can accommodate the risks of
erroneously issuing a bad certificate, e.g., to an imposter.
Suppose, however, that someone used an Internal Revenue Service tax-
filing certificate as the basis for encrypting multi-million-dollar-
value proprietary trade secrets, which subsequently fell into the
wrong hands because of a cryptanalytic attack by an attacker who is
able to decrypt the message. The Internal Revenue Service may want
to defend itself against claims for damages in such circumstances by
pointing to the criticality of the Certificate Policies extension to
show that the subscriber and relying party misused the certificate.
The critical-flagged Certificate Policies extension is intended to
mitigate the risk to the CA in such situations.
3.3.2. Policy Mappings Extension
The Policy Mappings extension may only be used in CA-certificates.
This field allows a certification authority to indicate that certain
policies in its own domain can be considered equivalent to certain
other policies in the subject certification authority’s domain.
For example, suppose that for purposes of facilitating
interoperability, the ACE Corporation establishes an agreement with
the ABC Corporation to cross-certify the public keys of each others’
certification authorities for the purposes of mutually securing their
respective business-to-business exchanges. Further, suppose that
both companies have pre-existing financial transaction protection
policies called ace-e-commerce and abc-e-commerce, respectively. One
can see that simply generating cross-certificates between the two
domains will not provide the necessary interoperability, as the two
companies’ applications are configured with, and employee
certificates are populated with, their respective certificate
policies. One possible solution is to reconfigure all of the
financial applications to require either policy and to reissue all
the certificates with both policies appearing in their Certificate
Policies extensions. Another solution, which may be easier to
administer, uses the Policy Mapping field. If this field is included
in a cross-certificate for the ABC Corporation certification
authority issued by the ACE Corporation certification authority, it
can provide a statement that the ABC’s financial transaction
protection policy (i.e., abc-e-commerce) can be considered equivalent
to that of the ACE Corporation (i.e., ace-e-commerce). With such a
statement included in the cross-certificate issued to ABC, relying
party applications in the ACE domain requiring the presence of the
object identifier for the ace-e-commerce CP can also accept, process,
and rely upon certificates issued within the ABC domain containing
the object identifier for the abc-e-commerce CP.
3.3.3. Policy Constraints Extension
The Policy Constraints extension supports two optional features. The
first is the ability for a certification authority to require that
explicit CP indications be present in all subsequent certificates in
a certification path. Certificates at the start of a certification
path may be considered by a relying party to be part of a trusted
domain, i.e., certification authorities are trusted for all purposes
so no particular CP is needed in the Certificate Policies extension.
Such certificates need not contain explicit indications of CP. When
a certification authority in the trusted domain, however, certifies
outside the domain, it can activate the requirement that a specific
CP’s object identifier appear in subsequent certificates in the
certification path.
The other optional feature in the Policy Constraints field is the
ability for a certification authority to disable policy mapping by
subsequent certification authorities in a certification path. It may
be prudent to disable policy mapping when certifying outside the
domain. This can assist in controlling risks due to transitive
trust, e.g., a domain A trusts domain B, domain B trusts domain C,
but domain A does not want to be forced to trust domain C.
3.3.4. Policy Qualifiers
The Certificate Policies extension field has a provision for
conveying, along with each CP identifier, additional policy-dependent
information in a qualifier field. The X.509 standard does not
mandate the purpose for which this field is to be used, nor does it
prescribe the syntax for this field. Policy qualifier types can be
registered by any organization.
The following policy qualifier types are defined in PKIX RFC 3280
[PKI1]:
(a) The CPS Pointer qualifier contains a pointer to a CPS, CPS
Summary, RPA, or PDS published by the CA. The pointer is in the
form of a uniform resource identifier (URI).
(b) The User Notice qualifier contains a text string that is to be
displayed to subscribers and relying parties prior to the use of
the certificate. The text string may be an IA5String or a
BMPString - a subset of the ISO 100646-1 multiple octet coded
character set. A CA may invoke a procedure that requires that
the relying party acknowledge that the applicable terms and
conditions have been disclosed and/or accepted.
Policy qualifiers can be used to support the definition of generic,
or parameterized, CPs. Provided the base CP so provides, policy
qualifier types can be defined to convey, on a per-certificate basis,
additional specific policy details that fill in the generic
definition.
3.4. Certification Practice Statement
The term certification practice statement (CPS) is defined by the DSG
and PAG as: "A statement of the practices which a certification
authority employs in issuing certificates." [ABA1, ABA2] As stated
above, a CPS establishes practices concerning lifecycle services in
addition to issuance, such as certificate management (including
publication and archiving), revocation, and renewal or re-keying. In
the DSG, the ABA expands this definition with the following comments:
"A certification practice statement may take the form of a
declaration by the certification authority of the details of its
trustworthy system and the practices it employs in its operations and
in support of issuance of a certificate . . . ." This form of CPS is
the most common type, and can vary in length and level of detail.
Some PKIs may not have the need to create a thorough and detailed
statement of practices. For example, the CA may itself be the
relying party and would already be aware of the nature and
trustworthiness of its services. In other cases, a PKI may provide
certificates providing only a very low level of assurances where the
applications being secured may pose only marginal risks if
compromised. In these cases, an organization establishing a PKI may
only want to write or have CAs use a subscriber agreement, relying
party agreement, or agreement combining subscriber and relying party
terms, depending on the role of the different PKI participants. In
such a PKI, that agreement may serve as the only "statement of
practices" used by one or more CAs within that PKI. Consequently,
that agreement may also be considered a CPS and can be entitled or
subtitled as such.
Likewise, since a detailed CPS may contain sensitive details of its
system, a CA may elect not to publish its entire CPS. It may instead
opt to publish a CPS Summary (or CPS Abstract). The CPS Summary
would contain only those provisions from the CPS that the CA
considers to be relevant to the participants in the PKI (such as the
responsibilities of the parties or the stages of the certificate
lifecycle). A CPS Summary, however, would not contain those
sensitive provisions of the full CPS that might provide an attacker
with useful information about the CA’s operations. Throughout this
document, the use of "CPS" includes both a detailed CPS and a CPS
Summary (unless otherwise specified).
CPSs do not automatically constitute contracts and do not
automatically bind PKI participants as a contract would. Where a
document serves the dual purpose of being a subscriber or relying
party agreement and CPS, the document is intended to be a contract
and constitutes a binding contract to the extent that a subscriber or
relying party agreement would ordinarily be considered as such. Most
CPSs, however, do not serve such a dual purpose. Therefore, in most
cases, a CPS’s terms have a binding effect as contract terms only if
a separate document creates a contractual relationship between the
parties and that document incorporates part or all of the CPS by
reference. Further, if a particular PKI employs a CPS Summary (as
opposed to the entire CPS), the CPS Summary could be incorporated
into any applicable subscriber or relying party agreement.
In the future, a court or applicable statutory or regulatory law may
declare that a certificate itself is a document that is capable of
creating a contractual relationship, to the extent its mechanisms
designed for incorporation by reference (such as the Certificate
Policies extension and its qualifiers) indicate that terms of its use
appear in certain documents. In the meantime, however, some
subscriber agreements and relying party agreements may incorporate a
CPS by reference and therefore make its terms binding on the parties
to such agreements.
3.5. Relationship Between Certificate Policy and Certification
Practice Statement
The CP and CPS address the same set of topics that are of interest to
the relying party in terms of the degree to and purpose for which a
public key certificate should be trusted. Their primary difference
is in the focus of their provisions. A CP sets forth the
requirements and standards imposed by the PKI with respect to the
various topics. In other words, the purpose of the CP is to
establish what participants must do. A CPS, by contrast, states how
a CA and other participants in a given domain implement procedures
and controls to meet the requirements stated in the CP. In other
words, the purpose of the CPS is to disclose how the participants
perform their functions and implement controls.
An additional difference between a CP and CPS relates the scope of
coverage of the two kinds of documents. Since a CP is a statement of
requirements, it best serves as the vehicle for communicating minimum
operating guidelines that must be met by interoperating PKIs. Thus,
a CP generally applies to multiple CAs, multiple organizations, or
multiple domains. By contrast, a CPS applies only to a single CA or
single organization and is not generally a vehicle to facilitate
interoperation.
A CA with a single CPS may support multiple CPs (used for different
application purposes and/or by different relying party communities).
Also, multiple CAs, with non-identical CPSs, may support the same CP.
For example, the Federal Government might define a government-wide CP
for handling confidential human resources information. The CP will
be a broad statement of the general requirements for participants
within the Government’s PKI, and an indication of the types of
applications for which it is suitable for use. Each department or
agency wishing to operate a certification authority in this PKI may
be required to write its own certification practice statement to
support this CP by explaining how it meets the requirements of the
CP. At the same time, a department’s or agency’s CPS may support
other certificate policies.
An additional difference between a CP and CPS concerns the level of
detail of the provisions in each. Although the level of detail may
vary among CPSs, a CPS will generally be more detailed than a CP. A
CPS provides a detailed description of procedures and controls in
place to meet the CP requirements, while a CP is more general.
The main differences between CPs and CPSs can therefore be summarized
as follows:
(a) A PKI uses a CP to establish requirements that state what
participants within it must do. A single CA or organization can
use a CPS to disclose how it meets the requirements of a CP or
how it implements its practices and controls.
(b) A CP facilitates interoperation through cross-certification,
unilateral certification, or other means. Therefore, it is
intended to cover multiple CAs. By contrast, a CPS is a
statement of a single CA or organization. Its purpose is not to
facilitate interoperation (since doing so is the function of a
CP).
(c) A CPS is generally more detailed than a CP and specifies how the
CA meets the requirements specified in the one or more CPs under
which it issues certificates.
In addition to populating the certificate policies extension with the
applicable CP object identifier, a certification authority may
include, in certificates it issues, a reference to its certification
practice statement. A standard way to do this, using a CP qualifier,
is described in Section 3.4.
3.6. Relationship Among CPs, CPSs, Agreements, and Other Documents
CPs and CPSs play a central role in documenting the requirements and
practices of a PKI. Nonetheless, they are not the only documents
relevant to a PKI. For instance, subscriber agreements and relying
party agreements play a critical role in allocating responsibilities
to subscribers and relying parties relating to the use of
certificates and key pairs. They establish the terms and conditions
under which certificates are issued, managed, and used. The term
subscriber agreement is defined by the PAG as: "An agreement between
a CA and a subscriber that establishes the right and obligations of
the parties regarding the issuance and management of certificates."
[ABA2] The PAG defines a relying party agreement as: "An agreement
between a certification authority and relying party that typically
establishes the rights and obligations between those parties
regarding the verification of digital signatures or other uses of
certificates." [ABA2]
As mentioned in Section 3.5, a subscriber agreement, relying party