< draft-ietf-pkix-roadmap-03.txt   draft-ietf-pkix-roadmap-04.txt >
PKIX Working Group A. Arsenault PKIX Working Group A. Arsenault
INTERNET DRAFT DOD INTERNET DRAFT DOD
S. Turner S. Turner
IECA IECA
Expires in six months from September 8, 1999 Expires April 22, 2000 October 22, 1999
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
PKIX Roadmap PKIX Roadmap
<draft-ietf-pkix-roadmap-03.txt> <draft-ietf-pkix-roadmap-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 1, line 37 skipping to change at page 1, line 36
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of current Internet-Drafts Shadow Directories can be The list of current Internet-Drafts Shadow Directories can be
accessed at http://www.ietf.org/shadow.html accessed at http://www.ietf.org/shadow.html
Abstract Abstract
This document provides an overview or 'roadmap' of the work done by This document provides an overview or "roadmap" of the work done by
the IETF PKIX working group. It describes some of the terminology the IETF PKIX working group. It describes some of the terminology
used in the working group's documents, and the theory behind an used in the working group's documents, and the theory behind an
X.509-based PKI. It identifies each document developed by the PKIX X.509-based Public Key Infrastructure and Privilege Management
working group, and describes the relationships among the various Infrastructure (PMI). It identifies each document developed by the
PKIX working group, and describes the relationships among the various
documents. It also provides advice to would-be PKIX implementors documents. It also provides advice to would-be PKIX implementors
about some of the issues discussed at length during PKIX development, about some of the issues discussed at length during PKIX development,
in hopes of making it easier to build implementations that will in hopes of making it easier to build implementations that will
actually interoperate. actually interoperate.
1 Introduction 1 Introduction
1.1 This Document 1.1 This Document
This document is an informational Internet draft that provides a This document is an informational Internet draft that provides a
"roadmap" to the documents produced by the PKIX working group. It is "roadmap" to the documents produced by the PKIX working group. It is
intended to provide information; there are no requirements or intended to provide information; there are no requirements or
specifications in this document. specifications in this document.
Section 2 of this document defines key terms used in this document. Section 2 of this document defines key terms used in this document.
Section 3 covers "PKIX theory"; it explains what the PKIX working Section 3 covers "PKIX theory;" it explains what the PKIX working
group's basic assumptions were. Section 4 provides an overview of the group's basic assumptions were. Section 4 provides an overview of the
various PKIX documents. It identifies which documents address which various PKIX documents. It identifies which documents address which
areas, and describes the relationships among the various documents. areas, and describes the relationships among the various documents.
Section 5 contains "Advice to implementors". Its primary purpose is Section 5 contains "Advice to implementors." Its primary purpose is
to capture some of the major issues discussed by the PKIX working to capture some of the major issues discussed by the PKIX working
group, as a way of explaining WHY some of the requirements and group, as a way of explaining WHY some of the requirements and
specifications say what they say. This should cut down on the number specifications say what they say. This should cut down on the number
of misinterpretations of the documents, and help developers build of misinterpretations of the documents, and help developers build
interoperable implementations. Section 6 contains a list of interoperable implementations. Section 6 contains a list of
references. Section 7 discusses security considerations, and Section contributors we wish to thank. Section 7 provides a list references.
8 provides contact information for the editors. Section 8 discusses security considerations, and Section 9 provides
contact information for the editors. Finally, Section 10 provides a
disclaimer.
1.2 Changes Since Last Version
Updated refences to current drafts.
Added terminology to paragraph 2 for Attribute Authorities, Attribute
Certificates, Certificates, Public Key Certificates, Public Key
Infrastructure, and Privilege Management Infrastructure.
Split paragraph 3.1 and 3.3 in two to allow seperate descriptions for
PKI (i.e., PKC discussions) and PMI (i.e., AC discussions).
Updated PKIX History (paragraph 3.2).
Split paragraph 3.4 in two to accomdate discussions for both X.509
Certificates and Attribute Certificates.
Updated Profiles, Operational Protocols, and Management Protocols
paragraphs 3.6.1, 3.6.2, and 3.6.3, respectively.
Updated Revocation paragraph 3.5.8 to indicate why a certificate is
retained on a CRL for one additional period.
Added descriptions for new drafts in 4.1-4.5: Operation Protocols -
LDAPv3, Simple Certificate Validation Protocol (SCVP), Using HTTP as
Transport Protocol for CMP, Using TCP as Transport Protocol for CMP,
Limited Attribute Certificate Aquisition Protocol (LAAP), OCSP
Extensions
Added paragraph 4.6 to talk about drafts that didn't make it through
working group review.
Removed references to [BERT1], [CACHE], and [WEB] from paragraph 7.
1.3 To Do
Add text in paragraph 5.3 to talk about extended key usages.
Add in paragraph to talk about PMI functions.
Add in paragraph to talk about delta between RFC2459 and the updated
RFC2459.
2 Terminology 2 Terminology
There are a number of terms used and misused throughout PKI-related There are a number of terms used and misused throughout PKI-related
literature. To limit confusion caused by some of those terms, and PMI-related literature. To limit confusion caused by some of
throughout this document, we will use the following terms in the those terms, throughout this document, we will use the following
following ways: terms in the following ways:
- Certification Authority (CA) - an authority trusted by one or - Attribute Authority (AA) - An authority trusted by one or more
more users to create and assign certificates. Optionally the users to create and sign attribute certificates. It is important
certification authority may create the user's keys. It is to note that the AA is responsible for the attribute certificates
important to note that the CA is responsible for the during their whole lifetime, not just for issuing them.
certificates during their whole lifetime, not just for issuing
them.
- Certificate Policy (CP) - a named set of rules that indicates - Attribute Certificate (AC) - A data structure containing a set of
the applicability of a certificate to a particular community attributes for an end-entity and some other information, which is
and/or class of application with common security requirements. digitally signed with the private key of the AA which issued it.
For example, a particular certificate policy might indicate
applicability of a type of certificate to the authentication
of electronic data interchange transactions for the trading of
goods within a given price range.
- Certification Practice Statement (CPS) - A statement of the - Certificate - Can refer to either an AC or a public key
practices which a certification authority employs in issuing certificate. Where there is no distinction made the context
certificates. should be assumed to apply to both an AC and a public key
certificate.
- Root CA - a CA that is directly trusted by an end entity; that - Certification Authority (CA) - An authority trusted by one or
is, securely acquiring the value of a root CA public key more users to create and assign public key certificates.
requires some out-of-band step(s). This term is not meant to Optionally the CA may create the user's keys. It is important to
imply that a root CA is necessarily at the top of any note that the CA is responsible for the public key certificates
hierarchy, simply that the CA in question is trusted directly. during their whole lifetime, not just for issuing them.
- Top CA - a CA that is at the top of a PKI hierarchy. - Certificate Policy (CP) - A named set of rules that indicates the
applicability of a public key 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 public key certificate to the
authentication of electronic data interchange transactions for
the trading of goods within a given price range.
Note: This is often also called a "root CA," from since in data - Certification Practice Statement (CPS) - A statement of the
structures terms and in graph theory, the node at the top of a practices which a CA employs in issuing public key certificates.
tree is the "root." However, to minimize confusion in this
document, we elect to call this node a "Top CA," and reserve
"Root CA" for the CA directly trusted by the user. Readers new to
PKIX should be aware that these terms are not used consistently
throughout the PKIX documents, as [RFC2459] uses "Root CA" to
refer to what this and other documents call a "Top CA," and
"most-trusted CA" to refer to what this and other documents call
a "Root CA."
- Subordinate CA - A "subordinate CA" is one that is not a root CA - End-entity - A subject of a certificate who is not a CA in the
for the end entity in question. Often, a subordinate CA will not PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the
be a Root CA for any entity but this is not mandatory. PMI.)
- Registration Authority (RA) - an optional entity given - Public Key Certificate (PKC) - A data structure containing the
public key of an end-entity and some other information, which is
digitally signed with the private key of the CA which issued it.
- Public Key Infrastructure (PKI) - The set of hardware, software,
people, policies and procedures needed to create, manage, store,
distribute, and revoke PKCs based on public-key cryptography.
- Privilege Management Infrastructure (PMI) - A collection of ACs,
with their issuing AA's, subjects, relying parties, and
repositories, is referred to as a Privilege Management
Infrastructure.
- Registration Authority (RA) - An optional entity given
responsibility for performing some of the administrative tasks responsibility for performing some of the administrative tasks
necessary in the registration of subjects, such as: confirming necessary in the registration of subjects, such as: confirming
the subject's identity; validating that the subject is entitled the subject's identity; validating that the subject is entitled
to have the attributes requested in a certificate; and verifying to have the values requested in a PKC; and verifying that the
that the subject has possession of the private key associated subject has possession of the private key associated with the
with the public key requested for a certificate. public key requested for a PKC.
- End-entity - a subject of a certificate who is not a CA.
- Relying party - a user or agent (e.g., a client or server) who - Relying party - A user or agent (e.g., a client or server) who
relies on the data in a certificate in making decisions. relies on the data in a certificate in making decisions.
- Subject - a subject is the entity (CA or end-entity) named in a - Root CA - A CA that is directly trusted by an EE; that is,
securely acquiring the value of a Root CA public key requires
some out-of-band step(s). This term is not meant to imply that a
Root CA is necessarily at the top of any hierarchy, simply that
the CA in question is trusted directly.
- Subordinate CA - A "subordinate CA" is one that is not a Root CA
for the EE in question. Often, a subordinate CA will not be a
Root CA for any entity but this is not mandatory.
- Subject - A subject is the entity (AA, CA, or EE) named in a
certificate. Subjects can be human users, computers (as certificate. Subjects can be human users, computers (as
represented by DNS names or IP addresses), or even software represented by Domain Name Service (DNS) names or Internet
agents. Protocol (IP) addresses), or even software agents.
- Top CA - A CA that is at the top of a PKI hierarchy.
Note: This is often also called a "Root CA," from since in data
structures terms and in graph theory, the node at the top of a tree
is the "root." However, to minimize confusion in this document, we
elect to call this node a "Top CA," and reserve "Root CA" for the
CA directly trusted by the EE. Readers new to PKIX should be aware
that these terms are not used consistently throughout the PKIX
documents, as [FORMAT] uses "Root CA" to refer to what this and
other documents call a "Top CA," and "most-trusted CA" to refer to
what this and other documents call a "Root CA."
3 PKIX Theory 3 PKIX Theory
3.1 Certificate-using Systems and PKIs 3.1 Certificate-using Systems
3.1.1 Certificate-using Systems and PKIs
At the heart of recent efforts to improve Internet security are a At the heart of recent efforts to improve Internet security are a
group of security protocols such as S/MIME, TLS, and IPSec. All of group of security protocols such as Secure Multipurpose Internet Mail
these protocols rely on public-key cryptography to provide services Extensions (S/MIME), Transport Layer Sercurity (TLS), and Internet
such as confidentiality, data integrity, data origin authentication, Protocol Security (IPSec). All of these protocols rely on public-key
and non-repudiation. The purpose of a PKI is to provide trusted and cryptography to provide services such as confidentiality, data
efficient key and certificate management, thus enabling the use of integrity, data origin authentication, and non-repudiation. The
authentication, non-repudiation, and confidentiality. purpose of a PKI is to provide trusted and efficient key and public
key certificate management, thus enabling the use of authentication,
non-repudiation, and confidentiality.
Users of public key-based systems must be confident that, any time Users of public key-based systems must be confident that, any time
they rely on a public key, the associated private key is owned by the they rely on a public key, the associated private key is owned by the
subject with which they are communicating. (This applies whether an subject with which they are communicating. (This applies whether an
encryption or digital signature mechanism is used.) This confidence encryption or digital signature mechanism is used.) This confidence
is obtained through the use of public key certificates, which are is obtained through the use of PKCs, which are data structures that
data structures that bind public key values to subjects. The binding bind public key values to subjects. The binding is achieved by having
is achieved by having a trusted CA verify the subject's identity and a trusted CA verify the subject's identity and digitally sign each
digitally sign each certificate. PKC.
A certificate has a limited valid lifetime which is indicated in its A PKC has a limited valid lifetime which is indicated in its signed
signed contents. Because a certificate's signature and timeliness can contents. Because a PKC's signature and timeliness can be
be independently checked by a certificate-using client, certificates independently checked by a certificate-using client, PKCs can be
can be distributed via untrusted communications and server systems, distributed via untrusted communications and server systems, and can
and can be cached in unsecured storage in certificate-using systems. be cached in unsecured storage in certificate-using systems.
Certificates are used in the process of validating signed data. PKCs are used in the process of validating signed data. Specifics
Specifics vary according to which algorithm is used, but the general vary according to which algorithm is used, but the general process
process works as follows: works as follows:
Note: there is no specific order in which the checks listed below Note: there is no specific order in which the checks listed below
must be made; implementers are free to implement them in the most must be made; implementors are free to implement them in the most
efficient way for their systems. efficient way for their systems.
- The recipient of signed data verifies that the claimed - The recipient of signed data verifies that the claimed identity
identity of the user is in accordance with the identity of the user is in accordance with the identity contained in the
contained in the certificate; PKC;
- The recipient validates that no certificate in the path is - The recipient validates that no PKC in the path is revoked (e.g.,
revoked (e.g., by retrieving a suitably-current by retrieving a suitably-current Certificate Revocation List
Certificate Revocation List (CRL) or querying an on-line (CRL) or querying an on-line certificate status responder), and
certificate status responder), and that all certificates that all PKCs are within their validity periods at the time the
are within their validity periods at the time the data was data was signed;
signed;
- The recipient verifies that the data are not claimed to - The recipient verifies that the data are not claimed to have any
have any attributes for which the certificate indicates values for which the PKC indicates that the signer is not
that the signer is not authorized; authorized;
- The recipient verifies that the data have not been altered - The recipient verifies that the data have not been altered since
since signing, by using the public key in the certificate. signing, by using the public key in the PKC.
If all of these checks pass, the recipient can accept that the data If all of these checks pass, the recipient can accept that the data
was signed by the purported signer. The process for keys used for was signed by the purported signer. The process for keys used for
encryption is similar. encryption is similar.
Note: It is of course possible that the data was signed by someone Note: It is of course possible that the data was signed by someone
very different from the signer, if for example the purported very different from the signer, if for example the purported
signer's private key was compromised. Security depends on all signer's private key was compromised. Security depends on all parts
parts of the certificate-using system, including but not limited of the certificate-using system, including but not limited to:
to: physical security of the place the computer resides; personnel physical security of the place the computer resides; personnel
security (i.e., the trustworthiness of the people who actually security (i.e., the trustworthiness of the people who actually
develop, install, run, and maintain the system); the security develop, install, run, and maintain the system); the security
provided by the operating system on which the private key is used; provided by the operating system on which the private key is used;
and the security provided the CA. A failure in any one of these and the security provided the CA. A failure in any one of these
areas can cause the entire system security to fail. PKIX is areas can cause the entire system security to fail. PKIX is limited
limited in scope, however, and only directly addresses issues in scope, however, and only directly addresses issues related to
related to the operation of the PKI subsystem. For guidance in the operation of the PKI subsystem. For guidance in many of the
many of the other areas, see [POLPROC]. other areas, see [POLPROC].
A collection of certificates, with their issuing CA's, subjects, 3.1.2 Certificate-using Systems and PMIs
relying parties, RA's, and repositories, is referred to as a Public
Key Infrastructure, or PKI.
3.2 PKIX History Many systems use the the PKC to perform identity based access control
decisions (i.e, the identity may be used to support identity-based
access control decisions after the client proves that it has access
to the private key that corresponds to the public key contained in
the PKC). For many systems this is sufficient, but increasingly
systems are beginning to find that rule-based, role-based, and rank-
based access control is required. These forms of access control
decisions require additional information that is normally not
included in a PKC, because the lifetime of the information is much
shorter than the lifetime of the public-private key pair. To support
binding this information to a PKC the Attribute Certificate (AC) was
defined in ANSI and later incorporated into ITU-T Recommendation
X.509. The AC format allows any additional information to be bound to
a PKC by including, in a digitally signed data structure, a refernce
back to one specific PKC or to multiple PKCs, useful when the subject
has the same identity in multiple PKCs. Additionally, the AC can be
constructed in such a way that it is only useful at one or more
particular targets (e.g., web server, mail host).
[This still needs more work.] Users of a PMI must be confident that the identity purporting to
posess an attribute has the right to possess that attribute. This
confidence may be obtained through the use of PKCs or it may be
configured in the AC-using system. If PKCs are used the party making
the access control decision can determine "if the AC issuer is
trusted to issue ACs containing this attribute."
3.2 PKIX History
In the beginning there was ITU-T Recommendation X.509. It defines a In the beginning there was ITU-T Recommendation X.509. It defines a
widely accepted basis for a public-key infrastructure, including data widely accepted basis for a PKI, including data formats and
formats and procedures related to distribution of public keys via procedures related to distribution of public keys via PKCs digitally
certificates digitally signed by CAs. X.509 does not however include signed by CAs. X.509 does not however include a profile to specify
a profile to specify the support requirements for many of the the support requirements for many of the PKC data structure's sub-
certificate data structure's sub-fields, for any of the extensions, fields, for any of the extensions, nor for certain data values. PKIX
nor for certain data values. PKIX was formed in October 1995 to was formed in October 1995 to deliver a profile for the Internet PKI
deliver a profile for the Internet PKI of X.509 version 3 of X.509 version 3 PKCs and version 2 CRLs. The Internet PKI profile
certificates and version 2 CRLs. The Internet PKI profile [FORMAT] [FORMAT] went through eleven draft versions before becoming an RFC.
went through eleven draft versions before becoming an RFC. Other Other profiles have been developed in PKIX for particular algorithms
profiles have been developed in PKIX for particular algorithms to to make use of [FORMAT]. There has been no sense of conflict between
make use of [FORMAT]. There has been no sense of conflict between the the groups that developed these profiles as they are seen as
groups that developed these profiles as they are seen as
complimentary. complimentary.
The development of the management protocols has not been so The development of the management protocols has not been so
straightforward. [CMP] was developed to define a message protocol straightforward. The Certificate Management Protocol (CMP) was
that is used between entities in a PKI. The demand for an enrollment developed to define a message protocol that is used between entities
protocol and the desire to use PKCS-10 message format as the in a PKI [CMP]. The demand for an enrollment protocol and the desire
certificate request syntax lead to the development of two different to use PKCS-10 message format as the certificate request syntax lead
documents in two different groups. The Certificate Request Syntax to the development of two different documents in two different
[CRS] draft was developed in the SMIME WG which used PKCS10 [PKCS10] groups. The Certificate Request Syntax (CRS) draft was developed in
as the certification request message format. Certificate Request the SMIME WG which used PKCS-10 [PKCS10] as the certification request
Message Format [CRMF] draft was also developed but in the PKIX WG. It message format. Certificate Request Message Format [CRMF] draft was
was to define a simple enrollment protocol that would subsume both also developed but in the PKIX WG. It was to define a simple
the [CMP] and [CRS] enrollment protocols, but it did not use PKCS10 enrollment protocol that would subsume both the CMP and CRS
as the certificate request message format. Then, [CMMF] was developed enrollment protocols, but it did not use PKCS-10 as the certificate
to define an extended set of management messages that flow between request message format. Then the certificate management message
the components of the Internet PKI. CMMF over CMS [CMC] was developed format document, was developed to define an extended set of
to allow the use of an existing protocol (S/MIME) as a PKI management management messages that flow between the components of the Internet
PKI. Certificate Management Messages over CMS (CMC) was developed to
allow the use of an existing protocol (S/MIME) as a PKI management
protocol, without requiring the development of an entirely new protocol, without requiring the development of an entirely new
protocol such as CMP [CMP]. It also included [PKCS10] as the protocol such as CMP [CMC]. It also included [PKCS10] as the
certificate request syntax, which caused work on [CRS] to stop. certificate request syntax, which caused work on the CRS draft to
Information from [CMMF] has been moved into [CMP] and [CMC] so [CMMF] stop. Information from the certificate management message format
is being discontinued. document was moved into [CMP] and [CMC] so work on the certificate
management message format document was discontinued.
Another long debated topic in the WG dealt with certificate
revocation. Numerous drafts have been developed to address different
issues related certificate revocations. CMP supports revocation
request, response, revocation announcement, and requests for CRL
messages. CMC defines revocation request, revocation response, and
requests for CRL messages messages, but uses CMS as the encapsulating
protocol. [OCSP] was devloped to address concerns that not all
relying parties want to go through the process checking CRLs from
every CA in the certification path. It defines an on-line mechanism
to determine the status of a given certificate, which may provide
more timely revocation information than is possible with CRLs. The
Simple Certification Verification Protocol (SCVP) was produced to
allow relying parties to off-load all of their certification
verification to another entity [SCVP]. The WG was arguable split over
whether such a function should be supported and whether it should be
its own protocol or included in OCSP. In response, a draft defining
OCSP Extensions [OCSPX] was produced to include the functions of
SCVP. One other draft called Open CRL Distribution Point (OCDP) was
produced which documented two extensions: one to support an
alternative CRL partitioning mechanism to the CRL Distribution Point
mechanism documented in [FORMAT] and one to support identifying other
revocation sources available to certificate-users. The work from
this draft was subsummed by an ITU-T | ISO/IEC Amendment to X.509,
hence work on this draft was halted.
Development of the operational protocols has been slightly more Development of the operational protocols has been slightly more
straightforward. Two documents for LDAPv2 have been developed one for straightforward. Three documents for the Light Weight Directory
defining LDAPv2 as an access protocol to repositories [PKI-LDAPv2]; Access Protocol (LDAP) have been developed one for defining LDAPv2 as
and one for storing PKI information in an LDAP directory [SCHEMA]. an access protocol to repositories [PKI-LDAPv2]; one for storing PKI
Using FTP and HTTP to retrieve certificates and CRL from PKI information in an LDAP directory [SCHEMA]; and one for LDAPv3
repositories was documented without a fight in [FTPHTTP]. Likewise, requirements for PKI [PKI-LDAPv3]. Using the File Transfer Protocol
methods, headers, and content-types ancillary to HTTP/1.1 to publish (FTP) and the Hyper Text Transmission Protocol (HTTP) to retrieve
and retrieve X.509 certificates and CRLs was documented in [WEB] PKCs and CRLs from PKI repositories was documented in [FTPHTTP].
without much argument.
[Need to add text about OpenCDP vs DistributionPoints, Why DCP was In late 1998 the PKIX charter was revised to include protocols for
started, information on TSP, and OCSP, and caching OCSP.] time stamping and data certification services. [TSP] was developed to
define protocols required to interact with a Time Stamp Authority
(TSA) who asserts that a datum existed at a given time. Of course, if
a true non-repudation service is to be provided additional services
that prove the data was actually in the possesion of the subject
requesting the time stamp. So, the [DVCS] draft was developed to
provide two mechaisms to prove the subject actually possed the data.
In addition, [DVCS] provides two additional services: one to verify
all signatures attached to the signed document using all appropriate
status information and PKCs and one to verify and assert the validity
of one or more PKCs at the specified time. Thoughtfully, [DVCS]
permits the [TSP] protocol to be used as one of the time stamp
tokens. Both [DVCS] and [TSP] use [CMS] as an encapsulating (though
in [TSP] request for a time stamp are not required to use [CMS]).
[ETNPT] was developed to use [DCVS] to maintain the trust in a token
issued by a non-repudiation Trusted Third Party (NR TTP) after the
key initially used to establish trust in the token expires.
Around the same time, a work item for ACs, defined in [X.509], was
added. ACs are similar to PKCs, but they do not bind public keys to
identities rather they bind attributes to identities. The attributes
bound to the identity can represent anything, but are mostly used to
support rule-based, role-based, and rank-based access control
decisions. Two drafts have since been developed: the Interent
Attribute Certificates Profile for Authorizations [AC] and the
Limited AttributeCertificate Acquisition Protocol [LAAP]. The first
profiles the fields and extensions of the AC and the second provides
a diliberately limited protocol to access a repository when LDAP is
not appropriate.
Other drafts have been produced to address specific issues. [DHPOP]
was developed to define two mechanisms by which a signature can
produced using a Diffie-Hellman pair. This draft provides a
mechanism to Diffie-Hellam key pairs to issue a PKCS-10 certification
request. After some operational experience with [CMP], two drafts,
one for using HTTP as the transport protocol [CMP-HTTP] and one for
Transmission Control Protocol (TCP) [CMP-TCP], were written to solve
problems encountered by implementors.
From the alphabet soup above, it is clear why this roadmap is
required.
3.3 Overview of the PKIX Approach 3.3 Overview of the PKIX Approach
PKIX is an effort to develop specifications for a Public Key 3.3.1 PKI
Infrastructure for the Internet using X.509 certificates. The PKIX
working group was initially chartered in 1995. A Public Key PKIX is an effort to develop specifications for a PKI for the
Infrastructure, or PKI, is defined as: Internet using PKCs. A PKI is defined as:
The set of hardware, software, people, policies and procedures needed The set of hardware, software, people, policies and procedures needed
to create, manage, store, distribute, and revoke certificates based to create, manage, store, distribute, and revoke PKCs based on
on public-key cryptography. public-key cryptography.
A PKI consists of five types of components [MISPC]: A PKI consists of five types of components [MISPC]:
- Certification Authorities (CAs) that issue and revoke - Certification Authorities (CAs) that issue and revoke PKCs;
certificates;
- Organizational Registration Authorities (ORAs) that vouch for - Organizational Registration Authorities (ORAs) that vouch for the
the binding between public keys and certificate holder binding between public keys and certificate holder identities and
identities and other attributes; other attributes;
- Certificate holders that are issued certificates and can sign - Certificate holders that are issued certificates and can sign
digital documents and encrypt documents; digital documents and encrypt documents;
- Clients that validate digital signatures and their - Clients that validate digital signatures and their certification
certification paths from a known public key of a trusted CA; paths from a known public key of a trusted CA;
- Repositories that store and make available certificates and - Repositories that store and make available certificates and
Certificate Revocation Lists (CRLs). Certificate Revocation Lists (CRLs).
Figure 1 is a simplified view of the architectural model assumed by Figure 1 is a simplified view of the architectural model assumed by
the PKIX Working Group. the PKIX Working Group.
+---+ +---+
| C | +------------+ | C | +------------+
| e | <-------------------->| End entity | | e | <-------------------->| End entity |
| r | Operational +------------+ | r | Operational +------------+
| t | transactions ^ | t | transactions ^
| | and management | Management | | and management | Management
skipping to change at page 9, line 5 skipping to change at page 11, line 37
| y | Publish CRL ^ | y | Publish CRL ^
| | | | | |
+---+ Management | +---+ Management |
transactions | transactions |
v v
+------+ +------+
| CA | | CA |
+------+ +------+
Figure 1 - PKI Entities Figure 1 - PKI Entities
3.4 X.509 certificates 3.3.2 PMI
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was PKIX is also an effort to develop specifications for a Privilege
Management Infrastructure for the Internet using ACs. A Privilege
Management Infrastructure, or PMI, is defined as:
The set of hardware, software, people, policies and procedures needed
to create, manage, store, distribute, and revoke ACs.
A PMI consists of five types of components [AC]:
- Attribute Authorities (AAs), or Attribute Certificate Issuer,
that issue and revoke ACs;
Note: AAs may implicitly revoke ACs by using very short validity
periods.
- Attribute Certificate Users that parses or processes an AC;
- Attribute Certificate Verifiers that check the validity of an AC
and then makes use of the result;
- Clients that request an action for which authorization checks are
to be made;
- Repositories that store and make available certificates and
Certificate Revocation Lists (CRLs).
Figure 2 is an example of the exchanges that may involve ACs.
+--------------+
| | Server Acquisition
| AC Issuer +----------------------------+
| | |
+--+-----------+ |
| |
| Client |
| Acquisition |
| |
+--+-----------+ +--+------------+
| | AC "push" | |
| Client +-------------------------+ Server |
| | (part of app. protocol) | |
+--+-----------+ +--+------------+
| |
| Client | Server
| Lookup +--------------+ | Lookup
| | | |
+---------------+ Repository +---------+
| |
+--------------+
Figure 2: AC Exchanges
3.4 Certificates
3.4.1 Public Key Certificates
ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was
first published in 1988 as part of the X.500 Directory first published in 1988 as part of the X.500 Directory
recommendations, defines a standard certificate format [X.509]. The recommendations, defines a standard public key certificate format
certificate format in the 1988 standard is called the version 1 (v1) [X.509]. The public key certificate format in the 1988 standard is
format. called the version 1 (v1) format.
When X.500 was revised in 1993, two more fields were added, resulting When X.500 was revised in 1993, two more fields,
subjectUniqueIdentier and issuerUniqueIdentifer were added, resulting
in the version 2 (v2) format. These two fields may be used to support in the version 2 (v2) format. These two fields may be used to support
directory access control. directory access control.
The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
include specifications for a public key infrastructure based on include specifications for a public key infrastructure based on X.509
X.509v1 certificates [PEM]. The experience gained in attempts to v1 public key certificates [PEM]. The experience gained in attempts
deploy [PEM] made it clear that the v1 and v2 certificate formats are to deploy [PEM] made it clear that the v1 and v2 public key
deficient in several respects. Most importantly, more fields were certificate formats are deficient in several respects. Most
needed to carry information which PEM design and implementation importantly, more fields were needed to carry information which PEM
experience has proven necessary. In response to these new design and implementation experience has proven necessary. In
requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 response to these new requirements, ISO/IEC/ITU and ANSI X9 developed
(v3) certificate format. The v3 format extends the v2 format by the X.509 version 3 (v3) public key certificate format. The v3 format
adding provision for additional extension fields. Particular extends the v2 format by adding provision for additional extension
extension field types may be specified in standards or may be defined fields. Particular extension field types may be specified in
and registered by any organization or community. In June 1996, standards or may be defined and registered by any organization or
standardization of the basic v3 format was completed [X.509]. community. In June 1996, standardization of the basic v3 format was
completed [X.509].
ISO/IEC/ITU and ANSI X9 have also developed standard extensions for ISO/IEC/ITU and ANSI X9 have also developed standard extensions for
use in the v3 extensions field [X.509][X9.55]. These extensions can use in the v3 extensions field [X.509][X9.55]. These extensions can
convey such data as additional subject identification information, convey such data as additional subject identification information,
key attribute information, policy information, and certification path key attribute information, policy information, and certification path
constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions
are very broad in their applicability. In order to develop are very broad in their applicability. In order to develop
interoperable implementations of X.509 v3 systems for Internet use, interoperable implementations of X.509 v3 systems for Internet use,
it is necessary to specify a profile for use of the X.509 v3 it is necessary to specify a profile for use of the X.509 v3
extensions tailored for the Internet. It is one goal of PKIX to extensions tailored for the Internet. It is one goal of PKIX to
specify a profile for Internet, electronic mail, and IPsec specify a profile for Internet, electronic mail, and IPsec
applications. Environments with additional requirements may build on applications, etc. Environments with additional requirements may
this profile or may replace it. build on this profile or may replace it.
3.4.2 Attribute Certificates
ANSI X.9 first published the Attribute Certificate format in [put
date in here] as part of [put reference in here]. It defined the
standard version 1 (v1) AC format. They later created a version 2
(v2) AC by modifying the owner field to point to either an identity
or a specifc PKC and including an extension mechism. In 1997 ITU-T
included it in [X.509].
ANSI, ITU-T, and IETF have developed standard extensions and
attributes for use in the v2 ACs. Extensions can convey such
informatoin as an audit identity that can be used to create an audit
trail, identity specific servers/services where the AC owner can use
their AC, point to a specific issuer's key, and indicate where to get
revocation information. The AC is generic enough to allow any
attribute to be conveyed in the data structure. Without limiting the
attributes and extensions that can be included in an AC it is very
difficult to develop interoperable implementations for Internet use.
It is the goal of PKIX to specify a profile for the Internet,
electronic mail, IPsec applications, etc. Environments with
additional requirements may build on this profile or replace it.
3.5 Functions of a PKI 3.5 Functions of a PKI
This section describes the major functions of a PKI. In some cases, This section describes the major functions of a PKI. In some cases,
PKIs may provide extra functions. PKIs may provide extra functions.
3.5.1 Registration 3.5.1 Registration
This is the process whereby a subject first makes itself known to a This is the process whereby a subject first makes itself known to a
CA (directly, or through an RA), prior to that CA issuing a CA (directly, or through an RA), prior to that CA issuing a PKC or
certificate or certificates for that subject. Registration involves PKCs for that subject. Registration involves the subject providing
the subject providing its name (e.g., common name, fully-qualified its name (e.g., common name, fully-qualified domain name, IP
domain name, IP address), and other attributes to be put in the address), and other attributes to be put in the PKC, followed by the
certificate, followed by the CA (possibly with help from the RA) CA (possibly with help from the RA) verifying in accordance with its
verifying in accordance with its Certfication Practice Statement Certfication Practice Statement (CPS) that the name and other
(CPS) that the name and other attributes are correct. attributes are correct.
3.5.2 Initialization 3.5.2 Initialization
Initialization is when the subject (e.g., the user or client system) Initialization is when the subject (e.g., the user or client system)
gets the values needed to begin communicating with the PKI. For gets the values needed to begin communicating with the PKI. For
example, initialization can involve providing the client system with example, initialization can involve providing the client system with
the public key and/or certificate of a CA, or generating the client the public key and/or PKC of a CA, or generating the client system's
system's own public/private key pair. own public/private key pair.
3.5.3 Certification 3.5.3 Certification
This is the process in which a CA issues a certificate for a This is the process in which a CA issues a PKC for a subject's public
subject's public key, and returns that certificate to the subject key, and returns that PKC to the subject and/or posts that PKC in a
and/or posts that certificate in a repository. repository.
3.5.4 Key Pair Recovery 3.5.4 Key Pair Recovery
In some implementations, key exchange or encryption keys will be In some implementations, key exchange or encryption keys will be
required by local policy to be "backed up", or recoverable in case required by local policy to be "backed up," or recoverable in case
the key is lost and access to previously-encrypted information is the key is lost and access to previously-encrypted information is
needed. Such implementations can include those where the private key needed. Such implementations can include those where the private key
exchange key is stored on a hardware token which can be lost or exchange key is stored on a hardware token which can be lost or
broken, or when a private key file is protected by a password which broken, or when a private key file is protected by a password which
can be forgotten. Often, a company is concerned about being able to can be forgotten. Often, a company is concerned about being able to
read mail encrypted by or for a particular employee when that read mail encrypted by or for a particular employee when that
employee is no longer available because she is ill or no longer works employee is no longer available because she is ill or no longer works
for the company. for the company.
In these cases, the user's private key can be backed up by a CA or by In these cases, the user's private key can be backed up by a CA or by
a separate key backup system. If a user or her employer needs to a separate key backup system. If a user or her employer needs to
recover these backed up key materials, the PKI must provide a system recover these backed up key materials, the PKI must provide a system
that permits the recovery without providing an unacceptable risk of that permits the recovery without providing an unacceptable risk of
compromise of the private key. compromise of the private key.
3.5.5 Key Generation 3.5.5 Key Generation
Depending on the CA's policy, the private/public key pair can either Depending on the CA's policy, the private/public key pair can either
be generated by the user in his local environment, or generated by be generated by the user in his local environment, or generated by
the CA. In the latter case, the key material may be distributed to the CA. In the latter case, the key material may be distributed to
the user in an encrypted file or on a physical token - e.g., a smart the user in an encrypted file or on a physical token (e.g., a smart
card or PCMCIA card. card or PCMCIA card).
3.5.6 Key Update 3.5.6 Key Update
All key pairs need to be updated regularly (i.e., replaced with a new All key pairs need to be updated regularly (i.e., replaced with a new
key pair) and new certificates issued. This will happen in two cases: key pair) and new PKCs issued. This will happen in two cases:
normally, when a key has passed its maximum usable lifetime; and normally, when a key has passed its maximum usable lifetime; and
exceptionally, when a key has been compromised and must be replaced. exceptionally, when a key has been compromised and must be replaced.
3.5.6.1 Key Expiry 3.5.6.1 Key Expiry
In the normal case, a PKI needs to provide a facility to gracefully In the normal case, a PKI needs to provide a facility to gracefully
transition from a certificate with an existing key to a new transition from a PKC with an existing key to a new PKC with a new
certificate with a new key. This is particularly true when the key to key. This is particularly true when the key to be updated is that of
be updated is that of a CA. Users will know in advance that the key a CA. Users will know in advance that the key will expire on a
will expire on a certain date; the PKI, working together with certain date; the PKI, working together with PKC-using applications,
certificate-using applications, should allow for appropriate keys to should allow for appropriate keys to work before and after the
work before and after the transition. There are a number of ways to transition. There are a number of ways to do this; see [CMP] for an
do this; see [insert appropriate reference here] for an example of example of one.
one.
3.5.6.2 Key Compromise 3.5.6.2 Key Compromise
In the case of a key compromise, the transition will not be In the case of a key compromise, the transition will not be
"graceful" in that there will be an unplanned switch of certificates "graceful" in that there will be an unplanned switch of PKCs and
and keys; users will not have known in advance what was about to keys; users will not have known in advance what was about to happen.
happen. Still, the PKI must support the ability to declare that the Still, the PKI must support the ability to declare that the previous
previous certificate is now invalid and shall not be used, and to PKC is now invalid and shall not be used, and to announce the
announce the validity and availability of the new certificate. validity and availability of the new PKC.
Note: compromise of a private key associated with a Root CA is Note: compromise of a private key associated with a Root CA is
catastrophic for users relying on that Root CA. If a Root CA's catastrophic for users relying on that Root CA. If a Root CA's
private key is compromised, that CA's certificate must be revoked private key is compromised, that CA's PKC must be revoked and all
and all certificates subordinate to it must also be revoked. Until PKCs subordinate to it must also be revoked. Until such time as the
such time as the Root CA has been issued a new certificate and the Root CA has been issued a new PKC and the Root CA issues PKCs to
Root CA issues certificates to users relying upon it, users users relying upon it, users relying on that Root CA are cut off
relying on that Root CA are cut off from the rest of the system, from the rest of the system, as there is no way to develop a valid
as there is no way to develop a valid certification path back to a certification path back to a trusted node.
trusted node.
Further, users will likely have to be notified by out-of-band Further, users will likely have to be notified by out-of-band
mechanisms about the change in CA keys. If the old key is mechanisms about the change in CA keys. If the old key is
compromised, any "update" message telling subordinates to switch to a compromised, any "update" message telling subordinates to switch to a
new key could have come from an attacker in possession of the old new key could have come from an attacker in possession of the old
key, and could point to a new public key for which the attacker key, and could point to a new public key for which the attacker
already has the private key. It is possible to have anticipated this already has the private key. It is possible to have anticipated this
event, and "pre-placed" replacement Root CA keys with all relying event, and "pre-placed" replacement Root CA keys with all relying
parties, but some secure, out-of-band mechanism will have to be used parties, but some secure, out-of-band mechanism will have to be used
to tell users to make the switch, and this will only help if the to tell users to make the switch, and this will only help if the
replacement key has not been compromised. replacement key has not been compromised.
Additionally, once the Root CA is brought back up with a new key, it Additionally, once the Root CA is brought back up with a new key, it
will likely be necessary to re-issue certificates, signed with the will likely be necessary to re-issue PKCs, signed with the new key,
new key, to all subordinate users, since their current certificate to all subordinate users, since their current PKC would be signed
would be signed with a now-revoked key. with a now-revoked key.
3.5.7 Cross-certification 3.5.7 Cross-certification
A cross-certificate is a certificate issued by one CA to another CA A cross-certificate is a PKC issued by one CA to another CA which
which contains a public CA key associated with the private CA contains a public CA key associated with the private CA signature key
signature key used for issuing certificates. Typically, a cross- used for issuing PKCs. Typically, a cross-certificate is used to
certificate is used to allow client systems/end entities in one allow client systems/end entities in one administrative domain to
administrative domain to communicate security with client systems/end communicate securely with client systems/end users in another
users in another administrative domain. Use of a cross-certificate administrative domain. Use of a cross-certificate issued from CA_1 to
issued from CA_1 to CA_2 allows user Alice, who trusts CA_1, to CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
accept a certificate used by Bob, which was issued by CA_2. Cross- which was issued by CA_2. Cross-certificates can also be issued from
certificates can also be issued from one CA to another CA in the same one CA to another CA in the same administrative domain, if required.
administrative domain, if required.
Cross-certificates can be issued in only one direction, or in both Cross-certificates can be issued in only one direction, or in both
directions, between two CA's. That is, just because CA_1 issues a directions, between two CA's. That is, just because CA_1 issues a
cross-certificate for CA_2, CA_2 does not have to issue a cross- cross-certificate for CA_2, CA_2 does not have to issue a cross-
certificate for CA_1. certificate for CA_1.
3.5.8 Revocation 3.5.8 Revocation
When a certificate is issued, it is expected to be in use for its When a PKC is issued, it is expected to be in use for its entire
entire validity period. However, various circumstances may cause a validity period. However, various circumstances may cause a PKC to
certificate to become invalid prior to the expiration of the validity become invalid prior to the expiration of the validity period. Such
period. Such circumstances include change of name, change of circumstances include change of name, change of association between
association between subject and CA (e.g., an employee terminates subject and CA (e.g., an employee terminates employment with an
employment with an organization), and compromise or suspected organization), and compromise or suspected compromise of the
compromise of the corresponding private key. Under such corresponding private key. Under such circumstances, the CA needs to
circumstances, the CA needs to revoke the certificate. revoke the PKC.
X.509 defines one method of certificate revocation. This method X.509 defines one method of PKC revocation. This method involves each
involves each CA periodically issuing a signed data structure called CA periodically issuing a signed data structure called a certificate
a certificate revocation list (CRL). A CRL is a time stamped list revocation list (CRL). A CRL is a time stamped list identifying
identifying revoked certificates which is signed by a CA and made revoked PKCs which is signed by a CA and made freely available in a
freely available in a public repository. Each revoked certificate is public repository. Each revoked PKC is identified in a CRL by its PKC
identified in a CRL by its certificate serial number. When a serial number. When a certificate-using system uses a PKC, that
certificate-using system uses a certificate, that system not only system not only checks the PKC signature and validity but also
checks the certificate signature and validity but also acquires a acquires a suitably-recent CRL and checks that the PKC serial number
suitably-recent CRL and checks that the certificate serial number is is not on that CRL. The meaning of "suitably-recent" may vary with
not on that CRL. The meaning of "suitably-recent" may vary with local local policy, but it usually means the most recently-issued CRL. A CA
policy, but it usually means the most recently-issued CRL. A CA
issues a new CRL on a regular periodic basis (e.g., hourly, daily, or issues a new CRL on a regular periodic basis (e.g., hourly, daily, or
weekly). CA's may also issue CRLs aperiodically; e.g., if an weekly). CA's may also issue CRLs aperiodically. For example, if an
important key is deemed compromised, the CA may issue a new CRL to important key is deemed compromised, the CA may issue a new CRL to
expedite notification of that fact, even if the next CRL does not expedite notification of that fact, even if the next CRL does not
have to be issued for some time. (A problem of aperiodic CRL issuance have to be issued for some time. (A problem of aperiodic CRL issuance
is that end-entities may not know that a new CRL has been issued, and is that end-entities may not know that a new CRL has been issued, and
thus may not retrieve it from a repository.) thus may not retrieve it from a repository.)
An entry is added to the CRL as part of the next update following An entry is added to the CRL as part of the next update following
notification of revocation. An entry may be removed from the CRL notification of revocation. An entry may be removed from the CRL
after appearing on one regularly scheduled CRL issued beyond the after appearing on one regularly scheduled CRL issued beyond the
revoked certificate's validity period. [Say why here] revoked PKC's validity period. Leaving the revoked PKC on the CRL for
this extra period allows for PKCs that are revoked prior to issuing a
new CRL and whose invalidity date falls before the CRL issuing time
to be accounted for. If the revoked PKC is not retained on the CRL
for this extra period then the possiblity arises that a revoked PKC
may never appear on a CRL.
An advantage of the CRL revocation method is that CRLs may be An advantage of the CRL revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves, distributed by exactly the same means as PKCs themselves, namely, via
namely, via untrusted communications and server systems. untrusted communications and server systems.
One limitation of the CRL revocation method, using untrusted One limitation of the CRL revocation method, using untrusted
communications and servers, is that the time granularity of communications and servers, is that the time granularity of
revocation is limited to the CRL issue period. For example, if a revocation is limited to the CRL issue period. For example, if a
revocation is reported now, that revocation will not be reliably revocation is reported now, that revocation will not be reliably
notified to certificate-using systems until the next CRL is issued - notified to certificate-using systems until the next CRL is issued -
this may be up to one hour, one day, or one week depending on the this may be up to one hour, one day, or one week depending on the
frequency that the CA issues CRLs. frequency that the CA issues CRLs.
As with the X.509 v3 certificate format, in order to facilitate As with the X.509 v3 PKC format, in order to facilitate interoperable
interoperable implementations from multiple vendors, the X.509 v2 CRL implementations from multiple vendors, the X.509 v2 CRL format needed
format needed to be profiled for Internet use. This was done as part to be profiled for Internet use. This was done as part of [FORMAT].
of [FORMAT]. However, PKIX does not require CAs to issue CRLs. On- However, PKIX does not require CAs to issue CRLs. On-line methods of
line methods of revocation notification may be applicable in some revocation notification may be applicable in some environments as an
environments as an alternative to the X.509 CRL. PKIX defines a alternative to the X.509 CRL. PKIX defines a protocol known as OCSP
protocol known as OCSP [OCSP] to facilitate on-line checking of the to facilitate on-line checking of the status of PKCs [OCSP].
status of certificates.
On-line revocation checking may significantly reduce the latency On-line revocation checking may significantly reduce the latency
between a revocation report and the distribution of the information between a revocation report and the distribution of the information
to relying parties. Once the CA accepts the report as authentic and to relying parties. Once the CA accepts the report as authentic and
valid, any query to the on-line service will correctly reflect the valid, any query to the on-line service will correctly reflect the
certificate validation impacts of the revocation. However, these PKC validation impacts of the revocation. However, these methods
methods impose new security requirements; the certificate validator impose new security requirements; the PKC validator must trust the
must trust the on-line validation service while the repository does on-line validation service while the repository does not need to be
not need to be trusted. trusted.
3.5.9 Certificate and Revocation Notice Distribution/Publication 3.5.9 Certificate and Revocation Notice Distribution/Publication
As alluded to in sections 3.1 and 3.5.8 above, the PKI is responsible As alluded to in sections 3.1 and 3.5.8 above, the PKI is responsible
for the distribution of certificates and certificate revocation for the distribution of PKCs and PKC revocation notices (whether in
notices (whether in CRL form or in some other form) in the system. CRL form or in some other form) in the system. "Distribution" of PKCs
"Distribution" of certificates includes transmission of the includes transmission of the PKC to its owner, and may also include
certificate to its owner, and may also include publication of the publication of the PKC in a repository. "Distribution" of revocation
certificate in a repository. "Distribution" of revocation notices may notices may involve posting CRLs in a repository, transmitting them
involve posting CRLs in a repository, transmitting them to end- to end-entities, and/or forwarding them to on-line responders.
entities, and/or forwarding them to on-line responders.
3.6 Parts of PKIX 3.6 Parts of PKIX
This section identifies the five different areas in which the PKIX This section identifies the six different areas in which the PKIX
working group has developed documents. The first area involves working group has developed documents. The first area involves
profiles of the X.509 v3 certificate standards and the X.509v2 CRL profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards
standards for the Internet. The second area involves operational for the Internet. The second area involves operational protocols, in
protocols, in which relying parties can obtain information such as which relying parties can obtain information such as PKCs or PKC
certificates or certificate status. The third area covers management status. The third area covers management protocols, in which
protocols, in which different entities in the system exchange different entities in the system exchange information needed for
information needed for proper management of the PKI. The fourth area proper management of the PKI. The fourth area provides information
provides information about certificate policies and certificate about certificate policies and certificate practice statements,
practice statements, covering the areas of PKI security not directly covering the areas of PKI security not directly addressed in the rest
addressed in the rest of PKIX. The fifth area deals with providing of PKIX. The fifth area deals with providing time stamping and data
time stamping and data certification services, which can be used to certification services, which can be used to build such services as
build such services as non-repudiation. non-repudiation.
3.6.1 Profile 3.6.1 Profiles
An X.509v3 certificate is a very complex data structure. It consists An X.509 v3 PKC is a very complex data structure. It consists of
of basic information fields, plus a number of optional certificate basic information fields, plus a number of optional extensions. Many
extensions. Many of the fields and numerous extensions can take on a of the fields and numerous extensions can take on a wide range of
wide range of options. This provides an enormous degree of options. This provides an enormous degree of flexibility, which
flexibility, which allows the X.509v3 certificate format to be used allows the X.509 v3 PKC format to be used with a wide range of
with a wide range of applications in a wide range of environments. applications in a wide range of environments. Unfortunately, this
Unfortunately, this same flexibility makes it extremely difficult to same flexibility makes it extremely difficult to produce independent
produce independent implementations that will actually interoperate implementations that will actually interoperate with one another. In
with one another. In order to build an Internet PKI based on X.509v3 order to build an Internet PKI based on X.509 v3 PKCs, the PKIX
certificates, the PKIX working group had to develop a profile of the working group had to develop a profile of the X.509 v3 PKC
X.509v3 specification. specification.
A profile of the X.509v3 specification is a description of the A profile of the X.509 v3 PKC specification is a description of the
contents of the certificate and which certificate extensions must be contents of the PKC and which extensions must be supported, which
supported, which extensions may be supported, and which extensions extensions may be supported, and which extensions may not be
may not be supported. [FORMAT] provides such a profile of X.509v3 for supported. [FORMAT] provides such a profile of X.509 v3 PKC for the
the Internet PKI. In addition, [FORMAT] suggests ranges of values for Internet PKI. In addition, [FORMAT] suggests ranges of values for
many of the extensions. many of the extensions.
[FORMAT] also provides a profile for Version 2 CRLs for use in the [FORMAT] also provides a profile for Version 2 CRLs for use in the
Internet PKI. CRLs, like certificates, have a number of optional Internet PKI. CRLs, like PKCs, have a number of optional extensions.
extensions. In order to promote interoperability, it is necessary to In order to promote interoperability, it is necessary to constrain
constrain the choices an implementor supports. the choices an implementor supports.
In addition to profiling the certificate and CRL formats, it is In addition to profiling the PKC and CRL formats, it is necessary to
necessary to define particular Object Identifiers (OIDs) for certain define particular Object Identifiers (OIDs) for certain encryption
encryption algorithms, because there are a variety of OIDs registered algorithms, because there are a variety of OIDs registered for some
for some algorithm suites. Many of the OIDs are defined in [FORMAT] algorithm suites. Many of the OIDs are defined in [FORMAT] to promote
to promote interoperability. Also, PKIX has produced two documents interoperability. Also, PKIX has produced two documents ([ECDSA] and
([ECDSA] and [KEA]) which provide guidance on the proper [KEA]) which provide guidance on the proper implementation of
implementation of specific algorithms. specific algorithms.
Certain countries are in a process of updating their legal frameworks Some countries are in a process of updating their legal frameworks in
in order to regulate and incorporate recognition of signatures in order to regulate and incorporate recognition of signatures in
electronic form. Many of these frameworks introduce certain basic electronic form. Many of these frameworks introduce certain basic
requirements on certificates, often termed Qualified Certificates, requirements on PKCs, often termed Qualified Certificates, supporting
supporting these types of "legal" signatures. Partly as a result of these types of "legal" signatures. Partly as a result of this there
this there is a need for a specific certificate profile providing is a need for a specific PKC profile providing standardized support
standardized support for certain related issues such as a common for certain related issues such as a common structure for expressing
structure for expressing unambiguous identities of certified subjects unambiguous identities of certified subjects (unmistakable identity).
(unmistakable identity). In December 1998, PKIX adopted as a work In December 1998, PKIX adopted as a work item the development of a
item the development of a refinement of [RFC2459] that further refinement of [RFC2459] that further profiles PKIX PKC into qualified
profiles PKIX certificates into qualified certificates. This work is certificates. This work is reflected in [QC].
reflected in [QC].
Like the X.509 v3 PKC the AC also a very complex data structure
consisting of basic information fields, a number of optional
extensions, and a virtually unlimited number of attributes. Again,
many of the fields, extensions, and attributes can take on a wide
range of options allowing an enomerous degree of flexibility. In
order to build an Internet PMI based on ACs, the PKIC working group
had to develop a profile of the AC.
The AC profile is description of the contents of the AC, the allowed
and required extensions, and applicable attributes. [AC] provides
such a profile of the X.509 v2 AC.
3.6.2 Operational Protocols 3.6.2 Operational Protocols
Operational protocols are required to deliver certificates and CRLs Operational protocols are required to deliver certificates and CRLs
(or other certificate status information) to certificate using (or other certificate status information) to certificate using
systems. Provision is needed for a variety of different means of systems. Provision is needed for a variety of different means of
certificate and CRL delivery, including distribution procedures based certificate and CRL delivery, including distribution procedures based
on LDAP, HTTP, FTP, and X.500. Operational protocols supporting these on LDAP, HTTP, FTP, and X.500. Operational protocols supporting these
functions are defined in [FTPHTTP], [OCSP], and [PKI-LDAPv2]. functions are defined in [FTPHTTP], [OCSP], [PKI-LDAPv2], and [PKI-
LDAPv3]. A limited protocol to support AC retrieval has also been
document in [LAAP].
[DHPOP] defines a procedure for producing signatures withg the
Diffie-Hellman key agreement algorithm. This signature mechanism was
developed to support PKCS-10 certificate requests.
3.6.3 Management Protocols 3.6.3 Management Protocols
Management protocols are required to support on-line interactions Management protocols are required to support on-line interactions
between PKI user and management entities. For example, a management between PKI user and management entities. For example, a management
protocol might be used between a CA and a client system with which a protocol might be used between a CA and a client system with which a
key pair is associated, or between two CAs which cross-certify each key pair is associated, or between two CAs which cross-certify each
other. A management protocol can be used to carry user or client other. A management protocol can be used to carry user or client
system registration information, or a request for revocation of a system registration information, or a request for revocation of a
certificate. certificate.
There are two parts to a "management protocol". The first is the There are two parts to a "management protocol." The first is the
format of the messages that will be sent, and the second is the format of the messages that will be sent, and the second is the
actual protocol that governs the transmission of those messages. actual protocol that governs the transmission of those messages.
Originally, the PKIX working group developed two documents, [CRMF] Originally, the PKIX working group developed two documents, [CRMF]
and [CMMF], that together described the necessary set of message and certificate management message format (CMMF), that together
formats, and two other documents, [CMP] and [CMC], that described described the necessary set of message formats, and two other
protocols for exchanging those messages. However, the message formats documents, [CMP] and [CMC], that described protocols for exchanging
defined in [CMMF] were inserted into both [CMP] and [CMC], and thus those messages. However, the message formats defined in in the CMMF
[CMMF] has been dropped as a PKIX document. draft were inserted into both [CMP] and [CMC], and thus the (CMMF)
draft has been dropped as a PKIX document.
[CMP-HTTP] and [CMP-TCP] were developed, after some implmentation
experience, to update the procedure documented in [CMP] for using CMP
with HTTP and TCP and the transport protocols [CMP].
3.6.4 Policy Outline 3.6.4 Policy Outline
As mentioned before, profiling certificates and specifying As mentioned before, profiling certificates and specifying
operational and management protocols only addresses a part of the operational and management protocols only addresses a part of the
problem of actually developing and implementing a secure PKI. What is problem of actually developing and implementing a secure PKI. What is
also needed is the development of a certificate policy (CP) and also needed is the development of a certificate policy (CP) and
certification practice statement (CPS), and then following those certification practice statement (CPS), and then following those
documents. The CP and CPS should address physical and personnel documents. The CP and CPS should address physical and personnel
security, subject identification requirements, revocation policy, and security, subject identification requirements, revocation policy, and
a number of other topics. [POLPROC] provides a framework for a number of other topics. [POLPROC] provides a framework for
certification practice statements. certification practice statements.
skipping to change at page 16, line 37 skipping to change at page 21, line 31
created after the indicated time. created after the indicated time.
[TSP] also defines the role of a Temporal Data Authority, or TDA. A [TSP] also defines the role of a Temporal Data Authority, or TDA. A
TDA is a Trusted Third Party (TTP) that creates a temporal data TDA is a Trusted Third Party (TTP) that creates a temporal data
token. This temporal data token associates a message with a token. This temporal data token associates a message with a
particular event and provides supplementary evidence for the time particular event and provides supplementary evidence for the time
included in the time stamp token. For example, a TDA could associate included in the time stamp token. For example, a TDA could associate
the message with the most recent closing value of the Dow Jones the message with the most recent closing value of the Dow Jones
Average. The temporal data with which the message is associated Average. The temporal data with which the message is associated
should be unpredictable in order to prevent forward dating of tokens. should be unpredictable in order to prevent forward dating of tokens.
The third iteration of the draft removed support for TDAs as no one
in the WG expressed a requirement for the role.
At the Minneapolis IETF meeting, it was disclosed that the materials At the Minneapolis IETF meeting, it was disclosed that the materials
covered in the Timestamp Internet draft may be covered by patent(s). covered in [TSP] draft may be covered by patent(s). Use of the
Use of the material covered by the patent(s) in question has not be material covered by the patent(s) in question has not be granted by
granted by the patentholder. Thus, anyone interested in implementing the patentholder. Thus, anyone interested in implementing the PKIX
the PKIX Timestamp draft must be aware of this intellectual property [TSP] draft must be aware of this intellectual property issue.
issue.
The second new effort is the definition of a Data Certification The second new effort is the definition of a Data Validation and
Server, or DCS, protocol [DCS]. A DCS is a Trusted Third Party that Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted
verifies the correctness of specific data submitted to it. Third Party that verifies the correctness of specific data submitted
to it.
This is different from the TSP service in that a TSA will not attempt This is different from the TSP service in that a TSA will not attempt
to parse and/or verify a message sent to it for certification; to parse and/or verify a message sent to it for certification;
instead, it will merely append a reliable indication of the current instead, it will merely append a reliable indication of the current
time, and sign the resulting string-of-bits. This offers an time, and sign the resulting string-of-bits. This offers an
indication that the given string-of-bits existed at a specified time; indication that the given string-of-bits existed at a specified time;
it does not offer any indication of the correctness or relevance of it does not offer any indication of the correctness or relevance of
that string of bits. By contrast, the DCS certifies possession of that string of bits. By contrast, the DVCS certifies possession of
data or the validity of another entity's signature. As part of this, data or the validity of another entity's signature. As part of this,
the DCS verifies the mathematical correctness of the actual signature the DVCS verifies the mathematical correctness of the actual
value contained in the request and also checks the full certification signature value contained in the request and also checks the full
path from the signing entity to a trusted point (e.g., the DCS's CA, certification path from the signing entity to a trusted point (e.g.,
or the Root CA in a hierarchy). the DVCS's CA, or the Root CA in a hierarchy).
The DCS supports non-repudiation in two ways. First, it provides The DVCS supports non-repudiation in two ways. First, it provides
evidence that a signature or public key certificate was valid at the evidence that a signature or PKC was valid at the time indicated in
time indicated in the token. The token can be used even after the the token. The token can be used even after the corresponding PKC
corresponding public key certificate expires and its revocation expires and its revocation information is no longer available on CRLs
information is no longer available on CRLs (for example). Second, the (for example). Second, the production of a data certification token
production of a data certification token in response to a signed in response to a signed request for certification of another
request for certification of another signature or public key signature or PKC also provides evidence that due diligence was
certificate also provides evidence that due diligence was performed performed by the requester in validating the signature or PKC.
by the requester in validating the signature or public key
certificate.
4 PKIX Documents 4 PKIX Documents
This section describes each of the documents written by the PKIX This section describes each of the documents written by the PKIX
working group. As PKIX progresses, this section will need to be working group. As PKIX progresses, this section will need to be
continually updated to reflect the status of each document (e.g., continually updated to reflect the status of each document (e.g.,
Proposed Standard, Draft Standard, Standard, Informational Draft, Proposed Standard, Draft Standard, Standard, Informational Draft,
Informational RFC, something-that-was-just-thrown-out-for- Informational RFC, something-that-was-just-thrown-out-for-
consideration, etc.) consideration, etc.).
4.1 Profile 4.1 Profile
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
and CRL Profile (RFC 2459) and CRL Profile (RFC 2459)
DESCRIPTION: This document describes the profiles to be used for DESCRIPTION: This document describes the profiles to be used for
X.509v3 certificates and version 2 CRLs by Internet PKI participants. X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The
The profiles include the identification of ISO/IEC/ITU and ANSI profiles include the identification of ISO/IEC/ITU and ANSI
extensions which may be useful in the Internet PKI. The profiles are extensions which may be useful in the Internet PKI. The profiles are
presented in the 1988 Abstract Syntax Notation One (ASN.1) rather presented in the 1988 Abstract Syntax Notation One (ASN.1) rather
than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be PKIX than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be PKIX
implementors and developers of certificate-using applications should implementors and developers of certificate-using applications should
start with [FORMAT] to ensure that their systems will be able to start with [FORMAT] to ensure that their systems will be able to
interoperate with other users of the PKI. interoperate with other users of the PKI.
[FORMAT] also includes path validation procedures. The procedures [FORMAT] also includes path validation procedures. The procedures
presented are based upon the ISO/IEC/ITU definition, but the presented are based upon the ISO/IEC/ITU definition, but the
presentation assumes one or more self-signed trusted CA certificates. presentation assumes one or more self-signed trusted CA PKCs. The
procedures are provided as examples only. Implementations are not
The procedures are provided as examples only. Implementations are not
required to use the procedures provided; they may implement whichever required to use the procedures provided; they may implement whichever
procedures are efficient for their situation. However, procedures are efficient for their situation. However,
implementations are required to derive the same results as the implementations are required to derive the same results as the
example procedures. example procedures.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) Representation of Elliptic Curve Digital Signature Algorithm (ECDSA)
Keys and Signatures in Internet X.509 Public Key Infrastructure Keys and Signatures in Internet X.509 Public Key Infrastructure
Certificates <draft-ietf-pkix-ipki-ecdsa-01.txt> Certificates <draft-ietf-pkix-ipki-ecdsa-01.txt>
DESCRIPTION: This document provides Object Identifiers (OIDs) and DESCRIPTION: This document provides Object Identifiers (OIDs) and
other guidance for IPKI users who use the Elliptic Curve Digital other guidance for IPKI users who use the Elliptic Curve Digital
Signature Algorithm (ECDSA). It profiles the format and semantics of Signature Algorithm (ECDSA). It profiles the format and semantics of
the subjectPublicKeyInfo field and the keyUsage extension in X.509 V3 the subjectPublicKeyInfo field and the keyUsage extension in X.509 v3
certificates containing ECDSA keys. This document should be used by PKCs containing ECDSA keys. This document should be used by anyone
anyone wishing to support ECDSA; others who do not support ECDSA are wishing to support ECDSA; others who do not support ECDSA are not
not required to comply with it. required to comply with it.
STATUS: WG Last Call. STATUS: WG Last Call.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509
Public Key Infrastructure Certificates (RFC 2528) Public Key Infrastructure Certificates (RFC 2528)
DESCRIPTION: This document provides Object Identifiers (OIDs) and DESCRIPTION: This document provides Object Identifiers (OIDs) and
other guidance for IPKI users who use the Key Exchange Algorithm other guidance for IPKI users who use the Key Exchange Algorithm
(KEA). It profiles the format and semantics of the (KEA). It profiles the format and semantics of the
subjectPublicKeyInfo field and the keyUsage extension in X.509 V3 subjectPublicKeyInfo field and the keyUsage extension in X.509 v3
certificates containing KEA keys. This document should be used by PKCs containing KEA keys. This document should be used by anyone
anyone wishing to support KEA; others who do not support ECDSA are wishing to support KEA; others who do not support ECDSA are not
not required to comply with it. required to comply with it.
STATUS: Informational RFC. STATUS: Informational RFC.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL
Distribution Options (OpenCDP) <draft-ietf-pkix-ocdp-01.txt>
DESCRIPTION: This document proposes an alternative to the CRL
Distribution Point (CDP) approach documented in [FORMAT]. OCDP
separates the CRL location function from the process of certificate
and CRL validation, and thus claims some benefits over the CDP
approach.
STATUS: Under WG review.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified
Certificates <draft-ietf-pkix-qc-00.txt> Certificates <draft-ietf-pkix-qc-01.txt>
DESCRIPTION: This document profiles the format for and defines DESCRIPTION: This document profiles the format for and defines
requirements on information content in a specific type of requirements on information content in a specific type of PKCs called
certificates called Qualified Certificates. A "Qualified Certificate" Qualified Certificates. A "Qualified Certificate" is a PKC that is
is a certificate that is issued to a natural person (i.e., a living issued to a natural person (i.e., a living human being); contains an
human being); contains an unmistakable identity based on a real name unmistakable identity based on a real name or a pseudonym of the
or a pseudonym of the subject; exclusively indicates non-repudiation subject; exclusively indicates non-repudiation as the key usage for
as the key usage for the certificate's public key; and meets a number the certificate's public key; and meets a number of requirements.
of requirements.
STATUS: Under WG review. STATUS: Under WG review.
DOCUMENT TITLE: An Internet AttributeCertificate Profile for DOCUMENT TITLE: An Internet AttributeCertificate Profile for
Authorizations <draft-ietf-pkix-acx509prof-00.txt> Authorizations <draft-ietf-pkix-acx509prof-01.txt>
DESCRIPTION: This document profiles the format for an defines DESCRIPTION: This document profiles the format for an defines
requirements on X.509 Attribute Certificates to support authorization requirements on X.509 v2 ACs to support authorization services
services required by various Internet protocols (TLS, CMS, and the required by various Internet protocols (TLS, CMS, and the consumers
consumers of CMS, etc.). Two profiles are defined on that supports of CMS, etc.). Two profiles are defined on that supports basic
basic authorizations and on the supports proxiable services. authorizations and on the supports proxiable services.
STATUS: Under WG review.
DOCUMENT TITLE: Diffie-Hellman Proof-of-Possesion Algorithms <draft-
ietf-pkix-dhpop-00.txt>
DESCRIPTION: This documents describes two signing algorithms using
the Diffie-Hellman key agreement process to provide a shared secret
as the basis of the signature. It allows Diffie-Hellman a key
agreement algorithm to be used instead of requiring that the public
key being requested for certification correspond to an algorithm that
is capable of signing and/or encrypting. The first algorithm
generates a signature for a specific verifier where the signer and
recipient have the same public key parameters. The second algorithm
generates a signature for arbitrary verifiers where the signer and
recipient do not have the same public key parameters.
STATUS: Under WG review. STATUS: Under WG review.
4.2 Operational Protocols 4.2 Operational Protocols
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational
Protocols - LDAPv2 (RFC 2559) Protocols - LDAPv2 (RFC 2559)
DESCRIPTION: This document describes the use of LDAPv2 as a protocol DESCRIPTION: This document describes the use of LDAPv2 as a protocol
for PKI elements to publish and retrieve certificates and CRLs from a for PKI elements to publish and retrieve certificates and CRLs from a
certificate repository. [LDAPv2] is a protocol that allows publishing repository. [LDAPv2] is a protocol that allows publishing and
and retrieving of information. retrieving of information.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2
Schema (RFC 2587) Schema (RFC 2587)
DESCRIPTION: This document defines a minimal schema necessary to DESCRIPTION: This document defines a minimal schema necessary to
support the use of LDAPv2 for certificate and CRL retrieval and support the use of LDAPv2 for PKC and CRL retrieval and related
related functions for PKIX. This document supplements [LDAPv2] by functions for PKIX. This document supplements [LDAPv2] by identifying
identifying the PKIX-related attributes that must be present. the PKIX-related attributes that must be present.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP <draft-ietf-pkix-ocsp-08.txt> Certificate Status Protocol - OCSP (RFC 2560)
DESCRIPTION: This document specifies a protocol useful in determining DESCRIPTION: This document specifies a protocol useful in determining
the current status of a certificate without the use of CRLs. A major the current status of a certificate without the use of CRLs. A major
complaint about certificate-based systems is the need for a relying complaint about certificate-based systems is the need for a relying
party to retrieve a current CRL as part of the certificate validation party to retrieve a current CRL as part of the certificate validation
process. Depending on the size of the CRL, this can cause severe process. Depending on the size of the CRL, this can cause severe
problems for bandwidth-challenged devices. Depending on the frequency problems for bandwidth-challenged devices. Depending on the frequency
of CRL issuance, this can also cause timeliness problems. (E.g., if of CRL issuance, this can also cause timeliness problems. (E.g., if
CRLs are only published weekly, with no interim releases, a CRLs are only published weekly, with no interim releases, a
certificate could actually have been revoked for just short of one certificate could actually have been revoked for just short of one
skipping to change at page 20, line 45 skipping to change at page 25, line 11
whereby a relying party identifies one or more certificates to an whereby a relying party identifies one or more certificates to an
approved OCSP "responder", and the responder sends back the current approved OCSP "responder", and the responder sends back the current
status of the certificate(s) - e.g., "revoked", "notRevoked", status of the certificate(s) - e.g., "revoked", "notRevoked",
"unknown". This can dramatically reduce the bandwidth required to "unknown". This can dramatically reduce the bandwidth required to
transmit revocation status - a relying party does not have to transmit revocation status - a relying party does not have to
retrieve a CRL of many entries to check the status of one retrieve a CRL of many entries to check the status of one
certificate. It can (although it is not guaranteed to) improve the certificate. It can (although it is not guaranteed to) improve the
timeliness of revocation notification, and thus reduce the window of timeliness of revocation notification, and thus reduce the window of
opportunity for someone trying to use a revoked certificate. opportunity for someone trying to use a revoked certificate.
STATUS: Approved as Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the
Online Certificate Status Protocol
DESCRIPTION: To improve the degree to which it can scale, OCSP allows
caching of responses - e.g., at intermediary servers, or even at the
relying party's end system. This document describes how to support
OCSP caching at intermediary servers.
STATUS: Has been discontinued.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational
Protocols: FTP and HTTP (RFC 2585) Protocols: FTP and HTTP (RFC 2585)
DESCRIPTION: This document describes the use of the File Transfer DESCRIPTION: This document describes the use of the File Transfer
Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain
certificates and CRLs from PKI repositories. certificates and CRLs from PKI repositories.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 DOCUMENT TITLE: Diffie-Hellman Proof-of-Possesion Algorithms <draft-
ietf-pkix-dhpop-02.txt>
DESCRIPTION: This document specifies a set of methods, headers, and DESCRIPTION: This documents describes two signing algorithms using
content-types ancillary to HTTP/1.1 to publish, retrieve X.509 the Diffie-Hellman key agreement process to provide a shared secret
certificates and Certificate Revocation Lists. This protocol also as the basis of the signature. It allows Diffie-Hellman a key
facilitates determining current status of a digital certificate agreement algorithm to be used instead of requiring that the public
without the use of CRLs. This protocol defines new methods, request key being requested for certification correspond to an algorithm that
and response bodies, error codes to HTTP/1.1 protocol for securely is capable of signing and/or encrypting. The first algorithm
publishing, retrieving, and validating certificates across a generates a signature for a specific verifier where the signer and
firewall. recipient have the same public key parameters. The second algorithm
generates a signature for arbitrary verifiers where the signer and
recipient do not have the same public key parameters.
STATUS: Has been discontinued. STATUS: Under WG review.
DOCUMENT TITLE: Limited Attribute Certificate Aquisition Protocol
<draft-ietf-pkix-laap-00.txt>
DESCRIPTION: This document specifies a deliberately limited protocol
for requesting ACs from a server. It is intended to be complementary
to the use of LDAP for AC retrieval, covering those cases where use
of an LDAP server is not suitable due to the type of authorization
model being employed.
STATUS: Under WG review.
4.3 Management Protocols 4.3 Management Protocols
DOCUMENT TITLE: Certificate Management Messages over CMS <draft- DOCUMENT TITLE: Certificate Management Messages over CMS <draft-ietf-
ietf-pkix-cmc-04.txt> pkix-cmc-05.txt>
DESCRIPTION: This document defines the means by which PKI clients and DESCRIPTION: This document defines the means by which PKI clients and
servers may exchange PKI messages when using S/MIME's Cryptographic servers may exchange PKI messages when using S/MIME's Cryptographic
Message Syntax [CMS]as a transaction envelope. CMC supports the Message Syntax [CMS] as a transaction envelope. CMC supports the
certificate request message body specified in the Certificate Request certificate request message body specified in the Certificate Request
Message Format [CRMF] documents, as well as a variety of other Message Format [CRMF] documents, as well as a variety of other
certificate management messages. The primary purpose of this certificate management messages. The primary purpose of this
specification is to allow the use of an existing protocol (S/MIME)as specification is to allow the use of an existing protocol (S/MIME) as
a PKI management protocol, without requiring the development of an a PKI management protocol, without requiring the development of an
entirely new protocol such as CMP. A secondary purpose is to codify entirely new protocol such as CMP. A secondary purpose is to codify
in IETF standards the current industry practice of using PKCS 10 in IETF standards the current industry practice of using PKCS-10
messages [PKCS10] for certificate requests. messages [PKCS10] for certificate requests.
STATUS: Under WG review. STATUS: Under WG review.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
Management Message Formats
DESCRIPTION: This document contains the formats for a series of
messages important in certificate/PKI management. These messages let
CA's, RA's, and relying parties communicate with each other. Note
that this document only specifies message formats; it does not
specify a protocol for transferring messages. That protocol can be
either CMP or CMC, or perhaps another custom protocol.
STATUS: Has been discontinued, as all useful information from it has
been moved into [CMP] and [CMC].
DOCUMENT TITLE: Internet X.509 Certificate Request Message Format DOCUMENT TITLE: Internet X.509 Certificate Request Message Format
(RFC 2511) (RFC 2511)
DESCRIPTION: CRMF specifies a format recommended for use whenever a DESCRIPTION: CRMF specifies a format recommended for use whenever a
relying party is requesting a certificate from a CA or requesting relying party is requesting a certificate from a CA or requesting
that an RA help it get a certificate. The request message format was that an RA help it get a certificate. The request message format was
needed before many of the other message formats had to be finalized, needed before many of the other message formats had to be finalized,
and so it was put into a separate document. This document only and so it was put into a separate document. This document only
specifies the format of a message. Specification of a protocol to specifies the format of a message. Specification of a protocol to
transport that message is beyond the scope of CRMF. transport that message is beyond the scope of CRMF.
skipping to change at page 22, line 38 skipping to change at page 26, line 48
Management Protocols (RFC 2510) Management Protocols (RFC 2510)
DESCRIPTION: This document specifies a new protocol specifically DESCRIPTION: This document specifies a new protocol specifically
developed for the purpose of transporting messages like those developed for the purpose of transporting messages like those
specified in CRMF among PKI elements. In general, CMP will be used in specified in CRMF among PKI elements. In general, CMP will be used in
conjunction with CRMF, and will then be run over a transfer service conjunction with CRMF, and will then be run over a transfer service
(e.g., S/MIME, HTTP) to provide a complete PKI management service. (e.g., S/MIME, HTTP) to provide a complete PKI management service.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP) <draft-
ietf-pkix-scvp-01.txt>
DESCRIPTION: The SCVP protocol allows a client to offload certificate
handling to a server. The server can give a variety of valuable
information about the certificate, such as whether or not the
certificate is valid, a chain to a trusted root, and so on.
STATUS: Under WG review.
DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP <draft-
ietf-pkix-cmp-http-00.txt>
DESCRIPTION: This document describes how to layer [CMP] over [HTTP].
A simple method for doing so is described in [CMP], but that method
does not accommodate a polling mechanism, which may be required in
some environments. This document specifies an alternative method
which uses the polling protocol defined in [CMP]. A new Content-Type
for messages is also defined.
STATUS: Under WG review.
DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP <draft-
ietf-pkix-cmp-tcp-00.txt>
DESCRIPTION: This document describes how to layer Certificate
Management Protocols [CMP] over [TCP]. A method for doing so is
described in [CMP], but that method does not solve problems
encountered by implementors. This document specifies an enhanced
method which extends the protocol.
STATUS: Under WG review.
DOCUMENT TITLE: OCSP Extensions <draft-ietf-pkix-ocspx-00.txt>
DESCRIPTION: This document defines Internet-standard extensions to
OCSP that enable a client to delegate processing of certificate
acceptance functions to a trusted server. The client may control the
degree to which delegation takes place. In addition limited support
is provided for delegating authorization decisions.
STATUS: Under WG review.
4.4 Policy Outline 4.4 Policy Outline
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework (RFC 2527) Policy and Certification Practices Framework (RFC 2527)
DESCRIPTION: As noted before, the specification and implementation of DESCRIPTION: As noted before, the specification and implementation of
certificate profiles, operational protocols, and management protocols certificate profiles, operational protocols, and management protocols
is only part of building a PKI. Equally as important - if not more is only part of building a PKI. Equally as important - if not more
important - is the development and enforcement of a certificate important - is the development and enforcement of a certificate
security policy, and a Certification Practice Statement (CPS). The security policy, and a Certification Practice Statement (CPS). The
skipping to change at page 23, line 13 skipping to change at page 28, line 17
their tasks. In particular, the framework identifies the elements their tasks. In particular, the framework identifies the elements
that may need to be considered in formulating a certificate policy or that may need to be considered in formulating a certificate policy or
a CPS. The purpose is not to define particular certificate policies a CPS. The purpose is not to define particular certificate policies
or CPSs, per se. or CPSs, per se.
STATUS: Informational RFC. STATUS: Informational RFC.
4.5 Time-Stamp and Data Certification Services 4.5 Time-Stamp and Data Certification Services
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp
Protocols <draft-ietf-pkix-time-stamp-01.txt> Protocols <draft-ietf-pkix-time-stamp-03.txt>
DESCRIPTION: This document defines the specification for a time stamp DESCRIPTION: This document defines the specification for a time stamp
service. It defines a Time Stamp Authority, or TSA, a trusted third service. It defines a Time Stamp Authority, or TSA, a trusted third
party who maintains a reliable time service. When the TSA receives a party who maintains a reliable time service. When the TSA receives a
time stamp request, it appends the current time to the request and time stamp request, it appends the current time to the request and
signs it into a token to certify that the original request existed signs it into a token to certify that the original request existed
prior to the indicated time. This helps provide non-repudiation by prior to the indicated time. This helps provide non-repudiation by
preventing someone (either a legitimate user or an attacker who has preventing someone (either a legitimate user or an attacker who has
successfully compromised a key) from "back-dating" a transaction. It successfully compromised a key) from "back-dating" a transaction. It
also makes it more difficult to challenge a transaction by asserting also makes it more difficult to challenge a transaction by asserting
that it has been back-dated. Note that the TSA does not provide any that it has been back-dated. Note that the TSA does not provide any
data parsing service; that is, the TSA does not attempt to validate data parsing service; that is, the TSA does not attempt to validate
that which it signs; it merely regards it as a string of bits whose that which it signs; it merely regards it as a string of bits whose
meaning is unimportant, but existence is vital. meaning is unimportant, but existence is vital.
STATUS: Under WG review. STATUS: Under WG review.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data
Certification Server Protocols <draft-ietf-pkix-dcs-00.txt> Certification Server Protocols <draft-ietf-pkix-dcs-03.txt>
DESCRIPTION: This document defines a data certification service, or DESCRIPTION: This document defines a data validation and
DCS, which can be used to certify both the existence and correctness certification service, or DVCS, which can be used to certify both the
of a message or signature. In contrast to the time stamp service existence and correctness of a message or signature. In contrast to
described above, the DCS certifies possession of data or the validity the time stamp service described above, the DVCS certifies possession
of another entity's signature. As part of this, the DCS verifies the of data or the validity of another entity's signature. As part of
mathematical correctness of the actual signature value contained in this, the DVCS verifies the mathematical correctness of the actual
the request and also checks the full certification path from the signature value contained in the request and also checks the full
signing entity to a trusted point (e.g., the DCS's CA, or the Root CA certification path from the signing entity to a trusted point (e.g.,
in a hierarchy). the DVCS's CA, or the Root CA in a hierarchy).
The DCS supports non-repudiation in two ways. First, it provides The DVCS supports non-repudiation in two ways. First, it provides
evidence that a signature or public key certificate was valid at the evidence that a signature or public key certificate was valid at the
time indicated in the token. The token can be used even after the time indicated in the token. The token can be used even after the
corresponding public key certificate expires and its revocation corresponding public key certificate expires and its revocation
information is no longer available on CRLs (for example). Second, the information is no longer available on CRLs (for example). Second, the
production of a data certification token in response to a signed production of a data certification token in response to a signed
request for certification of another signature or public key request for certification of another signature or public key
certificate also provides evidence that due diligence was performed certificate also provides evidence that due diligence was performed
by the requester in validating the signature or public key by the requester in validating the signature or public key
certificate. certificate.
STATUS: Under WG review. STATUS: Under WG review.
DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
bert1-01.txt>
DESCRIPTION: This document defines a finite method of representing a
discrete instant in time as a referable event. The Basic Event
Representation Token (BERT) is a light-weight binary token designed
for use in large numbers over short periods of time. The tokens
contain only a single instance of an event stamp and the trust
process is referenced against an external reference.
STATUS: Under WG review.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending
trust in non repudiation tokens in time <draft-ietf-pkix-extend- trust in non repudiation tokens in time <draft-ietf-pkix-extend-
trust-non-repudiation-token-00.txt> trust-non-repudiation-token-00.txt>
DESCRIPTION: This document describes a method to maintain the trust DESCRIPTION: This document describes a method to maintain the trust
in a token issued by a non-repudiation Trusted Third Party (NR TTP) in a token issued by a non-repudiation Trusted Third Party (NR TTP)
(DCS/TSA/TDA) after the key initially used to establish trust in the (DVCS/TSA/TDA) after the key initially used to establish trust in the
token expires. The document describes a general format for storage of token expires. The document describes a general format for storage of
DCS/TS/TDA tokens for this purpose, which establishes a chain of DVCS/TS/TDA tokens for this purpose, which establishes a chain of
custody for the data. custody for the data.
STATUS: Under WG review. STATUS: Under WG review.
4.6 Documents that never made it out of the working group
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
Management Message Formats
DESCRIPTION: This document contains the formats for a series of
messages important in certificate/PKI management. These messages let
CA's, RA's, and relying parties communicate with each other. Note
that this document only specifies message formats; it does not
specify a protocol for transferring messages. That protocol can be
either CMP or CMC, or perhaps another custom protocol.
STATUS: Work has been discontinued, as all useful information from it
has been moved into [CMP] and [CMC].
DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0
DESCRIPTION: This document specifies a set of methods, headers, and
content-types ancillary to HTTP/1.1 to publish, retrieve X.509
certificates and Certificate Revocation Lists. This protocol also
facilitates determining current status of a digital certificate
without the use of CRLs. This protocol defines new methods, request
and response bodies, error codes to HTTP/1.1 protocol for securely
publishing, retrieving, and validating certificates across a
firewall.
STATUS: Work has been discontinued due to lack of interest.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL
Distribution Options (OpenCDP)
DESCRIPTION: This document proposes an alternative to the CRL
Distribution Point (CDP) approach documented in [FORMAT]. OCDP
separates the CRL location function from the process of certificate
and CRL validation, and thus claims some benefits over the CDP
approach.
STATUS: Work has been discontinued, as all useful information has
been incorporated into [X.509]. An updated [FORMAT] RFC should
profile the use of the CDP approach.
DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the
Online Certificate Status Protocol
DESCRIPTION: To improve the degree to which it can scale, OCSP allows
caching of responses - e.g., at intermediary servers, or even at the
relying party's end system. This document describes how to support
OCSP caching at intermediary servers.
STATUS: Work has been discontinued due to lack of interest.
DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
bert1-01.txt>
DESCRIPTION: This document defines a finite method of representing a
discrete instant in time as a referable event. The Basic Event
Representation Token (BERT) is a light-weight binary token designed
for use in large numbers over short periods of time. The tokens
contain only a single instance of an event stamp and the trust
process is referenced against an external reference.
STATUS: Work has been discontinued.
5 Advice to Implementors 5 Advice to Implementors
This section provides guidance to those who would implement various This section provides guidance to those who would implement various
parts of the PKIX suite of documents. The topics discussed in this parts of the PKIX suite of documents. The topics discussed in this
section engendered significant discussion in the working group, and section engendered significant discussion in the working group, and
there was at times either widespread disagreement or widespread there was at times either widespread disagreement or widespread
misunderstanding of them. Thus, this discussion is provided to help misunderstanding of them. Thus, this discussion is provided to help
readers of the PKIX document set understand these issues, in the hope readers of the PKIX document set understand these issues, in the hope
of fostering greater interoperability among eventual PKIX of fostering greater interoperability among eventual PKIX
implementations. implementations.
5.1 Names 5.1 Names
PKIX has been referred to as a "name-centric" PKI because the PKIX has been referred to as a "name-centric" PKI because the PKCs
certificates associate public keys with names of entities. Each associate public keys with names of entities. Each PKC contains at
certificate contains at least one name for the owner of a particular least one name for the owner of a particular public key. The name can
public key. The name can be an X.500 distinguished name, contained in be an X.500 distinguished name, contained in the subjectDN field of
the subjectDN field of the certificate. There can also be names such the PKC. There can also be names such as RFC822 e-mail addresses, DNS
as RFC822 e-mail addresses, DNS domain names, and URIs associated domain names, and uniform resource identifiers (URIs) associated with
with the key; these attributes are kept in the subjectAltName the key; these attributes are kept in the subjectAltName extension of
extension of the certificate. A certificate must contain at least one the PKC. A PKC must contain at least one of these name forms, it may
of these name forms, it may contain multiple forms if deemed contain multiple forms if deemed appropriate by the CA based on the
appropriate by the CA based on the intended usage of the certificate. intended usage of the PKC.
5.1.1 Name Forms 5.1.1 Name Forms
There are two possible places to put a name in an X.509v3 There are two possible places to put a name in an X.509 v3 PKC. One
certificate. One is the subject field in the base certificate (often is the subject field in the base PKC (often called the "Distinguished
called the "Distinguished Name" or "DN" field), and the other is in Name" or "DN" field), and the other is in the subjectAltName
the subjectAltName extension. extension.
5.1.1.1 Distinguished Names 5.1.1.1 Distinguished Names
According to [FORMAT], a PKIX certificate must have a non-null value According to [FORMAT], a PKIX PKC must have a non-null value in the
in the Subject field, except for an end-entity certificate, which is subject field, except for an EE PKC, which is permitted to have an
permitted to have an empty subject field. Furthermore, if a empty subject field. Furthermore, if a PKC has a non-null subject
certificate has a non-null Subject field, it MUST contain an X.500 field, it MUST contain an X.500 Distinguished Name.
Distinguished Name.
5.1.1.2 SubjectAltName Forms 5.1.1.2 SubjectAltName Forms
In addition to the DN, a PKIX certificate may have one or more values In addition to the DN, a PKIX PKC may have one or more values in the
in the subjectAltName extension. subjectAltName extension.
The subjectAltName extension allows additional identities to be bound The subjectAltName extension allows additional identities to be bound
to the subject of the certificate - e.g., it allows "umbc.edu" and to the subject of the PKC (e.g., it allows "umbc.edu" and
"130.85.1.3" to be associated with a particular subject, as well as "130.85.1.3" to be associated with a particular subject, as well as
"C=US, O=University of Maryland, L=Baltimore, CN=UMBC". X.509-defined "C=US, O=University of Maryland, L=Baltimore, CN=UMBC").
options for this extension include: Internet electronic mail X.509-defined options for this extension include: Internet electronic
addresses; DNS names; IP addresses; and uniform resource indentifiers mail addresses; DNS names; IP addresses; and URIs. Other options can
(URIs). Other options can exist, including locally-defined name exist, including locally-defined name forms.
forms.
A single subjectAltName extension can include multiple name forms, A single subjectAltName extension can include multiple name forms,
and multiple instances of each name form. and multiple instances of each name form.
Whenever such Alternate Name forms are to be bound into a Whenever such alternate name forms are to be bound into a PKC, the
certificate, the subject alternative name (or issuer alternative subjectAltName (or issuerAltName) extension must be used. It is
name) extension must be used. It is technically possible to embed an technically possible to embed an alternate name form in the subject
Alternate Name Form in the subject field. For example, one could make field. For example, one could make a DN contain an IP address via a
a DN contain an IP address via a kludge such as "C=US, L=Baltimore, kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this
CN=130.85.1.3". However, this usage is deprecated; the alternative usage is deprecated; the alternative name extension is the preferred
name extension is the preferred location for finding such location for finding such information. As another example, some
information. As another example, some legacy implementations exist legacy implementations exist where an RFC822 name is embedded in the
where an RFC822 name is embedded in the subject distinguished name as subject distinguished name as an EmailAddress attribute. Per
an EmailAddress attribute. Per [FORMAT], PKIX-compliant [FORMAT], PKIX-compliant implementations generating new PKCs with
implementations generating new certificates with electronic mail electronic mail addresses MUST use the rfc822Name in the
addresses MUST use the rfc822Name in the subject alternative name subjectAltName extension to describe such EEs. Simultaneous inclusion
field to describe such entities. Simultaneous inclusion of the of the EmailAddress attribute in the subject distinguished name to
EmailAddress attribute in the subject distinguished name to support support legacy implementation is deprecated but permitted.
legacy implementation is deprecated but permitted.
In line with this, if the only subject identity included in a In line with this, if the only subject identity included in a PKC is
certificate is an alternative name form, then the subject an alternative name form, then the subject distinguished name must be
distinguished name must be empty (technically, an empty sequence), empty (technically, an empty sequence), and the subjectAltName
and the subjectAltName extension must be present. If the subject extension must be present. If the subject field contains an empty
field contains an empty sequence, the subjectAltName extension must sequence, the subjectAltName extension must be marked critical.
be marked critical.
If the subjectAltName extension is present, the sequence must contain If the subjectAltName extension is present, the sequence must contain
at least one entry. Unlike the subject field, conforming CAs shall at least one entry. Unlike the subject field, conforming CAs shall
not issue certificates with subjectAltNames containing empty not issue PKCs with subjectAltNames containing empty GeneralName
GeneralName fields. For example, an rfc822Name is represented as an fields. For example, an rfc822Name is represented as an IA5String.
IA5String. While an empty string is a valid IA5String, such an While an empty string is a valid IA5String, such an rfc822Name is not
rfc822Name is not permitted by PKIX. The behavior of clients that permitted by PKIX. The behavior of clients that encounter such a PKC
encounter such a certificate when processing a certification path is when processing a certification path is not defined by this working
not defined by this working group. group.
Because the subject alternative name is considered to be definitively Because the subject's alternative name is considered to be
bound to the public key, all parts of the subject alternative name definitively bound to the public key, all parts of the subject's
must be verified by the CA. alternative name must be verified by the CA.
5.1.1.2.1 Internet e-mail addresses 5.1.1.2.1 Internet e-mail addresses
When the subjectAltName extension contains an Internet mail address, When the subjectAltName extension contains an Internet mail address,
the adress is included as an rfc822Name. The format of an rfc822Name the adress is included as an rfc822Name. The format of an rfc822Name
is an "addr-spec" as defined in [RFC-822]. An addr-spec has the form is an "addr-spec" as defined in [RFC-822]. An addr-spec has the form
local-part@domain; it does not have a phrase (such as a common name) local-part@domain; it does not have a phrase (such as a common name)
before it, or a comment (text surrounded in parentheses) after it, before it, or a comment (text surrounded in parentheses) after it,
and it is not surrounded by "<" and ">". and it is not surrounded by "<" and ">".
skipping to change at page 27, line 13 skipping to change at page 33, line 15
be encoded as rfc822Name. be encoded as rfc822Name.
5.1.1.2.3 IP addresses 5.1.1.2.3 IP addresses
When the subjectAltName extension contains an iPAddress, the address When the subjectAltName extension contains an iPAddress, the address
shall be stored in the octet string in "network byte order," as shall be stored in the octet string in "network byte order," as
specified in [IP]. The least significant bit (LSB) of each octet is specified in [IP]. The least significant bit (LSB) of each octet is
the LSB of the corresponding byte in the network address. For IP the LSB of the corresponding byte in the network address. For IP
Version 4, as specified in [IP], the octet string must contain Version 4, as specified in [IP], the octet string must contain
exactly four octets. For IP Version 6, as specified in [IPv6], the exactly four octets. For IP Version 6, as specified in [IPv6], the
octet string must contain exactly sixteen octets [RFC1883]. octet string must contain exactly sixteen octets.
5.1.1.2.4 URIs 5.1.1.2.4 URIs
[FORMAT] notes "When the subjectAltName extension contains a URI, the [FORMAT] notes "When the subjectAltName extension contains a URI, the
name MUST be stored in the uniformResourceIdentifier (an IA5String). name MUST be stored in the uniformResourceIdentifier (an IA5String).
The name MUST be a non-relative URL, and MUST follow the URL syntax The name MUST be a non-relative URL, and MUST follow the URL syntax
and encoding rules specified in [RFC 1738]. The name must include and encoding rules specified in [RFC 1738]. The name must include
both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The
scheme-specific-part must include a fully qualified domain name or IP scheme-specific-part must include a fully qualified domain name or IP
address as the host. As specified in [RFC 1738], the scheme name is address as the host. As specified in [RFC 1738], the scheme name is
skipping to change at page 27, line 50 skipping to change at page 34, line 4
reasons. There is no single entity in the world trusted by everybody reasons. There is no single entity in the world trusted by everybody
to reside at the top of the name space, and there is no way to to reside at the top of the name space, and there is no way to
enforce uniqueness on names for all entities. (These were among the enforce uniqueness on names for all entities. (These were among the
reasons for the failure of PEM to be widely implemented.) reasons for the failure of PEM to be widely implemented.)
This does not mean, however, that a name-based PKI cannot work. It is This does not mean, however, that a name-based PKI cannot work. It is
important to recognize that the scope of names in PKIX is local; they important to recognize that the scope of names in PKIX is local; they
need to be defined and unique only within their own domain. need to be defined and unique only within their own domain.
Suppose for example that a Top CA is established with DN "O=IETF, Suppose for example that a Top CA is established with DN "O=IETF,
OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for users OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects
subordinate to it. The only requirement - and this can be enforced subordinate to it. The only requirement, which can be enforced
procedurally - is that no two distinct entities beneath this Top CA procedurally, is that no two distinct entities beneath this Top CA
have the same name. We can't prevent somebody else in the world from have the same name. We can't prevent somebody else in the world from
creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is
not necessary to do so. Within the domain of the original Top CA, not necessary to do so. Within the domain of the original Top CA,
there will be no conflict, and the fact that there is another CA of there will be no conflict, and the fact that there is another CA of
the same name in some other domain is irrelevant. the same name in some other domain is irrelevant.
This is analogous to the current DNS or IP address situations. On the This is analogous to the current DNS or IP address situations. On the
Internet, there is only one node called www.ietf.org. The fact that Internet, there is only one node called www.ietf.org. The fact that
there might be 10 different intranets, each with a host given the DNS there might be 10 different intranets, each with a host given the DNS
name www.ieft.org, is irrelevant and causes no interoperability name www.ieft.org, is irrelevant and causes no interoperability
skipping to change at page 28, line 33 skipping to change at page 34, line 36
be a problem. be a problem.
5.1.3 Certificate Path Construction 5.1.3 Certificate Path Construction
Certificate path construction has been the topic of many discussions Certificate path construction has been the topic of many discussions
in the WG. The issue centered around how best to get a certificate in the WG. The issue centered around how best to get a certificate
when the connection between the subject's name and the name of their when the connection between the subject's name and the name of their
CA, as well as the CA's repository (or directory), may not be CA, as well as the CA's repository (or directory), may not be
obvious. Many proposals were put forth, including implementing a obvious. Many proposals were put forth, including implementing a
global X.500 Directory Service, using DNS SRV records, and using an global X.500 Directory Service, using DNS SRV records, and using an
attribute to point to the directory provider. At the end of the extension to point to the directory provider. At the end of the
discussion the group decided to use the authority information access discussion the group decided to use the authority information access
extension defined in [FORMAT], which allows the CA to indicate the extension defined in [FORMAT], which allows the CA to indicate the
access method and location of CA information and services. The access method and location of CA information and services. The
extension would be included in subject's certificates and could be extension would be included in subject's certificates and could be
used to associate an Internet style identity for the location of used to associate an Internet style identity for the location of
repository to retrieve the issuer's certificate in cases where such a repository to retrieve the issuer's certificate in cases where such a
location is not related to the issuer's name. location is not related to the issuer's name.
Another discussion related to certificate path construction was where Another discussion related to certificate path construction was where
to store the CA and end-entity certificates in the directory to store the CA and EE PKCs in the directory (specifically LDAPv2
(specifically LDAPv2 directories). Two camps emerged with different directories). Two camps emerged with different views on where to
views on where to store CA and cross-certificates. In the CA's store CA and cross-certificates. In the CA's directory entry, one
directory entry, one camp wanted self-issued certificates stored in camp wanted self-issued PKCs stored in the cACertificate attribute,
the cACertificate attribute, certificates issued to this CA stored in PKCs issued to this CA stored in the forward element of the
the forward element of the crossCertificatePair, and certificates crossCertificatePair, and PKCs issued from this CA for other CAs in
issued from this CA for other CAs in the reverse element of the the reverse element of the crossCertificatePair attribute. The other
crossCertificatePair attribute. The other camp wanted all CA camp wanted all CA PKCs stored in the cACertificate attribute, and
certificates stored in the cACertificate attribute, and certificates PKCs issued to/from another domain stored in the crossCertificatePair
issued to/from another domain stored in the crossCertificatePair
attribute. There was a short discussion that the second was more attribute. There was a short discussion that the second was more
efficient than first, and that one solution or the other was more efficient than first, and that one solution or the other was more
widely deployed. The end result was to indicate that self-issued widely deployed. The end result was to indicate that self-issued PKCs
certificates and certificates issued to the CA by CAs in the same and PKCs issued to the CA by CAs in the same domain as the CA are
domain as the CA are stored in the cACertificate attribute. The stored in the cACertificate attribute. The crossCertificatePair
crossCertificatePair attribute's forward element will include all but attribute's forward element will include all but self-issued PKCs
self-issued certificates issued to the CA. The reverse element may issued to the CA. The reverse element may include a subset of PKCs
include a subset of certificates issued by the CA to other CAs. With issued by the CA to other CAs. With this resolution both camp's
this resolution both camp's implementations are supported and are implementations are supported and are free to chose the location of
free to chose the location of CA certificates to best support their CA PKCs to best support their implementation.
implementation.
5.1.4 Name Constraints 5.1.4 Name Constraints
A question that has arisen a number of times is "how does one enforce A question that has arisen a number of times is "how does one enforce
Name constraints when there is more than one name form in a Name constraints when there is more than one name form in a PKC?"
certificate?" That is, [FORMAT] states that: That is, [FORMAT] states that:
Subject alternative names may be constrained in the same manner as subject's alternative names may be constrained in the same manner
subject distinguished names using the name constraints extension as subject distinguished names using the name constraints extension
as described in section 4.2.1.11. as described in section 4.2.1.11.
What does this mean? Suppose that there is a CA with DN "O=IETF, What does this mean? Suppose that there is a CA with DN "O=IETF,
OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having
dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a PKC
certificate with an empty DN, with subjectAltName extension having with an empty DN, with subjectAltName extension having dNSName set to
dNSName set to "PKIX_CA.IETF.ORG", and rfc822Name set to "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The
Steve@PKIX_CA.IETF.ORG. The question is, are name constraints question is, are name constraints enforced on these two PKCs - is the
enforced on these two certificates - is the name of the end-entity name of the EE PKC considered to be properly subordinate to the name
certificate considered to be properly subordinate to the name of the of the CA?
CA?
The answer is "yes". The general rules for deciding whether a The answer is "yes". The general rules for deciding whether a PKC
certificate meets name constraints are: meets name constraints are:
- If a certificate complies with name constraints in any one of - If a PKC complies with name constraints in any one of its name
its name forms, then the certificate is deemed to comply with forms, then the PKC is deemed to comply with name constraints.
name constraints.
- If a certificate contains a name form that its issuer does - If a PKC contains a name form that its issuer does not, the PKC
not, the certificate is deemed to comply with name constraints is deemed to comply with name constraints for that name form.
for that name form.
In deciding whether a name form meets name constraints, the following In deciding whether a name form meets name constraints, the following
rules apply (in all cases Name B is the name in the name constraints rules apply (in all cases Name B is the name in the name constraints
extension): extension):
5.1.4.1 rfc822Names 5.1.4.1 rfc822Names
Three variations are allowed: Three variations are allowed:
- If the name constraint is specified as "larry@mail.mit.edu", - If the name constraint is specified as "larry@mail.mit.edu", then
then Name A is subordinate to Name B (in B's subtree) if Name Name A is subordinate to Name B (in B's subtree) if Name A
A contains all of Name B's name (specifies a particular contains all of Name B's name (specifies a particular mailbox).
mailbox). For example, larry@mail.mit.edu is subordinate, but For example, larry@mail.mit.edu is subordinate, but
larry_sanders@mail.mit.edu is not. larry_sanders@mail.mit.edu is not.
- If the name constraint is specified as "mail.mit.edu", then - If the name constraint is specified as "mail.mit.edu", then Name
Name A is subordinate to Name B (in B's subtree) if Name A A is subordinate to Name B (in B's subtree) if Name A contains
contains all of Name B's name (specified all mailboxes on host all of Name B's name (specified all mailboxes on host
mail.mit.edu). For example, curly@mail.mit.edu and mail.mit.edu). For example, curly@mail.mit.edu and
mo@mail.mit.edu are subordinate, but mo@mail6.mit.edu and mo@mail.mit.edu are subordinate, but mo@mail6.mit.edu and
curly@smtp.mail.mit.edu are not. curly@smtp.mail.mit.edu are not.
- If the name constraint is specified as ".mit.edu", then Name A - If the name constraint is specified as ".mit.edu", then Name A is
is subordinate to Name B (in B's subtree) if Name A contains subordinate to Name B (in B's subtree) if Name A contains all of
all of Name B's name, with the addition of zero or more Name B's name, with the addition of zero or more additional host
additional host or domain names to the left of Name B's name. or domain names to the left of Name B's name. That is,
That is, smtp.mit.edu is subordinate to .mit.edu, as is smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu.
pop.mit.edu. However, mit.edu is not subordinate to .mit.edu. However, mit.edu is not subordinate to .mit.edu. When the
When the constraint begins with a "." it specifies any address constraint begins with a "." it specifies any address within a
within a domain. In the previous example, "mit.edu" is not in domain. In the previous example, "mit.edu" is not in the domain
the domain of ".mit.edu". of ".mit.edu".
Note: If rfc822 names are constrained, but the certificate does not Note: If rfc822 names are constrained, but the PKC does not contain a
contain a subject alternative name, the EmailAddress attribute will subjectAltName extension, the EmailAddress attribute will be used to
be used to constrain the name in the subject distinguished name. For constrain the name in the subject distinguished name. For example (c
example (c is country, o is organization, ou is organizational unit, is country, o is organization, ou is organizational unit, and em is
and em is EmailAddress), Name A ("c=US, o=MIT, ou=CS, EmailAddress), Name A ("c=US, o=MIT, ou=CS, em=curly@mail.mit.edu")
em=curly@mail.mit.edu") is subordinate to Name B ("c=US, o=MIT, is subordinate to Name B ("c=US, o=MIT, ou=CS") (in B's subtree) if
ou=CS") (in B's subtree) if Name A contains all of Name B's names. Name A contains all of Name B's names.
5.1.4.2 dNSNames 5.1.4.2 dNSNames
Name A is subordinate to Name B (in B's subtree) if Name A contains Name A is subordinate to Name B (in B's subtree) if Name A contains
all of Name B's name, with the addition of zero or more additional all of Name B's name, with the addition of zero or more additional
domain names to the left of Name B's name. That is, www.mit.edu is domain names to the left of Name B's name. That is, www.mit.edu is
subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu
is not subordinate to web.mit.edu. is not subordinate to web.mit.edu.
5.1.4.3 x.400 addresses 5.1.4.3 x.400 addresses
skipping to change at page 31, line 24 skipping to change at page 37, line 22
Name A is subordinate to Name B (in B's subtree), if Name A contains Name A is subordinate to Name B (in B's subtree), if Name A contains
all of Name B's name, treating attribute values encoded in different all of Name B's name, treating attribute values encoded in different
types as different strings, ignoring case in PrintableString (in all types as different strings, ignoring case in PrintableString (in all
other types case is not ignored), removing leading and trailing white other types case is not ignored), removing leading and trailing white
space in PrintableString, and converting internal substrings of one space in PrintableString, and converting internal substrings of one
or more consecutive white space characters to a single space. For or more consecutive white space characters to a single space. For
example, (c is country, o is organization, ou is organizational unit, example, (c is country, o is organization, ou is organizational unit,
and cn is common name): and cn is common name):
- Assuming PrinatString types for all attribute values in Name A - Assuming PrinatString types for all attribute values in Name A
and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT, and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT,
ou=cs", as is "c=US, o=MIT, ou=CS, ou=adminstration". Another ou=cs", as is "c=US, o=MIT, ou=CS, ou=adminstration". Another
example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white
spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe". spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe".
- Assuming UTF8String types for all attribute values in Name A - Assuming UTF8String types for all attribute values in Name A and
and B, "c=US, o=MIT, ou=CS, ou=administration" is subordinate B, "c=US, o=MIT, ou=CS, ou=administration" is subordinate to
to "c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, "c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, ou=Adminstration".
ou=Adminstration". "c=US, o=MIT, ou=CS, cn= John Smith" (note "c=US, o=MIT, ou=CS, cn= John Smith" (note the white spaces) is
the white spaces) is not subordinate to "c=US, o=MIT, ou=CS, not subordinate to "c=US, o=MIT, ou=CS, cn= John Smith".
cn= John Smith".
- Assuming UTF8String types for all attribute values in Name A - Assuming UTF8String types for all attribute values in Name A and
and PrintableString types for all attribute values in Name B, PrintableString types for all attribute values in Name B, "c=US,
"c=US, o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the
the verification software supports the full comparison verification software supports the full comparison algorithm in
algorithm in the X.500 series. "c=US, o=MIT, ou=cs" is NOT the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to
subordinate to "c=US, o=MIT, ou=CS" if the verification "c=US, o=MIT, ou=CS" if the verification software supports the
software supports the comparison algorithm in [FORMAT]. comparison algorithm in [FORMAT].
5.1.4.6 URIs 5.1.4.6 URIs
The constraints apply only to the host part of the name. Two The constraints apply only to the host part of the name. Two
variations are allowed: variations are allowed:
- If the name constraint is specified as ".mit.edu", then Name A - If the name constraint is specified as ".mit.edu", then Name A is
is subordinate to Name B (in B's subtree) if Name A contains subordinate to Name B (in B's subtree) if Name A contains all of
all of Name B's name, with the addition of zero or more Name B's name, with the addition of zero or more additional host
additional host or domain names to the left of Name B's name. or domain names to the left of Name B's name. That is,
That is, www.mit.edu is subordinate to .mit.edu, as is www.mit.edu is subordinate to .mit.edu, as is curly.cs.mit.edu.
curly.cs.mit.edu. However, mit.edu is not subordinate to
.mit.edu. When the constraint begins with a "." it specifies a
host.
- If the name constraint is specified as "abc.mit.edu", then However, mit.edu is not subordinate to .mit.edu. When the
Name A is subordinate to Name B (in B's subtree) if Name A constraint begins with a "." it specifies a host.
conatins all of Name B's name. No leftward expansion of the
host or domain name is allowed. - If the name constraint is specified as "abc.mit.edu", then Name A
is subordinate to Name B (in B's subtree) if Name A conatins all
of Name B's name. No leftward expansion of the host or domain
name is allowed.
5.1.4.7 iPaddresses 5.1.4.7 iPaddresses
Two variations are allowed depending on the IP version: Two variations are allowed depending on the IP version:
- For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) - For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) is
is subordinate to Name B (128.32.1.0/255.255.255.0 encoded as subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20
80 20 00 00 FF FF FF 00) (in B's subtree) if Name A falls 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the
within the net denoted in Name B's CIDR notation. net denoted in Name B's CIDR notation.
- For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 - For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded
encoded as 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is as 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is
subordinate to Name B (4224.0.0.0.8.2048.8204.0/ subordinate to Name B (4224.0.0.0.8.2048.8204.0/
65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00
00 00 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF 00 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF 00 00) (in B's subtree) if Name A falls FF FF FF FF FF 00 00) (in B's subtree) if Name A falls within the
within the net denoted in Name B's CIDR notation. net denoted in Name B's CIDR notation.
5.1.4.8 Others 5.1.4.8 Others
As [FORMAT] does not define requirements for the name forms As [FORMAT] does not define requirements for the name forms
otherName, ediPartyName, or registeredID there are no corresponding otherName, ediPartyName, or registeredID there are no corresponding
name constraints requirements. name constraints requirements.
5.1.5 Wildcards in Name Forms 5.1.5 Wildcards in Name Forms
A "wildcard" in a name form is a placeholder for a set of names; e.g. A "wildcard" in a name form is a placeholder for a set of names
"*.mit.edu" meaning "any domain name ending in .mit.edu", and (e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and
*@aol.com meaning "email address that uses aol.com". There are many *@aol.com meaning "email address that uses aol.com"). There are many
people who believe that allowing wildcards in name forms in PKIX people who believe that allowing wildcards in name forms in PKIX PKCs
certificates would be a useful thing to do, because it would allow a would be a useful thing to do, because it would allow a single PKC to
single certificate to be used by all members of a group. These be used by all members of a group. These members would presumably
members would presumably have attributes in common; e.g., access have attributes in common; e.g., access rights to some set of
rights to some set of resources, and so issuance of a certificate resources, and so issuance of a PKC with a wildcard for the group
with a wildcard for the group would simplify management. would simplify management.
After much discussion, the PKIX working group decided to permit the After much discussion, the PKIX working group decided to permit the
use of wildcards in certificates. That is, it is permissible for a use of wildcards in PKCs. That is, it is permissible for a PKIX-
PKIX-conformant CA to issue a certificate with a wildcard. However, conformant CA to issue a PKC with a wildcard. However, the semantics
the semantics of subject alternative names that include wildcard of subjectAltName extension that include wildcard characters are not
characters are not addressed by PKIX. Applications with specific addressed by PKIX. Applications with specific requirements may use
requirements may use such names but must define the semantics. such names but must define the semantics.
5.1.6 Name Encoding 5.1.6 Name Encoding
A very important topic that consumed much of the WG's time was the A very important topic that consumed much of the WG's time was the
implementation of the directory string choices. While the long term implementation of the directory string choices. While the long term
goal of the IETF was clear, use UTF8String, the short term goals were goal of the IETF was clear, use UTF8String, the short term goals were
not so clear. Many implementations only use PrintableString, others not so clear. Many implementations only use PrintableString, others
use BMPString, and still others use Latin1String (ISO 8859-1) and tag use BMPString, and still others use Latin1String (ISO 8859-1) and tag
it as TeletexString (there are others still). To ensure that there is it as TeletexString (there are others still). To ensure that there is
consistency with encodings [FORMAT] defines a set of rules for the consistency with encodings [FORMAT] defines a set of rules for the
skipping to change at page 33, line 31 skipping to change at page 39, line 27
choice, also for it's widespread vendor support. Failing support by choice, also for it's widespread vendor support. Failing support by
PrintableString and BMPString, UTF8String must be used. In keeping PrintableString and BMPString, UTF8String must be used. In keeping
with the IETF mandate, UTF8String can be used at any time if the CA with the IETF mandate, UTF8String can be used at any time if the CA
supports it. Also, processing implementations that wish to support supports it. Also, processing implementations that wish to support
TeletexString should handle the entire ISO 8859-1 character set and TeletexString should handle the entire ISO 8859-1 character set and
not just the Latin1String subset. not just the Latin1String subset.
5.2 POP 5.2 POP
Proof of Possession, or POP, means that the CA is adequately Proof of Possession, or POP, means that the CA is adequately
convinced that the entity requesting a certificate containing a convinced that the entity requesting a PKC containing a public key Y
public key Y has access to the private key X corresponding to that has access to the private key X corresponding to that public key.
public key.
POP is important because it provides an appropriate level of POP is important because it provides an appropriate level of
assurance in the correct operation of the PKI as a whole. At its assurance in the correct operation of the PKI as a whole. At its
lowest level, POP counters the "self-inflicted denial of service"; lowest level, POP counters the "self-inflicted denial of service";
that is, an entity voluntarily getting a certificate that cannot be that is, an entity voluntarily getting a PKC that cannot be used to
used to sign or encrypt/decrypt information. However, as the sign or encrypt/decrypt information. However, as the following two
following two examples demonstrate, POP also counters less direct, examples demonstrate, POP also counters less direct, but more severe,
but more severe, threats. threats.
5.2.1 POP for Signing Keys 5.2.1 POP for Signing Keys
It is important to provide POP for keys used to sign material, in It is important to provide POP for keys used to sign material, in
order to provide non-repudiation of transactions. For example, order to provide non-repudiation of transactions. For example,
suppose Alice legitimately has private key X and its corresponding suppose Alice legitimately has private key X and its corresponding
public key Y. Alice has a certificate from Charlie, a CA, containing public key Y. Alice has a PKC from Charlie, a CA, containing Y. Alice
Y. Alice uses X to sign a transaction T. Without POP, Mal could also uses X to sign a transaction T. Without POP, Mal could also get a PKC
get a certificate from Charlie containing the same public key, Y. from Charlie containing the same public key, Y. Now, there are two
Now, there are two possible threats: Mal could claim to have been the possible threats: Mal could claim to have been the real signer of T;
real signer of T; or Alice can falsely deny signing T, claiming that or Alice can falsely deny signing T, claiming that it was instead
it was instead Mal. Since no one can reliably prove that Mal did or Mal. Since no one can reliably prove that Mal did or did not ever
did not ever possess X, neither of these claims can be refuted, and possess X, neither of these claims can be refuted, and thus the
thus the service provided by and the confidence in the PKI has been service provided by and the confidence in the PKI has been defeated.
defeated. (Of course, if Mal really did possess X, Alice's private (Of course, if Mal really did possess X, Alice's private key, then no
key, then no POP mechanism in the world will help, but that is a POP mechanism in the world will help, but that is a different
different problem.) problem.)
One level of protection can be gained by having Alice, as the true One level of protection can be gained by having Alice, as the true
signer of the transaction, include in the signed information her signer of the transaction, include in the signed information her PKC
certificate or an identifier of her certificate (e.g., a hash of her or an identifier of her PKC (e.g., a hash of her PKC). This might
certificate). This might make it more difficult for Mal to claim make it more difficult for Mal to claim authorship - he would have to
authorship - he would have to assert that he incorrectly included assert that he incorrectly included Alice's PKC, rather than his own.
Alice's certificate, rather than his own. However, it would not stop However, it would not stop Alice from falsely repudiating her
Alice from falsely repudiating her actions. Since the certificate actions. Since the PKC itself is a public item, Mal indeed could have
itself is a public item, Mal indeed could have inserted Alice's inserted Alice's PKC into the signed transaction, and thus its
certificate into the signed transaction, and thus its presence does presence does not indicate that Alice was the one who participated in
not indicate that Alice was the one who participated in the now- the now-repudiated transaction. The only reliable way to stop this
repudiated transaction. The only reliable way to stop this attack is attack is to require that Mal prove he possesses X before his PKC is
to require that Mal prove he possesses X before his certificate is
issued. issued.
For signing keys used only for authentication, and not for non- For signing keys used only for authentication, and not for non-
repudiation, the threat is lower because users may not care about repudiation, the threat is lower because users may not care about
Alice's after-the-fact repudiation, and thus POP becomes less Alice's after-the-fact repudiation, and thus POP becomes less
important. However, POP SHOULD still be done wherever feasible in important. However, POP SHOULD still be done wherever feasible in
this environment, by either off-line or on-line means. this environment, by either off-line or on-line means.
5.2.2 POP for Key Management Keys 5.2.2 POP for Key Management Keys
Similarly, POP for key management keys (that is, keys used for either Similarly, POP for key management keys (that is, keys used for either
key agreement or key exchange) can help to prevent undermining key agreement or key exchange) can help to prevent undermining
confidence in the PKI. Suppose that Al is a new instructor in the confidence in the PKI. Suppose that Al is a new instructor in the
Computer Science Department of a local University. Al has created a Computer Science Department of a local University. Al has created a
draft final exam for the Introduction to Networking course he is draft final exam for the Introduction to Networking course he is
teaching. He wants to send a copy of the draft final to Dorothy, the teaching. He wants to send a copy of the draft final to Dorothy, the
Department Head, for her review prior to giving the exam. This exam Department Head, for her review prior to giving the exam. This exam
will of course be encrypted, as several students have access to the will of course be encrypted, as several students have access to the
computer system. However, a quick search of the certificate computer system. However, a quick search of the PKC repository (e.g.,
repository (e.g., search the repository for all records with search the repository for all records with
subjectPublicKey=Dorothy's-value) turns up the fact that several subjectPublicKey=Dorothy's-value) turns up the fact that several
students have certificates containing the same public key management students have PKCs containing the same public key management key as
key as Dorothy. At this point, if no POP has been done by the CA, Al Dorothy. At this point, if no POP has been done by the CA, Al has no
has no way of knowing whether all of the students have simply created way of knowing whether all of the students have simply created these
these certificates without knowing the corresponding private key (and PKCs without knowing the corresponding private key (and thus it is
thus it is safe to send the encrypted exam to Dorothy), or whether safe to send the encrypted exam to Dorothy), or whether the students
the students have somehow acquired Dorothy's private key (and thus it have somehow acquired Dorothy's private key (and thus it is certainly
is certainly not safe to send the exam). Thus, the service to be not safe to send the exam). Thus, the service to be provided by the
provided by the PKI - allowing users to communicate with one another, PKI - allowing users to communicate with one another, with confidence
with confidence in who they are communicating with - has been totally in who they are communicating with - has been totally defeated. If
defeated. If the CA is providing POP, then either no students will the CA is providing POP, then either no students will have such PKCs,
have such certificates, or Al can know with certainty that the or Al can know with certainty that the students do indeed know
students do indeed know Dorothy's private key, and act accordingly. Dorothy's private key, and act accordingly.
CMP requires that POP be provided for all keys, either through on- CMP requires that POP be provided for all keys, either through on-
line or out-of-band means. There are any number of ways to provide line or out-of-band means. There are any number of ways to provide
POP, and the choice of which to use is a local matter. Additionally, POP, and the choice of which to use is a local matter. Additionally,
a certificate requester can provide POP to either a CA or to an RA, a PKC requester can provide POP to either a CA or to an RA, if the RA
if the RA can adequately assure the CA that POP has been performed. can adequately assure the CA that POP has been performed. Some of the
Some of the acceptable ways to provide POP include: acceptable ways to provide POP include:
- Out-of-band means: - Out-of-band means:
- For keys generated by the CA or an RA (e.g., on a token such - For keys generated by the CA or an RA (e.g., on a token such as
as a smart card or PCMCIA card), possession of the token can a smart card or PCMCIA card), possession of the token can
provide adequate proof of possession of the private key. provide adequate proof of possession of the private key.
- For user-generated keys, another approach can be used in - For user-generated keys, another approach can be used in
environments where "key recovery" requirements force the environments where "key recovery" requirements force the
requester to provide a copy of the private key to the CA or requester to provide a copy of the private key to the CA or an
an RA. In this case, the CA will not issue the requested RA. In this case, the CA will not issue the requested PKC until
certificate until such time as the requester has provided such time as the requester has provided the private key. This
the private key. This approach is in general not approach is in general not recommended, as it is extremely
recommended, as it is extremely risky (e.g., the system risky (e.g., the system designers need to figure out a way to
designers need to figure out a way to protect the private protect the private keys from compromise while they are being
keys from compromise while they are being sent to the sent to the CA/RA/other authority, and how to protect them
CA/RA/other authority, and how to protect them there), but there), but it can be used.
it can be used.
- On-line means: - On-line means:
- For signature keys that are generated by an end-entity, the - For signature keys that are generated by an EE, the requester
requester of a certificate can be required to sign some of a PKC can be required to sign some piece of data (typically,
piece of data (typically, the certificate request itself) the PKC request itself) using the private key. The CA will then
using the private key. The CA will then use the requested use the requested public key to verify the signature. If the
public key to verify the signature. If the signature signature verification works, the CA can safely conclude that
verification works, the CA can safely conclude that the the requester had access to the private key. If the signature
requester had access to the private key. If the signature verification process fails, the CA can conclude that the
verification process fails, the CA can conclude that the requester did not have access to the correct private key, and
requester did not have access to the correct private key, reject the request.
and reject the request.
- For key management keys that are generated by the requester, - For key management keys that are generated by the requester,
the CA can send the user the requested public key, along the CA can send the user the requested public key, along with
with the CA's own private key, to encrypt some piece of the CA's own private key, to encrypt some piece of data, and
data, and send it to the requester to be decrypted. For send it to the requester to be decrypted. For example, the CA
example, the CA can generate some random challenge, and can generate some random challenge, and require some action to
require some action to be taken after decryption (e.g., be taken after decryption (e.g., "decrypt this encrypted random
"decrypt this encrypted random number and send it back to number and send it back to me"). If the requester does not take
me"). If the requester does not take the requested action, the requested action, the CA concludes that the requester did
the CA concludes that the requester did not possess the not possess the private key, and the PKC is not issued.
private key, and the certificate is not issued.
Another method of providing POP for key management keys is for the CA Another method of providing POP for key management keys is for the CA
to generate the requested certificate, and then send it to the to generate the requested PKC, and then send it to the requester in
requester in encrypted form. If the requester does not have access to encrypted form. If the requester does not have access to the
the appropriate private key, the requester cannot decrypt the appropriate private key, the requester cannot decrypt the PKC, and
certificate, and thus cannot use it. After some period of time in thus cannot use it. After some period of time in which the PKC is not
which the certificate is not used, the CA will revoke the used, the CA will revoke the PKC. (This only works if the PKC is not
certificate. (This only works if the certificate is not made made available to any untrusted entities until after the requester
available to any untrusted entities until after the requester has has successfully decrypted it.)
successfully decrypted it.)
5.3 Key Usage Bits 5.3 Key Usage Bits
The key usage extension defines the purpose (e.g., encipherment, 5.3.1 Key Usage Extension
signature, certificate signing) of the key contained in the
certificate. This extension is used when a key that could be used for
more than one operation is to be restricted. For example, when an RSA
key should be used only for signing, the digitalSignature and/or
nonRepudiation bits would be asserted. Likewise, when an RSA key
should be used only for key management, the keyEncipherment bit would
be asserted. When used, this extension should be marked critical.
The eight bits defined for this extension identify seven mechanisms
and one service, namely:
- digitalSignature The key usage extension defines the purpose (e.g., encipherment,
- nonRepudiation signature, certificate signing) of the key contained in the PKC. This
- keyEncipherment extension is used when a key that could be used for more than one
- dataEncipherment operation is to be restricted. For example, when an RSA key should be
- keyAgreement used only for signing, the digitalSignature and/or nonRepudiation
- keyCertSign bits would be asserted. Likewise, when an RSA key should be used only
- cRLSign for key management, the keyEncipherment bit would be asserted. When
- encipherOnly used, this extension should be marked critical.
- decipherOnly
According to [FORMAT], bits in the KeyUsage type are used as follows: According to [FORMAT], bits in the KeyUsage type are used as follows:
- The digitalSignature bit is asserted when the subject public key is - The digitalSignature bit is asserted when the subject public key
used to verify digital signatures that have purposes other than is used to verify digital signatures that have purposes other
non-repudiation, certificate signature, and CRL signature. For than non-repudiation, certificate signature, and CRL signature.
example, the digitalSignature bit is asserted when the subject For example, the digitalSignature bit is asserted when the
public key is used to provide authentication via the signing of subject public key is used to provide authentication via the
ephemeral data. signing of ephemeral data.
- The nonRepudiation bit is asserted when the subject public key is - The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures used to provide a non-repudiation used to verify digital signatures used to provide a non-
service which protects against the signing entity falsely denying repudiation service which protects against the signing entity
some action, excluding certificate or CRL signing. falsely denying some action, excluding certificate or CRL
signing.
- The keyEncipherment bit is asserted when the subject public key is - The keyEncipherment bit is asserted when the subject public key
used for key transport. For example, when an RSA key is to be used is used for key transport. For example, when an RSA key is to be
for key management, this bit must asserted. used for key management, this bit must asserted.
- The dataEncipherment bit is asserted when the subject public key is - The dataEncipherment bit is asserted when the subject public key
used for enciphering user data, other than cryptographic keys. is used for enciphering user data, other than cryptographic keys.
- The keyAgreement bit is asserted when the subject public key is - The keyAgreement bit is asserted when the subject public key is
used for key agreement. For example, when a Diffie-Hellman key is used for key agreement. For example, when a Diffie-Hellman key is
to be used for key management, this bit must asserted. to be used for key management, this bit must asserted.
- The keyCertSign bit is asserted when the subject public key is used - The keyCertSign bit is asserted when the subject public key is
for verifying a signature on certificates. This bit may only be used for verifying a signature on certificates. This bit may only
asserted in CA certificates. be asserted in CA certificates.
- The cRLSign bit is asserted when the subject public key is used for - The cRLSign bit is asserted when the subject public key is used
verifying a signature on revocation information (e.g., a CRL). for verifying a signature on revocation information (e.g., a
CRL).
- The meaning of the encipherOnly bit is undefined in the absence of - The meaning of the encipherOnly bit is undefined in the absence
the keyAgreement bit. When the encipherOnly bit is asserted and the of the keyAgreement bit. When the encipherOnly bit is asserted
keyAgreement bit is also set, the subject public key may be used and the keyAgreement bit is also set, the subject public key may
only for enciphering data while performing key agreement. be used only for enciphering data while performing key agreement.
- The meaning of the decipherOnly bit is undefined in the absence of - The meaning of the decipherOnly bit is undefined in the absence
the keyAgreement bit. When the decipherOnly bit is asserted and the of the keyAgreement bit. When the decipherOnly bit is asserted
keyAgreement bit is also set, the subject public key may be used and the keyAgreement bit is also set, the subject public key may
only for deciphering data while performing key agreement. be used only for deciphering data while performing key agreement.
PKIX does not restrict the combinations of bits that may be set in an PKIX does not restrict the combinations of bits that may be set in an
instantiation of the keyUsage extension. instantiation of the keyUsage extension.
The discussion on the PKIX mailing list has centered on the The discussion on the PKIX mailing list has centered on the
digitalSignature bit and the nonRepudiation bit. The question has digitalSignature bit and the nonRepudiation bit. The question has
come down to something like: When support for the service of non- come down to something like: When support for the service of non-
repudiation is desired, should both the digitalSignature and repudiation is desired, should both the digitalSignature and
nonRepudiation bits be set, or just the nonRepudiation bit? nonRepudiation bits be set, or just the nonRepudiation bit?
(It is noted that provision of the service of non-repudiation Note: Provision of the service of non-repudiation requires more
requires more than a single bit set in a certificate. It requires an than a single bit set in a PKC. It requires an entire
entire infrastructure of components to preserve for some period of infrastructure of components to preserve for some period of time
time the keys, certificates, revocation status, signed material, the keys, PKCs, revocation status, signed material, etc., as well
etc., as well as a trusted source of time. However, the as a trusted source of time. However, the nonRepudiation key usage
nonRepudiation key usage bit is provided as an indicator that such bit is provided as an indicator that such keys should not be used
keys should not be used as a component of a system providing a non- as a component of a system providing a non-repudiation service.
repudiation service.)
According to [SIMONETTI], the intent is that the digitalSignature bit According to [SIMONETTI], the intent is that the digitalSignature bit
should be set when what is desired is the ability to sign ephemeral should be set when what is desired is the ability to sign ephemeral
transactions; e.g., for a single session authentication. These transactions; e.g., for a single session authentication. These
transactions are "ephemeral" in the sense that they are important transactions are "ephemeral" in the sense that they are important
only while they are in existence; after the session is terminated, only while they are in existence; after the session is terminated,
there is no long-term record of the digital signature and its there is no long-term record of the digital signature and its
properties kept. When something is intended to be kept for some properties kept. When something is intended to be kept for some
period of time, the nonRepudiation bit should be set. This generally period of time, the nonRepudiation bit should be set. This generally
implies that an application will digitally sign something; thus, some implies that an application will digitally sign something; thus, some
implementors turn on the digitalSignature bit as well. Other implementors turn on the digitalSignature bit as well. Other
implementors, however, keep the two bits mutually exclusive, to implementors, however, keep the two bits mutually exclusive, to
prevent a single key from being used for both ephemeral and long-term prevent a single key from being used for both ephemeral and long-term
signing. signing.
While [FORMAT] is silent on this specific issue, the working group's While [FORMAT] is silent on this specific issue, the working group's
general conclusion is that a certificate may have either or both bits general conclusion is that a PKC may have either or both bits set. If
set. If only the nonRepudiation bit is set, the key should not be only the nonRepudiation bit is set, the key should not be used for
used for ephemeral transactions. If only the digitalSignature bit is ephemeral transactions. If only the digitalSignature bit is set, the
set, the key should not be used for long-term signing. If both bits key should not be used for long-term signing. If both bits are set,
are set, the key may be used for either purpose. the key may be used for either purpose.
To actually enforce this requires that an application understands To actually enforce this requires that an application understands
whether it is signing ephemeral transactions or for the long-term. whether it is signing ephemeral transactions or for the long-term.
The application developers will have to understand the difference, The application developers will have to understand the difference,
and set up their checks on the key usage bits field accordingly. For and set up their checks on the key usage bits field accordingly. For
example, TLS implementors should check only the digitalSignature bit, example, TLS implementors should check only the digitalSignature bit,
and ignore the nonRepudiation bit. S/MIME implementors, though, will and ignore the nonRepudiation bit. S/MIME implementors, though, will
have a difficult choice to make, since their application could be have a difficult choice to make, since their application could be
used for either purpose, and they will generally accept signing using used for either purpose, and they will generally accept signing using
keys associated with certificates having either or both bits being keys associated with PKCs having either or both bits being turned on.
turned on. Certification Authorities should know what applications Certification Authorities should know what applications they are
they are providing certificates for, and provide certificates providing PKCs for, and provide PKCs according to the requirements of
according to the requirements of those applications. If CA's are tied those applications. If CA's are tied into non-repudiation systems,
into non-repudiation systems, they may treat certificates differently they may treat PKCs differently when the nonRepudiation bit is turned
when the nonRepudiation bit is turned on (e.g., store information on (e.g., store information associated with the PKC - like the user's
associated with the certificate - like the user's identification identification provided during PKC registration, or PKC generation
provided during certificate registration, or certificate generation
date/time stamps - for longer periods of time, in more secure date/time stamps - for longer periods of time, in more secure
environments). environments).
The bottom line is that this is an area where PKI implementors are The bottom line is that this is an area where PKI implementors are
somewhat limited in what they can do. The onus is on developers of somewhat limited in what they can do. The onus is on developers of
certificate-using systems to understand their requirements and PKC-using systems to understand their requirements and request PKCs
request certificates with the appropriate bits set. with the appropriate bits set.
5.3.1 Extended Key Usage Extension
[Add in text to talk about the extended key usages!]
5.4 Trust Models 5.4 Trust Models
(This section will describe the various trust models that PKIX can An important design decision is where in the PKI the trust point for
support. It is important to note that PKIX is bound to neither a pure a particular EE should be located (i.e., where is the EE's Root CA) .
hierarchical model a la PEM, nor a web of trust model a la PGP. PKIX There are two extremes: the Top CA or the CA who issues the EE's
can support either of those models, or any flavor in between. The certificate. Of course, the trust point for a particular EE can be
implications of different trust models should be described: anywhere in the PKI, but the following presents the advanatages and
disadvantages of locating the the trust point at these two places.
- efficiency of revocation - certification path building - etc.) Advantages of Top CA trust point:
- Path discovery is easier since all EEs trust the same CA.
- Certificate paths are potentially shorter between distant EEs,
since the verifier need only trace back to the root, not back to
his local CA.
- Root can enforce adherence to a certificate policy by subordinate
CAs.
- Cross certification with other PKIs can be controlled at a senior
level.
Disadvantages of root trust point:
- Compromise of the root key is catastrophic, requiring a re-
distribution of certificates to all EEs. Similarly trust point
roll-over affects entire hierarchy.
- Users are required to trust a CA which may be remote from them.
- Distribution of the trusted point certificate to distant EEs may
be non-trivial.
- Verification back to the root CA may be too onerous for low value
transactions.
- Certificate paths are potentially longer for nearby EEs since the
verifier must always trace back to the root, not back to the CA
it shares with the other party.
Advantages of local trusted point:
- The trusted point certificate need only be distributed from the
CA to its local (nearby) EEs.
- EEs are more likely to trust their local CA (which could be part
of the same immediate organization) than a geographically remote
CA.
- Compromise of the local CAs private key only affects its own EEs.
Similarly for trusted point roll-over.
- Potentially shorter certification paths between nearby EEs, since
the verifier may belong to the same CA as the other party.
Disavantages of local trust point:
- Potentially longer certification paths between distant EEs, since
the verifier must trace the path back to its local CA.
- Path discovery more complex and may not be supported in current
products.
- More difficult for the root to control cross-certification or
ensure adherence to the certificate policy.
6 Acknowledgements 6 Acknowledgements
A lot of the information in this document was taken from the PKIX A lot of the information in this document was taken from the PKIX
source documents; the authors of those deserve the credit for their source documents; the authors of those deserve the credit for their
own words. Other good material was taken from mail posted to the PKIX own words. Other good material was taken from mail posted to the PKIX
working group mail list (ietf-pkix@imc.org). Among those with good working group mail list (ietf-pkix@imc.org). Among those with good
things to say were (in alphabetical order, with apologies to anybody things to say were (in alphabetical order, with apologies to anybody
we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, Russ we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, Russ
Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, Tim Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, Tim
Polk, Stefan Santesson, Dave Simonetti, and. Polk, Stefan Santesson, Dave Simonetti, and Paul Hoffman.
7 References 7 References
[BERT1] McNeil, M., and Glassey, T., "Basic Event Representation [AC] S. Farrell, R. HousleyMcNeil, M., and Glassey, T., "An Internet
Token," <draft-ietf-pkix-bert1-01.txt>, May 1999. Attribute Certificate Profile for Authorization," <draft-ietf-pkix-
ac509prof-01.txt>, October 1999.
[CACHE] "Internet Public Key Infrastructure: Caching the Online
Certificate Status Protocol," <draft-ieft-pkix-ocsp-caching-00.txt>,
April 1998.
[CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate [CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate
Management Messages over CMS," <draft-ieft-pkix-cmc-04.txt>, May Management Messages over CMS," <draft-ieft-pkix-cmc-05.txt>, 14 July
1999. 1999.
[CMP] Adams, C., Farrell, S., "Internet X.509 Public Key [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key
Infrastructure Certificate Management Protocols", RFC 2510, March Infrastructure Certificate Management Protocols", RFC 2510, March
1999. 1999.
[CMS] R. Housley, "Cryptographic Message Syntax," <draft-ietf-smime- [CMP-HTTP] Tschal"ar, R., Kapoor, A., and Adams, C., "Using HTTP as a
cms-13.txt>, April 1999. Transport Protocol for CMP", <draft-ietf-pkix-cmp-http-00.txt>,
August 1999.
[CMP-TCP] Tschal"ar, R., Kapoor, A., and Adams, C., "Using TCP as a
Transport Protocol for CMP", <draft-ietf-pkix-cmp-tcp-00.txt>, August
1999.
[INTEROP] Moskowitz, R., "CMP Interoperability Testing: Results and
Agreements", <draft-moskowitz-cmpinterop-00.txt>, June 1999.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July
1999.
[CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509
Certificate Request Message Format," RFC 2511, March 1999. Certificate Request Message Format," RFC 2511, March 1999.
[DCS] Adams, C., and Zuccherato, R., "Internet X.509 Public Key [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-of-
Infrastructure Data Certification Server Protocols", <draft-ietf- Possession Algorithms," <draft-ietf-pkix-dhpop-02.txt>, 1 October
pkix-dcs-00.txt>, 23 September 1998.
[DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-
of-Possession Algorithms," <draft-ietf-pkix-dhpop-00.txt>, February
1999. 1999.
[DNS] Mockapetris, P.V., "Domain names - concepts and facilities," [DNS] Mockapetris, P.V., "Domain names - concepts and facilities,"
RFC 1034, November 1987. RFC 1034, November 1987.
[DVCS] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R.,
"Internet X.509 Public Key Infrastructure Data Certification Server
Protocols", <draft-ietf-pkix-dcs-03.txt>, 15 October 1999.
[ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509 [ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509
Public Key Infrastructure: Representation of Elliptic Curve Digital Public Key Infrastructure: Representation of Elliptic Curve Digital
Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509
Public Key Infrastructure Certificates," <draft-ietf-pkix-ipki- Public Key Infrastructure Certificates," <draft-ietf-pkix-ipki-
ecdsa-01.txt>, November 1997. ecdsa-01.txt>, 3 June 1999.
[ETNPT] Namjoshi, P., "Internet X.509 Public Key Infrastructure [ETNPT] Namjoshi, P., "Internet X.509 Public Key Infrastructure
Extending trust in non repudiation tokens in time," <draft-ietf- Extending trust in non repudiation tokens in time," <draft-ietf-pkix-
pkix-extend-trust-non-repudiation-token-00.txt>, May 1999. extend-trust-non-repudiation-token-00.txt>, 28 May 1999.
[IP] Postel, J., "Internet Protocol," RFC 791, September 1981. [IP] Postel, J., "Internet Protocol," RFC 791, September 1981.
[IPv6] Deering, S., and Hinden, R., "Internet Protocol, Version 6 [IPv6] Deering, S., and Hinden, R., "Internet Protocol, Version 6
[IPv6] Specification," RFC 1883, December 1995. [IPv6] Specification," RFC 1883, December 1995.
[FORMAT] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet [FORMAT] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and CRL Profile," RFC X.509 Public Key Infrastructure Certificate and CRL Profile," RFC
2459, January 1999. 2459, January 1999.
[FTPHTTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key [FTPHTTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July
1998. 1998.
[KEA] Housley, R., and Polk, W., "Internet X.509 Public Key [KEA] Housley, R., and Polk, W., "Internet X.509 Public Key
Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in
Internet X.509 Public Key Infrastructure Certificates," RFC 2528, Internet X.509 Public Key Infrastructure Certificates," RFC 2528,
March 1999. March 1999.
[LAAP] Farrell, S., Chadwick, C.W., "Limited AttributeCertificate
Acquisition Protocol", <draft-ietf-pkix-laap-00.txt>, Octoboer 1999.
[LDAPv2] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory [LDAPv2] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory
Access Protocol", RFC 1777, March 1995. Access Protocol", RFC 1777, March 1995.
[MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC [MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC
Minimum Interoperability Specification for PKI Components, Version Minimum Interoperability Specification for PKI Components, Version
1", <http://csrc.nist.gov/pki/mispc/welcome.html> September 3, 1997. 1", <http://csrc.nist.gov/pki/mispc/welcome.html>, 3 September 1997.
[OCDP] Hallam-Baker, P., and Ford, W., "Internet X.509 Public Key
Infrastructure Enhanced CRL Distribution Options (OpenCDP)," <draft-
ietf-pkix-ocdp-01.txt>, August 7, 1998.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams,
C., "X.509 Internet Public Key Infrastructure Online Certificate C., "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP," <draft-ietf-pkix-ocsp-08.txt>, March 1999. Status Protocol - OCSP," RFC 2560, June 1999.
[OCSPX] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams,
C., "OCSP Extensions," <draft-ietf-pkix-ocspx-00.txt>, 3 September
1999.
[PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail: [PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management," RFC 1422, February 1993. Part II: Certificate-Based Key Management," RFC 1422, February 1993.
[PKCS10] RSA Laboratories, "The Public-Key Cryptography [PKCS10] RSA Laboratories, "The Public-Key Cryptography
Standards(PKCS)," RSA Data Security Inc., Redwood City, California, Standards(PKCS)," RSA Data Security Inc., Redwood City, California,
November 1993 Release. November 1993 Release.
[PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 [PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509
Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559, Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559,
April 1999. April 1999.
[PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key
Infrastructure Operational Protocols - LDAPv3," <draft-ietf-pkix-
ldap-v3-01.txt>, August 1999.
[POLPRAC] Chokhani, S., and Ford, W., "Internet X.509 Public Key [POLPRAC] Chokhani, S., and Ford, W., "Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices Infrastructure Certificate Policy and Certification Practices
Framework," RFC 2527, March 1999. Framework," RFC 2527, March 1999.
[QC] Santesson, S., Polk, W., and Gloeckner, P., "Internet X.509 [QC] Santesson, S., Polk, W., and Gloeckner, P., "Internet X.509
Public Key Infrastructure Qualified Certificates", <draft-ietf-pkix- Public Key Infrastructure Qualified Certificates", <draft-ietf-pkix-
qc-00.txt>, 3 February 1999. qc-01.txt>, 6 August 1999.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages," RFC 822, August 1982. Messages," RFC 822, August 1982.
[SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 [SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509
Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999. Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999.
[SCVP] Malpani, A., Hoffman, P., "Simple Certificate Validation
Protocol (SCVP)," <draft-ietf-pkix-scvp-01.txt>, 9 August 1999.
[SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf- [SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf-
pkix@imc.org mailing list, 12 August 1998. pkix@imc.org mailing list, 12 August 1998.
[TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet [TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet
X.509 Public Key Infrastructure Time Stamp Protocols", <draft-ietf- X.509 Public Key Infrastructure Time Stamp Protocols", <draft-ietf-
pkix-time-stamp-02.txt>, May 1999. pkix-time-stamp-04.txt>, September 1999.
[WEB] Reddy, S., "WEB based Certificate Access Protocol--
WebCAP/1.0," <draft-ietf-pkix-webcap-00.txt>, April 19, 1998.
[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology -
Open Systems Interconnection - The Directory: Authentication Open Systems Interconnection - The Directory: Authentication
Framework, June 1997. Framework, June 1997.
[X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial [X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial
Services Industry: Agreement of Symmetric Algorithm Keys Using Services Industry: Agreement of Symmetric Algorithm Keys Using
Diffie-Hellman (Working Draft), December 1997. Diffie-Hellman (Working Draft), December 1997.
[X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial [X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial
skipping to change at line 1935 skipping to change at page 49, line 36
6734 Fort George G. Meade, MD 20755-6734 (410) 684-7114 6734 Fort George G. Meade, MD 20755-6734 (410) 684-7114
awarsen@missi.ncsc.mil awarsen@missi.ncsc.mil
Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 (703) Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 (703)
628-3180 turners@ieca.com 628-3180 turners@ieca.com
10 Disclaimer 10 Disclaimer
This work constitutes the opinion of the editors only, and may not This work constitutes the opinion of the editors only, and may not
reflect the opinions or policies of their employers. reflect the opinions or policies of their employers.
Expires April 22, 2000
 End of changes. 203 change blocks. 
870 lines changed or deleted 1239 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/