PKIX Working Group S. Chokhani (CygnaCom Solutions, Inc.)
Internet Draft W. Ford (VeriSign, Inc.)
Expires in six months from March 25, 1997
Internet Public Key Infrastructure
Part IV: Certificate Policy and Certification Practices Framework
<draft-ietf-pkix-ipki-part4-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of 6 months
and may be updated, replaced, or may become obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as work in progress.
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document presents a framework to assist the writers of
certificate policies or certification practice statements for
certification authorities and public key infrastructures. 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 definition or a certification practice statement.
It is intended that this document, when fully developed, be published
as an Informational RFC.
1. INTRODUCTION
1.1 BACKGROUND
A public-key certificate (hereinafter "certificate") binds a
public-key value to a set of information that identifies the
entity (such as person, organization, account, or site) associated
with use of the corresponding private key (this entity is known as
Chokhani/Ford [Page 1]
Internet Draft PKIX Part IV March 1997
the "subject" of the certificate). A certificate is used by a
"certificate user" or "relying party" that needs to use, and rely
upon the accuracy of, the public key distributed via that
certificate (a certificate user is typically an entity that is
verifying a digital signature from the certificate's subject or an
entity sending encrypted data to the subject). The degree to
which a certificate user can trust the binding embodied in a
certificate depends on several factors. These factors include the
practices followed by the certification authority (CA) in
authenticating the subject; the CA's operating policy, procedures,
and security controls; the subject's obligations (for example, in
protecting the private key); and the stated undertakings and legal
obligations of the CA (for example, warranties and limitations on
liability).
A Version 3 X.509 certificate may contain a field declaring that
one or more specific certificate policies applies to that
certificate [ISO1]. According to X.509, a certificate policy is
"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." A certificate policy may be
used by a certificate user to help in deciding whether a
certificate, and the binding therein, is sufficiently trustworthy
for a particular application. The certificate policy concept is
an outgrowth of the policy statement concept developed for
Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1].
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 Digital
Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a
statement of the practices which a certification authority employs
in issuing certificates." [ABA1]
1.2 PURPOSE
The purpose of this document is to establish a clear relationship
between certificate policies and CPSs, and to present a framework
to assist the writers of certificate policies or CPSs with their
tasks. In particular, the framework identifies the elements that
may need to be considered in formulating a certificate policy or a
CPS. The purpose is not to define particular certificate policies
or CPSs, per se.
Chokhani/Ford [Page 2]
Internet Draft PKIX Part IV March 1997
1.3 SCOPE
The scope of this document is limited to discussion of the
contents of a certificate policy (as defined in X.509) or CPS (as
defined in the ABA Guidelines). In particular, this document
describes the types of information that should be considered for
inclusion in a certificate policy definition or a CPS. While the
framework as presented generally assumes use of the X.509 version
3 certificate format, it is not intended that the material be
restricted to use of that certificate format. Rather, it is
intended that this framework be adaptable to other certificate
formats 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) beyond the policy elements that are
considered of particular relevance to certificate policies or
CPSs.
This document does not define a specific certificate policy or
CPS.
It is assumed that the reader is familiar with the general
concepts of digital signatures, certificates, and public-key
infrastructure, as used in X.509 and the ABA Guidelines.
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 or a passphrase).
CA-certificate - A certificate for one CA's public key issued by
another CA.
Certificate policy - 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 certificate policy might indicate
applicability of a type of certificate to the authentication of
electronic data interchange transactions for the trading of goods
within a given price range.
Certification path - An ordered sequence of certificates which,
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.
Chokhani/Ford [Page 3]
Internet Draft PKIX Part IV March 1997
Certification Practice Statement (CPS) - A statement of the
practices which a certification authority employs in issuing
certificates.
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).
Policy qualifier - Policy-dependent information that accompanies a
certificate policy identifier in an X.509 certificate.
Practices and policy specification - A list of practice and/or
policy statements, spanning a range of standard topics, for use in
expressing a certificate policy definition or CPS employing the
approach described in this framework.
Registration authority (RA) - An entity that is responsible for
identification and authentication of certificate subjects, but
that does not sign or issue certificates (i.e., an RA is delegated
certain tasks on behalf of a CA).
Relying party - A recipient of a certificate who acts in reliance
on that certificate and/or digital signatures verified using that
certificate. In this document, the terms "certificate user" and
"relying party" are used interchangeably.
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).
3. CONCEPTS
This section explains the concepts of certificate policy and CPS, and
describes their relationship. Other related concepts are also
described.
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 a particular
entity (the certificate subject). However, the extent to which
the certificate user should rely on that statement by the CA needs
to be assessed by the certificate user. Different certificates
are issued following different practices and procedures, and may
be suitable for different applications and/or purposes.
Chokhani/Ford [Page 4]
Internet Draft PKIX Part IV March 1997
The X.509 standard defines a certificate policy 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
contain an indication of certificate policy, which may be used by
a certificate user to decide whether or not to trust a certificate
for a particular purpose.
A certificate policy, which needs to be recognized by both the
issuer and user of a certificate, is represented in a certificate
by a unique, registered Object Identifier. The registration
process follows the procedures specified in ISO/IEC and ITU
standards. The party that registers the Object Identifier also
publishes a textual specification of the certificate policy, for
examination by certificate users. Any one certificate will
typically declare a single certificate policy or, possibly, be
issued consistent with a small number of different policies.
Certificate policies also constitute a basis for accreditation of
CAs. Each CA is accredited against one or more certificate
policies which 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 accreditation 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 certificate policy indications in its well-defined
trust model.
3.2 CERTIFICATE POLICY EXAMPLES
For example purposes, suppose that IATA undertakes to define some
certificate policies for use throughout the airline industry, in a
public-key infrastructure operated by IATA in combination with
public-key infrastructures operated by individual airlines. Two
certificate policies are defined - the IATA General-Purpose
policy, and the IATA Commercial-Grade policy.
The IATA General-Purpose policy is intended for use 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
Chokhani/Ford [Page 5]
Internet Draft PKIX Part IV March 1997
request form to a network administrator in his or her
organization.
The IATA Commercial-Grade policy is used to protect financial
transactions or binding contractual exchanges between airlines.
Under this policy, IATA requires that certified key pairs be
generated and stored in approved cryptographic hardware tokens.
Certificates and tokens are provided to airline employees with
disbursement authority. These authorized individuals are required
to present themselves to the corporate security office, show a
valid identification badge, and sign an undertaking to protect the
token and use it only for authorized purposes, before a token and
a certificate are issued.
3.3 X.509 CERTIFICATE FIELDS
The following extension fields in an X.509 certificate are used to
support certificate policies:
* Certificate Policies extension;
* Policy Mappings extension; and
* Policy Constraints extension.
3.3.1 Certificate Policies Extension
The Certificate Policies extension has two variants - one with
the field flagged non-critical and one with the field flagged
critical. The purpose of the field is different in the two
cases.
A non-critical Certificate Policies field lists certificate
policies that the certification authority declares are
applicable. However, use of the certificate is not restricted
to the purposes indicated by the applicable policies. Using
the example of the IATA General-Purpose and Commercial-Grade
policies defined in Section 3.2, the certificates issued to
regular airline employees will contain the object identifier
for certificate policy for the General-Purpose policy. The
certificates issued to the employees with disbursement
authority will contain the object identifiers for both the
General-Purpose policy and the Commercial-Grade policy. The
Certificate Policies field may also optionally convey qualifier
values for each identified policy; use of qualifiers is
discussed in Section 3.4.
The non-critical Certificate Policies field is designed to be
used by applications as follows. Each application is pre-
configured to know what policy it requires. Using the example
Chokhani/Ford [Page 6]
Internet Draft PKIX Part IV March 1997
in Section 3.2, electronic mail applications and Web servers
will be configured to require the General-Purpose policy.
However, an airline's financial applications will be configured
to require the Commercial-Grade policy for validating financial
transactions over a certain dollar value.
When processing a certification path, a certificate policy that
is acceptable to the certificate-using 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. 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 one of the
listed certificate policies. This field is intended to protect
the certification authority against damage claims by a relying
party who has used the certificate for an inappropriate purpose
or in an inappropriate manner, as stipulated in the applicable
certificate policy definition.
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 accidentally issuing a bad
certificate, e.g., to a wrongly-authenticated person. However,
suppose someone used an Internal Revenue Service tax-filing
certificate as the basis for encrypting multi-million-dollar-
value proprietary secrets which subsequently fell into the
wrong hands because of an error in issuing the Internal Revenue
Service certificate. The Internal Revenue Service may want to
protect itself against claims for damages in such
circumstances. The critical-flagged Certificate Policies
extension is intended to mitigate the risk to the certificate
issuer 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 the ACE Corporation establishes an
agreement with the ABC Corporation to cross-certify each
Chokhani/Ford [Page 7]
Internet Draft PKIX Part IV March 1997
others' public-key infrastructures for the purposes of mutually
protecting electronic data interchange (EDI). 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. 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).
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 certificate policy
indications be present in all subsequent certificates in a
certification path. Certificates at the start of a
certification path may be considered by a certificate user to
be part of a trusted domain, i.e., certification authorities
are trusted for all purposes so no particular certificate
policy is needed in the Certificate Policies extension. Such
certificates need not contain explicit indications of
certificate policy. However, when a certification authority in
the trusted domain certifies outside the domain, it can
activate the requirement for explicit certificate policy 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.
Chokhani/Ford [Page 8]
Internet Draft PKIX Part IV March 1997
3.4 POLICY QUALIFIERS
The Certificate Policies extension field has a provision for
conveying, along with each certificate policy 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 Part I
[PKI1]:
(a) The CPS Pointer qualifier contains a pointer to a
Certification Practice Statement (CPS) 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 a certificate user (including 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 certficate user acknowledge
that the applicable terms and conditions have been disclosed or
accepted.
3.5 CERTIFICATION PRACTICE STATEMENT
The term certification practice statement (CPS) is defined by the
ABA Guidelines as: "A statement of the practices which a
certification authority employs in issuing certificates." [ABA1]
In the 1995 draft of the ABA guidelines, 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, or it
may be a statute or regulation applicable to the certification
authority and covering similar subject matter. It may also be
part of the contract between the certification authority and
the subscriber. A certification practice statement may also be
comprised of multiple documents, a combination of public law,
private contract, and/or declaration.
Certain forms for legally implementing certification practice
statements lend themselves to particular relationships. For
example, when the legal relationship between a certification
Chokhani/Ford [Page 9]
Internet Draft PKIX Part IV March 1997
authority and subscriber is consensual, a contract would
ordinarily be the means of giving effect to a certification
practice statement. The certification authority's duties to a
relying person are generally based on the certification
authority's representations, which may include a certification
practice statement.
Whether a certification practice statement is binding on a
relying person depends on whether the relying person has
knowledge or notice of the certification practice statement. A
relying person has knowledge or at least notice of the contents
of the certificate used by the relying person to verify a
digital signature, including documents incorporated into the
certificate by reference. It is therefore advisable to
incorporate a certification practice statement into a
certificate by reference.
As much as possible, a certification practice statement should
indicate any of the widely recognized standards to which the
certification authority's practices conform. Reference to
widely recognized standards may indicate concisely the
suitability of the certification authority's practices for
another person's purposes, as well as the potential
technological compatibility of the certificates issued by the
certification authority with repositories and other systems.
3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION
PRACTICE STATEMENT
The concepts of certificate policy and CPS come from different
sources and were developed for different reasons. However, their
interrelationship is important.
A certification practice statement is a detailed statement by a
certification authority as to its practices, that potentially
needs to be understood and consulted by subscribers and
certificate users (relying parties). Although the level of detail
may vary among CPSs, they will generally be more detailed than
certificate policy definitions. Indeed, CPSs may be quite
comprehensive, robust documents providing a description of the
precise service offerings, detailed procedures of the life-cycle
management of certificates, and more - a level of detail which
weds the CPS to a particular (proprietary) implementation of a
service offering.
Although such detail may be indispensable to adequately disclose,
and to make a full assessment of trustworthiness in the absence of
accreditation or other recognized quality metrics, a detailed CPS
Chokhani/Ford [Page 10]
Internet Draft PKIX Part IV March 1997
does not form a suitable basis for interoperability between CAs
operated by different organizations. Rather, certificate policies
best serve as the vehicle on which to base common interoperability
standards and common assurance criteria on an industry-wide (or
possibly more global) basis. A CA with a single CPS may support
multiple certificate policies (used for different application
purposes and/or by different certificate user communities). Also,
multiple different CAs, with non-identical certification practice
statements, may support the same certificate policy.
For example, the Federal Government might define a government-wide
certificate policy for handling confidential human resources
information. The certificate policy definition will be a broad
statement of the general characteristics of that certificate
policy, and an indication of the types of applications for which
it is suitable for use. Different departments or agencies that
operate certification authorities with different certification
practice statements might support this certificate policy. At the
same time, such certification authorities may support other
certificate policies.
The main difference between certificate policy and CPS can
therefore be summarized as follows:
(a) Most organizations that operate public or inter-
organizational certification authorities will document their
own practices in CPSs or similar statements. The CPS is one of
the organization's means of protecting itself and positioning
its business relationships with subscribers and other entities.
(b) There is strong incentive, on the other hand, for a
certificate policy to apply more broadly than to just a single
organization. If a particular certificate policy is widely
recognized and imitated, it has great potential as the basis of
automated certificate acceptance in many systems, including
unmanned systems and systems that are manned by people not
independently empowered to determine the acceptability of
different presented certificates.
In addition to populating the certificate policies field with the
certificate policy 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 certificate policy qualifier, is described in Section 3.4.
Chokhani/Ford [Page 11]
Internet Draft PKIX Part IV March 1997
3.7 PRACTICES AND POLICY SPECIFICATION
A practices and policy specification is a list of practice and/or
policy statements, spanning a range of standard topics, for use in
expressing a certificate policy definition or CPS employing the
approach described in this framework.
A certificate policy can be expressed as a single practices and
policy specification.
A CPS can be expressed as a combination of the following:
(a) a list of certificate policies supported by the CPS;
(b) for each certificate policy in (a), a practices and policy
specification which contains statements that refine that
certificate policy by filling in details not stipulated in that
policy or expressly left to the discretion of the CPS by that
certificate policy; such statements serve to state how this
particular CPS implements the requirements of the particular
certificate policy;
(c) a practices and policy specification that contains
statements regarding the certification practices on the CA,
regardless of certificate policy.
The statements provided in (b) and (c) may augment or refine the
stipulations of the applicable certificate policy definition, but
must not conflict with any of the stipulations of such certificate
policy definition.
This framework outlines the contents of a practices and policy
specification, in terms of nine primary components, as follows:
* Community and Applicability;
* Identification and Authentication;
* Key Management;
* Non-Technical Security Controls;
* Technical Security Controls;
* Operational Requirements;
* General Provisions;
Chokhani/Ford [Page 12]
Internet Draft PKIX Part IV March 1997
* Certificate and CRL Profile; and
* Specification Administration.
Components 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.
4. PRACTICES AND POLICY SPECIFICATION TOPICS
This section expands upon the contents of a practices and policy
specification, as introduced in Section 3.7. The topics identified
in this section are, consequently, candidate topics for inclusion in
a certificate policy definition or CPS.
While many topics are identified, it is not necessary for a
certificate policy or a CPS to include a concrete statement for every
such topic. Rather, a particular certificate policy or CPS may
state "no stipulation" for a component, subcomponent, or element on
which the particular certificate policy or CPS imposes no
requirements. In this sense, the list of topics can be considered a
checklist of topics for consideration by the certificate policy or
CPS writer. It is recommended that each and every component and
subcomponent be included in a certificate policy or CPS, even if
there is "no stipulation"; this will indicate to the reader that a
conscious decision was made to include or exclude that topic. This
protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions.
4.1 COMMUNITY AND APPLICABILITY
This component describes the various types of entities for which
the practices and policy specification is targeted, and the
envisaged or target applications. This component has the
following subcomponents:
* Certification Authorities; (2)
* Registration Authorities;
* End Entities; (3) and
* Applicability.
Chokhani/Ford [Page 13]
Internet Draft PKIX Part IV March 1997
4.1.1 Certification Authorities
This subcomponent describes the types of entities that issue
certificates or that are certified as subject CAs. (4)
4.1.2 Registration Authorities
This subcomponent describes the types of entities that perform
RA functions. (5)
4.1.3 End Entities
This subcomponent describes the types of entities that are
certified as subject end entities or subscribers. (6)
4.1.4 Applicability
This subcomponent contains:
* A list of applications for which the issued certificates
are suitable.
* A list of applications for which use of the issued
certificates is restricted. (This list implicitly prohibits
all other uses for the certificates.)
* A list of applications for which use of the issued
certificates is prohibited.
4.2 IDENTIFICATION AND AUTHENTICATION
This component describes the procedures used to authenticate a
certificate applicant to a CA or RA prior to certificate issuance.
It also describes how parties requesting rekey or revocation are
authenticated. This component also addresses naming practices,
including name ownership recognition and name dispute resolution.
This component has the following subcomponents:
* Initial Registration;
* Routine Rekey;
* Rekey After Revocation; and
* Revocation Request.
Chokhani/Ford [Page 14]
Internet Draft PKIX Part IV March 1997
4.2.1 Initial Registration
This subcomponent includes the following elements regarding
identification and authentication procedures during entity
registration or certificate issuance:
* Types of names assigned to the subject (7);
* Whether names have to be meaningful or not (8);
* Rules for interpreting various name forms;
* Whether names have to be unique;
* How name claim disputes are resolved;
* Recognition, authentication, and role of trademarks;
* If and how the subject must prove possession of the
companion private key for the public key being registered
(9);
* Authentication requirements for organizational identity of
subject (CA, RA, or end entity) (10);
* Authentication requirements for a person acting on behalf
of a subject (CA, RA, or end entity) (11), including:
* Number of pieces of identification required;
* How a CA or RA validates the pieces of identification
provided;
* If the individual must present personally to the
authenticating CA or RA;
* How an individual as an organizational person is
authenticated (12).
4.2.2 Routine Rekey
This subcomponent describes the identification and
authentication procedures for routine rekey for each subject
type (CA, RA, and end entity). (13)
Chokhani/Ford [Page 15]
Internet Draft PKIX Part IV March 1997
4.2.3 Rekey After Revocation -- No Key Compromise
This subcomponent describes the identification and
authentication procedures for rekey for each subject type (CA,
RA, and end entity) after the subject certificate has been
revoked. (14)
4.2.4 Revocation Request
This subcomponent describes the identification and
authentication procedures for a revocation request by each
subject type (CA, RA, and end entity). (16)
4.3 KEY MANAGEMENT
This component is used to define the security measures taken by
the issuing CA to protect its cryptographic keys and activation
data (e.g., PINs, passwords, or manually-held key shares). This
component may also be used to impose constraints on subject CAs
and end entities to protect their cryptographic keys and critical
security parameters. For the sake of completeness, for each type
of entity (issuing CA, subject CA, RA, and end entity), and for
each type of keying material (private key, parameters, public key,
and activation data) this component provides for addressing all
aspects of the key life-cycle from generation, through storage and
usage, to archival and destruction.
Secure key management is critical to ensure that all secret and
private keys and activation data are protected and used only by
authorized personnel.
This component has the following subcomponents, each of which may
need to separately address stipulations on issuing CA, subject
CAs, RAs and end entities:
* Key Pair Generation and Installation;
* Private Key Protection;
* Other Aspects of Key Pair Management; and
* Activation Data.
Chokhani/Ford [Page 16]
Internet Draft PKIX Part IV March 1997
4.3.1 Key Pair Generation and Installation
Key pair generation and installation need to be considered for
the issuing CA, subject CAs, RAs, and subject end entities.
For each of these types of entities, the following questions
potentially need to be answered:
1. Who generates the entity public, private key pair?
2. How is the private key provided securely to the entity?
3. How is the entity's public key provided securely to the
certificate issuer?
4. If the entity is a CA (issuing or subject) how is the
entity's public key provided securely to the users?
5. What are the key sizes?
6. Who generates the public key parameters?
7. Is the quality of the parameters checked during key
generation?
8. Is the key generation performed in hardware or software?
9. For what purposes may the key be used, or for what
purposes should usage of the key be restricted (for X.509
certificates, these purposes should map to the key usage
flags in the Version 3, X.509 certificates)?
4.3.2 Private Key Protection
Requirements for private key protection need to be considered
for the issuing CA, subject CAs, RAs, and subject end entities.
For each of these types of entity, the following questions
potentially need to be answered:
1. What standards, if any, are required for the module used
to generate the keys? For example, are the keys certified
by the infrastructure required to be generated using modules
complaint with the US FIPS 140-1? If so, what is the
required FIPS 140-1 level of the module?
2. Is the private key under n out of m multi-person
control?(18) If yes, provide n and m (two person control is
a special case of n out of m, where n = m = 2)?
Chokhani/Ford [Page 17]
Internet Draft PKIX Part IV March 1997
3. Is the private key escrowed? (19) If so, who is the
escrow agent, what form is the key escrowed in (examples
include plaintext, encrypted, split key), and what are the
security controls on the escrow system?
4. Is the private key backed up? If so, who is the backup
agent, what form is the key backed up in (examples include
plaintext, encrypted, split key), and what are the security
controls on the backup system?
5. Is the private key archived? If so, who is the archival
agent, what form is the key archived in (examples include
plaintext, encrypted, split key), and what are the security
controls on the archival system?
6. Who enters the private key in the cryptographic module?
In what form (i.e., plaintext, encrypted, or split key)?
How is the private key stored in the module (i.e.,
plaintext, encrypted, or split key)?
7. Who can activate (use) the private key? What actions
must be performed to activate the private key (e.g., login,
power on, supply PIN, insert token/key, automatic, etc.)?
Once the key is activated, is the key active for an
indefinite period, active for one time, or active for a
defined time period?
8. Who can deactivate the private key and how? Example of
how might include, logout, power off, remove token/key,
automatic, or time expiration.
9. Who can destroy the private key and how? Examples of how
might include token surrender, token destruction, or key
overwrite.
4.3.3 Other Aspects of Key Pair Management
Other aspects of key management need to be considered for the
issuing CA, subject CAs, RAs, and subject end entities. For
each of these types of entity, the following questions
potentially need to be answered:
1. Is the public key archived? If so, who is the archival
agent and what are the security controls on the archival
system? The archival system should provide integrity
controls other than digital signatures since: the archival
period may be greater than the cryptanalysis period for the
key and the archive requires tamper protection, which is not
Chokhani/Ford [Page 18]
Internet Draft PKIX Part IV March 1997
provided by digital signatures.
2. What are the usage periods, or active lifetimes, for the
public and the private key respectively?
4.3.4 Activation Data
Activation data refers to data values other than keys that are
required to operate cryptographic modules and that need to be
protected (e.g., a PIN, passphrase, or manually-held key
share). (20) Protection of activation data potentially needs
to be considered for the issuing CA, subject CAs, RAs, and end
entities. Such consideration potentially needs to address the
entire life-cycle of the activation data from generation
through archival and destruction. For each of the entity types
(issuing CA, subject CA, RA, and end entity) all of the
questions listed in 4.3.1 through 4.3.3 potentially need to be
answered with respect to activation data rather than with
respect to keys.
4.4 NON-TECHNICAL SECURITY CONTROLS
This component describes non-technical security controls (that is,
physical, procedural, and personnel controls) used by the issuing
CA to perform securely the functions of key generation, subject
authentication, certificate issuance, certificate revocation,
audit, and archival.
This component can also be used to define non-technical security
controls on subject CAs, RAs, and end entities. The non technical
security controls for the subject CAs, RAs, and end entities could
be the same, similar, or very different.
These non-technical security controls are critical to trusting the
certificates since lack of security may compromise CA operations
resulting, for example, in the creation of certificates or CRLs
with erroneous information or the compromise of the CA private
key.
This component consists of three subcomponents:
* Physical Controls;
* Procedural Controls; and
* Personnel Controls.
Within each subcomponent, separate consideration will, in general,
Chokhani/Ford [Page 19]
Internet Draft PKIX Part IV March 1997
need to be given to each entity type, that is, issuing CA, subject
CAs, RAs, and end entities.
4.4.1 Physical Controls
In this subcomponent, the physical controls on the facility
housing the entity systems are described.(21)
4.4.2 Procedural Controls
In this subcomponent, requirements for recognizing trusted
roles are described, together with the responsibilities for
each role.(22)
For each task identified for each role, it should also be
stated how many individuals are required to perform the task (n
out m rule). Identification and authentication requirements
for each role may also be defined.
4.4.3 Personnel Controls
This subcomponent addresses the following:
* Background checks and clearance procedures required for
the personnel filling the trusted roles; (23)
* Background checks and clearance procedures requirements
for other personnel; (24)
* Training requirements and training procedures for each
role;
* Any retraining period and retraining procedures for each
role;
* Frequency and sequence for job rotation among various
roles;
* Sanctions against personnel for unauthorized actions,
unauthorized use of authority, and unauthorized use of
entity systems; (25)
* Controls on contracting personnel, including:
- Bonding requirements on contract personnel;
- Contractual requirements including indemnification for
damages due to the actions of the contractor personnel;
- Audit and monitoring of contractor personnel; and
Chokhani/Ford [Page 20]
Internet Draft PKIX Part IV March 1997
- Other controls on contracting personnel.
4.5 TECHNICAL SECURITY CONTROLS
This component describes technical security controls used by the
issuing CA to perform securely the functions of key generation,
user authentication, certificate registration, certificate
revocation, audit, and archival. Technical controls include life-
cycle security controls (including software development
environment security, trusted software development methodology)
and operational security controls.
This component can also be used to define technical security
controls on subject CAs, RAs, and end entities.
This component consists of the following subcomponents:
* Computer Security Controls;
* Life-Cycle Security Controls;
* Network Security Controls; and
* Cryptographic Module Engineering Controls.
Within each subcomponent, separate consideration will, in general,
need to be given to each entity type, that is, issuing CA, subject
CAs, RAs, and end entities.
4.5.1 Computer Security Controls
This subcomponent is used to describe computer security
controls such as: use of the trusted computing base concept,
discretionary access control, labels, mandatory access
controls, object reuse, audit, identification and
authentication, trusted path, security testing, and penetration
testing. Product assurance may also be addressed.
A computer security rating for computer systems may be
required. The rating could be based, for example, on the
Trusted System Evaluation Criteria (TCSEC), Canadian Trusted
Products Evaluation Criteria, European Information Technology
Security Evaluation Criteria (ITSEC), or the Common Criteria.
This subcomponent can also address requirements for product
evaluation analysis, testing, profiling, product certification,
and/or product accreditation related activity undertaken.
Chokhani/Ford [Page 21]
Internet Draft PKIX Part IV March 1997
4.5.2 Life Cycle Security Controls
This subcomponent addresses system development controls and
security management controls.
System development controls include development environment
security, development personnel security, configuration
management security during product maintenance, software
engineering practices, software development methodology,
modularity, layering, use of failsafe design and implementation
techniques (e.g., defensive programming) and development
facility security.
Security management controls include execution of tools and
procedures to ensure that the operational systems and networks
adhere to configured security. These tools and procedures
include checking the integrity of the security software,
firmware, and hardware to ensure their correct operation.
This subcomponent can also address life-cycle security ratings
based, for example, on the Trusted Software Development
Methodology (TSDM) level IV and V, independent life-cycle
security controls audit, and the Software Engineering
Institute's Capability Maturity Model (SEI-CMM).
4.5.3 Network Security Controls
This subcomponent addresses network security related controls,
e.g., firewalls.
4.5.4 Cryptographic Module Engineering Controls (26)
This subcomponent addresses the following aspects of a
cryptographic module: identification of the cryptographic
module boundary, input/output, roles and services, finite state
machine, physical security, software security, operating system
security, algorithm compliance, electromagnetic compatibility,
and self tests. Requirements may be expressed through
reference to a standard such as U.S. FIPS 140-1. (27)
4.6 OPERATIONAL REQUIREMENTS
This component is used to specify requirements imposed upon
issuing CA, subject CAs, RAs, or end entities with respect to
various operational activities. This component consists of the
following subcomponents:
* Certificate Application;
Chokhani/Ford [Page 22]
Internet Draft PKIX Part IV March 1997
* Certificate Issuance;
* Certificate Acceptance;
* Certificate Suspension and Revocation;
* Security Audit Procedures;
* Records Archival;
* CA Key Changeover;
* Compromise and Disaster Recovery; and
* CA Termination.
Within each subcomponent, separate consideration may need to be
given to issuing CA, subject CAs, RAs, and end entities.
4.6.1 Certificate Application
This subcomponent is used to state requirements regarding
subject enrollment and request for certificate issuance.
4.6.2 Certificate Issuance
This subcomponent is used to state requirements regarding
issuance of a certificate and notification to the applicant of
such issuance.
4.6.3 Certificate Acceptance
This subcomponent is used to state requirements regarding
acceptance of an issued certificate and for subsequent
publicationsubject enrollment and requerequired st for
certificate issuance.
4.6.4 Certificate Suspension and Revocation
This subcomponent addresses the following:
* Circumstances under which a certificate may be revoked;
* Who can request the revocation of the entity certificate;
* Procedures used for certificate revocation request;
* Revocation request grace period available to the subject;
Chokhani/Ford [Page 23]
Internet Draft PKIX Part IV March 1997
* Circumstances under which a certificate may be suspended;
* Who can request the suspension of a certificate;
* Procedures to request certificate suspension;
* How long the suspension may last;
* If a CRL mechanism is used, the issuance frequency;
* Requirements on relying parties to check CRLs;
* On-line revocation/status checking availability;
* Requirements on relying parties to perform on-line
revocation/status checks;
* Other forms of revocation advertisements available; and
* Requirements on relying parties to check other forms of
revocation advertisements.
* Any variations on the above stipulations when the
suspension or revocation is the result of private key
compromise (as opposed to other reasons for suspension or
revocation).
4.6.5 Security Audit Procedures
This subcomponent is used to describe event logging and audit
systems, implemented for the purpose of maintaining a secure
environment. Elements include the following:
* Types of events recorded; (28)
* Frequency with which audit logs are processed or audited;
* Period for which audit logs are kept;
* Protection of audit logs:
- Who can view audit logs;
- Protection against modification of audit log; and
- Protection against deletion of audit log.
* Audit log back up procedures;
* Whether the audit log accumulation system is internal or
Chokhani/Ford [Page 24]
Internet Draft PKIX Part IV March 1997
external to the entity; and
* Whether the subject who caused an audit event to occur is
notified of the audit action.
4.6.6 Records Archival
This subcomponent is used to describe general records archival
(or records retention) policies, including the following:
* Types of events recorded; (29)
* Retention period for archive;
* Protection of archive:
- Who can view the archive;
- Protection against modification of archive; and
- Protection against deletion of archive.
* Archive backup procedures;
* Whether the archive collection system is internal or
external; and
* Procedures to obtain and verify archive information.
4.6.7 CA Key Changeover
This subcomponent describes the procedures to provide a new
public key to a CA's users.
4.6.8 Compromise and Disaster Recovery
This subcomponent describes requirements relating to
notification and recovery procedures in the event of compromise
or disaster. Each of the following circumstances may need to
be addressed separately:
* The recovery procedures used if computing resources,
software, and/or data are corrupted or suspected to be
corrupted. These procedures describe how a secure
environment is reestablished, which certificates are
revoked, whether the entity key is revoked, how the new
entity public key is provided to the users, and how the
subjects are recertified.
* The recovery procedures used if the entity public key is
Chokhani/Ford [Page 25]
Internet Draft PKIX Part IV March 1997
revoked. These procedures describe how a secure environment
is reestablished, how the new entity public key is provided
to the users, and how the subjects are recertified.
* The recovery procedures used if the entity key is
compromised. These procedures describe how a secure
environment is reestablished, how the new entity public key
is provided to the users, and how the subjects are
recertified.
4.6.9 CA Termination
This subcomponent describes requirements relating to procedures
for termination and for termination notification of a CA or RA,
including the identity of the custodian of CA and RA archival
records
4.7 GENERAL PROVISIONS
This component specifies any applicable presumptions on a range of
legal and general practices topics. This component contains the
following subcomponents:
* Liability;
* Obligations;
* Financial Responsibility;
* Interpretation and Enforcement;
* Fees;
* Publication and Repositories;
* Compliance Audit;
* Confidentiality; and
* Intellectual Property Rights.
Each subcomponent may need to separately state provisions applying
to the entity types: CA, RA, subscriber, and relying party.
(Specific provisions regarding subscribers and relying parties are
only applicable in the Liability and Obligations subcomponents.)
Chokhani/Ford [Page 26]
Internet Draft PKIX Part IV March 1997
4.7.1 Liability
This subcomponent contains, for each entity type, any
applicable provisions regarding apportionment of liability,
such as:
* Warranties and limitations on warranties;
* Disclaimers;
* Loss limitations (caps); and
* Other exclusions.
4.7.2 Obligations
This subcomponent contains, for each entity type, any
applicable provisions regarding the entity's obligations to
other entities. Such provisions may include:
* CA and/or RA obligations:
* Notification of issuance of a certificate to the
subscriber who is the subject of the certificate being
issued;
* Notification of issuance of a certificate to others
than the subject of the certificate;
* Notification of revocation or suspension of a
certificate to the subscriber whose certificate is being
revoked or suspended; and
* Notification of revocation or suspension of a
certificate to others than the subject whose certificate
is being revoked or suspended.
* Subscriber obligations:
* Accuracy of representations in certificate application;
* Protection of the entity's private key;
* Restrictions on private key and certificate use; and
* Notification upon private key compromise.
* Relying party obligations:
* Purposes for which certificate is used;
* Digital signature verification responsibilities;
* Revocation and suspension checking responsibilities;
and
* Acknowledgment of applicable liability caps and
Chokhani/Ford [Page 27]
Internet Draft PKIX Part IV March 1997
warranties.
4.7.3 Financial Responsibility
This subcomponent contains, for CAs and RAs, any applicable
provisions regarding financial responsibilities, such as:
* Indemnification of CA and/or RA by relying parties; and
* Fiduciary relationships (or lack thereof) between the
various entities.
4.7.4 Interpretation and Enforcement
This subcomponent contains any applicable provisions regarding
interpretation and enforcement of the certificate policy or
CPS, addressing such topics as:
* Governing law;
* Severability of provisions, survival, merger, and notice;
and
* Dispute resolution procedures.
4.7.5 Fees
This subcomponent contains any applicable provisions regarding
fees charged by CAs or RAs, such as:
* Certificate issuance or renewal fees;
* Certificate access fee;
* Revocation or status information access fee;
* Fees for other services such as policy information; and
* Refund policy.
Chokhani/Ford [Page 28]
Internet Draft PKIX Part IV March 1997
4.7.6 Publication and Repositories
This subcomponent contains any applicable provisions regarding:
* A CA's obligations to publish information regarding its
practices, its certificates, and the current status of such
certificates;
* Frequency of publication;
* Access control on published information objects including
certificate policy definitions, CPS, certificates,
certificate status, and CRLs; and
* Requirements pertaining to the use of repositories
operated by CAs or by other independent parties.
4.7.7 Compliance Audit
This subcomponent addresses the following:
* Frequency of compliance audit for each entity;
* Identity of the auditor;
* Auditor's relationship to the entity being audited; (30)
* List of topics covered under the compliance audit; (31)
* Actions taken as a result of a deficiency found during
compliance audit; (32)
* Compliance audit results: who they are shared with (e.g.,
subject CA, RA, and/or end entities), who provides them
(e.g., entity being audited or auditor), how they are
communicated.
4.7.8 Confidentiality Policy
This subcomponent addresses the following:
* Types of information that must be kept confidential by CA
or RA;
* Types of information that are not considered confidential;
* Who is entitled to be informed of reasons for revocation
and suspension of certificates;
Chokhani/Ford [Page 29]
Internet Draft PKIX Part IV March 1997
* Policy on release of information to law enforcement
officials;
* Information that can be revealed as part of civil
discovery;
* Conditions upon which CA or RA may disclose upon owner's
request; and
* Any other circumstances under which confidential
information may be disclosed.
4.7.9 Intellectual Property Rights
This subcomponent addresses ownership rights of certificates,
practice/policy specifications, names, and keys.
4.8 CERTIFICATE AND CRL PROFILES
This component is used to specify the certificate format and, if
CRLs are used, the CRL format. Assuming use of the X.509
certificate and CRL formats, this includes information on
profiles, versions, and extensions used.
This component has two subcomponents:
* Certificate Profile; and
* CRL Profile.
4.8.1 Certificate Profile
This subcomponent addresses such topics as the following
(potentially by reference to a separate profile definition,
such as the PKIX Part I profile):
* Version number(s) supported;
* Certificate extensions populated and their criticality;
* Cryptographic algorithm object identifiers;
* Name forms used for the CA, RA, and end entity names;
* Name constraints used and the name forms used in the name
constraints;
* Applicable certificate policy Object Identifier(s);
Chokhani/Ford [Page 30]
Internet Draft PKIX Part IV March 1997
* Usage of the policy constraints extension;
* Policy qualifiers syntax and semantics; and
* Processing semantics for the critical certificate policy
extension.
4.8.2 CRL Profile
This subcomponent addresses such topics as the following
(potentially by reference to a separate profile definition,
such as the PKIX Part I profile):
* Version numbers supported for CRLs; and
* CRL and CRL entry extensions populated and their
criticality.
4.9 SPECIFICATION ADMINISTRATION
This component is used to specify how this particular practices
and policy specification will be maintained. It contains the
following subcomponents:
* Contact Information;
* Specification Change Procedures;
* Publication and Notification Procedures; and
* CPS Approval Procedures.
4.9.1 Contact Information
This subcomponent includes the name and mailing address of the
authority that is responsible for the registration,
maintenance, and interpretation of this certificate policy or
CPS. It also includes the name, electronic mail address,
telephone number, and fax number of a contact person.
Chokhani/Ford [Page 31]
Internet Draft PKIX Part IV March 1997
4.9.2 Specification Change Procedures
It will occasionally be necessary to change certificate
policies and Certification Practice Statements. Some of these
changes will not materially reduce the assurance that a
certificate policy or its implementation provides, and will be
judged by the policy administrator as not changing the
acceptability of certificates asserting the policy for the
purposes for which they have been used. Such changes to
certificate policies and Certification Practice Statements need
not require a change in the certificate policy Object
Identifier or the CPS pointer (URL). Other changes to a
specification will change the acceptability of certificates for
specific purposes, and these changes will require changes to
the certificate policy Object Identifier or CPS pointer (URL).
This subcomponent contains the following information:
* A list of specification components, subcomponents, and/or
elements thereof that can be changed without notification
and without changes to the certificate policy Object
Identifier or CPS pointer (URL).
* A list of specification components, subcomponents, and/or
elements thereof that may change following a notification
period without changing the certificate policy Object
Identifier or CPS pointer (URL). The procedures to be used
to notify interested parties (relying parties, certification
authorities, etc.) of the certificate policy or CPS changes
are described. The description of notification procedures
includes the notification mechanism, notification period for
comments, mechanism to receive, review and incorporate the
comments, mechanism for final changes to the policy, and the
period before final changes become effective.
* A list of specification components, subcomponents, and/or
elements, changes to which require a change in certificate
policy Object Identifier or CPS pointer (URL)..
Chokhani/Ford [Page 32]
Internet Draft PKIX Part IV March 1997
4.9.3 Publication and Notification Procedures
This subcomponent contains the following elements:
* A list of components, subcomponents, and elements thereof
that exist but that are not made publicly available; (33)
* Descriptions of mechanisms used to distribute the
certificate policy definition or CPS, including access
controls on such distribution.
4.9.4 CPS Approval Procedures
In a certificate policy definition, this subcomponent describes
how the compliance of a specific CPS with the certificate
policy can be determined.
5. PRACTICES AND POLICY SPECIFICATION OUTLINE
This section contains a possible outline for a practices and policy
specification, intended to serve as a checklist or (with some further
development) a standard template for use by certificate policy or CPS
writers. Such a common outline will facilitate:
(a) Comparison of two certificate policies during cross-
certification (for the purpose of equivalency mapping).
(b) Comparison of a CPS with a certificate policy definition to
ensure that the CPS faithfully implements the policy.
(c) Comparison of two CPSs.
1. COMMUNITY AND APPLICABILITY
1.1 Certification Authorities
1.2 Registration Authorities
1.3 End Entities
1.4 Applicability
1.4.1 List of suitable applications
1.4.2 List of approved applications
1.4.3 List of prohibited applications
2. IDENTIFICATION AND AUTHENTICATION (34)
Chokhani/Ford [Page 33]
Internet Draft PKIX Part IV March 1997
2.1 Initial Registration
2.1.1 Types of names
2.1.2 Need for names to be meaningful
2.1.3 Rules for interpreting various name forms
2.1.4 Uniqueness of names
2.1.5 Name claim dispute resolution procedure
2.1.6 Recognition, authentication and role of trademarks
2.1.7 Method to prove possession of private key
2.1.8 Authentication of organization identity
2.1.9 Authentication of individual identity
2.2 Routine Rekey
2.3 Rekey after Revocation
2.4 Revocation Request
3. KEY MANAGEMENT (34)
3.1 Key Pair Generation and Installation
3.1.1 Key pair generation
3.1.2 Private key delivery to entity
3.1.3 Public key delivery to certificate issuer
3.1.4 CA public key delivery to users
3.1.5 Key sizes
3.1.6 Public key parameters generation
3.1.7 Parameter quality checking
3.1.8 Hardware/software key generation
3.1.9 Key usage purposes (as per X.509 v3 key usage field)
3.2 Private Key Protection
3.2.1 Standards for cryptographic module
3.2.2 Private key (n out of m) multi-person control
3.2.3 Private key escrow
3.2.4 Private key backup
3.2.5 Private key archival
3.2.6 Private key entry into cryptographic module
3.2.7 Method of activating private key
3.2.8 Method of deactivating private key
3.2.9 Method of destroying private key
3.3 Other Aspects of Key Pair Management
3.3.1 Public key archival
3.3.2 Usage periods for the public and private keys
3.4 Activation Data
3.4.1 Activation data generation and installation
3.4.2 Activation data protection
Chokhani/Ford [Page 34]
Internet Draft PKIX Part IV March 1997
3.4.3 Other aspects of activation data
4. NON-TECHNICAL SECURITY CONTROLS (34)
4.1 Physical Controls
4.2 Procedural Controls
4.2.1 Trusted roles
4.2.2 Number of persons required per task
4.2.3 Identification and authentication for each role
4.3 Personnel Controls
4.3.1 Background, qualifications, experience, and clearance
requirements
4.3.2 Background check procedures
4.3.3 Training requirements
4.3.4 Retraining frequency and requirements
4.3.5 Job rotation frequency and sequence
4.3.6 Sanctions for unauthorized actions
4.3.7 Contracting personnel requirements
5. TECHNICAL SECURITY CONTROLS (34)
5.1 Computer Security Controls
5.1.2 Specific computer security technical requirements
5.1.2 Computer security rating
5.2 Life Cycle Technical Controls
5.2.1 System development controls
5.2.2 Security management controls
5.2.3 Life cycle security ratings
5.3 Network Security Controls
5.4 Cryptographic Module Engineering Controls
6. OPERATIONAL REQUIREMENTS (34)
6.1 Certificate Application
6.2 Certificate Issuance
6.3 Certificate Acceptance
6.4 Certificate Suspension and Revocation
6.4.1 Circumstances for revocation
6.4.2 Who can request revocation
6.4.3 Procedure for revocation request
Chokhani/Ford [Page 35]
Internet Draft PKIX Part IV March 1997
6.4.4 Revocation request grace period
6.4.5 Circumstances for suspension
6.4.6 Who can request suspension
6.4.7 Procedure for suspension request
6.4.8 Limits on suspension period
6.4.9 CRL issuance frequency (if applicable)
6.4.10 CRL checking requirements
6.4.11 On-line revocation/status checking availability
6.4.12 On-line revocation checking requirements
6.4.13 Other forms of revocation advertisements available
6.4.14 Checking requirements for other forms of revocation
advertisements
6.4.15 Special requirements re key compromise
6.5 Security Audit Procedures
6.5.1 Types of event recorded
6.5.2 Frequency of processing log
6.5.3 Retention period for audit log
6.5.4 Protection of audit log
6.5.5 Audit log backup procedures
6.5.6 Audit collection system (internal vs external)
6.5.7 Notification to event-causing subject
6.6 Records Archival
6.6.1 Types of event recorded
6.6.2 Retention period for archive
6.6.3 Protection of archive
6.6.4 Archive backup procedures
6.6.5 Archive collection system (internal or external)
6.6.6 Procedures to obtain and verify archive information
6.7 CA Key changeover
6.8 Compromise and Disaster Recovery
6.9 CA Termination
7. GENERAL PROVISIONS
7.1 Liability
7.1.1 Warranties and limitations on warranties
7.1.2 Disclaimers
7.1.1 Loss limitations (caps)
7.1.1 Other exclusions
Chokhani/Ford [Page 36]
Internet Draft PKIX Part IV March 1997
7.2 Obligations
7.2.1 CA and/or RA obligations
7.2.2 Subscriber obligations
7.2.3 Relying party obligations
7.3 Financial responsibility
7.3.1 Indemnification by relying parties
7.3.2 Fiduciary relationships
7.4 Interpretation and Enforcement
7.4.1 Governing law
7.4.2 Severability, survival, merger, notice
7.4.3 Dispute resolution procedures
7.5 Fees
7.5.1 Certificate issuance or renewal fees
7.5.2 Certificate access fees
7.5.3 Revocation or status information access fees
7.5.4 Fees for other services such as policy information
7.5.5 Refund policy
7.6 Publication and Repository
7.6.1 Publication of CA information
7.6.2 Frequency of publication
7.6.3 Access controls
7.6.4 Repositories
7.7 Compliance audit
7.7.1 Frequency of entity compliance audit
7.7.2 Identity/qualifications of auditor
7.7.3 Auditor's relationship to audited party
7.7.4 Topics covered by audit
7.7.5 Actions taken as a result of deficiency
7.7.6 Communication of results
7.8 Confidentiality
7.8.1 Types of information to be kept confidential
7.8.2 Types of information not considered confidential
7.8.3 Disclosure of certificate revocation/suspension information
7.8.4 Release to law enforcement officials
7.8.5 Release as part of civil discovery
Chokhani/Ford [Page 37]
Internet Draft PKIX Part IV March 1997
7.8.6 Disclosure upon owner's request
7.8.7 Other information release circumstances
7.9 Intellectual Property Rights
8. CERTIFICATE AND CRL PROFILES
8.1 Certificate Profile
8.1.1 Version number(s)
8.1.2 Certificate extensions
8.1.3 Algorithm object identifiers
8.1.4 Name forms
8.1.5 Name constraints
8.1.6 Certificate policy Object Identifier
8.1.7 Usage of Policy Constraints extension
8.1.8 Policy qualifiers syntax and semantics
8.1.9 Processing semantics for the critical certificate policy
extension
8.2 CRL Profile
8.2.1 Version number(s)
8.2.2 CRL and CRL entry extensions
9. POLICY ADMINISTRATION
9.1 Contact information
9.2 Specification change procedures
9.3 Publication and notification policies
9.4 CPS approval procedures
6. SECURITY CONSIDERATIONS
This entire memo deals with security, related to public-key
certificates.
7. ACKNOWLEDGMENTS
We wish to thank Dave Fillingham, Jim Brandt, and Edmond Van Hees for
their inspiration, support, and valuable inputs. The development of
this document was supported by the Government of Canada's Policy
Management Authority (PMA) Committee, the U.S. National Security
Agency, and the National Institute of Standards and Technology.
Chokhani/Ford [Page 38]
Internet Draft PKIX Part IV March 1997
We also wish to thank the following individuals for their review and
input: Noel Nazario, National Institute of Standards and Technology;
David Simonetti, Booz, Allen and Hamilton; Teresa Acevedo, A&N
Associates; Michael Baum and Mark Silvern, VeriSign; Patrick Cain,
BBN; Michael Harrop, Government of Canada Treasury Board; John Morris
and Jean Petty, CygnaCom Solutions, Inc.; Tim Moses and Darryl Stal,
Nortel; and John Nicolletos, A&N Associates. Johnny Hsiung, and
Chris Miller assisted in the preparation of the manuscript.
8. REFERENCES
[ABA1] American Bar Association, Digital Signature Guidelines: Legal
Infrastructure for Certification Authorities and Electronic Commerce,
Draft 1995.
[BAU1] Michael. S. Baum, Federal Certification Authority Liability
and Policy, NIST-GCR-94-654, June 1994.
[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
Technology - Open Systems Interconnection: The Directory:
Authentication Framework," 1997 edition. (Pending publication of 1997
edition, use 1993 edition with the following amendment applied:
Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate
Extensions, June 1996.)
[PEM1] S. Kent, "Privacy Enhancement for Internet Electronic Mail,
Part II: Certificate-Based Key Management," Internet RFC 1422, 1993.
[PKI1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key
Infrastructure, Part I: X.509 Certificate and CRL Profile," draft-
ietf-pkix-ipki-part1-03.txt, 1996.
9. AUTHORS' ADDRESSES
Santosh Chokhani
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, VA 22102
Phone: (703) 848-0883
Fax: (703) 848-0960
EMail: chokhani@cygnacom.com
Warwick Ford
VeriSign, Inc.
Chokhani/Ford [Page 39]
Internet Draft PKIX Part IV March 1997
One Alewife Center
Cambridge, MA 02140
Phone: (617) 492-2816 x225
Fax: (617) 661-0716
EMail: wford@verisign.com
NOTES
1 The ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details.
2 Example: A bank claims that it issues CA certificates to its branches only. Now, the user of a CA certificate issued by the bank can assume that the subject CA in the certificate is a branch of the bank.
3 Example: A Government CA claims that it issues certificates to Government employees only. Now, the user of a certificate issued by the Government CA can assume that the subject of the certificate is a Government employee.
4 Examples of the types of subject CA entities are a subordinate organizations (e.g., branch, division, etc.), a US Federal Government agency, a Government of Canada agency, a state agency, a provincial department, etc.
5 Examples of the types of subject RA entities are branch and division of an organization.
6 Examples of types of subject end entities are uniformed and civilian DoD personnel, DoD contractors, Ministry of Defense employees, bank customers, telephone company subscribers, etc.
7 Examples include X.500 distinguished names, RFC 822 Internet
names, URL, etc.
8 The term meaningful means that the name form has commonly understood semantics to determine identity of the person and/or organization. The directory names and RFC 822 names are examples of meaningful names.
9 Examples of proof include the issuing CA generating the key, or requiring the subject to send an electronically signed request or to sign a challenge.
10 Examples of organization identity authentication are: articles of incorporation, duly signed corporate resolutions, company seal, and notarized documents.
11 Examples of individual identity authentication are: biometrics (thumb print, ten finger print, face, palm, and retina scan), driver's license, passport, credit card, company badge, and government badge.
12 Examples include duly signed authorization papers, corporate badge, etc.
13 The identification policy for routine rekey should be the same as the one for initial registration since the same subject needs rekeying. The rekey authentication may be accomplished using the techniques for initial I&A or using digitally signed requests.
14 This I&A policy could be the same as the one for initial registration.
15 This policy could be the same as the one for initial registration.
16 The identification policy for Revocation request could be the same as the one for initial registration since the same subject certificate needs to be revoked. The authentication policy could accept a Revocation request digitally signed by subject. The authentication information used during initial registration could be acceptable for Revocation request. Other less stringent authentication policy could be defined.
17 The identification policy for key compromise notification could be the same as the one for initial registration since the same subject certificate needs to be revoked. The authentication policy could accept a Revocation request digitally signed by subject. The authentication information used during initial registration could be acceptable for key compromise notification. Other less stringent authentication policy could be defined.
18 The n out of m rule allows a key to be split in m parts. The m parts may be given to m different individuals. Any n parts out of the m parts may be used to fully reconstitute the key, but having any n-1 parts provides one with no information about the key.
Chokhani/Ford [Page 40]
Internet Draft PKIX Part IV March 1997
19 A key may be escrowed, backed up or archived. Each of these functions have different purpose. Thus, a key may go through any subset of these functions depending on the requirements. The purpose of escrow is to allow a third party (such as an organization or government) to legally obtain the key without the cooperation of the subject. The purpose of back up is to allow the subject to reconstitute the key in case of the destruction of the key. The purpose of archive is to provide for reuse of the key in future, e.g., use the private key to decrypt a document.
20 Critical security parameters are data other than the public and private key pair and public key parameters required to operate the module. An example of a critical security parameters is a PIN or passphrase. The public key parameters are NOT an example of critical security parameters.
21 Examples of physical controls are: monitored facility, guarded facility, locked facility, access controlled using tokens, access controlled using biometrics, access controlled through an access list, etc.
22 Examples of the roles include, system administrator, system security officer, system auditor, and crypto officer. The duties of the system administrator are to configure, generate, boot, and operate the system. The duties of the system security officer are to assign accounts and privileges. The duties of the system auditor are to set up system audit profile, perform audit file management, and audit review. The duties of the crypto officer are to hold, manage, and protect the CA keys and PINs, and to use them to operate the cryptographic devices used by the CA to sign the certificates and the CRLs.
23 The background checks may include clearance level (e.g., none, sensitive, confidential, secret, top secret, etc.) and the clearance granting authority name. In lieu of or in addition to a defined clearance, the background checks may include types of background information (e.g., name, place of birth, date of birth, home address, previous residences, previous employment, and any other information that may help determine trustworthiness). The description should also include which information was verified and how.
24 For example, the certificate policy may impose personnel security requirements on the network system administrator responsible for a CA's network access.
25 Each authorized person should be accountable for his/her actions.
26 A cryptographic module is hardware, software, or firmware or any combination of them.
27 The compliance description should be specific and detailed. For example, for each FIPS 140-1 requirement, describe the level and whether the level has been certified by an accredited laboratory.
28 Example of audit events are: request to create a certificate, request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of key compromise CRL, establishment of trusted roles on the CA, actions of truste personnel, changes to CA keys, etc.
29 Example of archive events are: request to create a certificate, request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of key compromise CRL, and changes to CA keys.
30 A parent CA is an example of audit relationship.
31 Example of compliance audit topics: sample check on the various I&A policies, comprehensive checks on key management policies, comprehensive checks on system security controls, comprehensive checks on operations policy, and comprehensive checks on certificate profiles,
32 The examples include, temporary suspension of operations until deficiencies are corrected, revocation of entity certificate, change in personnel, invocation of liability policy, more frequent compliance audit, etc.
33 An organization may choose not to make public some of its security controls, clearance procedures, or some others elements due to their sensitivity.
34 All or some of the following items may be different for the various types of entities, i.e., CA, RA, and end entities.
LIST OF ACRONYMS
ABA - American Bar Association
CA - Certification Authority
CPS - Certification Practice Statement
CRL - Certificate Revocation List
DAM - Draft Amendment
FIPS - Federal Information Processing Standard
I&A - Identification and Authentication
IEC - International Electrotechnical Commission
IETF - Internet Engineering Task Force
IP - Internet Protocol
ISO - International Organization for Standardization
ITU - International Telecommunications Union
NIST - National Institute of Standards and Technology
OID - Object Identifier
Chokhani/Ford [Page 41]
Internet Draft PKIX Part IV March 1997
PIN - Personal Identification Number
PKI - Public Key Infrastructure
PKIX - Public Key Infrastructure (X.509) (IETF Working Group)
RA - Registration Authority
RFC - Request For Comment
URL - Uniform Resource Locator
US - United States
Chokhani/Ford [Page 42]
