PKIX Working Group S. Chokhani (CygnaCom Solutions, Inc.)
Internet Draft W. Ford (VeriSign, Inc.)
expires in six months June 1997
Certificate Policy and Certification Practice Statement Framework
<draft-chokhani-cps-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of 6 months
and may be updated, replaced, or may become obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as work in progress.
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document presents an initial draft of a framework to assist the
writers of X.509 certificate policies or certification practice
statements for certification authorities and public key
infrastructures. In particular, the framework identifies a
comprehensive list of topics that potentially (at the writer's
discretion) need to be covered in an X.509 certificate policy or a
certification practice statement.
1. INTRODUCTION
1.1 BACKGROUND
An X.509 public key certificate (henceforth termed a certificate)
binds an entity to the entity's public key. The degree to which a
certificate user (a certificate user is typically a signature
verifier or a key token generator) can trust this binding depends
on several factors. These factors include the Certification
Authority (CA) policy and procedures for authentication of end
entities, CA operating policy, procedures and security controls,
Chokhani [Page 1]
Internet-Draft CPF and CPSF January 1997
end entity policy and procedures for handling private keys, etc.
The liability assumed by certificate issuers and end entities also
plays a role in the degree of trust.
Version 3 X.509 certificates may contain certificate policies [8].
A certificate policy allows the users of a certificate to decide
how much trust to place in the certificate, i.e., in the binding
of the entity's identity and the entity's public key. According
to X.509, version 3, a certificate policy is "a named set of rules
that indicates the applicability of a certificate to a particular
community and/or class of application with common security
requirements."
A detailed description of how certificate policies are implemented
by a particular CA is called a Certification Practice Statement
(CPS). According to the American Bar Association (ABA), "a CPS is
a statement of the practices which a certification authority
employs in issuing certificates." When negotiating a cross
certification, CAs examine and compare each other's CPS.
1.2 PURPOSE
The purpose of this document is to present a framework that
identifies the elements that may need to be considered in
formulating a certificate policy or a CPS, to assist the writers
of certificate policies or CPSs with their task. The purpose is
not to define particular certificate policies or CPSs per se.
1.3 SCOPE
There are many classes of policies, such as organization security
policy, system security policy, data labeling policy, etc. The
scope of this document is limited to defining the aspects and
elements of a certificate policy (as described and intended in the
X.509, version 3 certificate standard and ABA digital signature
guidelines). While the certificate policy and certification
practices statement framework presented here was motivated by the
X.509 version 3 certificate standard, the framework can be used by
other public key certificate standards.
This document does not define a specific certificate policy or
CPS. Instead, it describes what types of information should be
included in a certificate policy (and documented in a CPS). This
document does not provide specific values or specific mechanisms
to choose those values. Specific security policy and the
mechanisms that implement them are the scope of a detailed
document, a CPS.
Chokhani [Page 2]
Internet-Draft CPF and CPSF January 1997
This document's scope is limited to provide a comprehensive
framework. It does not contain any guidance on how to write sound
certificate policies or CPS.
This certificate policy and CPS framework contains many topics.
It is not necessary for a policy or a CPS to define something
concrete for each topic. A tangible statement, "none", and "not
applicable" are all acceptable values. Addressing each and every
topic ensures that the policy and CPS writers have not omitted
anything. Addressing each and every topic in the defined sequence
also facilitates comparison of policies and certification practice
statements for the purpose of equivalency mapping (as described in
Section 3).
1.4 AUDIENCE
The audience for this document are the designers and policy-
makers of certificate infrastructures using version 3 X.509
certificates.
1.5 DOCUMENT ORGANIZATION
This document contains seven main sections. This section has
provided an introduction. Section 2 contains definitions of key
terms used in this document. Section 3 further explains
certificate policy and CPS related terms and Section 4 provides a
list of references and related work. Section 5 provides an
overview of the certificate policy and certification practices
framework. Section 6 contains the details of the certificate
policy and CPS framework. Section 7 provides an outline format
for a certificate policy and certification practice statement.
2. DEFINITIONS
In this section, we define terms used in the development of
certificate policy and CPS. These terms are closely related, but
have subtle differences. The definitions are intended to clarify
those subtle differences.
Certificate Policy - A named set of rules that indicates the
applicability of a certificate to a particular community and/or
class of application with common security requirements. For
example, a particular certificate policy might indicate
applicability of a type of certificate to the authentication of
electronic data interchange transactions for the trading of goods
within a given price range. The certificate policy should be used
by the user of the certificate to decide whether or not to accept
the binding between the subject (of the certificate) and the
Chokhani [Page 3]
Internet-Draft CPF and CPSF January 1997
public key. A subset of the components in the certificate policy
and certification practices statement framework are given concrete
values to define a certificate policy. The certificate policy is
represented by a registered object identifier in the X.509,
version 3 certificate. The object owner also registers a textual
description of the policy and makes it available to the
certificate users.
The certificate policy object identifier can be included in the
following extensions in the X.509, version 3 certificates:
certificate policies, policy mappings, and policy constraints.
The object identifier(s) may appear in none, some, or all of these
fields. These object identifiers may be the same (referring to
the same certificate policy) or may be different (referring to
different certificate policies).
Element of Policy - A topic that may need to be covered in a
certificate policy or in a certification practice statement.
Certification Path - A set of certificates that provides a chain
of trust from the relying party's trusted CA to the entity whose
public key is required by the relying party.
Certificate Policy and Certificate Practice Statement (CPS)
Framework - A comprehensive set of security and liability related
components that can be used to define a certificate policy or a
CPS. A subset of the components in the certificate policy and CPS
framework are given concrete values to define a certificate policy
or a CPS.
Certification Practice Statement (CPS) - A statement of the
practices which a certification authority employs in issuing
certificates.
Issuing Certification Authority (CA) - A CA who has elected to
apply a policy to itself and its subjects (CA and end entities).
Policy Qualifier - Policy-dependent information that accompanies a
certificate policy identifier in an X.509 certificate.
Registration Authority (RA) - An entity who is responsible for
identification and authentication of subjects of certificate, but
is not a CA, and hence does not sign or issue certificates.
Subject CA - A CA that is certified by the issuing CA and hence
complies with the certificate policy of the issuing CA.
Subject RA - See Registration Authority (RA).
Chokhani [Page 4]
Internet-Draft CPF and CPSF January 1997
3. CERTIFICATE POLICY AND CPS RELATED CONCEPTS
This section contains a detailed explanation of a certificate policy
and a certification practice statement.
3.1 CERTIFICATE POLICY
When a certification authority issues a certificate, it is
providing a statement to a certificate user (i.e., a relying
party) that a particular public key is bound to a particular
entity (the certificate subject). But to what extent can the
certificate user rely on that statement by the certification
authority? Different certificates are issued following different
practices and procedures, and may be suitable for different
applications and/or purposes.
The term certificate policy derives from the X.509 standard [8].
Certificate policy refers to the way an X.509 certificate
indicates to a certificate user whether or not the certificate is
suitable for use for a particular application. A certificate
policy needs to be recognized by both the issuer and user of the
certificate. Any individual certificate will typically be
associated with a single certificate policy or, possibly, be
issued consistent with a small number of different policies.
The X.509 standard defines a certificate policy as "a named set of
rules that indicates the applicability of a certificate to a
particular community and/or class of application with common
security requirements."
A certificate policy is registered and assigned a globally unique
ISO/IEC/ITU object identifier (OID). This registration process
follows the procedures specified in ISO/IEC/ITU standards.
3.2 CERTIFICATE POLICY EXAMPLES
An organization can be expected to support a number of different
certificate policies. For example, a certain organization might
support two different certificate policies. One might govern how
certificates are issued for confidentiality (encryption)
applications, while the second might deal with how certificates
are issued for non-repudiation (digital signature) applications.
For the purposes of this example, call this organization ACME
research, and call the two policies the ACME Electronic Mail
policy, and the ACME Purchase policy. The ACME Electronic Mail
policy is used by the ACME employees for protecting routine
information (e.g., causal electronic mail) and for authenticating
Chokhani [Page 5]
Internet-Draft CPF and CPSF January 1997
connections from the World Wide Web browsers to the corporate Web
servers. The Certified key pairs may be generated, stored, and
managed using low-cost software-based systems. Under this policy,
a certificate is automatically issued to anybody identified in the
corporate directory who submits a signed certificate request form
to a network administrator.
The ACME Purchase policy is used to protect financial
transactions. Under this policy, ACME requires that certified key
pairs be generated and stored in approved cryptographic hardware
tokens. A certificate and token is provided to employees with
disbursement authority. These authorized individual are required
to present themselves to a special security office, and show a
valid identification badge before a token is issued.
3.3 X.509 CERTIFICATE FIELDS RELATING TO CERTIFICATE POLICIES
The following extension fields in an X.509 certificate are used to
support certificate policies:
* Certificate Policies extension
* Policy Mappings extension
* Policy Constraints extension
3.3.1 Certificate Policies Extension
The Certificate Policies extension has two variants - one with
the field flagged non-critical and one with the field flagged
critical. The purpose of the field is slightly different in
the two cases.
Each Certificate Policy may define one or more purposes for
which certificates issued on the policy may be used. A non-
critical Certificate Policies field lists certificate policies
that the certification authority declares are applicable,
however, use of the certificate is not restricted to the
purposes indicated by the applicable policies. Using the
example of the "Electronic Mail" and the "Purchase" policies
defined in Section 3.2 above, the certificates issued to the
organization's regular employees will contain the object
identifier for certificate policy for the Electronic Mail
policy. The certificates issued to the employees with
disbursement authority will contain the object identifiers for
both the Electronic Mail policy and the Purchase policy. The
Certificate Policies field may also optionally convey qualifier
values for each identified policy; use of qualifiers is
discussed below in Section 3.4.
Chokhani [Page 6]
Internet-Draft CPF and CPSF January 1997
The non-critical Certificate Policies field is designed to be
used by applications as follows. Each application is pre-
configured to know what policy it requires. Using the example
in Section 3.2, electronic mail applications and Web servers
will be configured to require the Electronic Mail policy. The
corporate financial applications will be configured to require
the Purchase policy for validating financial transactions.
When processing a certification path, a certificate policy that
is acceptable to the certificate-using application must be
present in every certificate in the path, i.e., in
certification authority certificates as well as end entity
certificates.
If the certificate policies field is flagged critical, it
serves the same purpose as described above but also has an
additional role. It indicates that the use of the certificate
is restricted to one of the identified policies, i.e., the
certification authority is declaring that the certificate must
not be used for any purpose other than those identified by the
certificate policies. This field is intended, first and
foremost, to protect the certification authority against damage
claims by some party who has used the certificate for a purpose
not defined in the applicable policies.
For example, the government might issue certificates to
taxpayers for the purpose of protecting tax filings. The
government understands and can accommodate the risks of
accidentally issuing a bad certificate, e.g., to a wrongly-
authenticated person. However, suppose someone used a
government tax-filing certificate as the basis for encrypting
multi-million-dollar-value proprietary secrets which
subsequently fell into the wrong hands because of an error in
issuing the government certificate. Would it not be possible
for the damaged party to sue the government for issuing a bad
certificate? It is this type of situation that the critical-
flagged Certificate Policies extension is intended to avert.
To provide protection against this type of situation, the
extension field should always be set critical in a certificate,
i.e., any application using the certificate must use the
certificate only for the purpose(s) defined by the policies in
the field.
Chokhani [Page 7]
Internet-Draft CPF and CPSF January 1997
3.3.2 Policy Mapping Extension
The next policy related extension field is the Policy Mappings
extension. This extension may only be used in CA-
certificates, i.e., certificates for certification authorities
issued by other certification authorities. This field allows a
certification authority to indicate that certain policies in
its own domain can be considered equivalent to certain other
policies in the subject certification authority's domain.
For example, suppose the ACE Corporation establishes an
agreement with the ABC Corporation to cross-certify each
others' public-key infrastructures for the purposes of mutually
protecting electronic data interchange. Further, suppose that
both companies have pre-existing financial transaction
protection policies called ace-e-commerce and abc-e-commerce,
respectively. One can see that simply generating cross
certificates between the two domains will not provide the
necessary interoperability, as the two companies' applications
are configured and employee certificates are populated with
their respective certificate policies. One possible solution
is to reconfigure all of the financial applications to require
either policy and to reissue all the certificates with both
policies. Another solution, which is much easier to
administer, uses the Policy Mapping field. If this field is
included in a cross- certificate for the ABC Corporation
certification authority issued by the ACE Corporation
certification authority, it can provide a statement that the
ABC's financial transaction protection policy (i.e., abc-e-
commerce) can be considered equivalent to that of the ACE
Corporation (i.e., ace-e- commerce).
3.3.3 Policy Constraints Extension
The Policy Constraints extension supports two optional
features. The first is the ability for a certification
authority to require explicit certificate policy to be present
in all subsequent certificates in a certification path.
Certificates at the start of a certification path may be
considered by a certificate user to be part of a trusted
domain, i.e., certification authorities are trusted for all
purposes so no particular certificate policy is needed in the
Certificate Policies extension. Whenever a certification
authority in the trusted domain certifies outside the domain,
it should activate the requirement for explicit policy in
subsequent certificates.
The other optional feature in the Policy Constraints field is
Chokhani [Page 8]
Internet-Draft CPF and CPSF January 1997
the ability for a certification authority to disable policy
mapping by subsequent certification authorities in a
certification path. Unless special requirements arise, it
would be prudent to always disable policy mapping when
certifying outside the domain. This will eliminate the
increase in security risk due to transitive trust. i.e., a
domain A trusts domain B, domain B trusts domain C, and hence
domain A trusts domain C even though domain A does not wish to
trust any other domain except domain B.
3.4 POLICY QUALIFIERS
The Certificate Policies extension field has a provision for
conveying, along with each certificate policy identifier,
additional policy-dependent information in a qualifier field. The
X.509 standard does not mandate the purpose for which this field
is to be used, nor does it prescribe the syntax for this field.
Policy qualifier types can be registered by any organization.
In practice, policy qualifiers will not be particularly useful
unless agreement is reached, outside the standard, on the purposes
for which they will be used and on the syntax for representing
them. A collection of common qualifier types will likely emerge.
Some important purposes currently envisaged for qualifiers are:
a. for providing a solid link back to a location from which a
copy of the full certification practice statement (see next
section) can be retrieved; the qualifier will convey a World
Wide Web URL and a digest field to enable a user to check that
the document has been retrieved uncorrupted; and
b. for conveying textual information comprising appropriate
legal text, e.g., disclaimer of limitation of liability, for
display to certificate users whenever certificates are used.
It is anticipated that the IETF PKIX Working Group will
standardize these qualifier types.
3.5 CERTIFICATION PRACTICE STATEMENT
The term certification practice statement derives from the
American Bar Association (ABA) Digital Signature Guidelines [10].
(E1) A certification practice statement is defined to be:
A statement of the practices which a certification authority
employs in issuing certificates.
Chokhani [Page 9]
Internet-Draft CPF and CPSF January 1997
In the 1995 draft of the ABA guidelines, the ABA expands this
definition with the following comments:
A certification practice statement may take the form of a
declaration by the certification authority of the details of
its trustworthy system and the practices it employs in its
operations and in support of issuance of a certificate, or it
may be a statute or regulation applicable to the certification
authority and covering similar subject matter. It may also be
part of the contract between the certification authority and
the subscriber. A certification practice statement may also be
comprised of multiple documents, a combination of public law,
private contract, and/or declaration.
Certain forms for legally implementing certification practice
statements lend themselves to particular relationships. For
example, when the legal relationship between a certification
authority and subscriber is consensual, a contract would
ordinarily be the means of giving effect to a certification
practice statement. The certification authority's duties to a
relying person are generally based on the certification
authority's representations, which may include a certification
practice statement.
Whether a certification practice statement is binding on a
relying person depends on whether the relying person has
knowledge or notice of the certification practice statement. A
relying person has knowledge or at least notice of the contents
of the certificate used by the relying person to verify a
digital signature, including documents incorporated into the
certificate by reference. It is therefore advisable to
incorporate a certification practice statement into a
certificate by reference.
NOTE: When the legal relationship is regulatory, for
example, between a government and its citizens, a statute
may be the means of giving effect to a certification
practice statement.
As much as possible, a certification practice statement should
indicate any of the widely recognized standards to which the
certification authority's practices conform. Reference to
widely recognized standards may indicate concisely the
suitability of the certification authority's practices for
another person's purposes, as well as the potential
technological compatibility of the certificates issued by the
certification authority with repositories and other systems.
Chokhani [Page 10]
Internet-Draft CPF and CPSF January 1997
3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION
PRACTICE STATEMENT
The concepts of certificate policy and certification practice
statement come from different sources and were developed for
different reasons. However, they are interrelated. This section
describes the relationship between the two.
A certification practice statement is a detailed statement by a
certification authority as to its practices, that potentially
needs to be understood and consulted by subscribers and
certificate users (relying parties). A certificate policy is a
mutually understood indicator from certification authority to
certificate user as to suitable applications and purposes for a
particular certificate. A certification authority with a single
certification practice statement may support multiple certificate
policies (used by different certificate user communities). Also,
multiple different certification authorities, with non-identical
certification practice statements, may support the same
certificate policy.
For example, the Government of Canada might define a government-
wide certificate policy for handling confidential human resources
information. The certificate policy definition will be a broad
statement of the general characteristics of that certificate
policy, and an indication of the types of applications for which
it is suitable for use. Different departments or agencies that
operate certification authorities with different certification
practice statements might support this certificate policy. At the
same time, such certification authorities may support other
certificate policies.
In addition to populating the certificate policies field with the
certificate policy identifier, a certification authority may
include, in certificates it issues, a reference to its
certification practice statement. A standard way to do this,
using a certificate policy qualifier, is described in Section 3.4.
3.7 CA DISCLOSURE RECORD
A CA Disclosure Record [9] is a body of textual information,
intended to convey information about a particular certification
authority that may be of some help to a certificate user in
evaluating the suitability of a certificate issued by that
certification authority.
The following excerpt from the Utah Administrative Code has the
following recommendations for the contents of a certification
Chokhani [Page 11]
Internet-Draft CPF and CPSF January 1997
authority disclosure record:
1. an indication that the certification authority disclosure
record is provided and maintained by this state;
2. the name, street address, and voice telephone number of the
certification authority;
3. the telephone number of the certification authority's
facsimile transmission machine, if the certification authority
has such a machine;
4. the electronic mail or other address by which the
certification authority may be contacted electronically;
5. the distinguished name of the certification authority;
6. the current public key or keys of the certification
authority by which its digital signatures on published
certificates may be verified;
7. the restrictions, if any, placed on the certification
authorities license pursuant to section 201(3);
8. if the certification authority's license has been revoked
or is currently suspended, the data of revocation or suspension
and the grounds for revocation or suspension;
9. the amount of the certification authority's suitable
guaranty;
10. the total amount of all claims filed with the division for
payment from the suitable guaranty filed by the certification
authority;
11. a brief description of any limit known to the division and
applicable to the certification authority's liability or legal
capacity to pay damages in tort or for breach of a duty
prescribed in this document; unless the limitation is specified
in this document;
12. the categorization pursuant to section 202(2) of the
certification authority's compliance with this document and
resulting from the most recent performance audit of the
certification authority's activities, and the data of the most
recent performance audit;
13. any event which substantially affects the certification
Chokhani [Page 12]
Internet-Draft CPF and CPSF January 1997
authority's ability to conduct its business or the validity of
a certificate published in the repository provided by the
Division or in a recognized repository;
14. if a certificate containing the public key required to
verify one or more certificates issued by the certification
authority has been revoked or is currently suspended, the date
of its revocation or suspension; and
15. if the certification authority has a material, primary
certification practice statement, indications of its location,
the method or procedure by which it may be retrieved, its form
and structure, its authorship, and its date, as prescribed in
rule 302.
4. REFERENCES
This document is based on the certificate taxonomy developed by
CygnaCom and documented in [1]. References 2 through 7 have been
used to refine the framework.
1. Technical Specifications for Federal Public Key
Infrastructure-Annex D: Interoperability Profiles, (Appendix E),
CygnaCom Solutions, Inc., December, 1995.
2. Technical Specifications for Federal Public Key
Infrastructure-Annex B: Technical Security Policy, National
Institutes of Standards and Technology, December, 1995.
3. Statement of Work Federal Public Key Infrastructure Pilot,
(Appendix A-Technical Specifications), Solicitation No.
52SBN5C8535, National Institutes of Standards and Technology,
October, 1994.
4. Information System Security Policy and Certification Practice
Statement, National Security Agency, March 12, 1996.
5. Government of Canada PKI - Certificate Policy and
Certification Practices Statement Framework, November 12, 1996.
6. MISSI Policy Analysis, Booz, Allen and Hamilton, March 1996.
7. Recommendation X.509 and ISO 9594-8, Information Processing
System - Open Systems Interconnection - The Directory -
Authentication Framework, 1988.
8. Final Text of Draft Amendment DAM 4 to ISO/IEC 9594-2, DAM 2
to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC
Chokhani [Page 13]
Internet-Draft CPF and CPSF January 1997
9594-8 on Certificate Extensions, June 1996.
9. Utah Administrative Code.
10. American Bar Association, Digital Signature Guidelines: Legal
Infrastructure for Certification Authorities and Electronic
Commerce, Draft 1995.
11. Baum, Michael S., Federal Certification Authority Liability
and Policy, NIST-GCR-94-654, June 1994.
12. Certification Practices Statement, Verisign, 1996.
13. Privacy Enhanced Mail, Internet RFC 1421-23, 1994
5. CERTIFICATE POLICY AND CERTIFICATION PRACTICES FRAMEWORK: OVERVIEW
This section provides a brief overview of the certificate policy
components. Section 6 provides a complete refinement of the
components. Both the certificate policy and the CPS are composed of
components described in this section and further refined in Section
6. Components can be further divided into subcomponents.
Subcomponents can be divided into elements. Elements can be divided
into subelements.
A certificate policy or CPS consists of the following components:
* Community and Applicability
* Identification and Authentication Policy
* Key Management Policy
* Local Security Policy
* Technical Security Policy
* Operations Policy
* Legal Provisions
* Certificate and CRL Profile
* Policy Administration
Each of these components is described below.
Chokhani [Page 14]
Internet-Draft CPF and CPSF January 1997
5.1 COMMUNITY AND APPLICABILITY
Under this component, the following are described:
* types of subject CA certified (e.g., subordinate banks, peer
banks, regional offices, etc.) (2)
* types of subject Registration Authority (RA) certified (e.g.,
regional offices)
* types of end entities certified (e.g., employees,
contractors, subscribers, customers, etc.) (3)
* applications for which the policy is suitable for, is
restricted to, or must not be used in conjunction with.
5.2 IDENTIFICATION AND AUTHENTICATION (I&A) POLICY
This component is used to describe the various I&A policies. The
I&A policies are fundamental to ensuring that the bindings between
the public keys and the individuals are correct. The I&A policies
may be the same or different for the subject CA, subject
Registration Authority (RA), and subject end entities. For each
class of subject (CA, RA, or end entity), the I&A policy may be
different for the various interactions with the parent CA. The
interactions include, initial registration, rekey, rekey after
revocation, and revocation request. The component also describes
if and how the trademarks are recognized (authenticated). The
component also describes if and how name disputes are resolved.
5.3 KEY MANAGEMENT POLICY
This component is used to define the security measures taken by
the CA to protect its cryptographic keys and critical security
parameters (e.g., Personal Identification Number or PIN). This
component may also be used to impose constraints on subject CAs
and end entities to protect their cryptographic keys and critical
security parameters. For the sake of completeness, for each type
of entity (issuer CA, subject CA, RA, and end entity), and for
each type of keying material (private key, parameters, public key,
and critical security parameters) this element addresses the
entire key life-cycle from generation, through storage and usage,
to archival and destruction.
Secure key management is critical to ensure that all secret and
private keys and critical security parameters are protected and
used only by authorized personnel.
Chokhani [Page 15]
Internet-Draft CPF and CPSF January 1997
5.4 LOCAL SECURITY POLICY
This component is used to define the non-technical security
controls used by the CA to perform CA functions securely. The CA
functions include key generation, user authentication, certificate
registration, certificate revocation, audit, and archival. The
non-technical security controls include physical, personnel, and
procedural controls.
This component is also used to define non-technical security
controls on subject CAs, RAs, and end entities. The non technical
security controls for the subject CAs, RAs, and end entities could
be the same, similar, or quite different. In most cases they are
envisioned to be quite different with tighter controls on the
subject CAs and RAs due to the sensitivity of the functions they
perform.
The security controls are critical to trusting the public key
certificates since lack of security may compromise CA operations,
resulting in creation of certificates or CRLs with erroneous
information or even the compromise of the CA private key.
5.5 TECHNICAL SECURITY POLICY
This component is used to define the technical security controls
used by the CA to perform CA functions securely. The CA functions
include key generation, user authentication, certificate
registration, certificate revocation, audit, and archival. The
technical controls include life-cycle security controls (including
software development environment security, trusted software
development methodology) and operational security controls.
This component is also used to define technical security controls
on subject CAs, RAs, and end entities. The technical security
controls for the subject CAs, RAs, and end entities could be the
same, similar, or quite different. In most cases they are
envisioned to be quite different with tighter controls on the
subject CAs and RAs due to the sensitivity of the roles they
perform.
The security controls are critical to trusting the public key
certificates since lack of security may compromise CA operations,
resulting in the creation of certificates or CRLs with erroneous
information or even the compromise of the CA private key.
Chokhani [Page 16]
Internet-Draft CPF and CPSF January 1997
5.6 OPERATIONS POLICY
This component is used to describe the frequency of routine
Certificate Revocation List (CRL) issuance, frequency of special
CRL issuance (e.g., key compromise CRL), and frequency for CA key
changeover. It also describes how the CA operations are
periodically audited by another entity and the CA's relationship
with that entity. This component is also used to define who can
revoke certificates under what circumstances.
This component is used to describe periodic compliance audits the
CA performs on the subject CAs, RAs, and end entities. Periodic
compliance audit on subject CAs and RAs is recommended to ensure
compliance and to maintain trustworthiness of the whole
infrastructure. Periodic compliance audit of subject end entities
is also desirable, but not as critical as the subject CAs.
This component is also used to define the frequency of routine CRL
issuance, frequency of special CRL issuance (e.g., key compromise
CRL), and frequency for key changeover for the subject CAs. This
component is also used to define the typical validity period for
subject end entity certificates. These validity periods could be
different based on key usage (e.g., signature, key establishment,
etc.)
This component is also used to describe the CA, subject CAs,
subject RAs, and subject end entities archival policies.
This component is also used to describe the procedures for
recovering from CA and RA failure and compromise.
This component is also used to define the confidentiality policy
for the information that the CA and RA hold.
This component is relevant for certificate policy, since a
compliance audit policy increases the overall trustworthiness of
the infrastructure entities. The CRL issuance frequency allows
the users of the certificate to develop appropriate caching
strategies. The key changeover period in conjunction with key
size directly relate to the security offered by the cryptosystem.
5.7 LEGAL PROVISIONS
This component describes the liability policy including
disclaimers of warranty and limitations on liability.
This component also defines the obligations of the subscribers
(subject CA, RA, and end entities) and those of the certificate
Chokhani [Page 17]
Internet-Draft CPF and CPSF January 1997
users (relying parties).
It also describes applicable laws and regulations and dispute
resolution procedures.
5.8 CERTIFICATE AND CRL PROFILE
This component is used to define the certificate and CRL versions
and extensions supported (populated) by the CA and the criticality
of the extensions. This component describes typical values of the
following fields within the policy constraints extension: require
explicit policy, and inhibit policy mapping.
This component is also used to define the certificate and CRL
versions and extensions supported (populated) by the subject CAs
and the criticality of the extensions. This component describes
typical values of the following fields within the policy
constraints extension: require explicit policy, and inhibit
policy mapping.
The certificate profile could be different for different key usage
such as signature, key management, certificate signing, CRL
signing, etc.
5.9 POLICY ADMINISTRATION
This component is used to define the authority that is responsible
for the registration, maintenance and interpretation of the
policy. The information includes the name and address of the
organization, and the name and the telephone number of a contact
person.
This component also describes how the policy change is
administered and how various notices are published and
distributed.
This component also describes how the compliance of a specific CPS
with the policy is determined.
6. CERTIFICATE POLICY AND CERTIFICATION PRACTICES FRAMEWORK:
DESCRIPTION
In this section, we provide a complete refinement of the certificate
policy and certification practices statement framework.
Chokhani [Page 18]
Internet-Draft CPF and CPSF January 1997
6.1 COMMUNITY AND APPLICABILITY
This component consists of the following subcomponents:
* Subject CAs
* Subject RAs
* Subject End Entities
* Applicability
This component describes the various types of certificate
subscribers, and applications and standards.
The following sections describe these subcomponents.
6.1.1 Subject CAs
This subcomponent contains a brief description of the types of
entities that are certified as subject CAs. (4)
6.1.2 Subject RAs
This subcomponent contains a brief description of the types of
entities that are certified as subject RAs. (5)
6.1.3 Subject End Entities
This subcomponent contains a brief description of the types of
entities that are certified as end entities. (6)
6.1.4 Applicability
This subcomponent contains:
* A list of applications for which the issued certificates
are suitable
* A list of applications that the issued certificates are
restricted to. (This list implicitly prohibits all other
uses for the certificates.)
* A list of applications that the issued certificates are
prohibited from being used for
Chokhani [Page 19]
Internet-Draft CPF and CPSF January 1997
6.2 IDENTIFICATION AND AUTHENTICATION (I&A) POLICY
This component contains the I&A policies for subject CAs, subject
RAs, and subject end entities. These policies could be the same
or different for each of these entities.
* Initial Registration
* Routine Rekey
* Rekey After Revocation
* Revocation Request
6.2.1 Initial Registration
This subcomponent contains the following:
* Identification and authentication policy for each subject
type (CA, RA, and end entity) for initial registration
* Types of names assigned to the subject (7)
* Whether names have to be meaningful or not (8)
* Rules for interpreting various name forms
* Whether names have to be unique
* How name claim disputes are resolved
* Whether trademarks are recognized or not
* How trademarks are authenticated
* What role trademarks play in naming and identification and
authentication
* If and how the subject must prove that (s)he possesses the
companion private key for the public key being registered
(9)
* Authentication requirements for organizational identity of
subject (CA, RA, or end entity) (10)
* Authentication requirements for a person acting on behalf
of subject (CA, RA, or end entity) (11)
Chokhani [Page 20]
Internet-Draft CPF and CPSF January 1997
* Number of identifications required
* How a CA or RA validates the identification cards provided
* If the person must present himself to the authenticating
CA or RA
* How an individual as an organizational person is
authenticated (12)
6.2.2 Routine Rekey
This subcomponent contains the I&A policy for routine rekey for
each subject type (CA, RA, and end entity). (13)
6.2.3 Rekey After Revocation -- No Key Compromise
This subcomponent is used to describe the I&A policy for rekey
for each subject type (CA, RA, and end entity) after the
subject certificate has been revoked. (14)
6.2.4 Revocation Request
This subcomponent is used to describe the I&A policy for
revocation request by each subject type (CA, RA, and end
entity). (16)
6.3 KEY MANAGEMENT POLICY
This component consists of the key management policies for the
following entities: issuing CA, subject CAs, subject RAs, and
subject end entities. These four sets of policies could be the
same or different.
6.3.1 Public and Private Key Pair
The key management policies for the issuing CA, subject CAs,
Subject RAs, and subject end entities address the entire life-
cycle of the public and private key pair from generation
through archival and destruction. For each of these types of
entities (issuing CA, subject CA, subject RA, subject end
entity) the following questions should be answered:
6.3.1.1 Key Pair Generation and Installation
1. Who generates the entity public, private key pair?
2. How is the private key provided securely to the
Chokhani [Page 21]
Internet-Draft CPF and CPSF January 1997
entity?
3. How is the entity's public key provided securely to
the certificate issuer?
4. If the entity is a CA (issuing or subject) how is the
entity's public key provided securely to the users?
5. What are the key sizes?
6. Who generates the public key parameters?
7. Is the quality of the parameters checked during key
generation?
8. Is the key generation performed in hardware or
software?
9. For what purposes may the key be used (these purposes
should be same as the key usage flags in the Version 3,
X.509 certificates)?
10. For what purposes may the key must be restricted
to(these purposes should be same as the key usage flags
in the Version 3, X.509 certificates and the key usage
field must be marked criical)?
11. What standards, if any, are required for the module
used to generate the keys? For example, are the keys
certified by the infrastructure required to be generated
using modules complaint with the US FIPS 140-1? If yes,
what is the security level of the module?
6.3.1.2 Private Key Protection
1. Is the private key under n out of m multi-person
control?(18) If yes, provide n and m (two person control
is a special case of n out of m, where n = m = 2)?
2. Is the private key escrowed? (19) If so, who is the
escrow agent, what form is the key escrowed in (examples
include plaintext, encrypted, split key), and what are
the security controls on the escrow system?
3. Is the private key backed up? If so, who is the
backup agent, what form is the key backed up in (examples
include plaintext, encrypted, split key), and what are
the security controls on the backup system?
Chokhani [Page 22]
Internet-Draft CPF and CPSF January 1997
4. Is the private key archived? If so, who is the
archival agent, what form is the key archived in
(examples include plaintext, encrypted, split key), and
what are the security controls on the archival system?
5. Who enters the private key in the cryptographic
module? In what form (i.e., plaintext, encrypted, or
split key)?
6. How is the private key stored in the module (i.e.,
plaintext, encrypted, or split key)?
7. Who can activate (use) the private key? What actions
must be performed to activate the private key (e.g.,
login, power on, supply PIN, insert token/key, automatic,
etc.)? Once the key is activated, is the key active for
an indefinite period, active for one time, or active for
a defined time period?
8. Who can deactivate the private key and how? Example
of how include, logout, power off, remove token/key,
automatic, time expiration, etc.
9. Who can destroy the private key and how? Examples of
how include token surrender, token destruction, key
overwrite, etc.
6.3.1.3 Other Aspects of Key Pair Management
1. Is the public key archived? If so, who is the
archival agent and what are the security controls on the
archival system? The archival system should provide
integrity controls other than digital signatures since:
the archival period may be greater than the cryptanalysis
period for the key and the archive requires tamper
protection, which is not provided by digital signatures.
2. What are the validity periods for the public and the
private key respectively?
Chokhani [Page 23]
Internet-Draft CPF and CPSF January 1997
6.3.2 Critical Security Parameters (20)
The key management policies for the issuing CA, subject CAs,
Subject RAs, and subject end entities address the entire life-
cycle of the critical security parameters from generation
through archival and destruction. For each of these types of
entities (issuing CA, subject CA, subject RA, subject end
entity) the following questions should be answered:
6.3.2.1 Critical Security Parameter Generation and
Installation
1. Who generates the initial critical security
parameters?
2. How are the critical security parameters provided
securely to the entity?
3. What are the size requirements on the parameters
(e.g., PIN size, password size, etc.)?
6.3.2.2 Critical Security Parameter Protection
1. Are the parameters stored in a token (e.g., crypto
ignition key)?
2. Are the parameters under n out of m multi-person
control? If yes, provide n and m (two person control is
a special case of n out of m, where n = m = 2).
3. Are the parameters escrowed? If so, who is the escrow
agent, what form are the parameters escrowed in (examples
include plaintext, encrypted, split key), and what are
the security controls on the escrow system?
4. Are the parameters backed up? If so, who is the
backup agent, what form are the parameters backed up in
(examples include plaintext, encrypted, split key), and
what are the security controls on the backup system?
5. Are the parameters archived? If so, who is the
archival agent, what form are the parameters archived in
(examples include plaintext, encrypted, split key), and
what are the security controls on the archival system?
6.3.2.3 Other Aspects of Critical Security Parameters
1. Who enters the parameters in the cryptographic module?
Chokhani [Page 24]
Internet-Draft CPF and CPSF January 1997
In what form (i.e., plaintext, encrypted, or split key)?
2. How are the parameters used in the module (e.g., for
authentication and private key activation, private key
decryption and activation, etc.)?
3. What is the recommended life for the parameters?
4. Who can change the parameters?
6.4 LOCAL SECURITY POLICY
This component consists of four security policies for the four
types of entities: one for the issuer CA, one for subject CAs,
one for the subject RAs, and one for subject end-entities. The
following sections describe the items required for these four
security policies:
* Physical Controls
* Procedural Controls
* Personnel Controls
6.4.1 Physical Controls
The physical controls on the facility housing the entity
systems are described.(21)
6.4.2 Procedural Controls
The procedural controls for the entity are described. These
controls include the description of various trusted roles and
responsibilities for each of the roles.(22)
For each of these roles, n out m rules should be defined, i.e.
define how many people are required to perform the task.
Identification and authentication requirements for each role
must also be defined.
Chokhani [Page 25]
Internet-Draft CPF and CPSF January 1997
6.4.3 Personnel Controls
This subcomponent contains the following:
* Background checks and clearance procedures required for
the personnel filling the trusted roles (23)
* Background checks and clearance procedures requirements
for other personnel (24)
* Training requirements and training procedures for each
role
* Any retraining period and retraining procedures for each
role
* Frequency and sequence for job rotation among various
roles
* Sanctions against personnel for unauthorized actions,
unauthorized use of authority, and unauthorized use of
entity systems (25)
* Controls on the contracting personnel for operating the
entity system and facility
- Bonding requirements on contract personnel
- Contractual requirements including indemnification for
damages due to the actions of the contractor personnel
- Audit and monitoring of contractor personnel
- Other controls on contracting personnel
6.5 TECHNICAL SECURITY POLICY
This component consists of four technical security policies for
the four types of entities: one for the issuer CA, one for subject
CAs, one for the subject RAs, and one for subject end- entities.
The following sections describe the items required for these four
technical security policies:
* Computer Security Controls
* Life-Cycle Security Controls
* Network Security Controls
Chokhani [Page 26]
Internet-Draft CPF and CPSF January 1997
* Cryptographic Module Engineering Controls
* Computer Security Assurance
* Life-Cycle Assurance
* Cryptographic Assurance
6.5.1 Computer Security Controls
This subcomponent is used to describe computer security
controls. Examples of computer security controls are: trusted
computing base concept, discretionary access control, labels,
mandatory access controls, object reuse, audit, identification
and authentication, trusted path, security testing, penetration
testing, etc.
6.5.2 Life Cycle Security Controls
This subcomponent is used to describe system development
controls and security management controls.
System development controls include development environment
security, development personnel security, configuration
management security during product maintenance, software
engineering practices, software development methodology,
modularity, layering, use of Fail-Safe design techniques, use
of Fail-Safe implementation techniques (e.g., defensive
programming) and development facility security.
Security management controls include execution of tools and
procedures to ensure that the operational systems and networks
adhere to configured security. These tools and procedures
include checking the integrity of the security software,
firmware, and hardware to ensure their correct operation.
6.5.3 Network Security Controls
This subcomponent is used to describe network security related
controls for the system. Examples of network security controls
are: firewalls, guards, etc.
Chokhani [Page 27]
Internet-Draft CPF and CPSF January 1997
6.5.4 Cryptographic Module Engineering Controls (26)
This subcomponent contains the following aspects of the
cryptographic module: identification of the cryptographic
module boundary, input/output, roles and services, finite state
machine, physical security, software security, operating system
security, algorithm compliance, electromagnetic compatibility,
key management, and self tests.
6.5.5 Computer Security Assurance
This subcomponent is used to describe the computer security
rating for the computer system. The rating could be based on
the Trusted System Evaluation Criteria (TCSEC), Canadian
Trusted Products Evaluation Criteria, European Information
Technology Security Evaluation Criteria, or the Common
Criteria.
This subcomponent is also used to describe the evaluation
analysis, testing, profiling, certification, and/or
accreditation related activity undertaken.
6.5.6 Life-Cycle Assurance
This subcomponent is used to describe the life-cycle security
controls rating such as the Trusted Software Development
Methodology (TSDM) level, IV&V, independent life-cycle security
controls audit, and Software Engineering Institute's Capability
Maturity Model (SEI-CMM).
6.5.7 Cryptographic Assurance
This subcomponent is used to describe the cryptographic
module's compliance with applicable standards (e.g., US FIPS
140-1). (27)
6.6 OPERATIONS POLICY
The operations policy is used to describe the operating procedures
for the issuing CA, subject CAs, subject RAs, and subject end
entities. Each operations policy consists of the following
subcomponents:
* revocation policy
* key compromise policy
* audit policy
Chokhani [Page 28]
Internet-Draft CPF and CPSF January 1997
* archive policy
* key changeover policy
* recovery procedures
* compliance audit
* non-disclosure policy. The subject end entity policy does
not contains the non-disclosure policy subcomponent.
6.6.1 Revocation Policy
This subcomponent contains the following:
* Circumstances under which the entity certificate may be
revoked
* Who can request the revocation of the entity certificate
* Procedures used for certificate revocation request
* Revocation request grace period available to the entity
* Circumstances under which the entity certificate may be
suspended (held)
* Who can request the suspension (hold) of the entity
certificate
* Procedures used for certificate suspension (hold) request
* How long the suspension may last
* CRL issuance frequency by the entity
* Requirements on the entity to check CRLs
* On-line revocation checks available
* Requirements on the entity to perform on-line revocation
checks
* Other forms of revocation advertisements available
* Requirements on the entity to checks other forms of
revocation advertisements
Chokhani [Page 29]
Internet-Draft CPF and CPSF January 1997
6.6.2 Key Compromise Policy
This subcomponent is used to describe the following:
* Procedures used by the entity to report key compromise
* Key compromise notification grace period available to the
entity
* Key compromise CRL issuance frequency by the entity
* Requirements on the entity to check key compromise CRL
6.6.3 Audit Policy
This subcomponent is used to describe the following:
* Types of events the entity audits (28)
* Frequency with which each event is audited
* Period for which audit logs are kept
* Protection of audit logs
- Who can view the audit log
- Protection against modification of audit log
- Protection against deletion of audit log
* Audit log back up procedures
* Whether the audit collection system is internal or
external to the entity
* Whether the subject who caused an audit event to occur is
notified of the audit action
Chokhani [Page 30]
Internet-Draft CPF and CPSF January 1997
6.6.4 Archive Policy
This subcomponent is used to describe the following:
* Types of event to be archived (29)
* Retention period for archive
* Protection of archive
- Who can view the archive
- Protection against modification of archive
- Protection against deletion of archive
* Archive back up procedures
* Whether the archive collection system is internal or
external to the entity
* Archive custodian in case of entity termination
* Procedures to obtain and verify archive information
6.6.5 Key Changeover
This subcomponent contains the following:
* Entity public key validity period
* Procedures to provide the new entity public key to the
users
6.6.6 Recovery Procedures
This subcomponent is used to describe the disaster recovery
procedures for the entity.
This subcomponent also contains the recovery procedures used by
the entity under each of the following circumstances:
* The recovery procedures used if the entity computing
resources, software, and/or data are corrupted or suspected
to be corrupted. These procedures describe how a secure
environment is reestablished, which certificates and CRL are
revoked, whether the entity key is revoked, how the new
entity public key is provided to the users, and how the
Chokhani [Page 31]
Internet-Draft CPF and CPSF January 1997
subjects are recertified.
* The recovery procedures used if the entity public key is
revoked. These procedures describe how a secure environment
is reestablished, how the new entity public key is provided
to the users, and how the subjects are recertified.
* The recovery procedures used if the entity key is
compromised. These procedures describe how a secure
environment is reestablished, how the new entity public key
is provided to the users, and how the subjects are
recertified.
6.6.7 Compliance Audit
This subcomponent contains the following:
* Frequency of compliance audit for the entity
* Identity of the audit entity
* Auditing entity's relationship to the entity being audited
(30)
* List of topics covered under the compliance audit(31)
* Actions taken as a result of a deficiency found during
compliance audit (32)
* Compliance audit results: who are they shared with (e.g.,
subject CA, RA, and/or end entities), who provides them
(e.g., entity being audited, or auditor), how are they
provided, i.e., communication mechanism
6.6.8 Non-disclosure Policy
This subcomponent contains the following:
* Information that must be kept confidential by the entity
* Who is entitled to know what in terms of the reasons for
revocation and suspension of the certificates issued by the
entity
* Who is entitled to know what in terms of the reasons for
revocation and suspension requested by the entity
* Information that can be revealed to the law enforcement
Chokhani [Page 32]
Internet-Draft CPF and CPSF January 1997
personnel
* Information that can be revealed as part of civil
discovery
* List of other mitigating circumstances under which
confidential information may be disclosed
6.7 LEGAL PROVISIONS
The legal provisions include the following subcomponents for each
of the four types of the entities (issuing CA, subject CAs,
subject RAs, and subject end entities):
* Entity Liability Policy
* Entity Obligations
* Certificate User (Relying Party) Obligations
* Financial Responsibility
* Laws and Procedures
* Fees
The subject end entities only contain the following subcomponents:
entity liability policy, entity obligations.
6.7.1 Entity Liability Policy
This subcomponent contains the following:
* Warranties and disclaimers of warranties
* Liabilities and limitations on liabilities
6.7.2 Entity Obligations
This subcomponent contains the following:
* Entity's obligations in terms of accuracy of
representation
* Obligations of the entity to protect the private key
* Purpose for which the entity's private key is constrained
to be used for
Chokhani [Page 33]
Internet-Draft CPF and CPSF January 1997
* Entity's obligations for notification of issuance of a
certificate to the subscriber who is the subject of the
certificate being issued
* Entity's general obligations for notification of issuance
of a certificate to others than the subject of the
certificate
* Entity's obligations for notification of revocation of a
certificate to the subscriber whose certificate is being
revoked
* Entity's general obligations for notification of
revocation of a certificate to others than the subject whose
certificate is being revoked
* Entity's obligations for notification of suspension of a
certificate to the subscriber whose certificate is being
suspended
* Entity's general obligations for notification of
suspension of a certificate to others than the subject whose
certificate is being suspended
6.7.3 Certificate User (Relying Party) Obligations
This subcomponent contains the following elements:
* Purposes for which a relying party may use the
certificates issued by the entity
* Certificate verification responsibilities of the relying
parties
* Revocation and suspension checking responsibilities of the
relying parties
6.7.4 Financial Responsibility
This subcomponent contains the following elements:
* Indemnification clause for the entity by the certificate
users
* Fiduciary relationship of the entity with subscribers and
entities in the infrastructure
Chokhani [Page 34]
Internet-Draft CPF and CPSF January 1997
6.7.5 Laws and Procedures
This subcomponent contains the following elements:
* Statement about applicable laws and regulations
* Dispute resolution procedures
6.7.6 Fees
This subcomponent contains the following elements:
* Certificate issuance fee
* Certificate access fee
* Revocation information access fee
* Fee for other services such as the certificate status,
policy information, etc.
* Refund policy for the various services
6.8 CERTIFICATE AND CRL PROFILES
This component is used to define the certificate and CRL versions
and extensions supported (populated) by the issuing CA and the
subject CAs. This component contains the following information:
* Certificate Profile
* CRL Profile
6.8.1 Certificate Profile
This subcomponent has the following information: certificate
version, naming, policy related information.
6.8.1.1 Certificate Version
This subcomponent has the following elements:
* A list of version numbers supported for the certificate
* A list of certificate profiles (e.g., PKIX, Federal
PKI, or ANSI X9.57, etc.)
* Certificate extensions populated and their criticality.
Chokhani [Page 35]
Internet-Draft CPF and CPSF January 1997
* Signature, key management, and other cryptographic
algorithms object identifiers
6.8.1.2 Naming
This subcomponent has the following elements:
* Name forms used for the CA, RA, and end entity names
* Name constraints used and the name forms used in the
name constraints
6.8.1.3 Policy
This subcomponent has the following elements:
* Applicable policy OID for this policy
* Typical values for the following fields within the
policy constraints extension: require explicit policy and
inhibit policy mapping
* Policy qualifiers syntax, semantics, and their
processing semantics
* Processing semantics for the critical certificate
policy extension
6.8.2 CRL Profile
This subcomponent has the following elements:
* A list of the version numbers supported for CRLs
* CRL and CRL entry extensions populated and their
criticality
6.9 POLICY ADMINISTRATION
This component is used to define the authority that is responsible
for the registration, maintenance, and interpretation of the
policy.
Chokhani [Page 36]
Internet-Draft CPF and CPSF January 1997
6.9.1 Contact Information
This subcomponent includes the name, mailing address of the
organization, and the name, electronic mail address, telephone
number, and fax number of a contact person. It also describes
who performs the analysis of a CPS to determine its suitability
as an implementation vehicle for the policy.
6.9.2 Policy Definition and Practice Statement Change Procedures
It will occasionally be necessary to change certificate
policies and Certification Practice Statements. Some of these
changes will not change the assurance that a certificate policy
or its implementation provide, and will be judged by the policy
administrator as not changing the acceptability of certificates
asserting the policy for the purposes for which they have been
used. Such changes to security policies and Certification
Practice Statements need not require a change in the policy
Object Identifier (OID). Changes to other policy components
(or their implementations) will change the acceptability of
certificates for specific purposes, and these changes will
require changes to the OID representing the changed policy.
This subcomponent contains the following information:
* a list of policy or CPS components, subcomponents, and
elements that can be changed without notification and
without changes to the policy OID.
* a list of the policy or CPS components, subcomponents, and
elements that may change following a notification period
without changing the policy OID. The procedures to be used
to notify interested parties (relying parties, certification
authorities, etc.) of the policy or CPS changes is
described. The description of notification procedures
includes the notification mechanism, notification period for
comments, mechanism to receive, review and incorporate the
comments, mechanism for final changes to the policy, and the
period before final changes become effective.
* a list of components, subcomponents, and elements changes
to which require a change in the policy object identifier.
Chokhani [Page 37]
Internet-Draft CPF and CPSF January 1997
6.9.3 Publication and Notification Policies
This subcomponent contains the following elements:
* list of components, subcomponents, and elements that are
not published in the CPS(33)
* descriptions of mechanisms used to distribute the policy,
CPS, certificates, certificate status, and CRLs
* access control on information objects including the
policy, CPS, certificates, certificate status, and CRLs
* notification procedures for the security breaches of CA
and RA
* procedures for termination and for termination
notification of the CA and RA, including the identity of the
custodian of CA and RA archival records
7. CERTIFICATE POLICY AND CPS OUTLINE
This appendix contains a possible outline for a certificate policy or a
CPS. With further development, it is intended to evolve to a standard
template suitable for use by certificate policy or CPS writers. Such a
common format will facilitate:
1. ease in comparing two policies during cross-certification (for the
purpose of equivalency mapping).
2. ease in comparing a CPS with a policy to ensure that the CPS
faithfully implements the policy.
3. ease in comparing two CPS for equivalency.
Following is the proposed outline for a certificate policy or CPS.
Since a certificate policy and a CPS both address the same issues (a CPS
is a detailed description of how a policy is implemented), we expect
that they both should be able to use the same outline.
It is proposed that the upper two levels of this outline form the basis
of a certificate policy or CPS template. Lower level items constitute a
useful checklist for the certificate or CPS writer, but would not form
part of the template.
COMMUNITY AND APPLICABILITY
Types of CAs certified
Chokhani [Page 38]
Internet-Draft CPF and CPSF January 1997
Types of RAs certified
Types of end entities certified
Applicability
List of suitable applications
List of approved applications
List of prohibited applications
IDENTIFICATION AND AUTHENTICATION (34)
Initial registration
Types of names
Need for names to be meaningful
Rules for interpreting various name forms
Uniqueness of names
Name claim dispute resolution procedure
Recognition, authentication and role of trademarks in I&A
Method to prove possession of private key
Authentication of organization identity
Authentication of individual identity
Number of identifications required
Authentication confirmation procedure
Need to present in person
Routine Rekey
Authentication method
Method to prove possession of private key
Rekey after revocation
Chokhani [Page 39]
Internet-Draft CPF and CPSF January 1997
Authentication method
Method to prove possession of private key
Revocation Request
Authentication method
KEY MANAGEMENT (34)
Key Pair Generation and Installation
Key pair generating entity
Method for private key delivery to entity
Method for public key delivery to certificate issuer
Method for CA public key delivery to users
Key sizes
Public key parameters generating entity
Parameter quality checking
Hardware/software key generation
Key usage purposes (as per X.509 v3 key usage field)
Key usage restrictions (as per X.509 v3 critical key usage field)
Standards for cryptographic module
Private Key Protection
Private key under (n out of m) multi-person control
Private key escrow
Private key backup
Private key archival
Private key entry into cryptographic module
Storage form of the private key in the module
Chokhani [Page 40]
Internet-Draft CPF and CPSF January 1997
Method of activating private key
Method of deactivating private key
Method of destroying private key
Other Aspects of Key Pair Management
Public key archival
Usage periods for the public and private keys
Critical Security Parameters Generation and Installation
Critical security parameter generating entity
Method for delivery of critical security parameters
Critical security parameter sizes
Critical Security Parameter Protection
Storage medium for critical security parameters
Critical security parameters under (n out of m) multi-person
control
Critical security parameters escrow
Critical security parameters backup
Critical security parameters archival
Other Aspects of Critical Security Parameters
Critical security parameters entry into cryptographic module
Critical security parameters purpose
Usage periods for critical security parameters
Changes to critical security parameters
LOCAL SECURITY POLICY (34)
Physical controls
Procedural controls
Chokhani [Page 41]
Internet-Draft CPF and CPSF January 1997
Separation of duties
n out of m rule for each role
I&A requirement for each role
Personnel Controls
Clearance procedures
Training requirements
Retraining period and requirements
Job rotation frequency and sequence
Sanctions for unauthorized use
Contracting personnel
Bonding requirements
Indemnification for damages due to contractor
Audit and monitoring of contractor personnel
Other controls
TECHNICAL SECURITY POLICY (34)
Computer security controls
Trusted Computing Base
Identification and Authentication
Discretionary Access Controls
Labels
Mandatory Access Controls
Object Reuse
Audit
Trusted Path
Chokhani [Page 42]
Internet-Draft CPF and CPSF January 1997
Security Testing
Penetration Testing
Life cycle technical controls
System development controls
Development environment security
Development personnel security
Configuration management
Development facility physical controls
Software engineering practices
Software development methodology
Modularity
Layering
Fail-Safe Design
Fail-Safe Implementation
Security management controls
Procedures
Tools
Software Integrity
Firmware Integrity
Hardware Integrity
Network security controls
firewalls and guard
firewall and guard policy
firewall and guard security rating
Chokhani [Page 43]
Internet-Draft CPF and CPSF January 1997
Crypto Engineering Controls
input/output
roles and services
finite state machine
physical security
software security
operating system security
algorithm compliance
electromagnetic compatibility
key management
self tests
Computer Security Assurance
standard
rating organization
accreditation of rating organization
rating
Evaluation analysis
Security testing
System security profiling
System certification and/or accreditation
Life-cycle Security Assurance
TSDM level, rating organization, and accreditation of rating
organization
IV&V
Independent life-cycle security controls audit
Chokhani [Page 44]
Internet-Draft CPF and CPSF January 1997
SEI CMM level, rating organization, and accreditation of rating
organization
Cryptographic Module Assurance
standard
rating organization
accreditation of rating organization
rating
OPERATIONS POLICY (34)
Revocation
When can entity (CA, RA, or end entity) certificate be revoked
Who can request revocation of entity certificate
Procedure for entity certificate revocation
Revocation request grace period
When can the entity certificate be suspended (put on hold)
Who can request the entity certificate suspension
Procedures for entity certificate suspension request
Length of suspension
CRL issuance frequency by the entity (if applicable)
CRL check requirement on the entity
On-line revocation checks available
Requirements on the entity to perform on-line revocation checks
Other forms of revocation advertisements available
Requirements on the entity to check other forms of revocation
advertisements
Key compromise
Procedure used by the entity to report key compromise
Chokhani [Page 45]
Internet-Draft CPF and CPSF January 1997
Key compromise notification grace period
Key compromise CRL issuance by the entity (if applicable)
Requirement on the entity to check key compromise CRL
Audit policy
Types of event to be audited
Frequency with which each event is audited
Retention period for audit log
Protection of audit log
Who can view the audit log
Protection against modification of audit log
Protection against deletion of audit log
Audit log back up procedures
Audit collection system (internal or external to the entity)
Notification to audit causing subject
Archive policy
Types of event to be archived
Retention period for archive
Protection of archive
Who can view the archive
Protection against modification of archive
Protection against deletion of archive
Archive back up procedures
Archive collection system (internal or external to the entity)
Archive custodian in case of entity termination
Chokhani [Page 46]
Internet-Draft CPF and CPSF January 1997
Procedures to obtain and verify archive information
Key changeover
Public key validity period
Procedures to provide new key to users
Recovery procedures
Disaster recovery procedures
Recovery from entity resources corruption
Recovery from entity public key revocation (no key compromise)
Recovery from entity private key compromise
Compliance audit
Frequency of entity compliance audit
Entity's relationship to the auditor
Topic covered by the audit
Actions taken as a result of deficiency
Entities who are provided the results of compliance audit
Entity who provides the results of compliance audit
Mechanism used to provide results of compliance audit
Non-disclosure policy
Information to be kept confidential by the entity
Disclosure rules (who can be told what) for reasons of
revocation/suspension of certificates
Information that can be revealed to the law enforcement personnel
Information that can be revealed as part of civil discovery
Mitigating circumstances when confidential information may be
disclosed
Chokhani [Page 47]
Internet-Draft CPF and CPSF January 1997
LEGAL PROVISIONS
Certification Authority
Liability
Warranties and disclaimers of warranties
Liabilities and limitations on liabilities
CA obligations
Accuracy of representations
Protection of issuing CA private key
Restrictions on issuing CA private key use
Notification of issuance of a certificate to the subject of the
certificate
Notification of issuance of a certificate to others
Notification of revocation of a certificate to the subject of
the certificate
Notification of revocation of a certificate to others
Notification of suspension of a certificate to the subject of
the certificate
Notification of suspension of a certificate to others
Certificate user obligations
Use of certificates for appropriate purpose
Certificate verification responsibilities
Revocation/suspension check responsibility
Financial responsibility
Indemnification of issuing CA by certificate users
Fiduciary relationships of the issuing CA
Laws and procedures
Chokhani [Page 48]
Internet-Draft CPF and CPSF January 1997
Applicable laws and regulations
Dispute resolution procedures
Fees
Certificate issuance fee
Certificate access fee
Revocation information access fee
Fee for other services such as the certificate status, policy
information, etc.
Refund policy for the various services.
Registration Authority
Liability
Warranties and disclaimers of warranties
Liabilities and limitations on liabilities
Subject RA obligations
Accuracy of representations
Protection of RA private key
Restrictions on RA private key use
Certificate user obligations
Use of certificates for appropriate purpose
Certificate verification responsibilities
Revocation/suspension check responsibility
Financial responsibility
Indemnification of RA by certificate users
Fiduciary relationships of RA
Laws and procedures
Chokhani [Page 49]
Internet-Draft CPF and CPSF January 1997
Applicable laws and regulations
Dispute resolution procedures
Fees
Certificate registration fee
Certificate revocation fee
Fee for other services
Refund policy for the various services.
End entity
Liability
Warranties and disclaimers of warranties
Liabilities and limitations on liabilities
End entity obligations
Accuracy of representations
Protection of end entity private key
Restrictions on end entity private key use
CERTIFICATE AND CRL PROFILES (34)
Certificate Profile
Certificate Version
A list of version numbers supported for the certificate
A list of certificate profiles (e.g., PKIX, Federal PKI, or
ANSI X9.57, etc.)
Certificate extensions populated and their criticality.
Signature, key management, and other cryptographic algorithms
object identifiers
Naming
Chokhani [Page 50]
Internet-Draft CPF and CPSF January 1997
Name forms used for the CA, RA, and end entity names
Name constraints used and the name forms used in the name
constraints
Policy
Applicable policy OID for this policy
Typical values for the following fields within the policy
constraints extension: require explicit policy and inhibit
policy mapping
Policy qualifiers syntax, semantics, and their processing
semantics
Processing semantics for the critical certificate policy
extension
CRL Profile
A list of the version numbers supported for CRLs
CRL and CRL entry extensions populated and their criticality
POLICY ADMINISTRATION
Contact information
Name and mailing address of the policy administration organization
Name, electronic mail address, telephone number, and fax number of
a contact person
Name and telephone number of person determining CPS suitability
for the policy
Policy definition change procedures
List the items that can change without notification
Items that can change with notification
List of items
Notification mechanism
Comment period
Chokhani [Page 51]
Internet-Draft CPF and CPSF January 1997
Mechanism to handle comments
Period for final change notice
List of items whose change requires a new policy
Publication and notification policies
List of items not published in the CPS
Mechanisms used to distribute policy, CPS, certificates,
certificate status, and CRLs.
Access control on information objects including the policy, CPS,
certificates, certificate status, and CRLs
Notification procedures for security breaches of issuing CA
Notification procedures for security breaches of subject CA
Notification procedures for security breaches of subject RA
Termination procedure and notification for issuing CA
Termination procedure and notification for subject CA
Termination procedure and notification for subject RA
8. LIST OF ACRONYMS
ABA - American Bar Association
CA - Certification Authority
CC - Common Criteria
CMM - Capability Maturity Model
CPS - Certification Practice Statement
CRL - Certificate Revocation List
DAM - Draft Amendment
DAP - Directory Access Protocol
FIPS - Federal Information Processing Standard
FSDA - Fail Safe Design Analysis
I&A - Identification and Authentication
IEC - International Electrotechnical Commission
IETF - Internet Engineering Task Force
IP - Internet Protocol
Chokhani [Page 52]
Internet-Draft CPF and CPSF January 1997
ISO - International Organization for Standardization
ITU - International Telecommunications Union
IV&V - Independent Validation and Verification
MSP - Message Security Protocol
NIST - National Institute of Standards and Technology
OID - Object Identifier
PIN - Personal Identification Number
PKCS - Public Key Cryptography Standard
PKI - Public Key Infrastructure
PKIX - Public Key Infrastructure (X.509) (IETF Working Group)
RA - Registration Authority
RFC - Request For Comment
SEI - Software Engineering Institute
S-HTTP - Secure HyperText Transfer Protocol
S/MIME - Secure/Multipurpose Internet Mail Extension
TCP - Transmission Control Protocol
TCSEC - Trusted Computer System Evaluation Criteria
TSDM - Trusted Software Development Methodology
URL - Uniform Resource Locator
US - United States
9. GLOSSARY OF TERMS
Accreditation: A decision by the responsible official of the
organization to operate a system and accept the residual risks
identified by the certification activities, or to accept the risks
even though no certification activities have been done or completed.
(System) Certification: A series of security engineering activities
to ensure that the security requirements for a system are implemented
correctly, and to identify residual risks. The certification
activities typically consist of security analysis of the system
architecture, design, and implementation and security testing of the
system.
End Entity: A person or a computer system who is not a CA or RA.
Entity: A CA, RA, or end entity.
Relying Party: Someone who uses a public key in a certificate to
Chokhani [Page 53]
Internet-Draft CPF and CPSF January 1997
either verify a digital signature or to encrypt keys or data.
Critical Security Parameters: security-related information (e.g.,
cryptographic keys, authentication data such as passwords and
personal identification number (PIN))
Subject: An entity whose public key is certified in a public key
certificate.
Subject End Entity: An end entity who is the subject of a
certificate.
Subscriber: See subject
User: See relying party
10. ENDNOTES
1 Extracts of the ABA Digital Signature Guidelines presented in this
report are taken from the 1995 draft version which was publicly
released for review and comment. Later work revising the document
has not been publicly released, but does not materially impact the
correctness of this report.
2 Example: A bank claims that it issues CA certificates to its
branches only. Now, the user of a CA certificate issued by the bank
can assume that the subject CA in the certificate is a branch of the
bank.
3 Example: A Government CA claims that it issues certificates to
Government employees only. Now, the user of a certificate issued by
the Government CA can assume that the subject of the certificate is a
Government employee.
4 Examples of the types of subject CA entities are a subordinate
organizations (e.g., branch, division, etc.), a US Federal Government
agency, a Government of Canada agency, a state agency, a provincial
department, etc.
5 Examples of the types of subject RA entities are branch and
division of an organization.
6 Examples of types of subject end entities are uniformed and
civilian DoD personnel, DoD contractors, Ministry of Defense
employees, bank customers, telephone company subscribers, etc.
7 Examples include X.500 distinguished names, RFC 822 Internet names,
URL, etc.
Chokhani [Page 54]
Internet-Draft CPF and CPSF January 1997
8 The term meaningful means that the name form has commonly
understood semantics to determine identity of the person and/or
organization. The directory names and RFC 822 names are examples of
meaningful names.
9 Examples of proof include the issuing CA generating the key, or
requiring the subject to send an electronically signed request or to
sign a challenge.
10 Examples of organization identity authentication are: articles of
incorporation, duly signed corporate resolutions, company seal, and
notarized documents.
11 Examples of individual identity authentication are: biometrics
(thumb print, ten finger print, face, palm, and retina scan),
driver's license, passport, credit card, company badge, and
government badge.
12 Examples include duly signed authorization papers, corporate
badge, etc.
13 The identification policy for routine rekey should be the same as
the one for initial registration since the same subject needs
rekeying. The rekey authentication may be accomplished using the
techniques for initial I&A or using digitally signed requests.
14 This I&A policy could be the same as the one for initial
registration.
15 This policy could be the same as the one for initial registration.
16 The identification policy for Revocation request could be the same
as the one for initial registration since the same subject
certificate needs to be revoked. The authentication policy could
accept a Revocation request digitally signed by subject. The
authentication information used during initial registration could be
acceptable for Revocation request. Other less stringent
authentication policy could be defined.
17 The identification policy for key compromise notification could be
the same as the one for initial registration since the same subject
certificate needs to be revoked. The authentication policy could
accept a Revocation request digitally signed by subject. The
authentication information used during initial registration could be
acceptable for key compromise notification. Other less stringent
authentication policy could be defined.
18 The n out of m rule allows a key to be split in m parts. The m
Chokhani [Page 55]
Internet-Draft CPF and CPSF January 1997
parts may be given to m different individuals. Any n parts out of
the m parts may be used to fully reconstitute the key, but having any
n-1 parts provides one with no information about the key.
19 A key may be escrowed, backed up or archived. Each of these
functions have different purpose. Thus, a key may go through any
subset of these functions depending on the requirements. The purpose
of escrow is to allow a third party (such as an organization or
government) to legally obtain the key without the cooperation of the
subject. The purpose of back up is to allow the subject to
reconstitute the key in case of the destruction of the key. The
purpose of archive is to provide for reuse of the key in future,
e.g., use the private key to decrypt a document.
20 The critical security parameters are the information other than
the public and private key pair and public key parameters required to
operate the module. An example of a critical security parameters is
a PIN or passphrase. The public key parameters are NOT an example of
critical security parameters.
21 Examples of physical controls are: monitored facility, guarded
facility, locked facility, access controlled using tokens, access
controlled using biometrics, access controlled through an access
list, etc.
22 Examples of the roles include, system administrator, system
security officer, system auditor, and crypto officer. The duties of
the system administrator are to configure, generate, boot, and
operate the system. The duties of the system security officer are to
assign accounts and privileges. The duties of the system auditor are
to set up system audit profile, perform audit file management, and
audit review. The duties of the crypto officer are to hold, manage,
and protect the CA keys and PINs, and to use them to operate the
cryptographic devices used by the CA to sign the certificates and the
CRLs.
23 The background checks may include clearance level (e.g., none,
sensitive, confidential, secret, top secret, etc.) and the clearance
granting authority name. In lieu of or in addition to a defined
clearance, the background checks may include types of background
information (e.g., name, place of birth, date of birth, home address,
previous residences, previous employment, and any other information
that may help determine trustworthiness). The description should
also include which information was verified and how.
24 For example, the certificate policy may impose personnel security
requirements on the network system administrator responsible for a
CA's network access.
Chokhani [Page 56]
Internet-Draft CPF and CPSF January 1997
25 Each authorized person should be accountable for his/her actions.
26 A cryptographic module is hardware, software, or firmware or any
combination of them.
27 The compliance description should be specific and detailed. For
example, for each FIPS 140-1 requirement, describe the level and
whether the level has been certified by an accredited laboratory.
28 Example of audit events are: request to create a certificate,
request to revoke a certificate, key compromise notification,
creation of a certificate, revocation of a certificate, issuance of a
certificate, issuance of a CRL, issuance of key compromise CRL,
establishment of trusted roles on the CA, actions of truste
personnel, changes to CA keys, etc.
29 Example of archive events are: request to create a certificate,
request to revoke a certificate, key compromise notification,
creation of a certificate, revocation of a certificate, issuance of a
certificate, issuance of a CRL, issuance of key compromise CRL, and
changes to CA keys.
30 a parent CA is an example of audit relationship.
31 Example of compliance audit topics: sample check on the various
I&A policies, comprehensive checks on key management policies,
comprehensive checks on system security controls, comprehensive
checks on operations policy, and comprehensive checks on certificate
profiles,
32 The examples include, temporary suspension of operations until
deficiencies are corrected, revocation of entity certificate, change
in personnel, invocation of liability policy, more frequent
compliance audit, etc.
33 An organization may choose not to make public some of its security
controls, clearance procedures, or some others elements due to their
sensitivity.
34 All or some of the following items may be different for the
various types of entities, i.e., CA, RA, and end entities.
11. Security Considerations
This entire memo deals with security related to public key certificates.
Chokhani [Page 57]
Internet-Draft CPF and CPSF January 1997
12. Acknowledgments
We would like to thank Dave Fillingham and Jim Brandt for their
inspiration, numerous valuable suggestions and inputs. We would also
like to thank Edmond Van Hees for his support and inputs. We would
also like to thank the Government of Canada's Policy Management
Authority (PMA) Committee for their contribution and support of this
work.
This document has been developed under the guidance of the
International Policy Framework Working Group. The members of this
working group are: Richard Bloom, US Federal Security Infrastructure
Program Management Office; Santosh Chokhani (Co-Author), CygnaCom
Solutions, Inc.; David W. Fillingham, National Security Agency;
Warwick Ford (Co-Author); Richard Kemp, US Federal Security
Infrastructure Program Management Office; Noel Nazario, National
Institute of Standards and Technology; David Simonetti, Booz, Allen
and Hamilton; and Edmond Van Hees, Communication Security
Establishment, Government of Canada.
We would also like the following industry members for their review
and input: Teresa Acevedo, A&N Associates; Michael Baum, Verisign;
Patrick Cain, BBN; Michael Harrop, Government of Canada Treasury
Board; John Morris, CygnaCom Solutions, Inc.; Tim Moses, Nortel; John
Nicolletos, A&N Associates; Jean Petty, CygnaCom Solutions, Inc.; and
Darryl Stal, Nortel.
Johnny Hsiung and Chris Miller assisted in the preparation of the
manuscript.
13. Author's Address
Questions about this document can be directed to the authors:
Santosh Chokhani
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, VA 22102
Phone: (703) 848-0883
Fax: (703) 848-0960
EMail: chokhani@cygnacom.com
Warwick Ford
VeriSign, Inc.
Chokhani [Page 58]
Internet-Draft CPF and CPSF January 1997
Phone: (613) 225-3487
Fax: (613) 225-6361
Email: wford@verisign.com
expires in six months June 1997
Chokhani [Page 59]