< draft-ietf-pkix-ipki-part4-02.txt   draft-ietf-pkix-ipki-part4-03.txt >
PKIX Working Group S. Chokhani (CygnaCom Solutions, Inc.) PKIX Working Group S. Chokhani (CygnaCom Solutions, Inc.)
Internet Draft W. Ford (VeriSign, Inc.) Internet Draft W. Ford (VeriSign, Inc.)
Expires in six months from September 30, 1997 Expires in six months from April 25, 1998
Internet Public Key Infrastructure Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework Certificate Policy and Certification Practices Framework
<draft-ietf-pkix-ipki-part4-02.txt> <draft-ietf-pkix-ipki-part4-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of 6 months Internet-Drafts are draft documents valid for a maximum of 6 months
and may be updated, replaced, or may become obsolete by other and may be updated, replaced, or may become obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as work in progress. reference material or to cite them other than as work in progress.
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Copyright (C) The Internet Society (date). All Rights Reserved.
Abstract Abstract
This document presents a framework to assist the writers of This document presents a framework to assist the writers of
certificate policies or certification practice statements for certificate policies or certification practice statements for
certification authorities and public key infrastructures. In certification authorities and public key infrastructures. In
particular, the framework provides a comprehensive list of topics particular, the framework provides a comprehensive list of topics
that potentially (at the writer's discretion) need to be covered in a that potentially (at the writer's discretion) need to be covered in a
certificate policy definition or a certification practice statement. certificate policy definition or a certification practice statement.
It is intended that this document, when fully developed, be published This document is being submitted to the RFC Editor with a request for
as an Informational RFC. publication as an Informational RFC.
1. INTRODUCTION 1. INTRODUCTION
1.1 BACKGROUND 1.1 BACKGROUND
A public-key certificate (hereinafter "certificate") binds a A public-key certificate (hereinafter "certificate") binds a
public-key value to a set of information that identifies the public-key value to a set of information that identifies the
entity (such as person, organization, account, or site) associated entity (such as person, organization, account, or site) associated
with use of the corresponding private key (this entity is known as with use of the corresponding private key (this entity is known as
the "subject" of the certificate). A certificate is used by a the "subject" of the certificate). A certificate is used by a
"certificate user" or "relying party" that needs to use, and rely "certificate user" or "relying party" that needs to use, and rely
upon the accuracy of, the public key distributed via that upon the accuracy of, the public key distributed via that
certificate (a certificate user is typically an entity that is certificate (a certificate user is typically an entity that is
verifying a digital signature from the certificate's subject or an verifying a digital signature from the certificate's subject or an
entity sending encrypted data to the subject). The degree to entity sending encrypted data to the subject). The degree to
which a certificate user can trust the binding embodied in a which a certificate user can trust the binding embodied in a
certificate depends on several factors. These factors include the certificate depends on several factors. These factors include the
practices followed by the certification authority (CA) in practices followed by the certification authority (CA) in
authenticating the subject; the CA's operating policy, procedures, authenticating the subject; the CA's operating policy, procedures,
and security controls; the subject's obligations (for example, in and security controls; the subject's obligations (for example, in
protecting the private key); and the stated undertakings and legal protecting the private key); and the stated undertakings and legal
obligations of the CA (for example, warranties and limitations on obligations of the CA (for example, warranties and limitations on
liability). liability).
A Version 3 X.509 certificate may contain a field declaring that A Version 3 X.509 certificate may contain a field declaring that
one or more specific certificate policies applies to that one or more specific certificate policies applies to that
certificate [ISO1]. According to X.509, a certificate policy is certificate [ISO1]. According to X.509, a certificate policy is
"a named set of rules that indicates the applicability of a "a named set of rules that indicates the applicability of a
certificate to a particular community and/or class of application certificate to a particular community and/or class of application
with common security requirements." A certificate policy may be with common security requirements." A certificate policy may be
used by a certificate user to help in deciding whether a used by a certificate user to help in deciding whether a
certificate, and the binding therein, is sufficiently trustworthy certificate, and the binding therein, is sufficiently trustworthy
for a particular application. The certificate policy concept is for a particular application. The certificate policy concept is
an outgrowth of the policy statement concept developed for an outgrowth of the policy statement concept developed for
Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1]. Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1].
A more detailed description of the practices followed by a CA in A more detailed description of the practices followed by a CA in
issuing and otherwise managing certificates may be contained in a issuing and otherwise managing certificates may be contained in a
certification practice statement (CPS) published by or referenced certification practice statement (CPS) published by or referenced
by the CA. According to the American Bar Association Digital by the CA. According to the American Bar Association Digital
Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a
statement of the practices which a certification authority employs statement of the practices which a certification authority employs
in issuing certificates." [ABA1] in issuing certificates." [ABA1]
1.2 PURPOSE 1.2 PURPOSE
The purpose of this document is to establish a clear relationship The purpose of this document is to establish a clear relationship
between certificate policies and CPSs, and to present a framework between certificate policies and CPSs, and to present a framework
to assist the writers of certificate policies or CPSs with their to assist the writers of certificate policies or CPSs with their
tasks. In particular, the framework identifies the elements that tasks. In particular, the framework identifies the elements that
may need to be considered in formulating a certificate policy or a may need to be considered in formulating a certificate policy or a
CPS. The purpose is not to define particular certificate policies CPS. The purpose is not to define particular certificate policies
or CPSs, per se. or CPSs, per se.
1.3 SCOPE 1.3 SCOPE
The scope of this document is limited to discussion of the The scope of this document is limited to discussion of the
contents of a certificate policy (as defined in X.509) or CPS (as contents of a certificate policy (as defined in X.509) or CPS (as
defined in the ABA Guidelines). In particular, this document defined in the ABA Guidelines). In particular, this document
describes the types of information that should be considered for describes the types of information that should be considered for
inclusion in a certificate policy definition or a CPS. While the inclusion in a certificate policy definition or a CPS. While the
framework as presented generally assumes use of the X.509 version framework as presented generally assumes use of the X.509 version
3 certificate format, it is not intended that the material be 3 certificate format, it is not intended that the material be
restricted to use of that certificate format. Rather, it is restricted to use of that certificate format. Rather, it is
intended that this framework be adaptable to other certificate intended that this framework be adaptable to other certificate
formats that may come into use. formats that may come into use.
The scope does not extend to defining security policies generally The scope does not extend to defining security policies generally
(such as organization security policy, system security policy, or (such as organization security policy, system security policy, or
data labeling policy) beyond the policy elements that are data labeling policy) beyond the policy elements that are
considered of particular relevance to certificate policies or considered of particular relevance to certificate policies or
CPSs. CPSs.
This document does not define a specific certificate policy or This document does not define a specific certificate policy or
CPS. CPS.
It is assumed that the reader is familiar with the general It is assumed that the reader is familiar with the general
concepts of digital signatures, certificates, and public-key concepts of digital signatures, certificates, and public-key
infrastructure, as used in X.509 and the ABA Guidelines. infrastructure, as used in X.509 and the ABA Guidelines.
2. DEFINITIONS 2. DEFINITIONS
This document makes use of the following defined terms: This document makes use of the following defined terms:
Activation data - Data values, other than keys, that are required Activation data - Data values, other than keys, that are required
to operate cryptographic modules and that need to be protected to operate cryptographic modules and that need to be protected
(e.g., a PIN, a passphrase, or a manually-held key share). (e.g., a PIN, a passphrase, or a manually-held key share).
CA-certificate - A certificate for one CA's public key issued by CA-certificate - A certificate for one CA's public key issued by
another CA. another CA.
Certificate policy - A named set of rules that indicates the Certificate policy - A named set of rules that indicates the
applicability of a certificate to a particular community and/or applicability of a certificate to a particular community and/or
class of application with common security requirements. For class of application with common security requirements. For
example, a particular certificate policy might indicate example, a particular certificate policy might indicate
applicability of a type of certificate to the authentication of applicability of a type of certificate to the authentication of
electronic data interchange transactions for the trading of goods electronic data interchange transactions for the trading of goods
within a given price range. within a given price range.
Certification path - An ordered sequence of certificates which, Certification path - An ordered sequence of certificates which,
together with the public key of the initial object in the path, 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. can be processed to obtain that of the final object in the path.
Certification Practice Statement (CPS) - A statement of the Certification Practice Statement (CPS) - A statement of the
practices which a certification authority employs in issuing practices which a certification authority employs in issuing
certificates. certificates.
Issuing certification authority (issuing CA) - In the context of a Issuing certification authority (issuing CA) - In the context of a
particular certificate, the issuing CA is the CA that issued the particular certificate, the issuing CA is the CA that issued the
certificate (see also Subject certification authority). certificate (see also Subject certification authority).
Policy qualifier - Policy-dependent information that accompanies a Policy qualifier - Policy-dependent information that accompanies a
certificate policy identifier in an X.509 certificate. certificate policy identifier in an X.509 certificate.
Registration authority (RA) - An entity that is responsible for Registration authority (RA) - An entity that is responsible for
identification and authentication of certificate subjects, but identification and authentication of certificate subjects, but
that does not sign or issue certificates (i.e., an RA is delegated that does not sign or issue certificates (i.e., an RA is delegated
certain tasks on behalf of a CA). [Note: The term Local certain tasks on behalf of a CA). [Note: The term Local
Registration Authority (LRA) is used elsewhere for the same Registration Authority (LRA) is used elsewhere for the same
concept.] concept.]
Relying party - A recipient of a certificate who acts in reliance Relying party - A recipient of a certificate who acts in reliance
on that certificate and/or digital signatures verified using that on that certificate and/or digital signatures verified using that
certificate. In this document, the terms "certificate user" and certificate. In this document, the terms "certificate user" and
"relying party" are used interchangeably. "relying party" are used interchangeably.
Set of provisions - A collection of practice and/or policy Set of provisions - A collection of practice and/or policy
statements, spanning a range of standard topics, for use in statements, spanning a range of standard topics, for use in
expressing a certificate policy definition or CPS employing the expressing a certificate policy definition or CPS employing the
approach described in this framework. approach described in this framework.
Subject certification authority (subject CA) - In the context of a Subject certification authority (subject CA) - In the context of a
particular CA-certificate, the subject CA is the CA whose public particular CA-certificate, the subject CA is the CA whose public
key is certified in the certificate (see also Issuing key is certified in the certificate (see also Issuing
certification authority). certification authority).
3. CONCEPTS 3. CONCEPTS
This section explains the concepts of certificate policy and CPS, and This section explains the concepts of certificate policy and CPS, and
describes their relationship. Other related concepts are also describes their relationship. Other related concepts are also
described. Some of the material covered in this section and in some described. Some of the material covered in this section and in some
other sections is specific to certificate policies extensions as other sections is specific to certificate policies extensions as
defined X.509 version 3. Except for those sections, this framework defined X.509 version 3. Except for those sections, this framework
is intended to be adaptable to other certificate formats that may is intended to be adaptable to other certificate formats that may
come into use. come into use.
3.1 CERTIFICATE POLICY 3.1 CERTIFICATE POLICY
When a certification authority issues a certificate, it is When a certification authority issues a certificate, it is
providing a statement to a certificate user (i.e., a relying providing a statement to a certificate user (i.e., a relying
party) that a particular public key is bound to a particular party) that a particular public key is bound to a particular
entity (the certificate subject). However, the extent to which entity (the certificate subject). However, the extent to which
the certificate user should rely on that statement by the CA needs the certificate user should rely on that statement by the CA needs
to be assessed by the certificate user. Different certificates to be assessed by the certificate user. Different certificates
are issued following different practices and procedures, and may are issued following different practices and procedures, and may
be suitable for different applications and/or purposes. be suitable for different applications and/or purposes.
The X.509 standard defines a certificate policy as "a named set of The X.509 standard defines a certificate policy as "a named set of
rules that indicates the applicability of a certificate to a rules that indicates the applicability of a certificate to a
particular community and/or class of application with common particular community and/or class of application with common
security requirements"[ISO1]. An X.509 Version 3 certificate may security requirements"[ISO1]. An X.509 Version 3 certificate may
contain an indication of certificate policy, which may be used by contain an indication of certificate policy, which may be used by
a certificate user to decide whether or not to trust a certificate a certificate user to decide whether or not to trust a certificate
for a particular purpose. for a particular purpose.
A certificate policy, which needs to be recognized by both the A certificate policy, which needs to be recognized by both the
issuer and user of a certificate, is represented in a certificate issuer and user of a certificate, is represented in a certificate
by a unique, registered Object Identifier. The registration by a unique, registered Object Identifier. The registration
process follows the procedures specified in ISO/IEC and ITU process follows the procedures specified in ISO/IEC and ITU
standards. The party that registers the Object Identifier also standards. The party that registers the Object Identifier also
publishes a textual specification of the certificate policy, for publishes a textual specification of the certificate policy, for
examination by certificate users. Any one certificate will examination by certificate users. Any one certificate will
typically declare a single certificate policy or, possibly, be typically declare a single certificate policy or, possibly, be
issued consistent with a small number of different policies. issued consistent with a small number of different policies.
Certificate policies also constitute a basis for accreditation of Certificate policies also constitute a basis for accreditation of
CAs. Each CA is accredited against one or more certificate CAs. Each CA is accredited against one or more certificate
policies which it is recognized as implementing. When one CA policies which it is recognized as implementing. When one CA
issues a CA-certificate for another CA, the issuing CA must assess issues a CA-certificate for another CA, the issuing CA must assess
the set of certificate policies for which it trusts the subject CA the set of certificate policies for which it trusts the subject CA
(such assessment may be based upon accreditation with respect to (such assessment may be based upon accreditation with respect to
the certificate policies involved). The assessed set of the certificate policies involved). The assessed set of
certificate policies is then indicated by the issuing CA in the certificate policies is then indicated by the issuing CA in the
CA-certificate. The X.509 certification path processing logic CA-certificate. The X.509 certification path processing logic
employs these certificate policy indications in its well-defined employs these certificate policy indications in its well-defined
trust model. trust model.
3.2 CERTIFICATE POLICY EXAMPLES 3.2 CERTIFICATE POLICY EXAMPLES
For example purposes, suppose that IATA undertakes to define some For example purposes, suppose that IATA undertakes to define some
certificate policies for use throughout the airline industry, in a certificate policies for use throughout the airline industry, in a
public-key infrastructure operated by IATA in combination with public-key infrastructure operated by IATA in combination with
public-key infrastructures operated by individual airlines. Two public-key infrastructures operated by individual airlines. Two
certificate policies are defined - the IATA General-Purpose certificate policies are defined - the IATA General-Purpose
policy, and the IATA Commercial-Grade policy. policy, and the IATA Commercial-Grade policy.
The IATA General-Purpose policy is intended for use by industry The IATA General-Purpose policy is intended for use by industry
personnel for protecting routine information (e.g., casual personnel for protecting routine information (e.g., casual
electronic mail) and for authenticating connections from World electronic mail) and for authenticating connections from World
Wide Web browsers to servers for general information retrieval Wide Web browsers to servers for general information retrieval
purposes. The key pairs may be generated, stored, and managed purposes. The key pairs may be generated, stored, and managed
using low-cost, software-based systems, such as commercial using low-cost, software-based systems, such as commercial
browsers. Under this policy, a certificate may be automatically browsers. Under this policy, a certificate may be automatically
issued to anybody listed as an employee in the corporate directory issued to anybody listed as an employee in the corporate directory
of IATA or any member airline who submits a signed certificate of IATA or any member airline who submits a signed certificate
request form to a network administrator in his or her request form to a network administrator in his or her
organization. organization.
The IATA Commercial-Grade policy is used to protect financial The IATA Commercial-Grade policy is used to protect financial
transactions or binding contractual exchanges between airlines. transactions or binding contractual exchanges between airlines.
Under this policy, IATA requires that certified key pairs be Under this policy, IATA requires that certified key pairs be
generated and stored in approved cryptographic hardware tokens. generated and stored in approved cryptographic hardware tokens.
Certificates and tokens are provided to airline employees with Certificates and tokens are provided to airline employees with
disbursement authority. These authorized individuals are required disbursement authority. These authorized individuals are required
to present themselves to the corporate security office, show a to present themselves to the corporate security office, show a
valid identification badge, and sign an undertaking to protect the valid identification badge, and sign an undertaking to protect the
token and use it only for authorized purposes, before a token and token and use it only for authorized purposes, before a token and
a certificate are issued. a certificate are issued.
3.3 X.509 CERTIFICATE FIELDS 3.3 X.509 CERTIFICATE FIELDS
The following extension fields in an X.509 certificate are used to The following extension fields in an X.509 certificate are used to
support certificate policies: support certificate policies:
* Certificate Policies extension; * Certificate Policies extension;
* Policy Mappings extension; and * Policy Mappings extension; and
* Policy Constraints extension. * Policy Constraints extension.
3.3.1 Certificate Policies Extension 3.3.1 Certificate Policies Extension
The Certificate Policies extension has two variants - one with The Certificate Policies extension has two variants - one with
the field flagged non-critical and one with the field flagged the field flagged non-critical and one with the field flagged
critical. The purpose of the field is different in the two critical. The purpose of the field is different in the two
cases. cases.
A non-critical Certificate Policies field lists certificate A non-critical Certificate Policies field lists certificate
policies that the certification authority declares are policies that the certification authority declares are
applicable. However, use of the certificate is not restricted applicable. However, use of the certificate is not restricted
to the purposes indicated by the applicable policies. Using to the purposes indicated by the applicable policies. Using
the example of the IATA General-Purpose and Commercial-Grade the example of the IATA General- Purpose and Commercial-Grade
policies defined in Section 3.2, the certificates issued to policies defined in Section 3.2, the certificates issued to
regular airline employees will contain the object identifier regular airline employees will contain the object identifier
for certificate policy for the General-Purpose policy. The for certificate policy for the General-Purpose policy. The
certificates issued to the employees with disbursement certificates issued to the employees with disbursement
authority will contain the object identifiers for both the authority will contain the object identifiers for both the
General-Purpose policy and the Commercial-Grade policy. The General-Purpose policy and the Commercial-Grade policy. The
Certificate Policies field may also optionally convey qualifier Certificate Policies field may also optionally convey qualifier
values for each identified policy; use of qualifiers is values for each identified policy; use of qualifiers is
discussed in Section 3.4. discussed in Section 3.4.
The non-critical Certificate Policies field is designed to be The non-critical Certificate Policies field is designed to be
used by applications as follows. Each application is pre- used by applications as follows. Each application is pre-
configured to know what policy it requires. Using the example configured to know what policy it requires. Using the example
in Section 3.2, electronic mail applications and Web servers in Section 3.2, electronic mail applications and Web servers
will be configured to require the General-Purpose policy. will be configured to require the General-Purpose policy.
However, an airline's financial applications will be configured However, an airline's financial applications will be configured
to require the Commercial-Grade policy for validating financial to require the Commercial-Grade policy for validating financial
transactions over a certain dollar value. transactions over a certain dollar value.
When processing a certification path, a certificate policy that When processing a certification path, a certificate policy that
is acceptable to the certificate-using application must be is acceptable to the certificate-using application must be
present in every certificate in the path, i.e., in CA- present in every certificate in the path, i.e., in CA-
certificates as well as end entity certificates. certificates as well as end entity certificates.
If the Certificate Policies field is flagged critical, it If the Certificate Policies field is flagged critical, it
serves the same purpose as described above but also has an serves the same purpose as described above but also has an
additional role. It indicates that the use of the certificate additional role. It indicates that the use of the certificate
is restricted to one of the identified policies, i.e., the is restricted to one of the identified policies, i.e., the
certification authority is declaring that the certificate must certification authority is declaring that the certificate must
only be used in accordance with the provisions of one of the only be used in accordance with the provisions of one of the
listed certificate policies. This field is intended to protect listed certificate policies. This field is intended to protect
the certification authority against damage claims by a relying the certification authority against damage claims by a relying
party who has used the certificate for an inappropriate purpose party who has used the certificate for an inappropriate purpose
or in an inappropriate manner, as stipulated in the applicable or in an inappropriate manner, as stipulated in the applicable
certificate policy definition. certificate policy definition.
For example, the Internal Revenue Service might issue For example, the Internal Revenue Service might issue
certificates to taxpayers for the purpose of protecting tax certificates to taxpayers for the purpose of protecting tax
filings. The Internal Revenue Service understands and can filings. The Internal Revenue Service understands and can
accommodate the risks of accidentally issuing a bad accommodate the risks of accidentally issuing a bad
certificate, e.g., to a wrongly-authenticated person. However, certificate, e.g., to a wrongly- authenticated person.
suppose someone used an Internal Revenue Service tax-filing However, suppose someone used an Internal Revenue Service tax-
certificate as the basis for encrypting multi-million-dollar- filing certificate as the basis for encrypting multi-million-
value proprietary secrets which subsequently fell into the dollar-value proprietary secrets which subsequently fell into
wrong hands because of an error in issuing the Internal Revenue the wrong hands because of an error in issuing the Internal
Service certificate. The Internal Revenue Service may want to Revenue Service certificate. The Internal Revenue Service may
protect itself against claims for damages in such want to protect itself against claims for damages in such
circumstances. The critical-flagged Certificate Policies circumstances. The critical-flagged Certificate Policies
extension is intended to mitigate the risk to the certificate extension is intended to mitigate the risk to the certificate
issuer in such situations. issuer in such situations.
3.3.2 Policy Mappings Extension 3.3.2 Policy Mappings Extension
The Policy Mappings extension may only be used in CA- The Policy Mappings extension may only be used in CA-
certificates. This field allows a certification authority to certificates. This field allows a certification authority to
indicate that certain policies in its own domain can be indicate that certain policies in its own domain can be
considered equivalent to certain other policies in the subject considered equivalent to certain other policies in the subject
certification authority's domain. certification authority's domain.
For example, suppose the ACE Corporation establishes an For example, suppose the ACE Corporation establishes an
agreement with the ABC Corporation to cross-certify each agreement with the ABC Corporation to cross-certify each
others' public-key infrastructures for the purposes of mutually others' public-key infrastructures for the purposes of mutually
protecting electronic data interchange (EDI). Further, suppose protecting electronic data interchange (EDI). Further, suppose
that both companies have pre-existing financial transaction that both companies have pre-existing financial transaction
protection policies called ace-e-commerce and abc-e-commerce, protection policies called ace-e- commerce and abc-e-commerce,
respectively. One can see that simply generating cross respectively. One can see that simply generating cross
certificates between the two domains will not provide the certificates between the two domains will not provide the
necessary interoperability, as the two companies' applications necessary interoperability, as the two companies' applications
are configured with and employee certificates are populated are configured with and employee certificates are populated
with their respective certificate policies. One possible with their respective certificate policies. One possible
solution is to reconfigure all of the financial applications to solution is to reconfigure all of the financial applications to
require either policy and to reissue all the certificates with require either policy and to reissue all the certificates with
both policies. Another solution, which may be easier to both policies. Another solution, which may be easier to
administer, uses the Policy Mapping field. If this field is administer, uses the Policy Mapping field. If this field is
included in a cross-certificate for the ABC Corporation included in a cross-certificate for the ABC Corporation
certification authority issued by the ACE Corporation certification authority issued by the ACE Corporation
certification authority, it can provide a statement that the certification authority, it can provide a statement that the
ABC's financial transaction protection policy (i.e., abc-e- ABC's financial transaction protection policy (i.e., abc-e-
commerce) can be considered equivalent to that of the ACE commerce) can be considered equivalent to that of the ACE
Corporation (i.e., ace-e-commerce). Corporation (i.e., ace-e-commerce).
3.3.3 Policy Constraints Extension 3.3.3 Policy Constraints Extension
The Policy Constraints extension supports two optional The Policy Constraints extension supports two optional
features. The first is the ability for a certification features. The first is the ability for a certification
authority to require that explicit certificate policy authority to require that explicit certificate policy
indications be present in all subsequent certificates in a indications be present in all subsequent certificates in a
certification path. Certificates at the start of a certification path. Certificates at the start of a
certification path may be considered by a certificate user to certification path may be considered by a certificate user to
be part of a trusted domain, i.e., certification authorities be part of a trusted domain, i.e., certification authorities
are trusted for all purposes so no particular certificate are trusted for all purposes so no particular certificate
policy is needed in the Certificate Policies extension. Such policy is needed in the Certificate Policies extension. Such
certificates need not contain explicit indications of certificates need not contain explicit indications of
certificate policy. However, when a certification authority in certificate policy. However, when a certification authority in
the trusted domain certifies outside the domain, it can the trusted domain certifies outside the domain, it can
activate the requirement for explicit certificate policy in activate the requirement for explicit certificate policy in
subsequent certificates in the certification path. subsequent certificates in the certification path.
The other optional feature in the Policy Constraints field is The other optional feature in the Policy Constraints field is
the ability for a certification authority to disable policy the ability for a certification authority to disable policy
mapping by subsequent certification authorities in a mapping by subsequent certification authorities in a
certification path. It may be prudent to disable policy certification path. It may be prudent to disable policy
mapping when certifying outside the domain. This can assist in mapping when certifying outside the domain. This can assist in
controlling risks due to transitive trust, e.g., a domain A controlling risks due to transitive trust, e.g., a domain A
trusts domain B, domain B trusts domain C, but domain A does trusts domain B, domain B trusts domain C, but domain A does
not want to be forced to trust domain C. not want to be forced to trust domain C.
3.4 POLICY QUALIFIERS 3.4 POLICY QUALIFIERS
The Certificate Policies extension field has a provision for The Certificate Policies extension field has a provision for
conveying, along with each certificate policy identifier, conveying, along with each certificate policy identifier,
additional policy-dependent information in a qualifier field. The additional policy-dependent information in a qualifier field. The
X.509 standard does not mandate the purpose for which this field 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. is to be used, nor does it prescribe the syntax for this field.
Policy qualifier types can be registered by any organization. Policy qualifier types can be registered by any organization.
The following policy qualifier types are defined in PKIX Part I The following policy qualifier types are defined in PKIX Part I
[PKI1]: [PKI1]:
(a) The CPS Pointer qualifier contains a pointer to a (a) The CPS Pointer qualifier contains a pointer to a
Certification Practice Statement (CPS) published by the CA. Certification Practice Statement (CPS) published by the CA.
The pointer is in the form of a uniform resource identifier The pointer is in the form of a uniform resource identifier
(URI). (URI).
(b) The User Notice qualifier contains a text string that is to (b) The User Notice qualifier contains a text string that is to
be displayed to a certificate user (including subscribers and be displayed to a certificate user (including subscribers and
relying parties) prior to the use of the certificate. The text relying parties) prior to the use of the certificate. The text
string may be an IA5String or a BMPString - a subset of the ISO 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 100646-1 multiple octet coded character set. A CA may invoke a
procedure that requires that the certficate user acknowledge procedure that requires that the certficate user acknowledge
that the applicable terms and conditions have been disclosed or that the applicable terms and conditions have been disclosed or
accepted. accepted.
Policy qualifiers can be used to support the definition of Policy qualifiers can be used to support the definition of
generic, or parameterized, certificate policy definitions. generic, or parameterized, certificate policy definitions.
Provided the base certificate policy definition so provides, Provided the base certificate policy definition so provides,
policy qualifier types can be defined to convey, on a per- policy qualifier types can be defined to convey, on a per-
certificate basis, additional specific policy details that fill in certificate basis, additional specific policy details that fill in
the generic definition. the generic definition.
3.5 CERTIFICATION PRACTICE STATEMENT 3.5 CERTIFICATION PRACTICE STATEMENT
The term certification practice statement (CPS) is defined by the The term certification practice statement (CPS) is defined by the
ABA Guidelines as: "A statement of the practices which a ABA Guidelines as: "A statement of the practices which a
certification authority employs in issuing certificates." [ABA1] certification authority employs in issuing certificates." [ABA1]
In the 1995 draft of the ABA guidelines, the ABA expands this In the 1995 draft of the ABA guidelines, the ABA expands this
definition with the following comments: definition with the following comments:
A certification practice statement may take the form of a A certification practice statement may take the form of a
declaration by the certification authority of the details of declaration by the certification authority of the details of
its trustworthy system and the practices it employs in its its trustworthy system and the practices it employs in its
operations and in support of issuance of a certificate, or it operations and in support of issuance of a certificate, or it
may be a statute or regulation applicable to the certification may be a statute or regulation applicable to the certification
authority and covering similar subject matter. It may also be authority and covering similar subject matter. It may also be
part of the contract between the certification authority and part of the contract between the certification authority and
the subscriber. A certification practice statement may also be the subscriber. A certification practice statement may also be
comprised of multiple documents, a combination of public law, comprised of multiple documents, a combination of public law,
private contract, and/or declaration. private contract, and/or declaration.
Certain forms for legally implementing certification practice Certain forms for legally implementing certification practice
statements lend themselves to particular relationships. For statements lend themselves to particular relationships. For
example, when the legal relationship between a certification example, when the legal relationship between a certification
authority and subscriber is consensual, a contract would authority and subscriber is consensual, a contract would
ordinarily be the means of giving effect to a certification ordinarily be the means of giving effect to a certification
practice statement. The certification authority's duties to a practice statement. The certification authority's duties to a
relying person are generally based on the certification relying person are generally based on the certification
authority's representations, which may include a certification authority's representations, which may include a certification
practice statement. practice statement.
Whether a certification practice statement is binding on a Whether a certification practice statement is binding on a
relying person depends on whether the relying person has relying person depends on whether the relying person has
knowledge or notice of the certification practice statement. A knowledge or notice of the certification practice statement. A
relying person has knowledge or at least notice of the contents relying person has knowledge or at least notice of the contents
of the certificate used by the relying person to verify a of the certificate used by the relying person to verify a
digital signature, including documents incorporated into the digital signature, including documents incorporated into the
certificate by reference. It is therefore advisable to certificate by reference. It is therefore advisable to
incorporate a certification practice statement into a incorporate a certification practice statement into a
certificate by reference. certificate by reference.
As much as possible, a certification practice statement should As much as possible, a certification practice statement should
indicate any of the widely recognized standards to which the indicate any of the widely recognized standards to which the
certification authority's practices conform. Reference to certification authority's practices conform. Reference to
widely recognized standards may indicate concisely the widely recognized standards may indicate concisely the
suitability of the certification authority's practices for suitability of the certification authority's practices for
another person's purposes, as well as the potential another person's purposes, as well as the potential
technological compatibility of the certificates issued by the technological compatibility of the certificates issued by the
certification authority with repositories and other systems. certification authority with repositories and other systems.
3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION 3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION
PRACTICE STATEMENT PRACTICE STATEMENT
The concepts of certificate policy and CPS come from different The concepts of certificate policy and CPS come from different
sources and were developed for different reasons. However, their sources and were developed for different reasons. However, their
interrelationship is important. interrelationship is important.
A certification practice statement is a detailed statement by a A certification practice statement is a detailed statement by a
certification authority as to its practices, that potentially certification authority as to its practices, that potentially
needs to be understood and consulted by subscribers and needs to be understood and consulted by subscribers and
certificate users (relying parties). Although the level of detail certificate users (relying parties). Although the level of detail
may vary among CPSs, they will generally be more detailed than may vary among CPSs, they will generally be more detailed than
certificate policy definitions. Indeed, CPSs may be quite certificate policy definitions. Indeed, CPSs may be quite
comprehensive, robust documents providing a description of the comprehensive, robust documents providing a description of the
precise service offerings, detailed procedures of the life-cycle precise service offerings, detailed procedures of the life- cycle
management of certificates, and more - a level of detail which management of certificates, and more - a level of detail which
weds the CPS to a particular (proprietary) implementation of a weds the CPS to a particular (proprietary) implementation of a
service offering. service offering.
Although such detail may be indispensable to adequately disclose, Although such detail may be indispensable to adequately disclose,
and to make a full assessment of trustworthiness in the absence of and to make a full assessment of trustworthiness in the absence of
accreditation or other recognized quality metrics, a detailed CPS accreditation or other recognized quality metrics, a detailed CPS
does not form a suitable basis for interoperability between CAs does not form a suitable basis for interoperability between CAs
operated by different organizations. Rather, certificate policies operated by different organizations. Rather, certificate policies
best serve as the vehicle on which to base common interoperability best serve as the vehicle on which to base common interoperability
standards and common assurance criteria on an industry-wide (or standards and common assurance criteria on an industry-wide (or
possibly more global) basis. A CA with a single CPS may support possibly more global) basis. A CA with a single CPS may support
multiple certificate policies (used for different application multiple certificate policies (used for different application
purposes and/or by different certificate user communities). Also, purposes and/or by different certificate user communities). Also,
multiple different CAs, with non-identical certification practice multiple different CAs, with non-identical certification practice
statements, may support the same certificate policy. statements, may support the same certificate policy.
For example, the Federal Government might define a government-wide For example, the Federal Government might define a government-wide
certificate policy for handling confidential human resources certificate policy for handling confidential human resources
information. The certificate policy definition will be a broad information. The certificate policy definition will be a broad
statement of the general characteristics of that certificate statement of the general characteristics of that certificate
policy, and an indication of the types of applications for which policy, and an indication of the types of applications for which
it is suitable for use. Different departments or agencies that it is suitable for use. Different departments or agencies that
operate certification authorities with different certification operate certification authorities with different certification
practice statements might support this certificate policy. At the practice statements might support this certificate policy. At the
same time, such certification authorities may support other same time, such certification authorities may support other
certificate policies. certificate policies.
The main difference between certificate policy and CPS can The main difference between certificate policy and CPS can
therefore be summarized as follows: therefore be summarized as follows:
(a) Most organizations that operate public or inter- (a) Most organizations that operate public or inter-
organizational certification authorities will document their organizational certification authorities will document their
own practices in CPSs or similar statements. The CPS is one of own practices in CPSs or similar statements. The CPS is one of
the organization's means of protecting itself and positioning the organization's means of protecting itself and positioning
its business relationships with subscribers and other entities. its business relationships with subscribers and other entities.
(b) There is strong incentive, on the other hand, for a (b) There is strong incentive, on the other hand, for a
certificate policy to apply more broadly than to just a single certificate policy to apply more broadly than to just a single
organization. If a particular certificate policy is widely organization. If a particular certificate policy is widely
recognized and imitated, it has great potential as the basis of recognized and imitated, it has great potential as the basis of
automated certificate acceptance in many systems, including automated certificate acceptance in many systems, including
unmanned systems and systems that are manned by people not unmanned systems and systems that are manned by people not
independently empowered to determine the acceptability of independently empowered to determine the acceptability of
different presented certificates. different presented certificates.
In addition to populating the certificate policies field with the In addition to populating the certificate policies field with the
certificate policy identifier, a certification authority may certificate policy identifier, a certification authority may
include, in certificates it issues, a reference to its include, in certificates it issues, a reference to its
certification practice statement. A standard way to do this, certification practice statement. A standard way to do this,
using a certificate policy qualifier, is described in Section 3.4. using a certificate policy qualifier, is described in Section 3.4.
3.7 SET OF PROVISIONS 3.7 SET OF PROVISIONS
A set of provisions is a collection of practice and/or policy A set of provisions is a collection of practice and/or policy
statements, spanning a range of standard topics, for use in statements, spanning a range of standard topics, for use in
expressing a certificate policy definition or CPS employing the expressing a certificate policy definition or CPS employing the
approach described in this framework. approach described in this framework.
A certificate policy can be expressed as a single set of A certificate policy can be expressed as a single set of
provisions. provisions.
A CPS can be expressed as a single set of provisions with each A CPS can be expressed as a single set of provisions with each
component addressing the requirements of one or more certificate component addressing the requirements of one or more certificate
policies, or, alternatively, as an organized collection of sets of policies, or, alternatively, as an organized collection of sets of
provisions. For example, a CPS could be expressed as a provisions. For example, a CPS could be expressed as a
combination of the following: combination of the following:
(a) a list of certificate policies supported by the CPS; (a) a list of certificate policies supported by the CPS;
(b) for each certificate policy in (a), a set of provisions (b) for each certificate policy in (a), a set of provisions
which contains statements that refine that certificate policy which contains statements that refine that certificate policy
by filling in details not stipulated in that policy or by filling in details not stipulated in that policy or
expressly left to the discretion of the CPS by that certificate expressly left to the discretion of the CPS by that certificate
policy; such statements serve to state how this particular CPS policy; such statements serve to state how this particular CPS
implements the requirements of the particular certificate implements the requirements of the particular certificate
policy; policy;
(c) a set of provisions that contains statements regarding the (c) a set of provisions that contains statements regarding the
certification practices on the CA, regardless of certificate certification practices on the CA, regardless of certificate
policy. policy.
The statements provided in (b) and (c) may augment or refine the The statements provided in (b) and (c) may augment or refine the
stipulations of the applicable certificate policy definition, but stipulations of the applicable certificate policy definition, but
must not conflict with any of the stipulations of such certificate must not conflict with any of the stipulations of such certificate
policy definition. policy definition.
This framework outlines the contents of a set of provisions, in This framework outlines the contents of a set of provisions, in
terms of eight primary components, as follows: terms of eight primary components, as follows:
* Introduction; * Introduction;
* General Provisions; * General Provisions;
* Identification and Authentication; * Identification and Authentication;
* Operational Requirements; * Operational Requirements;
* Physical, Procedural, and Personnel Security Controls; * Physical, Procedural, and Personnel Security Controls;
* Technical Security Controls; * Technical Security Controls;
* Certificate and CRL Profile; and * Certificate and CRL Profile; and
* Specification Administration. * Specification Administration.
Components can be further divided into subcomponents, and a Components can be further divided into subcomponents, and a
subcomponent may comprise multiple elements. Section 4 provides a subcomponent may comprise multiple elements. Section 4 provides a
more detailed description of the contents of the above components, more detailed description of the contents of the above components,
and their subcomponents. and their subcomponents.
4. CONTENTS OF A SET OF PROVISIONS 4. CONTENTS OF A SET OF PROVISIONS
This section expands upon the contents of a set of provisions, as This section expands upon the contents of a set of provisions, as
introduced in Section 3.7. The topics identified in this section introduced in Section 3.7. The topics identified in this section
are, consequently, candidate topics for inclusion in a certificate are, consequently, candidate topics for inclusion in a certificate
policy definition or CPS. policy definition or CPS.
While many topics are identified, it is not necessary for a While many topics are identified, it is not necessary for a
certificate policy or a CPS to include a concrete statement for every certificate policy or a CPS to include a concrete statement for every
such topic. Rather, a particular certificate policy or CPS may such topic. Rather, a particular certificate policy or CPS may
state "no stipulation" for a component, subcomponent, or element on state "no stipulation" for a component, subcomponent, or element on
which the particular certificate policy or CPS imposes no which the particular certificate policy or CPS imposes no
requirements. In this sense, the list of topics can be considered a requirements. In this sense, the list of topics can be considered a
checklist of topics for consideration by the certificate policy or checklist of topics for consideration by the certificate policy or
CPS writer. It is recommended that each and every component and CPS writer. It is recommended that each and every component and
subcomponent be included in a certificate policy or CPS, even if subcomponent be included in a certificate policy or CPS, even if
there is "no stipulation"; this will indicate to the reader that a there is "no stipulation"; this will indicate to the reader that a
conscious decision was made to include or exclude that topic. This conscious decision was made to include or exclude that topic. This
protects against inadvertent omission of a topic, while facilitating protects against inadvertent omission of a topic, while facilitating
comparison of different certificate policies or CPSs, e.g., when comparison of different certificate policies or CPSs, e.g., when
making policy mapping decisions. making policy mapping decisions.
In a certificate policy definition, it is possible to leave certain In a certificate policy definition, it is possible to leave certain
components, subcomponents, and/or elements unspecified, and to components, subcomponents, and/or elements unspecified, and to
stipulate that the required information will be indicated in a policy stipulate that the required information will be indicated in a policy
qualifier. Such certificate policy definitions can be considered qualifier. Such certificate policy definitions can be considered
parameterized definitions. The set of provisions should reference or parameterized definitions. The set of provisions should reference or
define the required policy qualifier types and should specify any define the required policy qualifier types and should specify any
applicable default values. applicable default values.
4.1 INTRODUCTION 4.1 INTRODUCTION
This component identifies and introduces the set of provisions, This component identifies and introduces the set of provisions,
and indicates the types of entities and applications for which the and indicates the types of entities and applications for which the
specification is targeted. specification is targeted.
This component has the following subcomponents: This component has the following subcomponents:
* Overview; * Overview;
* Identification; * Identification;
* Community and Applicability; and * Community and Applicability; and
skipping to change at page 14, line 36 skipping to change at page 14, line 36
specification. specification.
4.1.2 Identification 4.1.2 Identification
This subcomponent provides any applicable names or other This subcomponent provides any applicable names or other
identifiers, including ASN.1 object identifiers, for the set of identifiers, including ASN.1 object identifiers, for the set of
provisions. provisions.
4.1.3 Community and Applicability 4.1.3 Community and Applicability
This subcomponent describes the types of entities that issue This subcomponent describes the types of entities that issue
certificates or that are certified as subject CAs (2, 3), the certificates or that are certified as subject CAs (2, 3), the
types of entities that perform RA functions (4), and the types types of entities that perform RA functions (4), and the types
of entities that are certified as subject end entities or of entities that are certified as subject end entities or
subscribers. (5, 6) subscribers. (5, 6)
This subcomponent also contains: This subcomponent also contains:
* A list of applications for which the issued certificates * A list of applications for which the issued certificates
are suitable. are suitable. (Examples of application in this case are:
electronic mail, retail transactions, contracts, travel
order, etc.)
* A list of applications for which use of the issued * A list of applications for which use of the issued
certificates is restricted. (This list implicitly prohibits certificates is restricted. (This list implicitly prohibits
all other uses for the certificates.) all other uses for the certificates.)
* A list of applications for which use of the issued * A list of applications for which use of the issued
certificates is prohibited. certificates is prohibited.
4.1.4 Contact Details 4.1.4 Contact Details
This subcomponent includes the name and mailing address of the This subcomponent includes the name and mailing address of the
authority that is responsible for the registration, authority that is responsible for the registration,
maintenance, and interpretation of this certificate policy or maintenance, and interpretation of this certificate policy or
CPS. It also includes the name, electronic mail address, CPS. It also includes the name, electronic mail address,
telephone number, and fax number of a contact person. telephone number, and fax number of a contact person.
4.2 GENERAL PROVISIONS 4.2 GENERAL PROVISIONS
This component specifies any applicable presumptions on a range of This component specifies any applicable presumptions on a range of
legal and general practices topics. legal and general practices topics.
This component contains the following subcomponents: This component contains the following subcomponents:
* Obligations; * Obligations;
skipping to change at page 15, line 41 skipping to change at page 15, line 41
* Publication and Repositories; * Publication and Repositories;
* Compliance Audit; * Compliance Audit;
* Confidentiality; and * Confidentiality; and
* Intellectual Property Rights. * Intellectual Property Rights.
Each subcomponent may need to separately state provisions applying Each subcomponent may need to separately state provisions applying
to the entity types: CA, repository, RA, subscriber, and relying to the entity types: CA, repository, RA, subscriber, and relying
party. (Specific provisions regarding subscribers and relying party. (Specific provisions regarding subscribers and relying
parties are only applicable in the Liability and Obligations parties are only applicable in the Liability and Obligations
subcomponents.) subcomponents.)
4.2.1 Obligations 4.2.1 Obligations
This subcomponent contains, for each entity type, any This subcomponent contains, for each entity type, any
applicable provisions regarding the entity's obligations to applicable provisions regarding the entity's obligations to
other entities. Such provisions may include: other entities. Such provisions may include:
* CA and/or RA obligations: * CA and/or RA obligations:
* Notification of issuance of a certificate to the * Notification of issuance of a certificate to the
subscriber who is the subject of the certificate being subscriber who is the subject of the certificate being
issued; issued;
* Notification of issuance of a certificate to others * Notification of issuance of a certificate to others
than the subject of the certificate; than the subject of the certificate;
* Notification of revocation or suspension of a * Notification of revocation or suspension of a
certificate to the subscriber whose certificate is being certificate to the subscriber whose certificate is being
revoked or suspended; and revoked or suspended; and
* Notification of revocation or suspension of a * Notification of revocation or suspension of a
certificate to others than the subject whose certificate certificate to others than the subject whose certificate
is being revoked or suspended. is being revoked or suspended.
* Subscriber obligations: * Subscriber obligations:
* Accuracy of representations in certificate application; * Accuracy of representations in certificate application;
* Protection of the entity's private key; * Protection of the entity's private key;
* Restrictions on private key and certificate use; and * Restrictions on private key and certificate use; and
* Notification upon private key compromise. * Notification upon private key compromise.
* Relying party obligations: * Relying party obligations:
* Purposes for which certificate is used; * Purposes for which certificate is used;
* Digital signature verification responsibilities; * Digital signature verification responsibilities;
* Revocation and suspension checking responsibilities; * Revocation and suspension checking responsibilities;
and and
* Acknowledgment of applicable liability caps and * Acknowledgment of applicable liability caps and
warranties. warranties.
* Repository obligations * Repository obligations
* Timely publication of certificates and revocation * Timely publication of certificates and revocation
information information
4.2.2 Liability 4.2.2 Liability
This subcomponent contains, for each entity type, any This subcomponent contains, for each entity type, any
applicable provisions regarding apportionment of liability, applicable provisions regarding apportionment of liability,
such as: such as:
* Warranties and limitations on warranties; * Warranties and limitations on warranties;
* Kinds of damages covered (e.g., indirect, special, * Kinds of damages covered (e.g., indirect, special,
consequential, incidental, punitive, liquidated damages, consequential, incidental, punitive, liquidated damages,
negligence and fraud) and disclaimers; negligence and fraud) and disclaimers;
* Loss limitations (caps) per certificate or per * Loss limitations (caps) per certificate or per
transaction; and transaction; and
* Other exclusions (e.g., Acts of God, other party * Other exclusions (e.g., Acts of God, other party
responsibilities). responsibilities).
4.2.3 Financial Responsibility 4.2.3 Financial Responsibility
This subcomponent contains, for CAs, repository, and RAs, any This subcomponent contains, for CAs, repository, and RAs, any
applicable provisions regarding financial responsibilities, applicable provisions regarding financial responsibilities,
such as: such as:
* Indemnification of CA and/or RA by relying parties; * Indemnification of CA and/or RA by relying parties;
* Fiduciary relationships (or lack thereof) between the * Fiduciary relationships (or lack thereof) between the
various entities; and various entities; and
* Administrative processes (e.g., accounting, audit). * Administrative processes (e.g., accounting, audit).
4.2.4 Interpretation and Enforcement 4.2.4 Interpretation and Enforcement
This subcomponent contains any applicable provisions regarding This subcomponent contains any applicable provisions regarding
interpretation and enforcement of the certificate policy or interpretation and enforcement of the certificate policy or
CPS, addressing such topics as: CPS, addressing such topics as:
* Governing law; * Governing law;
* Severability of provisions, survival, merger, and notice; * Severability of provisions, survival, merger, and notice;
and and
* Dispute resolution procedures. * Dispute resolution procedures.
4.2.5 Fees 4.2.5 Fees
This subcomponent contains any applicable provisions regarding This subcomponent contains any applicable provisions regarding
fees charged by CAs, repositories, or RAs, such as: fees charged by CAs, repositories, or RAs, such as:
* Certificate issuance or renewal fees; * Certificate issuance or renewal fees;
* Certificate access fee; * Certificate access fee;
* Revocation or status information access fee; * Revocation or status information access fee;
* Fees for other services such as policy information; and * Fees for other services such as policy information; and
* Refund policy. * Refund policy.
4.2.6 Publication and Repositories 4.2.6 Publication and Repositories
This subcomponent contains any applicable provisions regarding: This subcomponent contains any applicable provisions regarding:
* A CA's obligations to publish information regarding its * A CA's obligations to publish information regarding its
practices, its certificates, and the current status of such practices, its certificates, and the current status of such
certificates; certificates;
* Frequency of publication; * Frequency of publication;
* Access control on published information objects including * Access control on published information objects including
certificate policy definitions, CPS, certificates, certificate policy definitions, CPS, certificates,
certificate status, and CRLs; and certificate status, and CRLs; and
* Requirements pertaining to the use of repositories * Requirements pertaining to the use of repositories
operated by CAs or by other independent parties. operated by CAs or by other independent parties.
4.2.7 Compliance Audit 4.2.7 Compliance Audit
This subcomponent addresses the following: This subcomponent addresses the following:
* Frequency of compliance audit for each entity; * Frequency of compliance audit for each entity;
* Identity of the auditor; * Identity/qualifictions of the auditor;
* Auditor's relationship to the entity being audited; (30) * Auditor's relationship to the entity being audited; (30)
* List of topics covered under the compliance audit; (31) * List of topics covered under the compliance audit; (31)
* Actions taken as a result of a deficiency found during * Actions taken as a result of a deficiency found during
compliance audit; (32) compliance audit; (32)
* Compliance audit results: who they are shared with (e.g., * Compliance audit results: who they are shared with (e.g.,
subject CA, RA, and/or end entities), who provides them subject CA, RA, and/or end entities), who provides them
(e.g., entity being audited or auditor), how they are (e.g., entity being audited or auditor), how they are
communicated. communicated.
4.2.8 Confidentiality Policy 4.2.8 Confidentiality Policy
This subcomponent addresses the following: This subcomponent addresses the following:
* Types of information that must be kept confidential by CA * Types of information that must be kept confidential by CA
or RA; or RA;
* Types of information that are not considered confidential; * Types of information that are not considered confidential;
* Who is entitled to be informed of reasons for revocation * Who is entitled to be informed of reasons for revocation
and suspension of certificates; and suspension of certificates;
* Policy on release of information to law enforcement * Policy on release of information to law enforcement
officials; officials;
* Information that can be revealed as part of civil * Information that can be revealed as part of civil
discovery; discovery;
* Conditions upon which CA or RA may disclose upon owner's * Conditions upon which CA or RA may disclose upon owner's
request; and request; and
* Any other circumstances under which confidential * Any other circumstances under which confidential
information may be disclosed. information may be disclosed.
4.2.9 Intellectual Property Rights 4.2.9 Intellectual Property Rights
This subcomponent addresses ownership rights of certificates, This subcomponent addresses ownership rights of certificates,
practice/policy specifications, names, and keys. practice/policy specifications, names, and keys.
4.3 IDENTIFICATION AND AUTHENTICATION 4.3 IDENTIFICATION AND AUTHENTICATION
This component describes the procedures used to authenticate a This component describes the procedures used to authenticate a
certificate applicant to a CA or RA prior to certificate issuance. certificate applicant to a CA or RA prior to certificate issuance.
It also describes how parties requesting rekey or revocation are It also describes how parties requesting rekey or revocation are
authenticated. This component also addresses naming practices, authenticated. This component also addresses naming practices,
including name ownership recognition and name dispute resolution. including name ownership recognition and name dispute resolution.
This component has the following subcomponents: This component has the following subcomponents:
* Initial Registration; * Initial Registration;
* Routine Rekey; * Routine Rekey;
* Rekey After Revocation; and * Rekey After Revocation; and
* Revocation Request. * Revocation Request.
4.3.1 Initial Registration 4.3.1 Initial Registration
This subcomponent includes the following elements regarding This subcomponent includes the following elements regarding
identification and authentication procedures during entity identification and authentication procedures during entity
registration or certificate issuance: registration or certificate issuance:
* Types of names assigned to the subject (7); * Types of names assigned to the subject (7);
* Whether names have to be meaningful or not (8); * Whether names have to be meaningful or not (8);
* Rules for interpreting various name forms; * Rules for interpreting various name forms;
* Whether names have to be unique; * Whether names have to be unique;
* How name claim disputes are resolved; * How name claim disputes are resolved;
* Recognition, authentication, and role of trademarks; * Recognition, authentication, and role of trademarks;
* If and how the subject must prove possession of the * If and how the subject must prove possession of the
companion private key for the public key being registered companion private key for the public key being registered
(9); (9);
* Authentication requirements for organizational identity of * Authentication requirements for organizational identity of
subject (CA, RA, or end entity) (10); subject (CA, RA, or end entity) (10);
* Authentication requirements for a person acting on behalf * Authentication requirements for a person acting on behalf
of a subject (CA, RA, or end entity) (11), including: of a subject (CA, RA, or end entity) (11), including:
* Number of pieces of identification required; * Number of pieces of identification required;
* How a CA or RA validates the pieces of identification * How a CA or RA validates the pieces of identification
provided; provided;
* If the individual must present personally to the * If the individual must present personally to the
authenticating CA or RA; authenticating CA or RA;
* How an individual as an organizational person is * How an individual as an organizational person is
authenticated (12). authenticated (12).
4.3.2 Routine Rekey 4.3.2 Routine Rekey
This subcomponent describes the identification and This subcomponent describes the identification and
authentication procedures for routine rekey for each subject authentication procedures for routine rekey for each subject
type (CA, RA, and end entity). (13) type (CA, RA, and end entity). (13)
4.3.3 Rekey After Revocation -- No Key Compromise 4.3.3 Rekey After Revocation -- No Key Compromise
This subcomponent describes the identification and This subcomponent describes the identification and
authentication procedures for rekey for each subject type (CA, authentication procedures for rekey for each subject type (CA,
RA, and end entity) after the subject certificate has been RA, and end entity) after the subject certificate has been
revoked. (14) revoked. (14)
4.3.4 Revocation Request 4.3.4 Revocation Request
This subcomponent describes the identification and This subcomponent describes the identification and
authentication procedures for a revocation request by each authentication procedures for a revocation request by each
subject type (CA, RA, and end entity). (16) subject type (CA, RA, and end entity). (16)
4.4 OPERATIONAL REQUIREMENTS 4.4 OPERATIONAL REQUIREMENTS
This component is used to specify requirements imposed upon This component is used to specify requirements imposed upon
issuing CA, subject CAs, RAs, or end entities with respect to issuing CA, subject CAs, RAs, or end entities with respect to
various operational activities. various operational activities.
This component consists of the following subcomponents: This component consists of the following subcomponents:
* Certificate Application; * Certificate Application;
* Certificate Issuance; * Certificate Issuance;
* Certificate Acceptance; * Certificate Acceptance;
skipping to change at page 21, line 44 skipping to change at page 21, line 44
* Security Audit Procedures; * Security Audit Procedures;
* Records Archival; * Records Archival;
* Key Changeover; * Key Changeover;
* Compromise and Disaster Recovery; and * Compromise and Disaster Recovery; and
* CA Termination. * CA Termination.
Within each subcomponent, separate consideration may need to be Within each subcomponent, separate consideration may need to be
given to issuing CA, repository, subject CAs, RAs, and end given to issuing CA, repository, subject CAs, RAs, and end
entities. entities.
4.4.1 Certificate Application 4.4.1 Certificate Application
This subcomponent is used to state requirements regarding This subcomponent is used to state requirements regarding
subject enrollment and request for certificate issuance. subject enrollment and request for certificate issuance.
4.4.2 Certificate Issuance 4.4.2 Certificate Issuance
This subcomponent is used to state requirements regarding This subcomponent is used to state requirements regarding
issuance of a certificate and notification to the applicant of issuance of a certificate and notification to the applicant of
such issuance. such issuance.
4.4.3 Certificate Acceptance 4.4.3 Certificate Acceptance
This subcomponent is used to state requirements regarding This subcomponent is used to state requirements regarding
acceptance of an issued certificate and for consequent acceptance of an issued certificate and for consequent
publication of certificates. publication of certificates.
4.4.4 Certificate Suspension and Revocation 4.4.4 Certificate Suspension and Revocation
This subcomponent addresses the following: This subcomponent addresses the following:
* Circumstances under which a certificate may be revoked; * Circumstances under which a certificate may be revoked;
* Who can request the revocation of the entity certificate; * Who can request the revocation of the entity certificate;
skipping to change at page 22, line 48 skipping to change at page 22, line 48
* Procedures to request certificate suspension; * Procedures to request certificate suspension;
* How long the suspension may last; * How long the suspension may last;
* If a CRL mechanism is used, the issuance frequency; * If a CRL mechanism is used, the issuance frequency;
* Requirements on relying parties to check CRLs; * Requirements on relying parties to check CRLs;
* On-line revocation/status checking availability; * On-line revocation/status checking availability;
* Requirements on relying parties to perform on-line * Requirements on relying parties to perform on-line
revocation/status checks; revocation/status checks;
* Other forms of revocation advertisements available; and * Other forms of revocation advertisements available; and
* Requirements on relying parties to check other forms of * Requirements on relying parties to check other forms of
revocation advertisements. revocation advertisements.
* Any variations on the above stipulations when the * Any variations on the above stipulations when the
suspension or revocation is the result of private key suspension or revocation is the result of private key
compromise (as opposed to other reasons for suspension or compromise (as opposed to other reasons for suspension or
revocation). revocation).
4.4.5 Security Audit Procedures 4.4.5 Security Audit Procedures
This subcomponent is used to describe event logging and audit This subcomponent is used to describe event logging and audit
systems, implemented for the purpose of maintaining a secure systems, implemented for the purpose of maintaining a secure
environment. Elements include the following: environment. Elements include the following:
* Types of events recorded; (28) * Types of events recorded; (28)
* Frequency with which audit logs are processed or audited; * Frequency with which audit logs are processed or audited;
* Period for which audit logs are kept; * Period for which audit logs are kept;
* Protection of audit logs: * Protection of audit logs:
- Who can view audit logs; - Who can view audit logs;
- Protection against modification of audit log; and - Protection against modification of audit log; and
- Protection against deletion of audit log. - Protection against deletion of audit log.
* Audit log back up procedures; * Audit log back up procedures;
* Whether the audit log accumulation system is internal or * Whether the audit log accumulation system is internal or
external to the entity; external to the entity;
* Whether the subject who caused an audit event to occur is * Whether the subject who caused an audit event to occur is
notified of the audit action; and notified of the audit action; and
* Vulnerability assessments. * Vulnerability assessments.
4.4.6 Records Archival 4.4.6 Records Archival
This subcomponent is used to describe general records archival This subcomponent is used to describe general records archival
(or records retention) policies, including the following: (or records retention) policies, including the following:
* Types of events recorded; (29) * Types of events recorded; (29)
* Retention period for archive; * Retention period for archive;
* Protection of archive: * Protection of archive:
- Who can view the archive; - Who can view the archive;
- Protection against modification of archive; and - Protection against modification of archive; and
- Protection against deletion of archive. - Protection against deletion of archive.
* Archive backup procedures; * Archive backup procedures;
* Requirements for time-stamping of records; * Requirements for time-stamping of records;
* Whether the archive collection system is internal or * Whether the archive collection system is internal or
external; and external; and
* Procedures to obtain and verify archive information. * Procedures to obtain and verify archive information.
4.4.7 Key Changeover 4.4.7 Key Changeover
This subcomponent describes the procedures to provide a new This subcomponent describes the procedures to provide a new
public key to a CA's users. public key to a CA's users.
4.4.8 Compromise and Disaster Recovery 4.4.8 Compromise and Disaster Recovery
This subcomponent describes requirements relating to This subcomponent describes requirements relating to
notification and recovery procedures in the event of compromise notification and recovery procedures in the event of compromise
or disaster. Each of the following circumstances may need to or disaster. Each of the following circumstances may need to
be addressed separately: be addressed separately:
* The recovery procedures used if computing resources, * The recovery procedures used if computing resources,
software, and/or data are corrupted or suspected to be software, and/or data are corrupted or suspected to be
corrupted. These procedures describe how a secure corrupted. These procedures describe how a secure
environment is reestablished, which certificates are environment is reestablished, which certificates are
revoked, whether the entity key is revoked, how the new revoked, whether the entity key is revoked, how the new
entity public key is provided to the users, and how the entity public key is provided to the users, and how the
subjects are recertified. subjects are recertified.
* The recovery procedures used if the entity public key is * The recovery procedures used if the entity public key is
revoked. These procedures describe how a secure environment revoked. These procedures describe how a secure environment
is reestablished, how the new entity public key is provided is reestablished, how the new entity public key is provided
to the users, and how the subjects are recertified. to the users, and how the subjects are recertified.
* The recovery procedures used if the entity key is * The recovery procedures used if the entity key is
compromised. These procedures describe how a secure compromised. These procedures describe how a secure
environment is reestablished, how the new entity public key environment is reestablished, how the new entity public key
is provided to the users, and how the subjects are is provided to the users, and how the subjects are
recertified. recertified.
* The CA's procedures for securing its facility during the
period of time following a natural or other disaster and
before a secure environment is reestablished either at the
original site or a remote hot-site. For example, procedures
to protect against theft of sensitive materials from an
earthquake-damaged site.
4.4.9 CA Termination 4.4.9 CA Termination
This subcomponent describes requirements relating to procedures This subcomponent describes requirements relating to procedures
for termination and for termination notification of a CA or RA, for termination and for termination notification of a CA or RA,
including the identity of the custodian of CA and RA archival including the identity of the custodian of CA and RA archival
records. records.
4.5 PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS 4.5 PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS
This component describes non-technical security controls (that is, This component describes non-technical security controls (that is,
skipping to change at page 31, line 31 skipping to change at page 31, line 14
facility security. facility security.
Security management controls include execution of tools and Security management controls include execution of tools and
procedures to ensure that the operational systems and networks procedures to ensure that the operational systems and networks
adhere to configured security. These tools and procedures adhere to configured security. These tools and procedures
include checking the integrity of the security software, include checking the integrity of the security software,
firmware, and hardware to ensure their correct operation. firmware, and hardware to ensure their correct operation.
This subcomponent can also address life-cycle security ratings This subcomponent can also address life-cycle security ratings
based, for example, on the Trusted Software Development based, for example, on the Trusted Software Development
Methodology (TSDM) level IV and V, independent life-cycle Methodology (TSDM) level IV and V, independent life- cycle
security controls audit, and the Software Engineering security controls audit, and the Software Engineering
Institute's Capability Maturity Model (SEI-CMM). Institute's Capability Maturity Model (SEI-CMM).
4.6.7 Network Security Controls 4.6.7 Network Security Controls
This subcomponent addresses network security related controls, This subcomponent addresses network security related controls,
including firewalls. including firewalls.
4.6.8 Cryptographic Module Engineering Controls (26) 4.6.8 Cryptographic Module Engineering Controls (26)
skipping to change at page 35, line 31 skipping to change at page 35, line 14
1.4.2 Contact person 1.4.2 Contact person
1.4.3 Person determining CPS suitability for the policy 1.4.3 Person determining CPS suitability for the policy
2. GENERAL PROVISIONS 2. GENERAL PROVISIONS
2.1 Obligations 2.1 Obligations
2.1.1 CA obligations 2.1.1 CA obligations
2.1.2 RA obligations 2.1.2 RA obligations
2.1.3 Subscriber obligations 2.1.3 Subscriber obligations
2.1.4 Relying party obligations 2.1.5 Repository obligations 2.1.4 Relying party obligations
2.1.5 Repository obligations
2.2 Liability 2.2 Liability
2.2.1 CA liability 2.2.1 CA liability
2.2.2 RA liability 2.2.2 RA liability
2.3 Financial responsibility 2.3 Financial responsibility
2.3.1 Indemnification by relying parties 2.3.1 Indemnification by relying parties
2.3.2 Fiduciary relationships 2.3.2 Fiduciary relationships
skipping to change at page 37, line 4 skipping to change at page 36, line 36
3.1.2 Need for names to be meaningful 3.1.2 Need for names to be meaningful
3.1.3 Rules for interpreting various name forms 3.1.3 Rules for interpreting various name forms
3.1.4 Uniqueness of names 3.1.4 Uniqueness of names
3.1.5 Name claim dispute resolution procedure 3.1.5 Name claim dispute resolution procedure
3.1.6 Recognition, authentication and role of trademarks 3.1.6 Recognition, authentication and role of trademarks
3.1.7 Method to prove possession of private key 3.1.7 Method to prove possession of private key
3.1.8 Authentication of organization identity 3.1.8 Authentication of organization identity
3.1.9 Authentication of individual identity 3.1.9 Authentication of individual identity
3.2 Routine Rekey 3.2 Routine Rekey
3.3 Rekey after Revocation 3.3 Rekey after Revocation
3.4 Revocation Request 3.4 Revocation Request
4. OPERATIONAL REQUIREMENTS (34) 4. OPERATIONAL REQUIREMENTS (34)
4.1 Certificate Application 4.1 Certificate Application
4.2 Certificate Issuance 4.2 Certificate Issuance
4.3 Certificate Acceptance 4.3 Certificate Acceptance
4.4 Certificate Suspension and Revocation 4.4 Certificate Suspension and Revocation
4.4.1 Circumstances for revocation 4.4.1 Circumstances for revocation
4.4.2 Who can request revocation 4.4.2 Who can request revocation
skipping to change at page 37, line 50 skipping to change at page 37, line 35
4.5.6 Audit collection system (internal vs external) 4.5.6 Audit collection system (internal vs external)
4.5.7 Notification to event-causing subject 4.5.7 Notification to event-causing subject
4.5.8 Vulnerability assessments 4.5.8 Vulnerability assessments
4.6 Records Archival 4.6 Records Archival
4.6.1 Types of event recorded 4.6.1 Types of event recorded
4.6.2 Retention period for archive 4.6.2 Retention period for archive
4.6.3 Protection of archive 4.6.3 Protection of archive
4.6.4 Archive backup procedures 4.6.4 Archive backup procedures
4.6.5 Archive collection system (internal or external) 4.6.5 Requirements for time-stamping of records
4.6.6 Procedures to obtain and verify archive information 4.6.6 Archive collection system (internal or external)
4.6.7 Procedures to obtain and verify archive information
4.7 Key changeover 4.7 Key changeover
4.8 Compromise and Disaster Recovery 4.8 Compromise and Disaster Recovery
4.8.1 Computing resources, software, and/or data are corrupted
4.8.2 Entity public key is revoked
4.8.3 Entity key is compromised
4.8.4 Secure facility after a natural or other type of disaster
4.9 CA Termination 4.9 CA Termination
5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34) 5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34)
5.1 Physical Controls 5.1 Physical Controls
5.1.1 Site location and construction 5.1.1 Site location and construction
5.1.2 Physical access 5.1.2 Physical access
5.1.3 Power and air conditioning 5.1.3 Power and air conditioning
5.1.4 Water exposures 5.1.4 Water exposures
5.1.5 Fire prevention and protection 5.1.5 Fire prevention and protection
5.1.6 Media storage 5.1.6 Media storage
5.1.7 Waste disposal 5.1.7 Waste disposal
5.1.8 Off-site backup 5.1.8 Off-site backup
skipping to change at page 39, line 38 skipping to change at page 39, line 28
6.6 Life Cycle Technical Controls 6.6 Life Cycle Technical Controls
6.6.1 System development controls 6.6.1 System development controls
6.6.2 Security management controls 6.6.2 Security management controls
6.6.3 Life cycle security ratings 6.6.3 Life cycle security ratings
6.7 Network Security Controls 6.7 Network Security Controls
6.8 Cryptographic Module Engineering Controls 6.8 Cryptographic Module Engineering Controls
7. CERTIFICATE AND CRL PROFILES 7. CERTIFICATE AND CRL PROFILES
7.1 Certificate Profile 7.1 Certificate Profile
7.1.1 Version number(s) 7.1.1 Version number(s)
7.1.2 Certificate extensions 7.1.2 Certificate extensions
7.1.3 Algorithm object identifiers 7.1.3 Algorithm object identifiers
7.1.4 Name forms 7.1.4 Name forms
7.1.5 Name constraints 7.1.5 Name constraints
7.1.6 Certificate policy Object Identifier 7.1.6 Certificate policy Object Identifier
7.1.7 Usage of Policy Constraints extension 7.1.7 Usage of Policy Constraints extension
skipping to change at page 40, line 13 skipping to change at page 40, line 4
extension extension
7.2 CRL Profile 7.2 CRL Profile
7.2.1 Version number(s) 7.2.1 Version number(s)
7.2.2 CRL and CRL entry extensions 7.2.2 CRL and CRL entry extensions
8. SPECIFICATION ADMINISTRATION 8. SPECIFICATION ADMINISTRATION
8.1 Specification change procedures 8.1 Specification change procedures
8.2 Publication and notification policies 8.2 Publication and notification policies
8.3 CPS approval procedures 8.3 CPS approval procedures
6. SECURITY CONSIDERATIONS 6. ACKNOWLEDGMENTS
This entire memo deals with security.
7. ACKNOWLEDGMENTS
The development of this document was supported by the Government of The development of this document was supported by the Government of
Canada's Policy Management Authority (PMA) Committee, the National Canada's Policy Management Authority (PMA) Committee, the National
Security Agency, the National Institute of Standards and Technology Security Agency, the National Institute of Standards and Technology
(NIST), and the American Bar Association Information Security (NIST), and the American Bar Association Information Security
Committee Accreditation Technical Working Group. Special thanks are Committee Accreditation Technical Working Group. Special thanks are
due to Dave Fillingham, Jim Brandt, and Edmond Van Hees for their due to Dave Fillingham, Jim Brandt, and Edmond Van Hees for their
inspiration, support, and valuable inputs. inspiration, support, and valuable inputs.
The following individuals also deserve credit for their review and The following individuals also deserve credit for their review and
skipping to change at page 41, line 10 skipping to change at page 40, line 45
Denis Pinkas, Bull; Denis Pinkas, Bull;
J.-F. Sauriol, Domus Software; J.-F. Sauriol, Domus Software;
Robert Shirey, BBN; Robert Shirey, BBN;
Mark Silvern, VeriSign; Mark Silvern, VeriSign;
David Simonetti, Booz, Allen and Hamilton; and David Simonetti, Booz, Allen and Hamilton; and
Darryl Stal, Entrust. Darryl Stal, Entrust.
Johnny Hsiung, and Chris Miller assisted in the preparation of the Johnny Hsiung, and Chris Miller assisted in the preparation of the
manuscript. manuscript.
8. REFERENCES 7. REFERENCES
[ABA1] American Bar Association, Digital Signature Guidelines: Legal [ABA1] American Bar Association, Digital Signature Guidelines: Legal
Infrastructure for Certification Authorities and Electronic Commerce, Infrastructure for Certification Authorities and Electronic Commerce,
1995. 1995.
[BAU1] Michael. S. Baum, Federal Certification Authority Liability [BAU1] Michael. S. Baum, Federal Certification Authority Liability
and Policy, NIST-GCR-94-654, June 1994. and Policy, NIST-GCR- 94-654, June 1994.
[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information [ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
Technology - Open Systems Interconnection: The Directory: Technology - Open Systems Interconnection: The Directory:
Authentication Framework," 1997 edition. (Pending publication of 1997 Authentication Framework," 1997 edition. (Pending publication of 1997
edition, use 1993 edition with the following amendment applied: edition, use 1993 edition with the following amendment applied:
Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate
Extensions, June 1996.) Extensions, June 1996.)
[PEM1] S. Kent, "Privacy Enhancement for Internet Electronic Mail, [PEM1] S. Kent, "Privacy Enhancement for Internet Electronic Mail,
Part II: Certificate-Based Key Management," Internet RFC 1422, 1993. Part II: Certificate-Based Key Management," Internet RFC 1422, 1993.
[PKI1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key [PKI1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public
Infrastructure, X.509 Certificate and CRL Profile," RFC [tbd], 1997. Key Infrastructure, Certificate and CRL Profile," RFC [tbd], 1998.
9. AUTHORS' ADDRESSES 8. AUTHORS' ADDRESSES
Santosh Chokhani Santosh Chokhani
CygnaCom Solutions, Inc. CygnaCom Solutions, Inc.
Suite 100 West Suite 100 West
7927 Jones Branch Drive 7927 Jones Branch Drive
McLean, VA 22102 McLean, VA 22102
Phone: (703) 848-0883 Phone: (703) 848-0883
Fax: (703) 848-0960 Fax: (703) 848-0960
EMail: chokhani@cygnacom.com EMail: chokhani@cygnacom.com
Warwick Ford Warwick Ford
VeriSign, Inc. VeriSign, Inc.
One Alewife Center 301 Edgewater Place, Suite 210
Cambridge, MA 02140 Wakefield, MA 01880
Phone: (617) 492-2816 x225 Phone: (781) 245-6996 x225
Fax: (617) 661-0716 Fax: (781) 245-6006
EMail: wford@verisign.com EMail: wford@verisign.com
NOTES NOTES
1 The ABA Digital Signature Guidelines can be purchased from the ABA. 1 The ABA Digital Signature Guidelines can be purchased from the ABA.
See http://www.abanet.com for ordering details. See http://www.abanet.com for ordering details.
2 Examples of types of entity for subject CAs are a subordinate 2 Examples of types of entity for subject CAs are a subordinate
organization (e.g., branch or division), a federal government agency, organization (e.g., branch or division), a federal government agency,
or a state or provincial government department. or a state or provincial government department.
3 This statement can have significant implications. For example, 3 This statement can have significant implications. For example,
suppose a bank claims that it issues CA certificates to its branches suppose a bank claims that it issues CA certificates to its branches
only. Now, the user of a CA certificate issued by the bank can 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 assume that the subject CA in the certificate is a branch of the bank
4 Examples of the types of subject RA entities are branch and 4 Examples of the types of subject RA entities are branch and
division of an organization. division of an organization.
5 Examples of types of subject end entities are bank customers, 5 Examples of types of subject end entities are bank customers,
telephone company subscribers, and employees of a government telephone company subscribers, and employees of a government
department department
6 This statement can have significant implications. For example, 6 This statement can have significant implications. For example,
suppose Government CA claims that it issues certificates to suppose Government CA claims that it issues certificates to
Government employees only. Now, the user of a certificate issued by Government employees only. Now, the user of a certificate issued by
the Government CA can assume that the subject of the certificate is a the Government CA can assume that the subject of the certificate is a
Government employee. Government employee.
7 Examples include X.500 distinguished name, Internet e-mail address, 7 Examples include X.500 distinguished name, Internet e-mail address,
and URL. and URL.
8 The term "meaningful" means that the name form has commonly 8 The term "meaningful" means that the name form has commonly
understood semantics to determine identity of the person and/or understood semantics to determine identity of the person and/or
organization. Directory names and RFC 822 names may be more or less organization. Directory names and RFC 822 names may be more or less
meaningful. meaningful.
9 Examples of proof include the issuing CA generating the key, or 9 Examples of proof include the issuing CA generating the key, or
requiring the subject to send an electronically signed request or to requiring the subject to send an electronically signed request or to
sign a challenge. sign a challenge.
10 Examples of organization identity authentication are: articles of 10 Examples of organization identity authentication are: articles of
incorporation, duly signed corporate resolutions, company seal, and incorporation, duly signed corporate resolutions, company seal, and
notarized documents. notarized documents.
11 Examples of individual identity authentication are: biometrics 11 Examples of individual identity authentication are: biometrics
(thumb print, ten finger print, face, palm, and retina scan), (thumb print, ten finger print, face, palm, and retina scan),
driver's license, passport, credit card, company badge, and driver's license, passport, credit card, company badge, and
government badge. government badge.
12 Examples include duly signed authorization papers or corporate ID 12 Examples include duly signed authorization papers or corporate ID
badge. badge.
13 The identification policy for routine rekey should be the same as 13 The identification policy for routine rekey should be the same as
the one for initial registration since the same subject needs the one for initial registration since the same subject needs
rekeying. The rekey authentication may be accomplished using the rekeying. The rekey authentication may be accomplished using the
techniques for initial I&A or using digitally signed requests. techniques for initial I&A or using digitally signed requests.
14 This identification and authentication policy could be the same as 14 This identification and authentication policy could be the same as
that for initial registration. that for initial registration.
15 This 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 16 The identification policy for Revocation request could be the same
as that for initial registration since the same subject certificate as that for initial registration since the same subject certificate
needs to be revoked. The authentication policy could accept a needs to be revoked. The authentication policy could accept a
Revocation request digitally signed by subject. The authentication Revocation request digitally signed by subject. The authentication
information used during initial registration could be acceptable for information used during initial registration could be acceptable for
Revocation request. Other less stringent authentication policy could Revocation request. Other less stringent authentication policy could
be defined. be defined.
17 The identification policy for key compromise notification could be 17 The identification policy for key compromise notification could be
the same as the one for initial registration since the same subject the same as the one for initial registration since the same subject
certificate needs to be revoked. The authentication policy could certificate needs to be revoked. The authentication policy could
accept a Revocation request digitally signed by subject. The accept a Revocation request digitally signed by subject. The
authentication information used during initial registration could be authentication information used during initial registration could be
acceptable for key compromise notification. Other less stringent acceptable for key compromise notification. Other less stringent
authentication policy could be defined. authentication policy could be defined.
18 The n out of m rule allows a key to be split in m parts. The m 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 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 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. n- 1 parts provides one with no information about the key.
19 A key may be escrowed, backed up or archived. Each of these 19 A key may be escrowed, backed up or archived. Each of these
functions have different purpose. Thus, a key may go through any functions have different purpose. Thus, a key may go through any
subset of these functions depending on the requirements. The purpose subset of these functions depending on the requirements. The purpose
of escrow is to allow a third party (such as an organization or of escrow is to allow a third party (such as an organization or
government) to legally obtain the key without the cooperation of the government) to legally obtain the key without the cooperation of the
subject. The purpose of back up is to allow the subject to subject. The purpose of back up is to allow the subject to
reconstitute the key in case of the destruction of the key. The 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, purpose of archive is to provide for reuse of the key in future,
e.g., use the private key to decrypt a document. e.g., use the private key to decrypt a document.
20 An example of activation data is a PIN or passphrase. 20 An example of activation data is a PIN or passphrase.
21 Examples of physical access controls are: monitored facility , 21 Examples of physical access controls are: monitored facility ,
guarded facility, locked facility, access controlled using tokens, guarded facility, locked facility, access controlled using tokens,
access controlled using biometrics, and access controlled through an access controlled using biometrics, and access controlled through an
access list. access list.
22 Examples of the roles include system administrator, system 22 Examples of the roles include system administrator, system
security officer, and system auditor. The duties of the system security officer, and system auditor. The duties of the system
administrator are to configure, generate, boot, and operate the administrator are to configure, generate, boot, and operate the
system. The duties of the system security officer are to assign system. The duties of the system security officer are to assign
accounts and privileges. The duties of the system auditor are to set accounts and privileges. The duties of the system auditor are to set
up system audit profile, perform audit file management, and audit up system audit profile, perform audit file management, and audit
review. review.
23 The background checks may include clearance level (e.g., none, 23 The background checks may include clearance level (e.g., none,
sensitive, confidential, secret, top secret, etc.) and the clearance sensitive, confidential, secret, top secret, etc.) and the clearance
granting authority name. In lieu of or in addition to a defined granting authority name. In lieu of or in addition to a defined
clearance, the background checks may include types of background clearance, the background checks may include types of background
information (e.g., name, place of birth, date of birth, home address, information (e.g., name, place of birth, date of birth, home address,
previous residences, previous employment, and any other information previous residences, previous employment, and any other information
that may help determine trustworthiness). The description should that may help determine trustworthiness). The description should
also include which information was verified and how. also include which information was verified and how.
24 For example, the certificate policy may impose personnel security 24 For example, the certificate policy may impose personnel security
requirements on the network system administrator responsible for a requirements on the network system administrator responsible for a
CA's network access. CA's network access.
25 Each authorized person should be accountable for his/her actions. 25 Regardless of whether authorized persons are employees, practices
should be implemented to ensure that each authorized person is held
accountable for his/her actions.
26 A cryptographic module is hardware, software, or firmware or any 26 A cryptographic module is hardware, software, or firmware or any
combination of them. combination of them.
27 The compliance description should be specific and detailed. For 27 The compliance description should be specific and detailed. For
example, for each FIPS 140-1 requirement, describe the level and example, for each FIPS 140-1 requirement, describe the level and
whether the level has been certified by an accredited laboratory. whether the level has been certified by an accredited laboratory.
28 Example of audit events are: request to create a certificate, 28 Example of audit events are: request to create a certificate,
request to revoke a certificate, key compromise notification, request to revoke a certificate, key compromise notification,
skipping to change at page 45, line 49 skipping to change at line 2092
ITU - International Telecommunications Union ITU - International Telecommunications Union
NIST - National Institute of Standards and Technology NIST - National Institute of Standards and Technology
OID - Object Identifier OID - Object Identifier
PIN - Personal Identification Number PIN - Personal Identification Number
PKI - Public Key Infrastructure PKI - Public Key Infrastructure
PKIX - Public Key Infrastructure (X.509) (IETF Working Group) PKIX - Public Key Infrastructure (X.509) (IETF Working Group)
RA - Registration Authority RA - Registration Authority
RFC - Request For Comment RFC - Request For Comment
URL - Uniform Resource Locator URL - Uniform Resource Locator
US - United States US - United States
36
 End of changes. 218 change blocks. 
511 lines changed or deleted 526 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/