< draft-ietf-pkix-roadmap-04.txt   draft-ietf-pkix-roadmap-05.txt >
PKIX Working Group A. Arsenault PKIX Working Group A. Arsenault
INTERNET DRAFT DOD INTERNET DRAFT DOD
S. Turner S. Turner
IECA IECA
Expires April 22, 2000 October 22, 1999 Expires 10 September, 2000 March 10, 2000
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
PKIX Roadmap PKIX Roadmap
<draft-ietf-pkix-roadmap-04.txt> <draft-ietf-pkix-roadmap-05.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 34 skipping to change at page 1, line 34
and may be updated, replaced, or may become obsolete by other and may be updated, replaced, or may become obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
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
This Internet-Draft will expire in September, 2000. Comments or
suggestions for improvement may be made on the "ietf-pkix" mailing
list, or directly to the authors.
Copyright (C) The Internet Society (2000). All Rights Reserved.
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 Public Key Infrastructure and Privilege Management X.509-based Public Key Infrastructure and Privilege Management
Infrastructure (PMI). It identifies each document developed by the Infrastructure (PMI). It identifies each document developed by the
PKIX working group, and describes the relationships among the various 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,
skipping to change at page 2, line 32 skipping to change at page 2, line 34
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
contributors we wish to thank. Section 7 provides a list references. contributors we wish to thank. Section 7 provides a list references.
Section 8 discusses security considerations, and Section 9 provides Section 8 discusses security considerations, and Section 9 provides
contact information for the editors. Finally, Section 10 provides a contact information for the editors. Finally, Section 10 provides a
disclaimer. disclaimer.
1.2 Changes Since Last Version 1.2 Changes Since Last Version
Updated refences to current drafts. Updated references 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 Add references to 2459bis (son-of-rfc 2459), 2510bis, Technical
paragraphs 3.6.1, 3.6.2, and 3.6.3, respectively. Requirements for a Non-Repudiation Service, A String Represenation of
General Name.
Updated Revocation paragraph 3.5.8 to indicate why a certificate is Revised 5th paragraph in clause 3.2 as per comments.
retained on a CRL for one additional period.
Added descriptions for new drafts in 4.1-4.5: Operation Protocols - Updated clause 5.2.2 as per comments.
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 Rewrote clause 5.3 Key Usage to addres more issues with respect to
working group review. the DS and NR bits. Also to change its focus from when to set the
bits to driving the definition of non-repudiation service
requirements.
Removed references to [BERT1], [CACHE], and [WEB] from paragraph 7. Added a new clause 5.4 to talk about non-repudiation requirements.
1.3 To Do 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 PMI functions.
Add in paragraph to talk about delta between RFC2459 and the updated Add in paragraph to talk about the whole QC naming issues
RFC2459. (dnQualifier vs serialNumber, serialNumber specification, etc.).
Rewrite trust models section.
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
and PMI-related literature. To limit confusion caused by some of and PMI-related literature. To limit confusion caused by some of
those terms, throughout this document, we will use the following those terms, throughout this document, we will use the following
terms in the following ways: terms in the following ways:
- Attribute Authority (AA) - An authority trusted by one or more - Attribute Authority (AA) - An authority trusted by one or more
users to create and sign attribute certificates. It is important users to create and sign attribute certificates. It is important
skipping to change at page 4, line 7 skipping to change at page 3, line 40
certificate. certificate.
- Certification Authority (CA) - An authority trusted by one or - Certification Authority (CA) - An authority trusted by one or
more users to create and assign public key certificates. more users to create and assign public key certificates.
Optionally the CA may create the user's keys. It is important to Optionally the CA may create the user's keys. It is important to
note that the CA is responsible for the public key certificates note that the CA is responsible for the public key certificates
during their whole lifetime, not just for issuing them. during their whole lifetime, not just for issuing them.
- Certificate Policy (CP) - A named set of rules that indicates the - Certificate Policy (CP) - A named set of rules that indicates the
applicability of a public key certificate to a particular applicability of a public key certificate to a particular
community and/or class of application with common security community or class of application with common security
requirements. For example, a particular certificate policy might requirements. For example, a particular certificate policy might
indicate applicability of a type of public key certificate to the indicate applicability of a type of public key certificate to the
authentication of electronic data interchange transactions for authentication of electronic data interchange transactions for
the trading of goods within a given price range. the trading of goods within a given price range.
- Certification Practice Statement (CPS) - A statement of the - Certification Practice Statement (CPS) - A statement of the
practices which a CA employs in issuing public key certificates. practices which a CA employs in issuing public key certificates.
- End-entity - A subject of a certificate who is not a CA in the - End-entity - A subject of a certificate who is not a CA in the
PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the
skipping to change at page 5, line 12 skipping to change at page 4, line 47
for the EE in question. Often, a subordinate CA will not be a for the EE in question. Often, a subordinate CA will not be a
Root CA for any entity but this is not mandatory. Root CA for any entity but this is not mandatory.
- Subject - A subject is the entity (AA, CA, or EE) named in a - 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 Domain Name Service (DNS) names or Internet represented by Domain Name Service (DNS) names or Internet
Protocol (IP) addresses), or even software agents. Protocol (IP) addresses), or even software agents.
- Top CA - A CA that is at the top of a PKI hierarchy. - 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 Note: This is often also called a "Root CA," since in data
structures terms and in graph theory, the node at the top of a tree 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 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 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 CA directly trusted by the EE. Readers new to PKIX should be aware
that these terms are not used consistently throughout the PKIX that these terms are not used consistently throughout the PKIX
documents, as [FORMAT] uses "Root CA" to refer to what this and 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 other documents call a "Top CA," and "most-trusted CA" to refer to
what this and other documents call a "Root CA." what this and other documents call a "Root CA."
3 PKIX Theory 3 PKIX Theory
3.1 Certificate-using Systems 3.1 Certificate-using Systems
3.1.1 Certificate-using Systems and PKIs 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 Secure Multipurpose Internet Mail group of security protocols such as Secure Multipurpose Internet Mail
Extensions (S/MIME), Transport Layer Sercurity (TLS), and Internet Extensions (S/MIME), Transport Layer Security (TLS), and Internet
Protocol Security (IPSec). All of these protocols rely on public-key Protocol Security (IPSec). All of these protocols rely on public-key
cryptography to provide services such as confidentiality, data cryptography to provide services such as confidentiality, data
integrity, data origin authentication, and non-repudiation. The integrity, data origin authentication, and non-repudiation. The
purpose of a PKI is to provide trusted and efficient key and public purpose of a PKI is to provide trusted and efficient key and public
key certificate management, thus enabling the use of authentication, key certificate management, thus enabling the use of authentication,
non-repudiation, and confidentiality. 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 PKCs, which are data structures that is obtained through the use of PKCs, which are data structures that
bind public key values to subjects. The binding is achieved by having bind public key values to subjects. The binding is achieved by having
a trusted CA verify the subject's identity and digitally sign each a trusted CA verify the subject's identity and digitally sign each
PKC. PKC.
A PKC has a limited valid lifetime which is indicated in its signed A PKC has a limited valid lifetime, which is indicated in its signed
contents. Because a PKC's signature and timeliness can be contents. Because a PKC's signature and timeliness can be
independently checked by a certificate-using client, PKCs can be independently checked by a certificate-using client, PKCs can be
distributed via untrusted communications and server systems, and can distributed via untrusted communications and server systems, and can
be cached in unsecured storage in certificate-using systems. be cached in unsecured storage in certificate-using systems.
PKCs are used in the process of validating signed data. Specifics PKCs are used in the process of validating signed data. Specifics
vary according to which algorithm is used, but the general process vary according to which algorithm is used, but the general 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
skipping to change at page 6, line 50 skipping to change at page 6, line 39
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 limited areas can cause the entire system security to fail. PKIX is limited
in scope, however, and only directly addresses issues related to in scope, however, and only directly addresses issues related to
the operation of the PKI subsystem. For guidance in many of the the operation of the PKI subsystem. For guidance in many of the
other areas, see [POLPROC]. other areas, see [POLPROC].
3.1.2 Certificate-using Systems and PMIs 3.1.2 Certificate-using Systems and PMIs
Many systems use the the PKC to perform identity based access control Many systems use the PKC to perform identity based access control
decisions (i.e, the identity may be used to support identity-based decisions (i.e., the identity may be used to support identity-based
access control decisions after the client proves that it has access access control decisions after the client proves that it has access
to the private key that corresponds to the public key contained in to the private key that corresponds to the public key contained in
the PKC). For many systems this is sufficient, but increasingly the PKC). For many systems this is sufficient, but increasingly
systems are beginning to find that rule-based, role-based, and rank- systems are beginning to find that rule-based, role-based, and rank-
based access control is required. These forms of access control based access control is required. These forms of access control
decisions require additional information that is normally not decisions require additional information that is normally not
included in a PKC, because the lifetime of the information is much included in a PKC, because the lifetime of the information is much
shorter than the lifetime of the public-private key pair. To support shorter than the lifetime of the public-private key pair. To support
binding this information to a PKC the Attribute Certificate (AC) was binding this information to a PKC the Attribute Certificate (AC) was
defined in ANSI and later incorporated into ITU-T Recommendation defined in ANSI and later incorporated into ITU-T Recommendation
X.509. The AC format allows any additional information to be bound to 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 a PKC by including, in a digitally signed data structure, a reference
back to one specific PKC or to multiple PKCs, useful when the subject 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 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 constructed in such a way that it is only useful at one or more
particular targets (e.g., web server, mail host). particular targets (e.g., web server, mail host).
Users of a PMI must be confident that the identity purporting to Users of a PMI must be confident that the identity purporting to
posess an attribute has the right to possess that attribute. This posess an attribute has the right to possess that attribute. This
confidence may be obtained through the use of PKCs or it may be 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 configured in the AC-using system. If PKCs are used the party making
the access control decision can determine "if the AC issuer is the access control decision can determine "if the AC issuer is
skipping to change at page 7, line 41 skipping to change at page 7, line 30
widely accepted basis for a PKI, including data formats and widely accepted basis for a PKI, including data formats and
procedures related to distribution of public keys via PKCs digitally procedures related to distribution of public keys via PKCs digitally
signed by CAs. X.509 does not however include a profile to specify signed by CAs. X.509 does not however include a profile to specify
the support requirements for many of the PKC data structure's sub- the support requirements for many of the PKC data structure's sub-
fields, for any of the extensions, nor for certain data values. PKIX fields, for any of the extensions, nor for certain data values. PKIX
was formed in October 1995 to deliver a profile for the Internet PKI was formed in October 1995 to deliver a profile for the Internet PKI
of X.509 version 3 PKCs and version 2 CRLs. The Internet PKI profile of X.509 version 3 PKCs and version 2 CRLs. The Internet PKI profile
[FORMAT] went through eleven draft versions before becoming an RFC. [FORMAT] went through eleven draft versions before becoming an RFC.
Other profiles have been developed in PKIX for particular algorithms Other profiles have been developed in PKIX for particular algorithms
to make use of [FORMAT]. There has been no sense of conflict between to make use of [FORMAT]. There has been no sense of conflict between
the groups that developed these profiles as they are seen as the authors 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. The Certificate Management Protocol (CMP) was straightforward. The Certificate Management Protocol (CMP) was
developed to define a message protocol that is used between entities developed to define a message protocol that is used between entities
in a PKI [CMP]. The demand for an enrollment protocol and the desire in a PKI [CMP]. The demand for an enrollment protocol and the desire
to use PKCS-10 message format as the certificate request syntax lead to use PKCS-10 message format as the certificate request syntax lead
to the development of two different documents in two different to the development of two different documents in two different
groups. The Certificate Request Syntax (CRS) draft was developed in groups. The Certificate Request Syntax (CRS) draft was developed in
the SMIME WG which used PKCS-10 [PKCS10] as the certification request the SMIME WG which used PKCS-10 [PKCS10] as the certification request
skipping to change at page 8, line 25 skipping to change at page 8, line 14
certificate request syntax, which caused work on the CRS draft to certificate request syntax, which caused work on the CRS draft to
stop. Information from the certificate management message format stop. Information from the certificate management message format
document was moved into [CMP] and [CMC] so work on the certificate document was moved into [CMP] and [CMC] so work on the certificate
management message format document was discontinued. management message format document was discontinued.
Another long debated topic in the WG dealt with certificate Another long debated topic in the WG dealt with certificate
revocation. Numerous drafts have been developed to address different revocation. Numerous drafts have been developed to address different
issues related certificate revocations. CMP supports revocation issues related certificate revocations. CMP supports revocation
request, response, revocation announcement, and requests for CRL request, response, revocation announcement, and requests for CRL
messages. CMC defines revocation request, revocation response, and messages. CMC defines revocation request, revocation response, and
requests for CRL messages messages, but uses CMS as the encapsulating requests for CRL messages, but uses CMS as the encapsulating
protocol. [OCSP] was devloped to address concerns that not all protocol. [OCSP] was developed to address concerns that not all
relying parties want to go through the process checking CRLs from relying parties want to go through the process checking CRLs from
every CA in the certification path. It defines an on-line mechanism every CA in the certification path. It defines an on-line mechanism
to determine the status of a given certificate, which may provide to determine the status of a given certificate, which may provide
more timely revocation information than is possible with CRLs. The more timely revocation information than is possible with CRLs. The
Simple Certification Verification Protocol (SCVP) was produced to Simple Certification Verification Protocol (SCVP) was produced to
allow relying parties to off-load all of their certification allow relying parties to off-load all of their certification
verification to another entity [SCVP]. The WG was arguable split over verification to another entity [SCVP]. The WG was arguable split over
whether such a function should be supported and whether it should be whether such a function should be supported and whether it should be
its own protocol or included in OCSP. In response, a draft defining its own protocol or included in OCSP. In response, a draft defining
OCSP Extensions [OCSPX] was produced to include the functions of OCSP Extensions [OCSPX] was produced to include the functions of
SCVP. One other draft called Open CRL Distribution Point (OCDP) was SCVP. One other draft called Open CRL Distribution Point (OCDP) was
produced which documented two extensions: one to support an produced which documented two extensions: one to support an
alternative CRL partitioning mechanism to the CRL Distribution Point alternative CRL partitioning mechanism to the CRL Distribution Point
mechanism documented in [FORMAT] and one to support identifying other mechanism documented in [FORMAT] and one to support identifying other
revocation sources available to certificate-users. The work from revocation sources available to certificate-users. The work from
this draft was subsummed by an ITU-T | ISO/IEC Amendment to X.509, this draft was subsumed by an ITU-T | ISO/IEC Amendment to X.509,
hence work on this draft was halted. 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. Three documents for the Light Weight Directory straightforward. Three documents for the Light Weight Directory
Access Protocol (LDAP) have been developed one for defining LDAPv2 as Access Protocol (LDAP) have been developed one for defining LDAPv2 as
an access protocol to repositories [PKI-LDAPv2]; one for storing PKI an access protocol to repositories [PKI-LDAPv2]; one for storing PKI
information in an LDAP directory [SCHEMA]; and one for LDAPv3 information in an LDAP directory [SCHEMA]; and one for LDAPv3
requirements for PKI [PKI-LDAPv3]. Using the File Transfer Protocol requirements for PKI [PKI-LDAPv3]. Using the File Transfer Protocol
(FTP) and the Hyper Text Transmission Protocol (HTTP) to retrieve (FTP) and the Hyper Text Transmission Protocol (HTTP) to retrieve
PKCs and CRLs from PKI repositories was documented in [FTPHTTP]. PKCs and CRLs from PKI repositories was documented in [FTPHTTP].
In late 1998 the PKIX charter was revised to include protocols for In late 1998 the PKIX charter was revised to include protocols for
time stamping and data certification services. [TSP] was developed to time stamping and data certification services. [TSP] was developed to
define protocols required to interact with a Time Stamp Authority define protocols required to interact with a Time Stamp Authority
(TSA) who asserts that a datum existed at a given time. Of course, if (TSA) who asserts that a datum existed at a given time. [DVCS] allows
a true non-repudation service is to be provided additional services to verify and assert the validity of all signatures attached to the
that prove the data was actually in the possesion of the subject signed document using all appropriate status information and PKCs or
requesting the time stamp. So, the [DVCS] draft was developed to to verify and assert the validity of one or more PKCs at the
provide two mechaisms to prove the subject actually possed the data. specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating
In addition, [DVCS] provides two additional services: one to verify (though in [TSP] request for a time stamp are not required to use
all signatures attached to the signed document using all appropriate
status information and PKCs and one to verify and assert the validity [CMS]). [ETNPT] was developed to use [DCVS] to maintain the trust in
of one or more PKCs at the specified time. Thoughtfully, [DVCS] a token issued by a non-repudiation Trusted Third Party (NR TTP)
permits the [TSP] protocol to be used as one of the time stamp after the key initially used to establish trust in the token expires.
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 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 added. ACs are similar to PKCs, but they do not bind public keys to
identities rather they bind attributes to identities. The attributes identities rather they bind attributes to identities. The attributes
bound to the identity can represent anything, but are mostly used to bound to the identity can represent anything, but are mostly used to
support rule-based, role-based, and rank-based access control support rule-based, role-based, and rank-based access control
decisions. Two drafts have since been developed: the Interent decisions. Two drafts have since been developed: the Internet
Attribute Certificates Profile for Authorizations [AC] and the Attribute Certificates Profile for Authorizations [AC] and the
Limited AttributeCertificate Acquisition Protocol [LAAP]. The first Limited AttributeCertificate Acquisition Protocol [LAAP]. The first
profiles the fields and extensions of the AC and the second provides profiles the fields and extensions of the AC and the second provides
a diliberately limited protocol to access a repository when LDAP is a deliberately limited protocol to access a repository when LDAP is
not appropriate. not appropriate.
Other drafts have been produced to address specific issues. [DHPOP] Other drafts have been produced to address specific issues. [DHPOP]
was developed to define two mechanisms by which a signature can was developed to define two mechanisms by which a signature can
produced using a Diffie-Hellman pair. This draft provides a produced using a Diffie-Hellman pair. This draft provides a
mechanism to Diffie-Hellam key pairs to issue a PKCS-10 certification mechanism to Diffie-Hellam key pairs to issue a PKCS-10 certification
request. After some operational experience with [CMP], two drafts, request. After some operational experience with [CMP], two drafts,
one for using HTTP as the transport protocol [CMP-HTTP] and one for one for using HTTP as the transport protocol [CMP-HTTP] and one for
Transmission Control Protocol (TCP) [CMP-TCP], were written to solve Transmission Control Protocol (TCP) [CMP-TCP], were written to solve
problems encountered by implementors. problems encountered by implementors.
From the alphabet soup above, it is clear why this roadmap is From the alphabet soup above, it is clear why this roadmap is
required. required.
Note that [FORMAT] and [CMP] are currently being updated based on
implementation experience, see [2459bis] and [2510bis].
3.3 Overview of the PKIX Approach 3.3 Overview of the PKIX Approach
3.3.1 PKI 3.3.1 PKI
PKIX is an effort to develop specifications for a PKI for the PKIX is an effort to develop specifications for a PKI for the
Internet using PKCs. A 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 PKCs based on to create, manage, store, distribute, and revoke PKCs based on
public-key cryptography. public-key cryptography.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
3.4.1 Public Key Certificates 3.4.1 Public Key Certificates
ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was 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 public key certificate format recommendations, defines a standard public key certificate format
[X.509]. The public key certificate format in the 1988 standard is [X.509]. The public key certificate format in the 1988 standard is
called the version 1 (v1) format. called the version 1 (v1) format.
When X.500 was revised in 1993, two more fields, When X.500 was revised in 1993, two more fields,
subjectUniqueIdentier and issuerUniqueIdentifer were added, resulting subjectUniqueIdentifier and issuerUniqueIdentifier were added,
in the version 2 (v2) format. These two fields may be used to support resulting in the version 2 (v2) format. These two fields may be used
directory access control. to support 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 X.509 include specifications for a public key infrastructure based on X.509
v1 public key certificates [PEM]. The experience gained in attempts v1 public key certificates [PEM]. The experience gained in attempts
to deploy [PEM] made it clear that the v1 and v2 public key to deploy [PEM] made it clear that the v1 and v2 public key
certificate formats are deficient in several respects. Most certificate formats are deficient in several respects. Most
importantly, more fields were needed to carry information which PEM importantly, more fields were needed to carry information which PEM
design and implementation experience has proven necessary. In design and implementation experience has proven necessary. In
response to these new requirements, ISO/IEC/ITU and ANSI X9 developed response to these new requirements, ISO/IEC/ITU and ANSI X9 developed
the X.509 version 3 (v3) public key certificate format. The v3 format the X.509 version 3 (v3) public key certificate format. The v3 format
skipping to change at page 13, line 35 skipping to change at page 13, line 35
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, etc. Environments with additional requirements may applications, etc. Environments with additional requirements may
build on this profile or may replace it. build on this profile or may replace it.
3.4.2 Attribute Certificates 3.4.2 Attribute Certificates
ANSI X.9 first published the Attribute Certificate format in [put ANSI X.9 first published the Attribute Certificate format in [put
date in here] as part of [put reference in here]. It defined the 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 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 (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 or a specific PKC and including an extension mechanism. In 1997 ITU-T
included it in [X.509]. included it in [X.509].
ANSI, ITU-T, and IETF have developed standard extensions and ANSI, ITU-T, and IETF have developed standard extensions and
attributes for use in the v2 ACs. Extensions can convey such attributes for use in the v2 ACs. Extensions can convey such
informatoin as an audit identity that can be used to create an audit informatoin as an audit identity that can be used to create an audit
trail, identity specific servers/services where the AC owner can use trail, identity specific servers and services where the AC owner can
their AC, point to a specific issuer's key, and indicate where to get use their AC, point to a specific issuer's key, and indicate where to
revocation information. The AC is generic enough to allow any get revocation information. The AC is generic enough to allow any
attribute to be conveyed in the data structure. Without limiting the attribute to be conveyed in the data structure. Without limiting the
attributes and extensions that can be included in an AC it is very attributes and extensions that can be included in an AC it is very
difficult to develop interoperable implementations for Internet use. difficult to develop interoperable implementations for Internet use.
It is the goal of PKIX to specify a profile for the Internet, It is the goal of PKIX to specify a profile for the Internet,
electronic mail, IPsec applications, etc. Environments with electronic mail, IPSec applications, etc. Environments with
additional requirements may build on this profile or replace it. 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 PKC or CA (directly, or through an RA), prior to that CA issuing a PKC or
PKCs for that subject. Registration involves the subject providing PKCs for that subject. Registration involves the subject providing
its name (e.g., common name, fully-qualified domain name, IP its name (e.g., common name, fully-qualified domain name, IP
address), and other attributes to be put in the PKC, followed by the address), and other attributes to be put in the PKC, followed by the
CA (possibly with help from the RA) verifying in accordance with its CA (possibly with help from the RA) verifying in accordance with its
Certfication Practice Statement (CPS) that the name and other Certification Practice Statement (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 PKC of a CA, or generating the client system's the public key or PKC of a CA, or generating the client system's own
own public/private key pair. public-private key pair.
3.5.3 Certification 3.5.3 Certification
This is the process in which a CA issues a PKC for a subject's public This is the process in which a CA issues a PKC for a subject's public
key, and returns that PKC to the subject and/or posts that PKC in a key, and returns that PKC to the subject or posts that PKC 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
skipping to change at page 15, line 16 skipping to change at page 15, line 16
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 PKCs 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
skipping to change at page 16, line 31 skipping to change at page 16, line 31
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 PKCs, signed with the new key, will likely be necessary to re-issue PKCs, signed with the new key,
to all subordinate users, since their current PKC would be signed to all subordinate users, since their current PKC 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 PKC issued by one CA to another CA which A cross-certificate is a PKC issued by one CA to another CA which
contains a public CA key associated with the private CA signature key contains a public CA key associated with the private CA signature key
used for issuing PKCs. Typically, a cross-certificate is used to used for issuing PKCs. Typically, a cross-certificate is used to
allow client systems/end entities in one administrative domain to allow client systems orend entities in one administrative domain to
communicate securely with client systems/end users in another communicate securely with client systems or end users in another
administrative domain. Use of a cross-certificate issued from CA_1 to administrative domain. Use of a cross-certificate issued from CA_1 to
CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob, CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
which was issued by CA_2. Cross-certificates can also be issued from which was issued by CA_2. Cross-certificates can also be issued from
one CA to another CA in the same administrative domain, if required. one CA to another CA in the same 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.
skipping to change at page 17, line 31 skipping to change at page 17, line 31
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 PKC's validity period. Leaving the revoked PKC on the CRL for 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 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 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 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 for this extra period then the possibility arises that a revoked PKC
may never appear on a CRL. 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 PKCs themselves, namely, via distributed by exactly the same means as PKCs themselves, 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
skipping to change at page 18, line 15 skipping to change at page 18, line 15
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
PKC validation impacts of the revocation. However, these methods PKC validation impacts of the revocation. However, these methods
impose new security requirements; the PKC validator must trust the impose new security requirements; the PKC validator must trust the
on-line validation service while the repository does not need to be on-line validation service while the repository does not need to be
trusted. trusted.
3.5.9 Certificate and Revocation Notice Distribution/Publication 3.5.9 Certificate and Revocation Notice Distribution and 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 PKCs and PKC revocation notices (whether in for the distribution of PKCs and PKC revocation notices (whether in
CRL form or in some other form) in the system. "Distribution" of PKCs CRL form or in some other form) in the system. "Distribution" of PKCs
includes transmission of the PKC to its owner, and may also include includes transmission of the PKC to its owner, and may also include
publication of the PKC in a repository. "Distribution" of revocation publication of the PKC in a repository. "Distribution" of revocation
notices may involve posting CRLs in a repository, transmitting them notices may involve posting CRLs in a repository, transmitting them
to end-entities, and/or forwarding them to on-line responders. to end-entities, or forwarding them to on-line responders.
3.6 Parts of PKIX 3.6 Parts of PKIX
This section identifies the six different areas in which the PKIX This section identifies the five 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 PKC standards and the X.509 v2 CRL standards profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards
for the Internet. The second area involves operational protocols, in for the Internet. The second area involves operational protocols, in
which relying parties can obtain information such as PKCs or PKC which relying parties can obtain information such as PKCs or PKC
status. The third area covers management protocols, in which status. The third area covers management protocols, in which
different entities in the system exchange information needed for different entities in the system exchange information needed for
proper management of the PKI. The fourth area provides information proper management of the PKI. The fourth area provides information
about certificate policies and certificate practice statements, about certificate policies and certificate practice statements,
covering the areas of PKI security not directly addressed in the rest covering the areas of PKI security not directly addressed in the rest
of PKIX. The fifth area deals with providing time stamping and data of PKIX. The fifth area deals with providing time stamping and data
skipping to change at page 19, line 39 skipping to change at page 19, line 39
electronic form. Many of these frameworks introduce certain basic electronic form. Many of these frameworks introduce certain basic
requirements on PKCs, often termed Qualified Certificates, supporting requirements on PKCs, often termed Qualified Certificates, supporting
these types of "legal" signatures. Partly as a result of this there these types of "legal" signatures. Partly as a result of this there
is a need for a specific PKC profile providing standardized support is a need for a specific PKC profile providing standardized support
for certain related issues such as a common structure for expressing for certain related issues such as a common structure for expressing
unambiguous identities of certified subjects (unmistakable identity). unambiguous identities of certified subjects (unmistakable identity).
In December 1998, PKIX adopted as a work item the development of a In December 1998, PKIX adopted as a work item the development of a
refinement of [RFC2459] that further profiles PKIX PKC into qualified refinement of [RFC2459] that further profiles PKIX PKC into qualified
certificates. This work is reflected in [QC]. certificates. This work is reflected in [QC].
Like the X.509 v3 PKC the AC also a very complex data structure Like the X.509 v3 PKC, the AC also a very complex data structure
consisting of basic information fields, a number of optional consisting of basic information fields, a number of optional
extensions, and a virtually unlimited number of attributes. Again, extensions, and a virtually unlimited number of attributes. Again,
many of the fields, extensions, and attributes can take on a wide many of the fields, extensions, and attributes can take on a wide
range of options allowing an enomerous degree of flexibility. In range of options allowing an enormous degree of flexibility. In order
order to build an Internet PMI based on ACs, the PKIC working group to build an Internet PMI based on ACs, the PKIX working group had to
had to develop a profile of the AC. develop a profile of the AC.
The AC profile is description of the contents of the AC, the allowed The AC profile is description of the contents of the AC, the allowed
and required extensions, and applicable attributes. [AC] provides and required extensions, and applicable attributes. [AC] provides
such a profile of the X.509 v2 AC. 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
skipping to change at page 20, line 37 skipping to change at page 20, line 37
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 certificate management message format (CMMF), that together and certificate management message format (CMMF), that together
described the necessary set of message formats, and two other described the necessary set of message formats, and two other
documents, [CMP] and [CMC], that described protocols for exchanging documents, [CMP] and [CMC], that described protocols for exchanging
those messages. However, the message formats defined in in the CMMF those messages. However, the message formats defined in the CMMF
draft were inserted into both [CMP] and [CMC], and thus the (CMMF) draft were inserted into both [CMP] and [CMC], and thus the (CMMF)
draft has been dropped as a PKIX document. draft has been dropped as a PKIX document.
[CMP-HTTP] and [CMP-TCP] were developed, after some implmentation [CMP-HTTP] and [CMP-TCP] were developed, after some implementation
experience, to update the procedure documented in [CMP] for using CMP experience, to update the procedure documented in [CMP] for using CMP
with HTTP and TCP and the transport protocols [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.
3.6.5 Time-Stamp and Data Certification Services 3.6.5 Time-Stamp, Data Verification, and Data Certification Services
In late 1998, the PKIX working group began two efforts that were not In late 1998, the PKIX working group began two efforts that were not
in the original working group charter, but were deemed to be in the original working group charter, but were deemed to be
appropriate because they described infrastructure services that could appropriate because they described infrastructure services that could
be used to provide desired security services. The first of these is be used to provide desired security services. The first of these is
time stamping, described in [TSP]. Time stamping is a service in time stamping, described in [TSP]. Time stamping is a service in
which a trusted third party - a Time Stamp Authority, or TSA - signs which a trusted third party - a Time Stamp Authority, or TSA - signs
a message, in order to provide evidence that it existed prior to a a message, in order to provide evidence that it existed prior to a
given time. Time stamping provides some support for non-repudiation, given time. Time stamping provides some support for non-repudiation,
in that a user cannot claim that a transaction was later forged after in that a user cannot claim that a transaction was later forged after
skipping to change at page 21, line 37 skipping to change at page 21, line 37
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 The third iteration of the draft removed support for TDAs as no one
in the WG expressed a requirement for the role. 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 [TSP] draft may be covered by patent(s). Use of the covered in [TSP] draft may be covered by patent(s). Use of the
material covered by the patent(s) in question has not be granted by material covered by the patent(s) in question has not be granted by
the patentholder. Thus, anyone interested in implementing the PKIX the patent holder. Thus, anyone interested in implementing the PKIX
[TSP] draft must be aware of this intellectual property issue. [TSP] draft must be aware of this intellectual property issue.
The second new effort is the definition of a Data Validation and The second new effort is the definition of a Data Validation and
Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted Certification Server, or DVCS, protocol [DVCS]. A DVCS is a Trusted
Third Party that verifies the correctness of specific data submitted Third Party that verifies the correctness of specific data submitted
to it. to it. It also allows the delegation of trustworthy servers and
allows for chaining of verifications.
This is different from the TSP service in that a TSA will not attempt This services offered by DVCS are different from the TSP service in
to parse and/or verify a message sent to it for certification; that a TSA will not attempt to parse or verify a message sent to it
instead, it will merely append a reliable indication of the current for certification; instead, it will merely append a reliable
time, and sign the resulting string-of-bits. This offers an indication of the current time, and sign the resulting string-of-
indication that the given string-of-bits existed at a specified time; bits. This offers an indication that the given string-of-bits existed
it does not offer any indication of the correctness or relevance of at a specified time; it does not offer any indication of the
that string of bits. By contrast, the DVCS certifies possession of correctness or relevance of that string of bits. By contrast, the
data or the validity of another entity's signature. As part of this, DVCS certifies possession of data or the validity of another entity's
the DVCS verifies the mathematical correctness of the actual signature. As part of this, the DVCS verifies the mathematical
signature value contained in the request and also checks the full correctness of the actual signature value contained in the request
certification path from the signing entity to a trusted point (e.g., and also checks the full certification path from the signing entity
the DVCS's CA, or the Root CA in a hierarchy). to a trusted point (e.g., the DVCS's CA, or the Root CA in a
hierarchy).
The DVCS 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 PKC was valid at the time indicated in evidence that a signature or PKC was valid at the time indicated in
the token. The token can be used even after the corresponding PKC the token. The token can be used even after the corresponding PKC
expires and its revocation information is no longer available on CRLs expires and its revocation information is no longer available on CRLs
(for example). Second, the production of a data certification token (for example). Second, the production of a data certification token
in response to a signed request for certification of another in response to a signed request for certification of another
signature or PKC also provides evidence that due diligence was signature or PKC also provides evidence that due diligence was
performed by the requester in validating the signature or PKC. performed by the requester in validating the signature or PKC.
skipping to change at page 23, line 10 skipping to change at page 23, line 11
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-02.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
PKCs containing ECDSA keys. This document should be used by anyone PKCs containing ECDSA keys. This document should be used by anyone
wishing to support ECDSA; others who do not support ECDSA are not wishing to support ECDSA; others who do not support ECDSA are not
required to comply with it. required to comply with it.
STATUS: WG Last Call. STATUS: Finished 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
PKCs containing KEA keys. This document should be used by anyone PKCs containing KEA keys. This document should be used by anyone
wishing to support KEA; others who do not support ECDSA are not wishing to support KEA; others who do not support ECDSA are 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 Qualified DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified
Certificates <draft-ietf-pkix-qc-01.txt> Certificates <draft-ietf-pkix-qc-03.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 PKCs called requirements on information content in a specific type of PKCs called
Qualified Certificates. A "Qualified Certificate" is a PKC that is Qualified Certificates. A "Qualified Certificate" is a PKC that is
issued to a natural person (i.e., a living human being); contains an issued to a natural person (i.e., a living human being); contains an
unmistakable identity based on a real name or a pseudonym of the unmistakable identity based on a real name or a pseudonym of the
subject; exclusively indicates non-repudiation as the key usage for subject; exclusively indicates non-repudiation as the key usage for
the certificate's public key; and meets a number of requirements. the certificate's public key; and meets a number of requirements.
STATUS: Under WG review. STATUS: WG Last Call.
DOCUMENT TITLE: An Internet AttributeCertificate Profile for DOCUMENT TITLE: An Internet AttributeCertificate Profile for
Authorizations <draft-ietf-pkix-acx509prof-01.txt> Authorizations <draft-ietf-pkix-acx509prof-02.txt>
DESCRIPTION: This document profiles the format for an defines DESCRIPTION: This document profiles the format for an defines
requirements on X.509 v2 ACs to support authorization services requirements on X.509 v2 ACs to support authorization services
required by various Internet protocols (TLS, CMS, and the consumers required by various Internet protocols (TLS, CMS, and the consumers
of CMS, etc.). Two profiles are defined on that supports basic of CMS, etc.). Two profiles are defined in support of basic
authorizations and on the supports proxiable services. authorizations and in support of services that can operate via proxy.
STATUS: Under WG review.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
and CRL Profile <draft-ietf-pkix-new-part1-00.txt>
DESCRIPTION: This document is an update of [FORMAT].
STATUS: Under WG review.
DOCUMENT TITLE: A String Representation of General Name <draft-ietf-
pkix-generalname-00.txt>
DESCRIPTION: This document specifies a string format for the ASN.1
construct GeneralName.
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
skipping to change at page 25, line 22 skipping to change at page 25, line 38
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: Diffie-Hellman Proof-of-Possesion Algorithms <draft- DOCUMENT TITLE: Diffie-Hellman Proof-of-Possession Algorithms <draft-
ietf-pkix-dhpop-02.txt> ietf-pkix-dhpop-02.txt>
DESCRIPTION: This documents describes two signing algorithms using DESCRIPTION: This documents describes two signing algorithms using
the Diffie-Hellman key agreement process to provide a shared secret the Diffie-Hellman key agreement process to provide a shared secret
as the basis of the signature. It allows Diffie-Hellman a key as the basis of the signature. It allows Diffie-Hellman, a key
agreement algorithm to be used instead of requiring that the public agreement algorithm, to be used instead of requiring that the public
key being requested for certification correspond to an algorithm that key being requested for certification correspond to an algorithm that
is capable of signing and/or encrypting. The first algorithm is capable of signing and encrypting. The first algorithm generates a
generates a signature for a specific verifier where the signer and signature for a specific verifier where the signer and recipient have
recipient have the same public key parameters. The second algorithm the same public key parameters. The second algorithm generates a
generates a signature for arbitrary verifiers where the signer and signature for arbitrary verifiers where the signer and recipient do
recipient do not have the same public key parameters. not have the same public key parameters.
STATUS: Under WG review. STATUS: IETF Last Call.
DOCUMENT TITLE: Limited Attribute Certificate Aquisition Protocol DOCUMENT TITLE: Limited Attribute Certificate Acquisition Protocol
<draft-ietf-pkix-laap-00.txt> <draft-ietf-pkix-laap-00.txt>
DESCRIPTION: This document specifies a deliberately limited protocol DESCRIPTION: This document specifies a deliberately limited protocol
for requesting ACs from a server. It is intended to be complementary 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 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 of an LDAP server is not suitable due to the type of authorization
model being employed. model being employed.
STATUS: Under WG review. STATUS: Under WG review.
skipping to change at page 26, line 22 skipping to change at page 27, line 22
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: IETF Last Call.
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
skipping to change at page 27, line 42 skipping to change at page 28, line 42
DOCUMENT TITLE: OCSP Extensions <draft-ietf-pkix-ocspx-00.txt> DOCUMENT TITLE: OCSP Extensions <draft-ietf-pkix-ocspx-00.txt>
DESCRIPTION: This document defines Internet-standard extensions to DESCRIPTION: This document defines Internet-standard extensions to
OCSP that enable a client to delegate processing of certificate OCSP that enable a client to delegate processing of certificate
acceptance functions to a trusted server. The client may control the acceptance functions to a trusted server. The client may control the
degree to which delegation takes place. In addition limited support degree to which delegation takes place. In addition limited support
is provided for delegating authorization decisions. is provided for delegating authorization decisions.
STATUS: Under WG review. STATUS: Under WG review.
DOCUMENT TITLE: Certificate Management Protocols <draft-ietf-pkix-
rfc2510bis-00.txt>
DESCRIPTION: This document is an update of [CMP].
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
purpose of this document (PKIX-4) is to establish a clear purpose of this document (PKIX-4) is to establish a clear
relationship between certificate policies and CPSs, and to present a relationship between certificate policies and CPSs, and to present a
framework to assist the writers of certificate policies or CPSs with framework to assist the writers of certificate policies or CPSs with
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, Data Validation, 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-03.txt> Protocols <draft-ietf-pkix-time-stamp-06.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: In WG Last.
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-03.txt> Certification Server Protocols <draft-ietf-pkix-dcs-04.txt>
DESCRIPTION: This document defines a data validation and DESCRIPTION: This document defines a data validation and
certification service, or DVCS, which can be used to certify both the certification service, or DVCS, which can be used to certify both the
existence and correctness of a message or signature. In contrast to existence and correctness of a message or signature. In contrast to
the time stamp service described above, the DVCS certifies possession the time stamp service described above, the DVCS certifies possession
of data or the validity of another entity's signature. As part of of data or the validity of another entity's signature. As part of
this, the DVCS verifies the mathematical correctness of the actual this, the DVCS verifies the mathematical correctness of the actual
signature value contained in the request and also checks the full signature value contained in the request and also checks the full
certification path from the signing entity to a trusted point (e.g., certification path from the signing entity to a trusted point (e.g.,
the DVCS's CA, or the Root CA in a hierarchy). the DVCS's CA, or the Root CA in a hierarchy).
skipping to change at page 29, line 13 skipping to change at page 30, line 20
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: Internet X.509 Public Key Infrastructure Extending DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Technical
trust in non repudiation tokens in time <draft-ietf-pkix-extend- Requirements for a non-Repudiation Service <draft-ietf-pkix-
trust-non-repudiation-token-00.txt> technr-01.txt>
DESCRIPTION: This document describes a method to maintain the trust DESCRIPTION: This document describes those features of a service
in a token issued by a non-repudiation Trusted Third Party (NR TTP) which processes signed documents which must be present in order for
(DVCS/TSA/TDA) after the key initially used to establish trust in the that service to constitute a "technical non-repudiation" service. A
token expires. The document describes a general format for storage of technical non-repudiation service must permit an independent verifier
DVCS/TS/TDA tokens for this purpose, which establishes a chain of to determine whether a given signature was applied to a given data
custody for the data. object by the private key associated with a given valid certificate,
at a time later than the signature. The features of a technical non-
repudiation service are expected to be necessary for a full non-
repudiation service, although they may not be sufficient.
STATUS: Under WG review. This document is intended to clarify the definition of the "non-
repudiation" service in RFC 2459. It should thus serve as a guide to
when the nonRepudiation bit of the keyUsage extension should be set
and to when a Certificate Authority is required to archive CRL's.
4.6 Documents that never made it out of the working group STATUS: Under WG Review.
4.6 Expired Documents
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
Management Message Formats Management Message Formats
DESCRIPTION: This document contains the formats for a series of DESCRIPTION: This document contains the formats for a series of
messages important in certificate/PKI management. These messages let messages important in certificate and PKI management. These messages
CA's, RA's, and relying parties communicate with each other. Note let CA's, RA's, and relying parties communicate with each other. Note
that this document only specifies message formats; it does not that this document only specifies message formats; it does not
specify a protocol for transferring messages. That protocol can be specify a protocol for transferring messages. That protocol can be
either CMP or CMC, or perhaps another custom protocol. either CMP or CMC, or perhaps another custom protocol.
STATUS: Work has been discontinued, as all useful information from it STATUS: Work has been discontinued. All useful information from it
has been moved into [CMP] and [CMC]. has been moved into [CMP] and [CMC].
DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0
DESCRIPTION: This document specifies a set of methods, headers, and DESCRIPTION: This document specifies a set of methods, headers, and
content-types ancillary to HTTP/1.1 to publish, retrieve X.509 content-types ancillary to HTTP/1.1 to publish, retrieve X.509
certificates and Certificate Revocation Lists. This protocol also certificates and Certificate Revocation Lists. This protocol also
facilitates determining current status of a digital certificate facilitates determining current status of a digital certificate
without the use of CRLs. This protocol defines new methods, request without the use of CRLs. This protocol defines new methods, request
and response bodies, error codes to HTTP/1.1 protocol for securely and response bodies, error codes to HTTP/1.1 protocol for securely
publishing, retrieving, and validating certificates across a publishing, retrieving, and validating certificates across a
firewall. firewall.
STATUS: Work has been discontinued due to lack of interest. STATUS: Expired.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL
Distribution Options (OpenCDP) Distribution Options (OpenCDP)
DESCRIPTION: This document proposes an alternative to the CRL DESCRIPTION: This document proposes an alternative to the CRL
Distribution Point (CDP) approach documented in [FORMAT]. OCDP Distribution Point (CDP) approach documented in [FORMAT]. OCDP
separates the CRL location function from the process of certificate separates the CRL location function from the process of certificate
and CRL validation, and thus claims some benefits over the CDP and CRL validation, and thus claims some benefits over the CDP
approach. approach.
skipping to change at page 30, line 28 skipping to change at page 31, line 42
profile the use of the CDP approach. profile the use of the CDP approach.
DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the
Online Certificate Status Protocol Online Certificate Status Protocol
DESCRIPTION: To improve the degree to which it can scale, OCSP allows DESCRIPTION: To improve the degree to which it can scale, OCSP allows
caching of responses - e.g., at intermediary servers, or even at the caching of responses - e.g., at intermediary servers, or even at the
relying party's end system. This document describes how to support relying party's end system. This document describes how to support
OCSP caching at intermediary servers. OCSP caching at intermediary servers.
STATUS: Work has been discontinued due to lack of interest. STATUS: Work has been discontinued.
DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix- DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
bert1-01.txt> bert1-01.txt>
DESCRIPTION: This document defines a finite method of representing a DESCRIPTION: This document defines a finite method of representing a
discrete instant in time as a referable event. The Basic Event discrete instant in time as a referable event. The Basic Event
Representation Token (BERT) is a light-weight binary token designed Representation Token (BERT) is a light-weight binary token designed
for use in large numbers over short periods of time. The tokens for use in large numbers over short periods of time. The tokens
contain only a single instance of an event stamp and the trust contain only a single instance of an event stamp and the trust
process is referenced against an external reference. process is referenced against an external reference.
STATUS: Work has been discontinued. STATUS: Expired.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending
trust in non repudiation tokens in time <draft-ietf-pkix-extend-
trust-non-repudiation-token-00.txt>
DESCRIPTION: This document describes a method to maintain the trust
in a token issued by a non-repudiation Trusted Third Party (NR TTP)
(DVCS/TSA/TDA) after the key initially used to establish trust in the
token expires. The document describes a general format for storage of
DVCS/TS/TDA tokens for this purpose, which establishes a chain of
custody for the data.
STATUS: Expired.
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 PKCs PKIX has been referred to as a "name-centric" PKI because the PKCs
associate public keys with names of entities. Each PKC contains at associate public keys with names of entities. Each PKC contains at
least one name for the owner of a particular public key. The name can least one name for the owner of a particular public key. The name can
skipping to change at page 31, line 26 skipping to change at page 33, line 4
intended usage of the PKC. 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.509 v3 PKC. One There are two possible places to put a name in an X.509 v3 PKC. One
is the subject field in the base PKC (often called the "Distinguished is the subject field in the base PKC (often called the "Distinguished
Name" or "DN" field), and the other is in the subjectAltName Name" or "DN" field), and the other is in the subjectAltName
extension. extension.
5.1.1.1 Distinguished Names 5.1.1.1 Distinguished Names
According to [FORMAT], a CA's PKC must have a non-null value in the
According to [FORMAT], a PKIX PKC must have a non-null value in the subject field, while EE's PKCs are permitted to have an empty subject
subject field, except for an EE PKC, which is permitted to have an field. If a PKC has a non-null subject field, it MUST contain an
empty subject field. Furthermore, if a PKC has a non-null subject X.500 Distinguished Name.
field, it MUST contain an X.500 Distinguished Name.
5.1.1.2 SubjectAltName Forms 5.1.1.2 SubjectAltName Forms
In addition to the DN, a PKIX PKC may have one or more values in the In addition to the DN, a PKIX PKC may have one or more values 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 PKC (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"). "C=US, O=University of Maryland, L=Baltimore, CN=UMBC").
skipping to change at page 32, line 36 skipping to change at page 34, line 14
when processing a certification path is not defined by this working when processing a certification path is not defined by this working
group. group.
Because the subject's alternative name is considered to be Because the subject's alternative name is considered to be
definitively bound to the public key, all parts of the subject's definitively bound to the public key, all parts of the subject's
alternative name 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 address 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 ">".
5.1.1.2.2 DNS Names 5.1.1.2.2 DNS Names
When the subjectAltName extension contains a domain name service When the subjectAltName extension contains a domain name service
label, the domain name is stored in the dNSName attribute(an label, the domain name is stored in the dNSName attribute(an
IA5String). The string shall be in the "preferred name syntax," as IA5String). The string shall be in the "preferred name syntax," as
specified by [DNS]. Note that while upper and lower case letters are specified by [DNS]. Note that while upper and lower case letters are
allowed in domain names, no signifigance is attached to the case. In allowed in domain names, no significance is attached to the case. In
addition, while the string " " is a legal domain name, subjectAltName addition, while the string " " is a legal domain name, subjectAltName
extensions with a dNSName " " are not permitted. Finally, the use of extensions with a dNSName " " are not permitted. Finally, the use of
the DNS representation for Internet mail addresses (wpolk.nist.gov the DNS representation for Internet mail addresses (wpolk.nist.gov
instead of wpolk@nist.gov) is not permitted; such identities are to instead of wpolk@nist.gov) is not permitted; such identities are to
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
skipping to change at page 34, line 16 skipping to change at page 35, line 42
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.ietf.org, is irrelevant and causes no interoperability
problems - those are different domains. However, if there were to be problems - those are different domains. However, if there were to be
another node on the Internet with domain name www.ietf.org, then another node on the Internet with domain name www.ietf.org, then
there would be a problem due to name duplication. there would be a problem due to name duplication.
The same applies for IP addresses. As long as only one node on the The same applies for IP addresses. As long as only one node on the
Internet responds to the IP address 130.85.1.3, there is no problem, Internet responds to the IP address 130.85.1.3, there is no problem,
despite the fact that there are 100 different corporate Intranets, despite the fact that there are 100 different corporate Intranets,
each using that same IP address. However, if two different nodes on each using that same IP address. However, if two different nodes on
the Internet each responded to the IP address 130.85.1.3, there would the Internet each responded to the IP address 130.85.1.3, there would
be a problem. be a problem.
skipping to change at page 35, line 6 skipping to change at page 36, line 32
Another discussion related to certificate path construction was where Another discussion related to certificate path construction was where
to store the CA and EE PKCs in the directory (specifically LDAPv2 to store the CA and EE PKCs in the directory (specifically LDAPv2
directories). Two camps emerged with different views on where to directories). Two camps emerged with different views on where to
store CA and cross-certificates. In the CA's directory entry, one store CA and cross-certificates. In the CA's directory entry, one
camp wanted self-issued PKCs stored in the cACertificate attribute, camp wanted self-issued PKCs stored in the cACertificate attribute,
PKCs issued to this CA stored in the forward element of the PKCs issued to this CA stored in the forward element of the
crossCertificatePair, and PKCs issued from this CA for other CAs in crossCertificatePair, and PKCs issued from this CA for other CAs in
the reverse element of the crossCertificatePair attribute. The other the reverse element of the crossCertificatePair attribute. The other
camp wanted all CA PKCs stored in the cACertificate attribute, and camp wanted all CA PKCs stored in the cACertificate attribute, and
PKCs issued to/from another domain stored in the crossCertificatePair PKCs issued to and from another domain stored in the
attribute. There was a short discussion that the second was more crossCertificatePair attribute. There was a short discussion that the
efficient than first, and that one solution or the other was more second was more efficient than first, and that one solution or the
widely deployed. The end result was to indicate that self-issued PKCs other was more widely deployed. The end result was to indicate that
and PKCs issued to the CA by CAs in the same domain as the CA are self-issued PKCs and PKCs issued to the CA by CAs in the same domain
stored in the cACertificate attribute. The crossCertificatePair as the CA are stored in the cACertificate attribute. The
attribute's forward element will include all but self-issued PKCs crossCertificatePair attribute's forward element will include all but
issued to the CA. The reverse element may include a subset of PKCs self-issued PKCs issued to the CA. The reverse element may include a
issued by the CA to other CAs. With this resolution both camp's subset of PKCs issued by the CA to other CAs. With this resolution
implementations are supported and are free to chose the location of both camp's implementations are supported and are free to chose the
CA PKCs to best support their implementation. location of CA PKCs to best support their 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 PKC?" Name constraints when there is more than one name form in a PKC?"
That is, [FORMAT] states that: That is, [FORMAT] states that:
subject's alternative names may be constrained in the same manner Subject's alternative names may be constrained in the same manner
as 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 PKC dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a PKC
with an empty DN, with subjectAltName extension having dNSName set to with an empty DN, with subjectAltName extension having dNSName set to
"PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The
question is, are name constraints enforced on these two PKCs - is the question is, are name constraints enforced on these two PKCs - is the
name of the EE PKC considered to be properly subordinate to the name name of the EE PKC considered to be properly subordinate to the name
skipping to change at page 36, line 52 skipping to change at page 38, line 30
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
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. For example (c is country-name, admd is all of Name B's name. For example (c is country-name, admd is
administrative-domain-name, and o is orgnaization-name, ou is administrative-domain-name, and o is organization-name, ou is
organizational-unit-name, pn is personal-name, sn=surname, and gn is organizational-unit-name, pn is personal-name, sn=surname, and gn is
given-name in both Name A and B), the mneumonic X.400 address (using given-name in both Name A and B), the mnemonic X.400 address (using
PrintableString choices for c and admd) "c=US, admd=AT&T, o=MIT, PrintableString choices for c and admd) "c=US, admd=AT&T, o=MIT,
ou=cs, pn='sn=Doe,gn=John'" is subordinate to "c=US, admd=AT&T, ou=cs, pn='sn=Doe,gn=John'" is subordinate to "c=US, admd=AT&T,
o=MIT, ou=cs" and "c=US, admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn o=MIT, ou=cs" and "c=US, admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn
is a SET that includes, among other things, sn and gn). is a SET that includes, among other things, sn and gn).
5.1.4.5 DNs 5.1.4.5 DNs
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 PrintableString 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=administration". 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 and - Assuming UTF8String types for all attribute values in Name A and
B, "c=US, o=MIT, ou=CS, ou=administration" is subordinate to B, "c=US, o=MIT, ou=CS, ou=administration" is subordinate to
"c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, ou=Adminstration". "c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs,
"c=US, o=MIT, ou=CS, cn= John Smith" (note the white spaces) is ou=Administration". "c=US, o=MIT, ou=CS, cn= John Smith" (note
not subordinate to "c=US, o=MIT, ou=CS, cn= John Smith". the white spaces) is not subordinate to "c=US, o=MIT, ou=CS, cn=
John Smith".
- Assuming UTF8String types for all attribute values in Name A and - Assuming UTF8String types for all attribute values in Name A and
PrintableString types for all attribute values in Name B, "c=US, PrintableString types for all attribute values in Name B, "c=US,
o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the
verification software supports the full comparison algorithm in verification software supports the full comparison algorithm in
the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to
"c=US, o=MIT, ou=CS" if the verification software supports the "c=US, o=MIT, ou=CS" if the verification software supports the
comparison algorithm in [FORMAT]. comparison algorithm in [FORMAT].
5.1.4.6 URIs 5.1.4.6 URIs
skipping to change at page 38, line 4 skipping to change at page 39, line 31
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 is - If the name constraint is specified as ".mit.edu", then Name A is
subordinate to Name B (in B's subtree) if Name A contains all of 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 host Name B's name, with the addition of zero or more additional host
or domain names to the left of Name B's name. That is, or domain names to the left of Name B's name. That is,
www.mit.edu is subordinate to .mit.edu, as is curly.cs.mit.edu. www.mit.edu is subordinate to .mit.edu, as is curly.cs.mit.edu.
However, mit.edu is not subordinate to .mit.edu. When the However, mit.edu is not subordinate to .mit.edu. When the
constraint begins with a "." it specifies a host. constraint begins with a "." it specifies a host.
- If the name constraint is specified as "abc.mit.edu", then Name A - 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 is subordinate to Name B (in B's subtree) if Name A contains all
of Name B's name. No leftward expansion of the host or domain of Name B's name. No leftward expansion of the host or domain
name is allowed. 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) is - For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01) is
subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20 subordinate to Name B (128.32.1.0/255.255.255.0 encoded as 80 20
00 00 FF FF FF 00) (in B's subtree) if Name A falls within the 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the
skipping to change at page 39, line 24 skipping to change at page 40, line 51
consistency with encodings [FORMAT] defines a set of rules for the consistency with encodings [FORMAT] defines a set of rules for the
string choices. PrintableString was kept as the first choice because string choices. PrintableString was kept as the first choice because
of it's widespread support by vendors. BMPString was the second of it's widespread support by vendors. BMPString was the second
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.1.7 Uniqueness
[Add text in here about the QC uniqueness issues.]
5.2 POP 5.2 POP
Proof of Possession, or POP, means that the CA is adequately Proof of Possession, or POP, or also CA POP, means that the CA is
convinced that the entity requesting a PKC containing a public key Y adequately convinced that the entity requesting a PKC containing a
has access to the private key X corresponding to that public key. public key Y has access to the private key X corresponding to that
public key.
POP is important because it provides an appropriate level of There has been some debate whether POP was or not needed.
assurance in the correct operation of the PKI as a whole. At its
lowest level, POP counters the "self-inflicted denial of service"; This question needs to be addressed separately considering the
that is, an entity voluntarily getting a PKC that cannot be used to context of use of the key, in particular whether a key is used for an
sign or encrypt/decrypt information. However, as the following two authentication or non repudiation service, or in a confidentiality
examples demonstrate, POP also counters less direct, but more severe, service. Note that this does not map to the key usage bit directly,
threats. since it is possible to use a confidentiality key to perform an
authentication service, e.g. by asking to decrypt an encrypted
challenge.
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 PKC from Charlie, a CA, containing Y. Alice public key Y. Alice has a PKC from Charlie, a CA, containing Y. Alice
uses X to sign a transaction T. Without POP, Mal could also get a PKC uses X to sign a transaction T. Without POP, Mal could also get a PKC
from Charlie containing the same public key, Y. Now, there are two from Charlie containing the same public key, Y. Now without POP,
possible threats: Mal could claim to have been the real signer of T; there are two possible threats: Mal could claim to have been the real
or Alice can falsely deny signing T, claiming that it was instead signer of T; or Alice can falsely deny signing T, claiming that it
Mal. Since no one can reliably prove that Mal did or did not ever was instead Mal. Since no one can reliably prove that Mal did or did
possess X, neither of these claims can be refuted, and thus the not ever possess X, neither of these claims can be refuted, and thus
service provided by and the confidence in the PKI has been defeated. the service provided by and the confidence in the PKI has been
(Of course, if Mal really did possess X, Alice's private key, then no defeated. (Of course, if Mal really did possess X, Alice's private
POP mechanism in the world will help, but that is a different key, then no POP mechanism in the world will help, but that is a
problem.) different problem.)
One level of protection can be gained by having Alice, as the true Protection can be gained by having Alice, as the true signer of the
signer of the transaction, include in the signed information her PKC transaction, include in the signed information her PKC or an
or an identifier of her PKC (e.g., a hash of her PKC). This might identifier of her PKC (e.g., a hash of her PKC). This makes
make it more difficult for Mal to claim authorship - he would have to impossible for Mal to claim authorship because he does not know the
assert that he incorrectly included Alice's PKC, rather than his own. private key from Alice and thus is unable to include his certificate
However, it would not stop Alice from falsely repudiating her under the signature.
actions. Since the PKC itself is a public item, Mal indeed could have
inserted Alice's PKC into the signed transaction, and thus its
presence does not indicate that Alice was the one who participated in
the now-repudiated transaction. The only reliable way to stop this
attack is to require that Mal prove he possesses X before his PKC is
issued.
For signing keys used only for authentication, and not for non- The adequate protection may be obtained in the general case, by
repudiation, the threat is lower because users may not care about mandating the inclusion of a reference of the certificate every time
Alice's after-the-fact repudiation, and thus POP becomes less a signature (or non repudiation) key is being used in a protocol.
important. However, POP SHOULD still be done wherever feasible in
this environment, by either off-line or on-line means. However, because all the protocols were not doing so, a conservative
measure has been taken by requesting POP to be performed by CAs. It
should thus be understood, that this measure is not strictly
necessary and is only a temporary measure to make old protocols
secure. New protocols or data formats are being developed. If the key
being used is always used in a context where the identifier of the
certificate is included in the protocol, then POP by the CA is not
necessary. The inclusion of the identifier of the certificate in the
protocol or data format may be understood as POP being performed at
the transaction time rather than by the CA, at the registration time
of the user in the PKI.
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 Suppose that Al is a new instructor in the Computer Science
key agreement or key exchange) can help to prevent undermining Department of a local University. Al has created a draft final exam
confidence in the PKI. Suppose that Al is a new instructor in the for the Introduction to Networking course he is teaching. He wants to
Computer Science Department of a local University. Al has created a send a copy of the draft final to Dorothy, the Department Head, for
draft final exam for the Introduction to Networking course he is her review prior to giving the exam. This exam will of course be
teaching. He wants to send a copy of the draft final to Dorothy, the encrypted, as several students have access to the computer system.
Department Head, for her review prior to giving the exam. This exam However, a quick search of the PKC repository (e.g., search the
will of course be encrypted, as several students have access to the repository for all records with subjectPublicKey=Dorothy's-value)
computer system. However, a quick search of the PKC repository (e.g., turns up the fact that several students have PKCs containing the same
search the repository for all records with public key management key as Dorothy. At this point, if no POP has
subjectPublicKey=Dorothy's-value) turns up the fact that several been done by the CA, Al has no way of knowing whether all of the
students have PKCs containing the same public key management key as students have simply created these PKCs without knowing the
Dorothy. At this point, if no POP has been done by the CA, Al has no corresponding private key (and thus it is safe to send the encrypted
way of knowing whether all of the students have simply created these exam to Dorothy), or whether the students have somehow acquired
PKCs without knowing the corresponding private key (and thus it is Dorothy's private key (and thus it is certainly not safe to send the
safe to send the encrypted exam to Dorothy), or whether the students exam).
have somehow acquired Dorothy's private key (and thus it is certainly
not safe to send the exam). Thus, the service to be provided by the The later case may seem unsafe. However, if the other students have
PKI - allowing users to communicate with one another, with confidence acquired the key, they do not even need to publish their certificates
in who they are communicating with - has been totally defeated. If and can simply decrypt in parallel.
the CA is providing POP, then either no students will have such PKCs,
or Al can know with certainty that the students do indeed know The end story is that, if the key only known to Dorothy, there is no
Dorothy's private key, and act accordingly. problem. Thus POP by the CA is not needed.
If the key, like a Diffie-Hellman key, is used for an authentication
service the answer depends from the protocol being used. In the
former example, the decryption was done locally and no data was sent
back on the wire. In an authentication protocol, the story is
different because either some encrypted or decrypted data is sent
back. If the data sent back contains the identifier of the
certificate in a way that it cannot be modified without that
modification being detected, then there is no need for POP. On the
contrary, POP by the CA is needed.
As a conservative measure, POP for encryption keys is recommended,
but it should be realized that it is not always needed.
In general it should be noticed that POP at the time of the
transaction is much superior than POP made by the CA, since it is
possible in real time to be sure that everything is correct, rather
than rely on that verification to be done at the time of registration
by the CA. Should the CA fail in that verification, then there is a
security breach. On the contrary, doing POP at the time of the
transaction, eliminates that problem.
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 PKC requester can provide POP to either a CA or to an RA, if the RA a PKC requester can provide POP to either a CA or to an RA, if the RA
can adequately assure the CA that POP has been performed. Some of the can adequately assure the CA that POP has been performed. Some of the
acceptable ways to provide POP include: acceptable ways to provide POP include:
- Out-of-band means: - Out-of-band means:
skipping to change at page 41, line 43 skipping to change at page 44, line 4
the PKC request itself) using the private key. The CA will then the PKC request itself) using the private key. The CA will then
use the requested public key to verify the signature. If the use the requested public key to verify the signature. If the
signature verification works, the CA can safely conclude that signature verification works, the CA can safely conclude that
the requester had access to the private key. If the signature the 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, and
reject the request. 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 with the CA can send the user the requested public key, along with
the CA's own private key, to encrypt some piece of data, and the CA's own public key, to encrypt some piece of data, and
send it to the requester to be decrypted. For example, the CA send it to the requester to be decrypted. For example, the CA
can generate some random challenge, and require some action to can generate some random challenge, and require some action to
be taken after decryption (e.g., "decrypt this encrypted random be taken after decryption (e.g., "decrypt this encrypted random
number and send it back to me"). If the requester does not take number and send it back to me"). If the requester does not take
the requested action, the CA concludes that the requester did the requested action, the CA concludes that the requester did
not possess the private key, and the PKC is not issued. not possess the private key, and the PKC 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 PKC, and then send it to the requester in to generate the requested PKC, and then send it to the requester in
encrypted form. If the requester does not have access to the encrypted form. If the requester does not have access to the
appropriate private key, the requester cannot decrypt the PKC, and appropriate private key, the requester cannot decrypt the PKC, and
thus cannot use it. After some period of time in which the PKC is not thus cannot use it. After some period of time in which the PKC is not
used, the CA will revoke the PKC. (This only works if the PKC is not used, the CA will revoke the PKC. (This only works if the PKC is not
made available to any untrusted entities until after the requester made available to any untrusted entities until after the requester
has successfully decrypted it.) has successfully decrypted it.)
5.3 Key Usage Bits 5.3 Key Usage Bits
5.3.1 Key Usage Extension
The key usage extension defines the purpose (e.g., encipherment, The key usage extension defines the purpose (e.g., encipherment,
signature, certificate signing) of the key contained in the PKC. This signature, certificate signing) of the key contained in the PKC. This
extension is used when a key that could be used for more than one 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 operation is to be restricted. For example, if a CA's RSA key should
used only for signing, the digitalSignature and/or nonRepudiation be used only for signing CRLS, the cRLSign bit would be asserted.
bits would be asserted. Likewise, when an RSA key should be used only Likewise, when an RSA key should be used only for key management, the
for key management, the keyEncipherment bit would be asserted. When keyEncipherment bit would be asserted. When used, this extension
used, this extension should be marked critical. should be marked critical.
According to [FORMAT], bits in the KeyUsage type are used as follows:
- The digitalSignature bit is asserted when the subject public key
is used to verify digital signatures that have purposes other
than non-repudiation, certificate signature, and CRL signature.
For example, the digitalSignature bit is asserted when the
subject public key is used to provide authentication via the
signing of ephemeral data.
- The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures used to provide a non-
repudiation service which protects against the signing entity
falsely denying some action, excluding certificate or CRL
signing.
- The keyEncipherment bit is asserted when the subject public key
is used for key transport. For example, when an RSA key is to be
used for key management, this bit must asserted.
- The dataEncipherment bit is asserted when the subject public key
is used for enciphering user data, other than cryptographic keys.
- The keyAgreement bit is asserted when the subject public key is
used for key agreement. For example, when a Diffie-Hellman key is
to be used for key management, this bit must asserted.
- The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on certificates. This bit may only
be asserted in CA certificates.
- The cRLSign bit is asserted when the subject public key is used
for verifying a signature on revocation information (e.g., a
CRL).
- The meaning of the encipherOnly bit is undefined in the absence [FORMAT] includes some text for how the bits in the KeyUsage type are
of the keyAgreement bit. When the encipherOnly bit is asserted used. Developing the text for some of the bits was easy; however,
and the keyAgreement bit is also set, the subject public key may many discussions were needed to arrive at a common agreement on the
be used only for enciphering data while performing key agreement. meaning of the digitalSignature (DS bit) and nonRepudiation (NR bit)
bits and when they should be set. The group quickly realized that key
usage extension mixes services and mechanisms. The DS bit indicates a
mechanism - a public key used to verify a digital signature. The NR
bit indicates a service - a public key used to verify a digital
signature and to provide a non-repudiation service. When trying to
indicate when each bit should be indicated arguments were based on:
- The meaning of the decipherOnly bit is undefined in the absence - The lifetime of the object being singed. Some felt that the DS
of the keyAgreement bit. When the decipherOnly bit is asserted bit should be set when the certificate is used to sign ephemeral
and the keyAgreement bit is also set, the subject public key may objects (e.g., bind tokens) while the NR bit should be set for
be used only for deciphering data while performing key agreement. things that are survive longer (e.g., documents). Of course, the
problem with this distinction to determine how long is the time
period for ephemeral?
PKIX does not restrict the combinations of bits that may be set in an - A concious act taken by the signer. Many felt that the NR bit
instantiation of the keyUsage extension. should be set only when the subject has expressly acknowledged
that they want to use the private key to sign an object. Signing
a document say where there is a concious decision by the subject
would be appropriate for the key usage extension to contain NR,
but when the key is used for authentication purposes, which can
occur automically and more frequently, the DS bit is more
appropriate. The discussion also concluded that since some
authentication schemes occur automatically, that the DS bit and
NR bit should never be set together in the same certificate. Some
agreed to the differentiation of the bits based on the time, but
did not agree that the two could not be in the same key usage
extension.
The discussion on the PKIX mailing list has centered on the - The procedures followed by the CA. Some felt that NR bit was kind
digitalSignature bit and the nonRepudiation bit. The question has of 'quality mark' indicating to the verifier that the verifier
come down to something like: When support for the service of non- could be assured that the CA is implementing appropriate
repudiation is desired, should both the digitalSignature and procedures for checking the subject's identity, performing
nonRepudiation bits be set, or just the nonRepudiation bit? certificate archival, etc. Other felt that it was not entirely
the CAs job and that some other entity must be involved.
Note: Provision of the service of non-repudiation requires more In the end the WG agreed to a few things:
than a single bit set in a PKC. It requires an entire
infrastructure of components to preserve for some period of time
the keys, PKCs, revocation status, signed material, etc., as well
as a trusted source of time. However, the nonRepudiation key usage
bit is provided as an indicator that such keys should not be used
as a component of a system providing a non-repudiation service.
According to [SIMONETTI], the intent is that the digitalSignature bit - Provision of the service of non-repudiation requires more than a
should be set when what is desired is the ability to sign ephemeral single bit set in a PKC. It requires an entire infrastructure of
transactions; e.g., for a single session authentication. These components to preserve for some period of time the keys, PKCs,
transactions are "ephemeral" in the sense that they are important revocation status, signed material, etc., as well as a trusted
only while they are in existence; after the session is terminated, source of time. However, the nonRepudiation key usage bit is
there is no long-term record of the digital signature and its provided as an indicator that such keys could be used as a
properties kept. When something is intended to be kept for some component of a system providing a non-repudiation service.
period of time, the nonRepudiation bit should be set. This generally
implies that an application will digitally sign something; thus, some
implementors turn on the digitalSignature bit as well. Other
implementors, however, keep the two bits mutually exclusive, to
prevent a single key from being used for both ephemeral and long-term
signing.
While [FORMAT] is silent on this specific issue, the working group's - The certificate policy is the appropriate place to indicate the
general conclusion is that a PKC may have either or both bits set. If permitted combinations of key usages. That is, a policy may
only the nonRepudiation bit is set, the key should not be used for indicate that the DS and NR bits can not be set in the same
ephemeral transactions. If only the digitalSignature bit is set, the certificate while another may say that the DS and NR bits can be
key should not be used for long-term signing. If both bits are set, set in the same certificate.
the key may be used for either purpose.
To actually enforce this requires that an application understands [2459bis] includes new text indicating the above agreements.
whether it is signing ephemeral transactions or for the long-term.
The application developers will have to understand the difference,
and set up their checks on the key usage bits field accordingly. For
example, TLS implementors should check only the digitalSignature bit,
and ignore the nonRepudiation bit. S/MIME implementors, though, will
have a difficult choice to make, since their application could be
used for either purpose, and they will generally accept signing using
keys associated with PKCs having either or both bits being turned on.
Certification Authorities should know what applications they are
providing PKCs for, and provide PKCs according to the requirements of
those applications. If CA's are tied into non-repudiation systems,
they may treat PKCs differently when the nonRepudiation bit is turned
on (e.g., store information associated with the PKC - like the user's
identification provided during PKC registration, or PKC generation
date/time stamps - for longer periods of time, in more secure
environments).
The bottom line is that this is an area where PKI implementors are 5.4 Non-Repudiation
somewhat limited in what they can do. The onus is on developers of
PKC-using systems to understand their requirements and request PKCs
with the appropriate bits set.
5.3.1 Extended Key Usage Extension The major benefit of the whole DS bit vs NR bit discussion is
development of the Technical Requirements for Non-Repudiation
[TECHNR] draft. To fill this void [TECHNR] was developed to "describe
those features of a service which processes signed documents which
must be present in order for that service to constitute a 'technical
non-repudiation' service." The basic understanding of nonon-
repudiation is that it requires that a digital signature be preserved
in such a manner that it can convince a neutral third party that it
was actually created by someone with access to the private key of a
certified key pair. Whether this definition of non-repudiation is
enough to form a legally bind agreement is still being debated.
[Add in text to talk about the extended key usages!] [Add text to describe the different modes.]
5.4 Trust Models 5.5 Trust Models
An important design decision is where in the PKI the trust point for An important design decision is where in the PKI the trust point for
a particular EE should be located (i.e., where is the EE's Root CA) . a particular EE should be located (i.e., where is the EE's Root CA) .
There are two extremes: the Top CA or the CA who issues the EE's There are two extremes: the Top CA or the CA who issues the EE's
certificate. Of course, the trust point for a particular EE can be certificate. Of course, the trust point for a particular EE can be
anywhere in the PKI, but the following presents the advanatages and anywhere in the PKI, but the following presents the advanatages and
disadvantages of locating the the trust point at these two places. disadvantages of locating the the trust point at these two places.
Advantages of Top CA trust point: [Rewrite section]
- 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 Paul Hoffman. Polk, Stefan Santesson, Dave Simonetti, Paul Hoffman, Denis Pinkas,
Ed Greck, Tom Gindin, Parag Namjoshi, Peter Sylvester, and Michael
Zolotarev.
7 References 7 References
[2459bis] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and CRL Profile," <draft-
ietf-pkix-new-part1-00.txt>, 22 October 1999.
[2510bis] Adams, C., Farrell, S., "Internet X.509 Public Key
Infrastructure Certificate Management Protocols", <draft-ietf-pkix-
rfc2510bis-00.txt>, March 2000.
[AC] S. Farrell, R. HousleyMcNeil, M., and Glassey, T., "An Internet [AC] S. Farrell, R. HousleyMcNeil, M., and Glassey, T., "An Internet
Attribute Certificate Profile for Authorization," <draft-ietf-pkix- Attribute Certificate Profile for Authorization," <draft-ietf-pkix-
ac509prof-01.txt>, October 1999. ac509prof-02.txt>, 08 March 2000.
[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-05.txt>, 14 July 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.
[CMP-HTTP] Tschal"ar, R., Kapoor, A., and Adams, C., "Using HTTP as a [CMP-HTTP] Tschal"ar, R., Kapoor, A., and Adams, C., "Using HTTP as a
skipping to change at page 47, line 14 skipping to change at page 47, line 33
[DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-of- [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-of-
Possession Algorithms," <draft-ietf-pkix-dhpop-02.txt>, 1 October Possession Algorithms," <draft-ietf-pkix-dhpop-02.txt>, 1 October
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., [DVCS] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R.,
"Internet X.509 Public Key Infrastructure Data Certification Server "Internet X.509 Public Key Infrastructure Data Certification Server
Protocols", <draft-ietf-pkix-dcs-03.txt>, 15 October 1999. Protocols", <draft-ietf-pkix-dcs-04.txt>, 08 March 2000.
[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>, 3 June 1999. ecdsa-02.txt>, 22 October 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-pkix- Extending trust in non repudiation tokens in time," <draft-ietf-pkix-
extend-trust-non-repudiation-token-00.txt>, 28 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.
skipping to change at page 47, line 45 skipping to change at page 48, line 16
[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 [LAAP] Farrell, S., Chadwick, C.W., "Limited AttributeCertificate
Acquisition Protocol", <draft-ietf-pkix-laap-00.txt>, Octoboer 1999. Acquisition Protocol", <draft-ietf-pkix-laap-00.txt>, 12 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>, 3 September 1997. 1", <http://csrc.nist.gov/pki/mispc/welcome.html>, 3 September 1997.
[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
skipping to change at page 48, line 32 skipping to change at page 49, line 5
April 1999. April 1999.
[PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key [PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key
Infrastructure Operational Protocols - LDAPv3," <draft-ietf-pkix- Infrastructure Operational Protocols - LDAPv3," <draft-ietf-pkix-
ldap-v3-01.txt>, August 1999. 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., Barzin, P., and Nystrom, M., "Internet
Public Key Infrastructure Qualified Certificates", <draft-ietf-pkix- X.509 Public Key Infrastructure Qualified Certificates", <draft-ietf-
qc-01.txt>, 6 August 1999. pkix-qc-03.txt>, February 2000.
[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 [SCVP] Malpani, A., Hoffman, P., "Simple Certificate Validation
Protocol (SCVP)," <draft-ietf-pkix-scvp-01.txt>, 9 August 1999. 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.
[TECHNR] Internet X.509 Public Key Infrastructure Technical
Requirements for a non-Repudiation Service <draft-ietf-pkix-
technr-01.txt>
[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-04.txt>, September 1999. pkix-time-stamp-06.txt>, 02 March 2000.
[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 page 49, line 37 skipping to change at page 50, line 14
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 Expires 10 September, 2000
 End of changes. 119 change blocks. 
403 lines changed or deleted 388 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/