< draft-ietf-pkix-roadmap-06.txt   draft-ietf-pkix-roadmap-07.txt >
PKIX Working Group A. Aresenault PKIX Working Group A. Aresenault
Internet Draft Diversinet Internet Draft Diversinet
Document: draft-ietf-pkix-roadmap-06.txt S. Turner Document: draft-ietf-pkix-roadmap-07.txt S. Turner
Category: Informational IECA Expires: July, 2002 IECA
Expires: May, 2001 November 2000 January 2002
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure: Roadmap
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.
Internet-Drafts are draft documents valid for a maximum of 6 months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or may become obsolete by other months and may be updated, replaced, or obsoleted by other documents
documents at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." 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 Internet-Draft Shadow Directories can be accessed at
accessed at http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire in May, 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. This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to ietf-smime-request@imc.org with the
single word subscribe in the body of the message. There is a Web
site for the mailing list at <http://www.imc.org/ietf-smime/>.
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, Privilege Management X.509-based Public Key Infrastructure, Privilege Management
Infrastructure (PMI), and Time Stamping and Data Certification Infrastructure (PMI), and Time Stamping and Data Certification
Infrastructures. It identifies each document developed by the PKIX Infrastructures. It identifies each document developed by the PKIX
working group, and describes the relationships among the various 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 about some of the issues discussed at length during PKIX development,
development, in hopes of making it easier to build implementations in hopes of making it easier to build implementations that will
that will actually interoperate. actually interoperate.
Aresenault, Turner November 2000 1 Turner 1
1 Introduction.....................................................3 Conventions used in this document
1.1 This Document..................................................3
1.2 Terminology....................................................3 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
1.3 History........................................................5 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1 INTRODUCTION.....................................................3
1.1 THIS DOCUMENT..................................................3
1.2 TERMINOLOGY....................................................4
1.3 HISTORY........................................................5
2 PKI..............................................................8 2 PKI..............................................................8
2.1 Theory.........................................................8 2.1 THEORY.........................................................8
2.2 Architecture Model.............................................9 2.2 ARCHITECTURE MODEL............................................10
2.3 Public Key Certificates.......................................11 2.3 PUBLIC KEY CERTIFICATES.......................................11
2.4 Functions of a PKI............................................12 2.4 FUNCTIONS OF A PKI............................................12
2.4.1 Registration................................................12 2.4.1 REGISTRATION................................................12
2.4.2 Initialization..............................................12 2.4.2 INITIALIZATION..............................................12
2.4.3 Certification...............................................12 2.4.3 CERTIFICATION...............................................13
2.4.4 Key Pair Recovery...........................................13 2.4.4 KEY PAIR RECOVERY...........................................13
2.4.5 Key Generation..............................................13 2.4.5 KEY GENERATION..............................................13
2.4.6 Key Update..................................................13 2.4.6 KEY UPDATE..................................................13
2.4.6.1 Key Expiry................................................13 2.4.6.1 KEY EXPIRY................................................13
2.4.6.2 Key Compromise............................................13 2.4.6.2 KEY COMPROMISE............................................14
2.4.7 Cross-certification.........................................14 2.4.7 CROSS-CERTIFICATION.........................................14
2.4.8 Revocation..................................................14 2.4.8 REVOCATION..................................................15
2.4.9 Certificate and Revocation Notice Distribution and Publication 2.4.9 CERTIFICATE & REVOCATION NOTICE DISTRIBUTION & PUBLICATION..16
..................................................................16
3 PMI.............................................................16 3 PMI.............................................................16
3.1 Theory........................................................16 3.1 THEORY........................................................16
3.2 Architectural Model...........................................17 3.2 ARCHITECTURAL MODEL...........................................17
3.3 Attribute Certificates........................................18 3.3 ATTRIBUTE CERTIFICATES........................................18
4 PKIX Documents..................................................19 4 PKIX DOCUMENTS..................................................19
4.1 Profiles......................................................19 4.1 PROFILES......................................................19
4.2 Operational Protocols.........................................22 4.2 OPERATIONAL PROTOCOLS.........................................22
4.3 Management Protocols..........................................25 4.3 MANAGEMENT PROTOCOLS..........................................25
4.4 Policy Outline................................................27 4.4 POLICY OUTLINE................................................27
4.4 Time Stamping and Data Certification..........................28 4.4 TIME STAMPING AND DATA CERTIFICATION..........................28
4.5 Expired Drafts................................................30 4.5 EXPIRED DRAFTS................................................30
5 Implementation Advice...........................................33 5 IMPLEMENTATION ADVICE...........................................34
5.1 Names.........................................................33 5.1 NAMES.........................................................35
5.1.1 Name Forms..................................................33 5.1.1 NAME FORMS..................................................35
5.1.1.1 Distinguished Names.......................................33 5.1.1.1 DISTINGUISHED NAMES.......................................35
5.1.1.2 SubjectAltName Forms......................................34 5.1.1.2 SUBJECTALTNAME FORMS......................................35
5.1.1.2.1 Internet e-mail addresses...............................35 5.1.1.2.1 INTERNET E-MAIL ADDRESSES...............................36
5.1.1.2.2 DNS Names...............................................35 5.1.1.2.2 DNS NAMES...............................................36
5.1.1.2.3 IP addresses............................................35 5.1.1.2.4 URIS....................................................37
5.1.1.2.4 URIs....................................................35 5.1.2 SCOPE OF NAMES..............................................37
5.1.2 Scope of Names..............................................36 5.1.3 CERTIFICATE PATH CONSTRUCTION...............................38
5.1.3 Certificate Path Construction...............................36 5.1.4 NAME CONSTRAINTS............................................39
5.1.4 Name Constraints............................................37 5.1.4.1 RFC822NAMES...............................................39
5.1.4.1 rfc822Names...............................................38 5.1.4.2 DNSNAMES..................................................40
5.1.4.2 dNSNames..................................................39 5.1.4.3 X.400 ADDRESSES...........................................40
5.1.4.3 x.400 addresses...........................................39 5.1.4.5 DNS.......................................................40
5.1.4.5 DNs.......................................................39
5.1.4.6 URIs......................................................40
5.1.4.7 iPaddresses...............................................40
5.1.4.8 Others....................................................40
Aresenault, Turner November, 2000 2 Arsenault, Turner 2
5.1.5 Wildcards in Name Forms.....................................40 5.1.4.6 URIS......................................................41
5.1.6 Name Encoding...............................................41 5.1.4.7 IPADDRESSES...............................................41
5.2 POP...........................................................41 5.1.4.8 OTHERS....................................................42
5.2.1 POP for Signing Keys........................................41 5.1.5 WILDCARDS IN NAME FORMS.....................................42
5.2.2 POP for Key Management Keys.................................42 5.1.6 NAME ENCODING...............................................42
5.3 Key Usage Bits................................................44 5.2 POP...........................................................43
5.4 Non-Repudiation...............................................46 5.2.1 POP FOR SIGNING KEYS........................................43
5.5 Trust Models..................................................46 5.2.2 POP FOR KEY MANAGEMENT KEYS.................................44
5.5.1 Hierarchical................................................46 5.3 KEY USAGE BITS................................................46
5.5.2 Local/Federation............................................46 5.4 NON-REPUDIATION...............................................47
5.5.3 Root Repository.............................................47 5.5 TRUST MODELS..................................................47
5.5.4 RP's Perspective............................................47 5.5.1 HIERARCHICAL................................................47
6 Acknowledgements................................................47 5.5.2 LOCAL/FEDERATION............................................48
7 References......................................................48 5.5.3 ROOT REPOSITORY.............................................48
8 Security Considerations.........................................51 5.5.4 RP'S PERSPECTIVE............................................49
9 Editor's Address................................................51 6 REFERENCES......................................................49
7 SECURITY CONSIDERATIONS.........................................52
8 ACKNOWLEDGEMENTS................................................52
9 AUTHOR'S ADDRESSES..............................................53
1 Introduction 1 Introduction
1.1 This Document 1.1 This Document
This document is an informational Internet-Draft that provides a This document is an informational Internet-Draft that provides a
"roadmap" to the documents produced by the PKIX working group. It is "roadmap" to the documents produced by the PKIX working group. It is
intended to provide information; there are no requirements or intended to provide information; there are no requirements or
specifications in this document. specifications in this document.
Section 1.2 of this document defines key terms used in this Section 1.2 of this document defines key terms used in this document.
document. Section 1.3 covers some of the basic history behind the Section 1.3 covers some of the basic history behind the PKIC working
PKIC working group. Section 2 covers Public Key Infrastructure (PKI) group. Section 2 covers Public Key Infrastructure (PKI) theory and
theory and functions. Section 3 covers Privilege Management functions. Section 3 covers Privilege Management Infrastructure (PMI)
Infrastructure (PMI) theory and functions. Sections 2 through 5 theory and functions. Sections 2 through 5 attempts to explain the
attempts to explain the PKIX working group's basic assumptions in PKIX working group's basic assumptions in each of the areas. Section
each of the areas. Section 4 provides an overview of the various 4 provides an overview of the various PKIX documents. It identifies
PKIX documents. It identifies which documents address which areas, which documents address which areas, and describes the relationships
and describes the relationships among the various documents. Section among the various documents. Section 5 contains "Advice to
5 contains "Advice to implementors." Its primary purpose is to implementors." Its primary purpose is to capture some of the major
capture some of the major issues discussed by the PKIX working issues discussed by the PKIX working group, as a way of explaining
group, as a way of explaining WHY some of the requirements and WHY some of the requirements and specifications say what they say.
specifications say what they say. This should cut down on the number This should cut down on the number of misinterpretations of the
of misinterpretations of the documents, and help developers build documents, and help developers build interoperable implementations.
interoperable implementations. Section 6 contains a list of Section 6 contains a list of contributors we wish to thank. Section 7
contributors we wish to thank. Section 7 provides a list references. provides a list references. Section 8 discusses security
Section 8 discusses security considerations, and Section 9 provides considerations, and Section 9 provides contact information for the
contact information for the editors. Finally, Section 10 provides a editors. Finally, Section 10 provides a disclaimer.
disclaimer.
Arsenault, Turner 3
1.2 Terminology 1.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,
PMI-related, and Time Stamp and Data Certification literature. To PMI-related, and Time Stamp and Data Certification literature. To
Aresenault, Turner November, 2000 3
limit confusion caused by some of those terms, used throughout this limit confusion caused by some of those terms, used throughout this
document, we will use the following terms in the following ways: document, we will use the following 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
to note that the AA is responsible for the attribute certificates to note that the AA is responsible for the attribute
during their whole lifetime, not just for issuing them. certificates during their whole lifetime, not just for issuing
them.
- Attribute Certificate (AC) - A data structure containing a set of - Attribute Certificate (AC) - A data structure containing a set of
attributes for an end-entity and some other information, which is attributes for an end-entity and some other information, which
digitally signed with the private key of the AA which issued it. is digitally signed with the private key of the AA which issued
it.
- Certificate - Can refer to either an AC or a public key - Certificate - Can refer to either an AC or a public key
certificate. Where there is no distinction made the context certificate. Where there is no distinction made the context
should be assumed that the term could apply to both an AC or a should be assumed that the term could apply to both an AC or a
public key certificate. public key 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 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
authentication of electronic data interchange transactions for the authentication of electronic data interchange transactions
the trading of goods within a given price range. for 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
PMI.) the PMI.)
- Public Key Certificate (PKC) - A data structure containing the - Public Key Certificate (PKC) - A data structure containing the
public key of an end-entity and some other information, which is public key of an end-entity and some other information, which is
digitally signed with the private key of the CA which issued it. digitally signed with the private key of the CA which issued it.
- Public Key Infrastructure (PKI) - The set of hardware, software, - Public Key Infrastructure (PKI) - The set of hardware, software,
people, policies and procedures needed to create, manage, store, people, policies and procedures needed to create, manage, store,
distribute, and revoke PKCs based on public-key cryptography. distribute, and revoke PKCs based on public-key cryptography.
- Privilege Management Infrastructure (PMI) - A collection of ACs, Arsenault, Turner 4
with their issuing AA's, subjects, relying parties, and - Privilege Management Infrastructure (PMI) - A collection of ACs,
repositories, is referred to as a Privilege Management with their issuing AA's, subjects, relying parties, and
Infrastructure. repositories, is referred to as a Privilege Management
Infrastructure.
Aresenault, Turner November, 2000 4 - Registration Authority (RA) - An optional entity given
- Registration Authority (RA) - An optional entity given responsibility for performing some of the administrative tasks
responsibility for performing some of the administrative tasks necessary in the registration of subjects, such as: confirming
necessary in the registration of subjects, such as: confirming the subject's identity; validating that the subject is entitled
the subject's identity; validating that the subject is entitled to have the values requested in a PKC; and verifying that the
to have the values requested in a PKC; and verifying that the subject has possession of the private key associated with the
subject has possession of the private key associated with the public key requested for a PKC.
public key requested for a PKC.
- Relying party - A user or agent (e.g., a client or server) who - Relying party - A user or agent (e.g., a client or server) who
relies on the data in a certificate in making decisions. relies on the data in a certificate in making decisions.
- Root CA - A CA that is directly trusted by an EE; that is, - Root CA - A CA that is directly trusted by an EE; that is,
securely acquiring the value of a Root CA public key requires securely acquiring the value of a Root CA public key requires
some out-of-band step(s). This term is not meant to imply that a some out-of-band step(s). This term is not meant to imply that a
Root CA is necessarily at the top of any hierarchy, simply that Root CA is necessarily at the top of any hierarchy, simply that
the CA in question is trusted directly. the CA in question is trusted directly.
- Subordinate CA - A "subordinate CA" is one that is not a Root CA - Subordinate CA - A "subordinate CA" is one that is not a Root CA
for the EE in question. Often, a subordinate CA will not be a 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, either a PKC or AC. Subjects can be human users, certificate, either a PKC or AC. Subjects can be human users,
computers (as represented by Domain Name Service (DNS) names or computers (as represented by Domain Name Service (DNS) names or
Internet Protocol (IP) addresses), or even software agents. Internet Protocol (IP) addresses), or even software agents.
- Time Stamp Authority (TSA) - A TSA is a trusted Third Party who - Time Stamp Authority (TSA) - A TSA is a trusted Third Party who
provides a "proof-of-existence" for a particular datum at an provides a "proof-of-existence" for a particular datum at an
instant in time. instant in time.
- 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," since in data Note: This is often also called a "Root CA," since in data structures
structures terms and in graph theory, the node at the top of a terms and in graph theory, the node at the top of a tree is the
tree is the "root." However, to minimize confusion in this "root." However, to minimize confusion in this document, we elect to
document, we elect to call this node a "Top CA," and reserve call this node a "Top CA," and reserve "Root CA" for the CA directly
"Root CA" for the CA directly trusted by the EE. Readers new to trusted by the EE. Readers new to PKIX should be aware that these
PKIX should be aware that these terms are not used consistently terms are not used consistently throughout the PKIX documents, as the
throughout the PKIX documents, as [FORMAT] uses "Root CA" to Internet PKI profile [2459bis] uses "Root CA" to refer to what this
refer to what this and other documents call a "Top CA," and and other documents call a "Top CA," and "most-trusted CA" to refer
"most-trusted CA" to refer to what this and other documents call to what this and other documents call a "Root CA."
a "Root CA."
1.3 History 1.3 History
The PKIX working group was formed in October of 1995 to develop The PKIX working group was formed in October of 1995 to develop
Internet standards necessary to support PKIs. The first work item Internet standards necessary to support PKIs. The first work item was
was a profile of the ITU-T Recommendation X.509 PKC. X.509, which is a profile of the ITU-T Recommendation X.509 PKC. X.509, which is a
a widely accepted basis for a PKI, including data formats and
Arsenault, Turner 5
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
Aresenault, Turner November, 2000 5
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. The fields, for any of the extensions, nor for certain data values. The
Internet PKI profile [FORMAT] went through eleven draft versions Internet PKI profile [2459bis] went through eleven draft versions
before becoming an RFC. Other profiles have been developed in PKIX before becoming an RFC. Other profiles have been developed in PKIX
for particular algorithms to make use of [FORMAT]. There has been no for particular algorithms to make use of the Internet PKI Profile
sense of conflict between the authors that developed these profiles [2459bis]. There has been no sense of conflict between the authors
as they are seen as complimentary. The Internet PKI profile has been that developed these profiles as they are seen as complimentary. The
a draft standard for more than six months and is currently going Internet PKI profile has been a draft standard for more than six
through an update process to clarify any inconsistencies and to months and is currently going through an update process to clarify
bolster certain sections. any inconsistencies and to bolster certain sections.
In parallel with the profile development, work was undertaken to In parallel with the profile development, work was undertaken to
develop the protocols necessary to manage PKI-related information develop the protocols necessary to manage PKI-related information
was. The first developed was the Certificate Management Protocol was. The first developed was the Certificate Management Protocol
(CMP). It defines a message protocol to initializing, certifying, (CMP). It defines a message protocol to initializing, certifying,
updating, and revoking PKI entities [CMP]. The demand for an updating, and revoking PKI entities [CMP]. The demand for an
enrollment protocol and the desire to use PKCS-10 message format as enrollment protocol and the desire to use PKCS-10 message format as
the certificate request syntax lead to the development of two the certificate request syntax lead to the development of two
different documents in two different groups. The Certificate Request different documents in two different groups. The Certificate Request
Syntax (CRS) draft was developed in the SMIME WG which used PKCS-10 Syntax (CRS) draft was developed in the SMIME WG which used PKCS-10
[PKCS10] as the certification request message format. Certificate [PKCS10] as the certification request message format. Certificate
Request Message Format [CRMF] draft was also developed but in the Request Message Format [CRMF] draft was also developed but in the
PKIX WG. It was to define a simple enrollment protocol that would PKIX WG. It was to define a simple enrollment protocol that would
subsume both the CMP and CRS enrollment protocols, but it did not subsume both the CMP and CRS enrollment protocols, but it did not use
use PKCS-10 as the certificate request message format. Then the PKCS-10 as the certificate request message format. Then the
certificate management message format document, was developed to certificate management message format document, was developed to
define an extended set of management messages that flow between the define an extended set of management messages that flow between the
components of the Internet PKI. Certificate Management Messages over components of the Internet PKI. Certificate Management Messages over
CMS (CMC) was developed to allow the use of an existing protocol CMS (CMC) was developed to allow the use of an existing protocol
(S/MIME) as a PKI management protocol, without requiring the (S/MIME) as a PKI management protocol, without requiring the
development of an entirely new protocol such as CMP [CMC]. It also development of an entirely new protocol such as CMP [CMC]. It also
included [PKCS10] as the certificate request syntax, which caused included [PKCS10] as the certificate request syntax, which caused
work on the CRS draft to stop. Information from the certificate work on the CRS draft to stop. Information from the certificate
management message format document was moved into [CMP] and [CMC] so management message format document was moved into [CMP] and [CMC] so
work on the certificate management message format document was work on the certificate management message format document was
skipping to change at line 308 skipping to change at line 310
drafts, one for using HTTP as the transport protocol and one for drafts, one for using HTTP as the transport protocol and one for
Transmission Control Protocol (TCP), were written to solve problems Transmission Control Protocol (TCP), were written to solve problems
encountered by implementors. These drafts were merged into one draft encountered by implementors. These drafts were merged into one draft
Transport Protocols for CMP [TPCMP]. [CMP] has been a draft standard Transport Protocols for CMP [TPCMP]. [CMP] has been a draft standard
for more than six months and is currently undergoing revisions to for more than six months and is currently undergoing revisions to
document. The transport section has been removed and will remain in document. The transport section has been removed and will remain in
[TPCMP]. [TPCMP].
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, but uses CMS as the encapsulating requests for CRL messages, but uses CMS as the encapsulating
protocol. [OCSP] was developed to address concerns that not all
Aresenault, Turner November, 2000 6 Arsenault, Turner 6
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 verification to another entity [SCVP]. The WG was arguably split over
over whether such a function should be supported and whether it whether such a function should be supported and whether it should be
should be its own protocol or included in OCSP. In response, a draft its own protocol or included in OCSP. In response, a draft defining
defining OCSP Extensions was produced to include the functions of OCSP Extensions was produced to include the functions of SCVP. [OCSP]
SCVP. [OCSP] has been a draft standard for more than six months and has been a draft standard for more than six months and is in the
is in the process of being revised [OCSPv2]. To capture the work process of being revised [OCSPv2]. To capture the work from the OCSP
from the OCSP Extensions, two drafts have been developed: Delegated Extensions, two drafts were developed: Delegated Path Validation
Path Validation [DPV] and Delegated Path Discovery [DPD]. One other [DPV] and Delegated Path Discovery [DPD]. After considerable debate,
draft called Open CRL Distribution Point (OCDP) was produced which the WG selected SCVP as the PKIX protocol for delegated path
documented two extensions: one to support an alternative CRL validation and delegated path discovery. A requirements document has
partitioning mechanism to the CRL Distribution Point mechanism been developed, and is currently under WG review. [DPREQ] Upon
documented in [FORMAT] and one to support identifying other completion of [DPREQ], the SCVP protocol will be completed.
revocation sources available to certificate-users. The work from
this draft was subsumed by an ITU-T | ISO/IEC Amendment to X.509, One other certificate status draft called Open CRL Distribution Point
hence work on this draft was halted. (OCDP) was produced which documented two extensions: one to support
an alternative CRL partitioning mechanism to the CRL Distribution
Point mechanism documented in the Internet PKI Profile [2459bis] and
one to support identifying other revocation sources available to
certificate-users. The work from this draft was subsumed by an ITU-T
| ISO/IEC Amendment to X.509, hence work on this draft was halted.
Development of the operational protocols has been slightly more Development of the operational protocols has been slightly more
straightforward. Four documents for the Light Weight Directory straightforward. Four documents for the Light Weight Directory Access
Access Protocol (LDAP) have been developed one for defining LDAPv2 Protocol (LDAP) have been developed one for defining LDAPv2 as an
as an access protocol to repositories [PKI-LDAPv2]; two for storing access protocol to repositories [PKI-LDAPv2]; two for storing PKI
PKI information in an directory [SCHEMA] and [ADDSCHEMA]; and one information in an directory [SCHEMA] and [ADDSCHEMA]; and one for
for LDAPv3 requirements for PKI [PKI-LDAPv3]. Using the File LDAPv3 requirements for PKI [PKI-LDAPv3]. Using the File Transfer
Transfer Protocol (FTP) and the Hyper Text Transmission Protocol Protocol (FTP) and the Hyper Text Transmission Protocol (HTTP) to
(HTTP) to retrieve PKCs and CRLs from PKI repositories was retrieve PKCs and CRLs from PKI repositories was documented in
documented in [FTPHTTP]. Recognizing that LDAP directories are not [FTPHTTP]. Recognizing that LDAP directories are not the only
the only repository service, the working group draft a Repository repository service, the working group draft a Repository Locator
Locator Service [RLS] to make use of DNS SRV records to locate where Service [RLS] to make use of DNS SRV records to locate where and how
and how PKI information can be retrieved from a repository. PKI information can be retrieved from a repository.
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 time stamping and data certification services. [TSP] was developed to
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. [DVCS] (TSA) who asserts that a datum existed at a given time. [DVCS] allows
allows to verify and assert the validity of all signatures attached to verify and assert the validity of all signatures attached to the
to the signed document using all appropriate status information and signed document using all appropriate status information and PKCs or
PKCs or to verify and assert the validity of one or more PKCs at the to verify and assert the validity of one or more PKCs at the
specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating
(though in [TSP] request for a time stamp are not required to use (though in [TSP] request for a time stamp are not required to use
[CMS]). A draft for extending trust in tokens in time was developed [CMS]). A draft for extending trust in tokens in time was developed
to use [DCVS] to maintain the trust in a token issued by a non- to use [DCVS] to maintain the trust in a token issued by a non-
repudiation Trusted Third Party (NR TTP) after the key initially repudiation Trusted Third Party (NR TTP) after the key initially used
used to establish trust in the token expires; however, this draft
has expired. The [TRNRS] draft was developed to describe those
features of a service which processes signed documents that must be
Aresenault, Turner November, 2000 7 Arsenault, Turner 7
present in order for that service to constitute a "technical non- to establish trust in the token expires; however, this draft has
repudiation" service. expired. The [TRNRS] draft was developed to describe those features
of a service which processes signed documents that must be present in
order for that service to constitute a "technical non- repudiation"
service.
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 and role-based access control decisions. Two support rule-based and role-based access control decisions. Two
drafts have since been developed: the Internet Attribute drafts have since been developed: the Internet Attribute Certificates
Certificates Profile for Authorizations [AC] and the Limited Profile for Authorizations [AC] and the Limited Attribute Certificate
Attribute Certificate Acquisition Protocol [LAAP]. The first Acquisition Protocol [LAAP]. The first profiles the fields and
profiles the fields and extensions of the AC and the second provides extensions of the AC and the second provides a deliberately limited
a deliberately limited protocol to access a repository when LDAP is 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
mechanism to Diffie-Hellam key pairs to issue a PKCS-10 to use Diffie-Hellam key pairs to authenticate a PKCS-10
certification request. [REP] was developed during the revision to certification request. [REP] was developed during the revision to the
[FORMAT] to separate the definitions of the object identifiers and Internet PKI Profile [2459bis] to separate the definitions of the
encoding rules for keys and digital signatures in PKCs. The object identifiers and encoding rules for keys and digital signatures
Qualified Certificates [QC] and Permanent Identifier [PI] drafts in PKCs. The Qualified Certificates [QC] and Permanent Identifier
were developed to address naming issues. [PI] drafts were developed to address naming issues.
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.
2 PKI 2 PKI
2.1 Theory 2.1 Theory
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 group of security protocols such as Secure Multipurpose Internet Mail
Mail Extensions (S/MIME), Transport Layer Security (TLS), and Extensions (S/MIME), Transport Layer Security (TLS), and Internet
Internet Protocol Security (IPSec). All of these protocols rely on Protocol Security (IPSec). All of these protocols rely on public-key
public-key cryptography to provide services such as confidentiality, cryptography to provide services such as confidentiality, data
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 subject that they are communicating they rely on a public key, the subject that they are communicating
with owns the associated private key, this applies whether an with owns the associated private key, this applies whether an
encryption or digital signature mechanism is used. This confidence encryption or digital signature mechanism is used. This confidence is
is obtained through the use of PKCs, which are data structures that obtained through the use of PKCs, which are data structures that bind
bind public key values to subjects. The binding is achieved by public key values to subjects. The binding is achieved by having a
having a trusted CA verify the subject's identity and digitally sign trusted CA verify the subject's identity and digitally sign each PKC.
each PKC.
Aresenault, Turner November, 2000 8 Arsenault, Turner 8
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
must be made; implementors are free to implement them in the most
efficient way for their systems.
Note: there is no specific order in which the checks listed below - The recipient of signed data verifies that the claimed identity
must be made; implementors are free to implement them in the most of the user is in accordance with the identity contained in the
efficient way for their systems. PKC;
- The recipient of signed data verifies that the claimed identity
of the user is in accordance with the identity contained in the
PKC;
- The recipient validates that no PKC in the path is revoked (e.g., - The recipient validates that no PKC in the path is revoked (e.g.,
by retrieving a suitably-current Certificate Revocation List by retrieving a suitably-current Certificate Revocation List
(CRL) or querying an on-line certificate status responder), and (CRL) or querying an on-line certificate status responder), and
that all PKCs are within their validity periods at the time the that all PKCs are within their validity periods at the time the
data was signed; data was signed;
- The recipient verifies that the data are not claimed to have any - The recipient verifies that the data are not claimed to have any
values for which the PKC indicates that the signer is not values for which the PKC indicates that the signer is not
authorized; authorized;
- The recipient verifies that the data have not been altered since - The recipient verifies that the data have not been altered since
signing, by using the public key in the PKC. signing, by using the public key in the PKC.
- If all of these checks pass, the recipient can accept that the - If all of these checks pass, the recipient can accept that the
data was signed by the purported signer. The process for keys data was signed by the purported signer. The process for keys
used for encryption is similar. used for encryption is similar.
Note: It is of course possible that the data was signed by Note: It is of course possible that the data was signed by someone
someone very different from the signer, if for example the very different from the signer, if for example the purported signer's
purported signer's private key was compromised. Security depends private key was compromised. Security depends on all parts of the
on all parts of the certificate-using system, including but not certificate-using system, including but not limited to: physical
limited to: physical security of the place the computer resides; security of the place the computer resides; personnel security (i.e.,
personnel security (i.e., the trustworthiness of the people who the trustworthiness of the people who actually develop, install, run,
actually develop, install, run, and maintain the system); the and maintain the system); the security provided by the operating
security provided by the operating system on which the private system on which the private key is used; and the security provided
key is used; and the security provided the CA. A failure in any the CA. A failure in any one of these areas can cause the entire
one of these areas can cause the entire system security to fail. system security to fail. PKIX is limited in scope, however, and only
PKIX is limited in scope, however, and only directly addresses directly addresses issues related to the operation of the PKI
issues related to the operation of the PKI subsystem. For subsystem. For guidance in many of the other areas, see [POLPROC].
guidance in many of the other areas, see [POLPROC].
Arsenault, Turner 9
2.2 Architecture Model 2.2 Architecture Model
Aresenault, Turner November, 2000 9
A PKI is defined as: A PKI is defined as:
The set of hardware, software, people, policies and procedures The set of hardware, software, people, policies and procedures needed
needed to create, manage, store, distribute, and revoke PKCs based to create, manage, store, distribute, and revoke PKCs based on
on public-key cryptography. public-key cryptography.
A PKI consists of five types of components [MISPC]: A PKI consists of five types of components [MISPC]:
- Certification Authorities (CAs) that issue and revoke PKCs; - Certification Authorities (CAs) that issue and revoke PKCs;
- Organizational Registration Authorities (ORAs) that vouch for the - Organizational Registration Authorities (ORAs) that vouch for the
binding between public keys and certificate holder identities and binding between public keys and certificate holder identities
other attributes; and other attributes;
- PKC holders that are issued certificates and can sign digital - PKC holders that are issued certificates and can sign digital
documents and encrypt documents; documents and encrypt documents;
- Clients that validate digital signatures and their certification - Clients that validate digital signatures and their certification
paths from a known public key of a trusted CA; paths from a known public key of a trusted CA;
- Repositories that store and make available PKCs and Certificate - Repositories that store and make available PKCs and Certificate
Revocation Lists (CRLs). Revocation Lists (CRLs).
Figure 1 is a simplified view of the architectural model assumed by Figure 1 is a simplified view of the architectural model assumed by
the PKIX Working Group. the PKIX Working Group.
Aresenault, Turner November, 2000 10 Arsenault, Turner 10
+---+ +---+ cert. publish +------------+
| C | +------------+ | | <--------------------- | End Entity | <-------
| e | <-------------------->| End entity | | C | +------------+ "out-of-band"
| r | Operational +------------+ | | | ^ loading
| t | transactions ^ | e | | | initial
| | and management | Management | r | | | registration/
| / | transactions | transactions | t | | | certification
| | | PKI users | | | | key pair recovery
| C | v | / | | | key pair update
| R | -------------------+--+-----------+-------------- | | | | certificate update
| L | ^ ^ PKI | C | PKI "USERS" V | revocation request
| | | | management | R | -------------------+-+-----+-+------+-+-------------------
| | v | entities | L | PKI MANAGEMENT | ^ | ^
| R | +------+ | | | ENTITIES | | | |
| e | <---------------------| RA | <---+ | | | V | | |
| p | Publish certificate +------+ | | | R | +------+ | |
| o | | | | e | <------------ | RA | <-----+ | |
| s | | | | p | cert. | | ----+ | | |
| I | v v | o | publish +------+ | | | |
| t | +------------+ | s | | | | |
| o | <------------------------------| CA | | i | V | V |
| r | Publish certificate +------------+ | t | +------------+
| y | Publish CRL ^ | o | <------------------------| CA |------->
| | | | r | +------------+ "out-of-band"
+---+ Management | | y | cert. publish | ^ publication
transactions | | | CRL publish | |
v +---+ | | cross-certification
+------+ | | cross-certificate
| CA | | | update
+------+ | |
Figure 1 - PKI Entities V |
+------+
| CA-2 |
+------+
Figure 1 - PKI Entities
2.3 Public Key Certificates 2.3 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 PKC format [X.509]. The PKC recommendations, defines a standard PKC format [X.509]. The PKC
format in the 1988 standard is called the version 1 (v1) format. format in the 1988 standard is 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,
subjectUniqueIdentifier and issuerUniqueIdentifier were added, subjectUniqueIdentifier and issuerUniqueIdentifier were added,
resulting in the version 2 (v2) format. These two fields may be used resulting in the version 2 (v2) format. These two fields may be used
to support 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 include specifications for a public key infrastructure based on X.509
X.509 v1 public key certificates [PEM]. The experience gained in v1 public key certificates [PEM]. The experience gained in attempts
attempts to deploy [PEM] made it clear that the v1 and v2 public key
Arsenault, Turner 11
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
Aresenault, Turner November, 2000 11
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 response to these new requirements, ISO|IEC, ITU, and ANSI X9
developed the X.509 version 3 (v3) PKC format. The v3 format extends developed the X.509 version 3 (v3) PKC format. The v3 format extends
the v2 format by adding provision for additional extension fields. the v2 format by adding provision for additional extension fields.
Particular extension field types may be specified in standards or Particular extension field types may be specified in standards or may
may be defined and registered by any organization or community. In be defined and registered by any organization or community. In June
June 1996, standardization of the basic v3 format was completed 1996, standardization of the basic v3 format was completed [X.509].
[X.509].
ISO|IEC, ITU, and ANSI X9 have also developed standard extensions ISO|IEC, ITU, and ANSI X9 have also developed standard extensions for
for use in the v3 extensions field [X.509][X9.55]. These extensions use in the v3 extensions field [X.509][X9.55]. These extensions can
can convey such data as additional subject identification convey such data as additional subject identification information,
information, key attribute information, policy information, and key attribute information, policy information, and certification path
certification path constraints. However, the ISO/IEC/ITU and ANSI X9 constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions
standard extensions are very broad in their applicability. In order are very broad in their applicability. In order to develop
to develop interoperable implementations of X.509 v3 systems for interoperable implementations of X.509 v3 systems for Internet use,
Internet use, it is necessary to specify a profile for use of the it is necessary to specify a profile for use of the X.509 v3
X.509 v3 extensions tailored for the Internet. It is one goal of extensions tailored for the Internet. It is one goal of PKIX to
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.
2.4 Functions of a PKI 2.4 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.
2.4.1 Registration 2.4.1 Registration
skipping to change at line 596 skipping to change at line 603
attributes are correct. attributes are correct.
2.4.2 Initialization 2.4.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 or PKC of a CA, or generating the client system's own the public key or PKC of a CA, or generating the client system's own
public-private key pair. public-private key pair.
Arsenault, Turner 12
2.4.3 Certification 2.4.3 Certification
This is the process in which a CA issues a PKC for a subject's This is the process in which a CA issues a PKC for a subject's public
public key, and returns that PKC to the subject or posts that PKC in key, and returns that PKC to the subject or posts that PKC in a
a repository. repository.
Aresenault, Turner November, 2000 12
2.4.4 Key Pair Recovery 2.4.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 that can be lost or exchange key is stored on a hardware token that can be lost or
broken, or when a private key file is protected by a password which broken, or when a private key file is protected by a password which
can be forgotten. Often, a company is concerned about being able to can be forgotten. Often, a company is concerned about being able to
read mail encrypted by or for a particular employee when that read mail encrypted by or for a particular employee when that
employee is no longer available because she is ill or no longer employee is no longer available because she is ill or no longer works
works for the company. for the company.
In these cases, the user's private key can be backed up by a CA or In these cases, the user's private key can be backed up by a CA or by
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.
2.4.5 Key Generation 2.4.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 PC card). card or PC card).
2.4.6 Key Update 2.4.6 Key Update
All key pairs need to be updated regularly (i.e., replaced with a All key pairs need to be updated regularly (i.e., replaced with a new
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
exceptionally, when a key has been compromised and must be replaced. exceptionally, when a key has been compromised and must be replaced.
2.4.6.1 Key Expiry 2.4.6.1 Key Expiry
In the normal case, a PKI needs to provide a facility to gracefully In the normal case, a PKI needs to provide a facility to gracefully
transition from a PKC with an existing key to a new PKC with a new transition from a PKC with an existing key to a new PKC with a new
key. This is particularly true when the key to be updated is that of key. This is particularly true when the key to be updated is that of
a CA. Users will know in advance that the key will expire on a a CA. Users will know in advance that the key will expire on a
certain date; the PKI, working together with PKC-using applications, certain date; the PKI, working together with PKC-using applications,
should allow for appropriate keys to work before and after the should allow for appropriate keys to work before and after the
Arsenault, Turner 13
transition. There are a number of ways to do this; see [CMP] for an transition. There are a number of ways to do this; see [CMP] for an
example of one. example of one.
2.4.6.2 Key Compromise 2.4.6.2 Key Compromise
In the case of a key compromise, the transition will not be In the case of a key compromise, the transition will not be
"graceful" in that there will be an unplanned switch of PKCs and "graceful" in that there will be an unplanned switch of PKCs and
keys; users will not have known in advance what was about to happen. keys; users will not have known in advance what was about to happen.
Aresenault, Turner November, 2000 13
Still, the PKI must support the ability to declare that the previous Still, the PKI must support the ability to declare that the previous
PKC is now invalid and shall not be used, and to announce the PKC is now invalid and shall not be used, and to announce the
validity and availability of the new PKC. validity and availability of the new PKC.
Note: compromise of a private key associated with a Root CA is Note: compromise of a private key associated with a Root CA is
catastrophic for users relying on that Root CA. If a Root CA's catastrophic for users relying on that Root CA. If a Root CA's
private key is compromised, that CA's PKC must be revoked and all private key is compromised, that CA's PKC must be revoked and all
PKCs subordinate to it must also be revoked. Until such time as PKCs subordinate to it must also be revoked. Until such time as the
the Root CA has been issued a new PKC and the Root CA issues PKCs Root CA has been issued a new PKC and the Root CA issues PKCs to
to users relying upon it, users relying on that Root CA are cut users relying upon it, users relying on that Root CA are cut off from
off from the rest of the system, as there is no way to develop a the rest of the system, as there is no way to develop a valid
valid certification path back to a trusted node. certification path back to a trusted node.
Further, users will likely have to be notified by out-of-band Further, users will likely have to be notified by out-of-band
mechanisms about the change in CA keys. If the old key is mechanisms about the change in CA keys. If the old key is
compromised, any "update" message telling subordinates to switch to compromised, any "update" message telling subordinates to switch to a
a new key could have come from an attacker in possession of the old new key could have come from an attacker in possession of the old
key, and could point to a new public key for which the attacker key, and could point to a new public key for which the attacker
already has the private key. It is possible to have anticipated this already has the private key. It is possible to have anticipated this
event, and "pre-placed" replacement Root CA keys with all relying event, and "pre-placed" replacement Root CA keys with all relying
parties, but some secure, out-of-band mechanism will have to be used parties, but some secure, out-of-band mechanism will have to be used
to tell users to make the switch, and this will only help if the to tell users to make the switch, and this will only help if the
replacement key has not been compromised. replacement key has not been compromised.
Additionally, once the Root CA is brought back up with a new key, it Additionally, once the Root CA is brought back up with a new key, it
will likely be necessary to re-issue 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.
2.4.7 Cross-certification 2.4.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 contains a public CA key associated with the private CA signature key
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 or end entities in one administrative domain to allow client systems or end entities in one administrative domain to
communicate securely with client systems or 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 administrative domain. Use of a cross-certificate issued from CA_1 to
to CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
Bob, which was issued by CA_2. Cross-certificates can also be issued which was issued by CA_2. Cross-certificates can also be issued from
from one CA to another CA in the same administrative domain, if one CA to another CA in the same administrative domain, if required.
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
Arsenault, Turner 14
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.
2.4.8 Revocation 2.4.8 Revocation
When a PKC is issued, it is expected to be in use for its entire When a PKC is issued, it is expected to be in use for its entire
validity period. However, various circumstances may cause a PKC to validity period. However, various circumstances may cause a PKC to
Aresenault, Turner November, 2000 14
become invalid prior to the expiration of the validity period. Such become invalid prior to the expiration of the validity period. Such
circumstances include change of name, change of association between circumstances include change of name, change of association between
subject and CA (e.g., an employee terminates employment with an subject and CA (e.g., an employee terminates employment with an
organization), and compromise or suspected compromise of the organization), and compromise or suspected compromise of the
corresponding private key. Under such circumstances, the CA needs to corresponding private key. Under such circumstances, the CA needs to
revoke the PKC. revoke the PKC.
X.509 defines one method of PKC revocation. This method involves X.509 defines one method of PKC revocation. This method involves each
each CA periodically issuing a signed data structure called a CA periodically issuing a signed data structure called a certificate
certificate revocation list (CRL). A CRL is a time stamped list revocation list (CRL). A CRL is a time stamped list identifying
identifying revoked PKCs that is signed by a CA and made freely revoked PKCs that is signed by a CA and made freely available in a
available in a public repository. Each revoked PKC is identified in public repository. Each revoked PKC is identified in a CRL by its PKC
a CRL by its PKC serial number. When a certificate-using system uses serial number. When a certificate-using system uses a PKC, that
a PKC, that system not only checks the PKC signature and validity system not only checks the PKC signature and validity but also
but also acquires a suitably recent CRL and checks that the PKC acquires a suitably recent CRL and checks that the PKC serial number
serial number is not on that CRL. The meaning of "suitably recent" is not on that CRL. The meaning of "suitably recent" may vary with
may vary with local policy, but it usually means the most recently local policy, but it usually means the most recently issued CRL. A CA
issued CRL. A CA issues a new CRL on a regular periodic basis (e.g., issues a new CRL on a regular periodic basis (e.g., hourly, daily, or
hourly, daily, or weekly). CA's may also issue CRLs aperiodically. weekly). CA's may also issue CRLs aperiodically. For example, if an
For example, if an important key is deemed compromised, the CA may important key is deemed compromised, the CA may issue a new CRL to
issue a new CRL to expedite notification of that fact, even if the expedite notification of that fact, even if the next CRL does not
next CRL does not have to be issued for some time. (A problem of have to be issued for some time. (A problem of aperiodic CRL issuance
aperiodic CRL issuance is that end-entities may not know that a new is that end-entities may not know that a new CRL has been issued, and
CRL has been issued, and thus may not retrieve it from a thus may not retrieve it from a repository.)
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 revoked PKC's validity period. Leaving the revoked PKC on the CRL for
for this extra period allows for PKCs that are revoked prior to this extra period allows for PKCs that are revoked prior to issuing a
issuing a new CRL and whose invalidity date falls before the CRL new CRL and whose invalidity date falls before the CRL issuing time
issuing time to be accounted for. If the revoked PKC is not retained to be accounted for. If the revoked PKC is not retained on the CRL
on the CRL for this extra period then the possibility arises that a for this extra period then the possibility arises that a revoked PKC
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, distributed by exactly the same means as PKCs themselves, namely, via
via untrusted communications and server systems. untrusted communications and server systems.
One limitation of the CRL revocation method, using untrusted One limitation of the CRL revocation method, using untrusted
communications and servers, is that the time granularity of communications and servers, is that the time granularity of
revocation is limited to the CRL issue period. For example, if a revocation is limited to the CRL issue period. For example, if a
revocation is reported now, that revocation will not be reliably revocation is reported now, that revocation will not be reliably
notified to certificate-using systems until the next CRL is issued, notified to certificate-using systems until the next CRL is issued,
Arsenault, Turner 15
which may be up to one hour, one day, or one week depending on the which may be up to one hour, one day, or one week depending on the
frequency that the CA issues CRLs. frequency that the CA issues CRLs.
As with the X.509 v3 PKC format, in order to facilitate As with the X.509 v3 PKC format, in order to facilitate interoperable
interoperable implementations from multiple vendors, the X.509 v2 implementations from multiple vendors, the X.509 v2 CRL format needed
CRL format needed to be profiled for Internet use. This was done as to be profiled for Internet use. This was done as part of the
Internet PKI Profile [2459bis]. However, PKIX does not require CAs to
Aresenault, Turner November, 2000 15 issue CRLs. On-line methods of revocation notification may be
part of [FORMAT]. However, PKIX does not require CAs to issue CRLs. applicable in some environments as an alternative to the X.509 CRL.
On-line methods of revocation notification may be applicable in some PKIX defines a few protocols that support on-line checking. [OCSP],
environments as an alternative to the X.509 CRL. PKIX defines a few [DVCS], and [SCVP] all support on-line checking of the status of
protocols that support on-line checking. [OCSP], [DVCS], and [SCVP] PKCs.
all support on-line checking of the status of PKCs.
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.
2.4.9 Certificate and Revocation Notice Distribution and Publication 2.4.9 Certificate & Revocation Notice Distribution & Publication
As alluded to in sections 2.1 and 2.5.8 above, the PKI is As alluded to in sections 2.1 and 2.5.8 above, the PKI is responsible
responsible for the distribution of PKCs and PKC revocation notices for the distribution of PKCs and PKC revocation notices (whether in
(whether in CRL form or in some other form) in the system. CRL form or in some other form) in the system. "Distribution" of PKCs
"Distribution" of PKCs includes transmission of the PKC to its includes transmission of the PKC to its owner, and may also include
owner, and may also include publication of the PKC in a repository. publication of the PKC in a repository. "Distribution" of revocation
"Distribution" of revocation notices may involve posting CRLs in a notices may involve posting CRLs in a repository, transmitting them
repository, transmitting them to end-entities, or forwarding them to to end-entities, or forwarding them to on-line responders.
on-line responders.
3 PMI 3 PMI
3.1 Theory 3.1 Theory
Many systems use 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 and role-based access systems are beginning to find that rule-based and role-based access
control is required. These forms of access control decisions require control is required. These forms of access control decisions require
additional information that is normally not included in a PKC, additional information that is normally not included in a PKC,
because the lifetime of the information is much shorter than the because the lifetime of the information is much shorter than the
lifetime of the public-private key pair. To support binding this lifetime of the public-private key pair. To support binding this
information to a PKC the Attribute Certificate (AC) was defined in information to a PKC the Attribute Certificate (AC) was defined in
ANSI and later incorporated into ITU-T Recommendation X.509. The AC ANSI and later incorporated into ITU-T Recommendation X.509. The AC
format allows any additional information to be bound to a PKC by format allows any additional information to be bound to a PKC by
including, in a digitally signed data structure, a reference back to including, in a digitally signed data structure, a reference back to
one specific PKC or to multiple PKCs, useful when the subject has one specific PKC or to multiple PKCs, useful when the subject has the
the same identity in multiple PKCs. Additionally, the AC can be
Arsenault, Turner 16
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
posses an attribute has the right to possess that attribute. This posses an attribute has the right to possess that attribute. This
Aresenault, Turner November, 2000 16
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
trusted to issue ACs containing this attribute." trusted to issue ACs containing this attribute."
ACs are complicated by the fact that they can point to an identity ACs are complicated by the fact that they can point to an identity
which may be in more than one PKC. If the RP has multiple which may be in more than one PKC. If the RP has multiple
certification chains to chose from then it has to make the certification chains to chose from then it has to make the
determination as to which certification path to trust. Regardless, determination as to which certification path to trust. Regardless,
before the RP uses the AC it must make sure that a path from the AC before the RP uses the AC it must make sure that a path from the AC
back to its trust point is valid. back to its trust point is valid.
3.2 Architectural Model 3.2 Architectural Model
A Privilege Management Infrastructure, or PMI, is defined as: A Privilege Management Infrastructure, or PMI, is defined as:
The set of hardware, software, people, policies and procedures The set of hardware, software, people, policies and procedures needed
needed to create, manage, store, distribute, and revoke ACs. to create, manage, store, distribute, and revoke ACs.
A PMI consists of five types of components [AC]: A PMI consists of five types of components [AC]:
- Attribute Authorities (AAs), or Attribute Certificate Issuer, - Attribute Authorities (AAs), or Attribute Certificate Issuer,
that issue and revoke ACs; that issue and revoke ACs;
Note: AAs may implicitly revoke ACs by using very short validity Note: AAs may implicitly revoke ACs by using very short validity
periods. periods.
- Attribute Certificate Users that parses or processes an AC; - Attribute Certificate Users that parses or processes an AC;
- Attribute Certificate Verifiers that check the validity of an AC - Attribute Certificate Verifiers that check the validity of an AC
and then makes use of the result; and then makes use of the result;
- Clients that request an action for which authorization checks are - Clients that request an action for which authorization checks are
to be made; to be made;
- Repositories that store and make available certificates and - Repositories that store and make available certificates and
Certificate Revocation Lists (CRLs). Certificate Revocation Lists (CRLs).
Figure 2 is an example of the exchanges that may involve ACs. Figure 2 is an example of the exchanges that may involve ACs.
Aresenault, Turner November, 2000 17 Arsenault, Turner 17
+--------------+ +--------------+
| | Server Acquisition | | Server Acquisition
| AC Issuer +----------------------------+ | AC issuer +----------------------------+
| | | | | |
+--+-----------+ | +--+-----------+ |
| | | |
| Client | | Client |
| Acquisition | | Acquisition |
| | | |
+--+-----------+ +--+------------+ +--+-----------+ +--+------------+
| | AC "push" | | | | AC "push" | |
| Client +-------------------------+ Server | | Client +-------------------------+ Server |
| | (part of app. protocol) | | | | (part of app. protocol) | |
+--+-----------+ +--+------------+ +--+-----------+ +--+------------+
| | | |
| Client | Server | Client | Server
| Lookup +--------------+ | Lookup | Lookup +--------------+ | Lookup
| | | | | | | |
+---------------+ Repository +---------+ +---------------+ Repository +---------+
| | | |
+--------------+ +--------------+
Figure 2: AC Exchanges Figure 2: AC Exchanges
3.3 Attribute Certificates 3.3 Attribute Certificates
ANSI X.9 first published the Attribute Certificate format. It ANSI X.9 first published the Attribute Certificate format. It defined
defined the standard version 1 (v1) AC format. They later created a the standard version 1 (v1) AC format. They later created a version 2
version 2 (v2) AC by modifying the owner field to point to either an (v2) AC by modifying the owner field to point to either an identity
identity or a specific PKC and including an extension mechanism. In or a specific PKC and including an extension mechanism. In 1997 ITU-T
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
information as an audit identity that can be used to create an audit information as an audit identity that can be used to create an audit
trail, identity specific servers and services where the AC owner can trail, identity specific servers and services where the AC owner can
use their AC, point to a specific issuer's key, and indicate where use their AC, point to a specific issuer's key, and indicate where to
to get 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.
The [AC] profile constrains many of the options allowed in X.509. The [AC] profile constrains many of the options allowed in X.509. For
For example, the AC chains, like their PKC brethren, are allowed by example, the AC chains, like their PKC brethren, are allowed by
X.509, but the AC profile recommends that they not be supported in X.509, but the AC profile recommends that they not be supported in to
to simplify the implementation. simplify the implementation.
Aresenault, Turner November, 2000 18 Arsenault, Turner 18
4 PKIX Documents 4 PKIX Documents
This section identifies the five 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 profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards
standards for the Internet. The second area involves operational for the Internet. The second area involves operational protocols, in
protocols, in which relying parties can obtain information such as which relying parties can obtain information such as PKCs or PKC
PKCs or PKC status. The third area covers management protocols, in status. The third area covers management protocols, in which
which different entities in the system exchange information needed different entities in the system exchange information needed for
for proper management of the PKI. The fourth area provides proper management of the PKI. The fourth area provides information
information about certificate policies and certificate practice about certificate policies and certificate practice statements,
statements, covering the areas of PKI security not directly covering the areas of PKI security not directly addressed in the rest
addressed in the rest of PKIX. The fifth area deals with providing of PKIX. The fifth area deals with providing time stamping and data
time stamping and data certification services, which can be used to certification services, which can be used to build such services as
build such services as non-repudiation. non-repudiation.
4.1 Profiles 4.1 Profiles
An X.509 v3 PKC is a very complex data structure. It consists of An X.509 v3 PKC is a very complex data structure. It consists of
basic information fields, plus a number of optional extensions. Many basic information fields, plus a number of optional extensions. Many
of the fields and numerous extensions can take on a wide range of of the fields and numerous extensions can take on a wide range of
options. This provides an enormous degree of flexibility, which options. This provides an enormous degree of flexibility, which
allows the X.509 v3 PKC format to be used with a wide range of allows the X.509 v3 PKC format to be used with a wide range of
applications in a wide range of environments. Unfortunately, this applications in a wide range of environments. Unfortunately, this
same flexibility makes it extremely difficult to produce independent same flexibility makes it extremely difficult to produce independent
implementations that will actually interoperate with one another. In implementations that will actually interoperate with one another. In
order to build an Internet PKI based on X.509 v3 PKCs, the PKIX order to build an Internet PKI based on X.509 v3 PKCs, the PKIX
working group had to develop a profile of the X.509 v3 PKC working group had to develop a profile of the X.509 v3 PKC
specification. specification.
A profile of the X.509 v3 PKC specification is a description of the A profile of the X.509 v3 PKC specification is a description of the
contents of the PKC and which extensions must be supported, which contents of the PKC and which extensions must be supported, which
extensions may be supported, and which extensions may not be extensions may be supported, and which extensions may not be
supported. [FORMAT] provides such a profile of X.509 v3 PKC for the supported. The Internet PKI Profile [2459bis] provides such a profile
Internet PKI. In addition, [FORMAT] suggests ranges of values for of X.509 v3 PKC for the Internet PKI. In addition, the Internet PKI
many of the extensions. Profile [2459bis] suggests ranges of values for many of the
extensions.
[FORMAT] also provides a profile for Version 2 CRLs for use in the The Internet PKI Profile [2459bis] also provides a profile for
Internet PKI. CRLs, like PKCs, have a number of optional extensions. Version 2 CRLs for use in the Internet PKI. CRLs, like PKCs, have a
In order to promote interoperability, it is necessary to constrain number of optional extensions. In order to promote interoperability,
the choices an implementor supports. it is necessary to constrain the choices an implementor supports.
In addition to profiling the PKC and CRL formats, it is necessary to In addition to profiling the PKC and CRL formats, it is necessary to
define particular Object Identifiers (OIDs) for certain encryption define particular Object Identifiers (OIDs) for certain encryption
algorithms, because there are a variety of OIDs registered for some algorithms, because there are a variety of OIDs registered for some
algorithm suites. PKIX has produced two documents ([RPKDS] and algorithm suites. PKIX has produced two documents ([RPKDS] and [KEA])
[KEA]) which provide guidance on the proper implementation of which provide guidance on the proper implementation of specific
specific algorithms. algorithms.
Some countries are in a process of updating their legal frameworks Some countries are in a process of updating their legal frameworks in
in order to regulate and incorporate recognition of signatures in order to regulate and incorporate recognition of signatures in
Aresenault, Turner November, 2000 19 Arsenault, Turner 19
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, requirements on PKCs, often termed Qualified Certificates, supporting
supporting these types of "legal" signatures. Partly as a result of these types of "legal" signatures. Partly as a result of this there
this there is a need for a specific PKC profile providing is a need for a specific PKC profile providing standardized support
standardized support for certain related issues such as a common for certain related issues such as a common structure for expressing
structure for expressing unambiguous identities of certified unambiguous identities of certified subjects (unmistakable identity).
subjects (unmistakable identity). In December 1998, PKIX adopted as In December 1998, PKIX adopted as a work item the development of a
a work item the development of a refinement of [RFC2459] that refinement of [RFC2459] that further profiles PKIX PKC into qualified
further profiles PKIX PKC into qualified certificates. This work is certificates. This work is reflected in [QC].
reflected in [QC].
Like the X.509 v3 PKC, the AC also a very complex data structure 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 enormous 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 PKIX 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.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
and CRL Profile (RFC 2459) Certificate and CRL Profile [2459bis]
DESCRIPTION: This document describes the profiles to be used for DESCRIPTION: This document describes the profiles to be used for
X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The X.509 v3 PKCs and version 2 CRLs by Internet PKI participants. The
profiles include the identification of ISO/IEC/ITU and ANSI profiles include the identification of ISO/IEC/ITU and ANSI
extensions which may be useful in the Internet PKI. The profiles are extensions which may be useful in the Internet PKI. The profiles
presented in the 1988 Abstract Syntax Notation One (ASN.1) rather are presented in the 1988 Abstract Syntax Notation One (ASN.1)
than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be rather than the 1994 syntax used in the ISO/IEC/ITU standards.
PKIX implementors and developers of certificate-using applications Would-be PKIX implementors and developers of certificate-using
should start with [FORMAT] to ensure that their systems will be able applications should start with the Internet PKI Profile [2459bis]
to interoperate with other users of the PKI. to ensure that their systems will be able to interoperate with
other users of the PKI.
[FORMAT] also includes path validation procedures. The procedures The Internet PKI Profile [2459bis] also includes path validation
presented are based upon the ISO/IEC/ITU definition, but the procedures. The procedures presented are based upon the ISO/IEC/ITU
presentation assumes one or more self-signed trusted CA PKCs. The definition, but the presentation assumes one or more self-signed
procedures are provided as examples only. Implementations are not trusted CA PKCs. The procedures are provided as examples only.
required to use the procedures provided; they may implement Implementations are not required to use the procedures provided;
whichever procedures are efficient for their situation. However, they may implement whichever procedures are efficient for their
implementations are required to derive the same results as the situation. However, implementations are required to derive the same
example procedures. results as the 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 Key Exchange Algorithm (KEA) Keys in Internet Representation of Key Exchange Algorithm (KEA) Keys in Internet
X.509 Public Key Infrastructure Certificates (RFC 2528) X.509 Public Key Infrastructure Certificates (RFC 2528) [KEA]
Aresenault, Turner November, 2000 20 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
subjectPublicKeyInfo field and the keyUsage extension in X.509 v3
PKCs containing KEA keys. This document should be used by anyone
wishing to support KEA; others who do not support ECDSA are not
required to comply with it.
STATUS: Informational RFC. Arsenault, Turner 20
(KEA). It profiles the format and semantics of the
subjectPublicKeyInfo field and the keyUsage extension in X.509 v3
PKCs containing KEA keys. This document should be used by anyone
wishing to support KEA; others who do not support ECDSA are not
required to comply with it.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified STATUS: Informational RFC.
Certificates <draft-ietf-pkix-qc-06.txt>
DESCRIPTION: This document profiles the format for and defines - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified
requirements on information content in a specific type of PKCs Certificates (RFC 3039) [QC]
called Qualified Certificates. A "Qualified Certificate" is a PKC
that is 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 subject; exclusively indicates non-repudiation as
the key usage for the certificate's public key; and meets a number
of requirements.
STATUS: WG Last Call. DESCRIPTION: This document profiles the format for and defines
requirements on information content in a specific type of PKCs
called Qualified Certificates. A "Qualified Certificate" is a PKC
that is 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 subject; exclusively indicates non-repudiation as
the key usage for the certificate's public key; and meets a number
of requirements.
DOCUMENT TITLE: An Internet Attribute Certificate Profile for STATUS: Proposed Standard.
Authorizations <draft-ietf-pkix-acx509prof-05.txt>
DESCRIPTION: This document profiles the format for an defines - DOCUMENT TITLE: An Internet Attribute Certificate Profile for
requirements on X.509 v2 ACs to support authorization services Authorizations <draft-ietf-pkix-ac509prof-05.txt> [AC]
required by various Internet protocols (TLS, CMS, and the consumers
of CMS, etc.). Two profiles are defined in support of basic
authorizations and in support of services that can operate via
proxy.
STATUS: Under WG review. DESCRIPTION: This document profiles the format for an defines
requirements on X.509 v2 ACs to support authorization services
required by various Internet protocols (TLS, CMS, and the consumers
of CMS, etc.). Two profiles are defined in support of basic
authorizations and in support of services that can operate via
proxy.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate STATUS: Approved as Proposed Standard; in RFC editorÆs Queue.
and CRL Profile <draft-ietf-pkix-new-part1-02.txt> Issuance as an RFC blocked until the normative reference [2459bis]
progresses to Proposed Standard as well. (See below.)
DESCRIPTION: This document is an update of [FORMAT]. - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Certificate and CRL Profile <draft-ietf-pkix-new-part1-11.txt>
[2459bis]
STATUS: Under WG review. DESCRIPTION: This document is an update of the Internet PKI Profile
[2459bis]. The treatment of path validation is enhanced, and
additional specificity is offered for various certificate and CRL
extensions. This document omits the encoding and identification of
public keys and digital signatures. (See [RPKDS] below.)
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Permanent STATUS: Tentatively approved by IESG.
Identifier <draft-ietf-pkix-pi-01.txt>
DESCRIPTION: This document defines a new form of name, the permanent Arsenault, Turner 21
identifier, which is a name assigned by an organization, unique - DOCUMENT TITLE: Representation of Public Keys and Digital
within that organization, that singles out a particular individual Signatures in Internet X.509 Public Key Infrastructure
fro all other individuals. The permanent identifier is an optional Certificates <draft-ietf-pkix-ipki-pkalgs-05.txt> [RPKDS]
feature that may be used by a CA to indicate that the certificate
Aresenault, Turner November, 2000 21 DESCRIPTION: This document specifies algorithm identifiers and
relates to the same individual even if the name or the affiliation encoding formats for the representation of cryptographic algorithms
of that individual has changed. The permanent identifier is keys, associated parameters, and digital signatures in Internet PKI
important in the context of access control and of non-repudiation. and X.509 certificates and certificate revocation lists. This draft
does not attempt to define the cryptographic algorithms themselves.
It instead references other appropriate standards. This draft
incorporates information from Section 7 of RFC 2459 and the
Internet-Draft ôRepresentation of Elliptic Curve Digital Signature
Algorithm (ECDSA) Keys in Internet X.509 Public Infrastructure
Certificates.ö
STATUS: Under WG review. STATUS: Tentatively approved by IESG.
DOCUMENT TITLE: Representation of Public Keys and Digital Signatures - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Permanent
in Internet X.509 Public Key Infrastructure Certificates Identifier <draft-ietf-pkix-pi-01.txt> [PI]
<draft-ietf-pkix-ipki-pkalgs-00.txt>
DESCRIPTION: This document specifies algorithm identifiers and DESCRIPTION: This document defines a new form of name, the
encoding formats for the representation of cryptographic algorithms permanent identifier, which is a name assigned by an organization,
keys, associated parameters, and digital signatures in Internet PKI unique within that organization, that singles out a particular
and X.509 certificates and certificate revocation lists. This draft individual fro all other individuals. The permanent identifier is
does not attempt to define the cryptographic algorithms themselves. an optional feature that may be used by a CA to indicate that the
It instead references other appropriate standards. This draft certificate relates to the same individual even if the name or the
incorporates information from Section 7 of RFC 2459 and the affiliation of that individual has changed. The permanent
Internet-Draft _Representation of Elliptic Curve Digital Signature identifier is important in the context of access control and of
Algorithm (ECDSA) Keys in Internet X.509 Public Infrastructure non-repudiation.
Certificates._
STATUS: Under WG review. STATUS: Under AD review.
- DOCUMENT TITLE: Supplemental Algorithms and Identifiers for the
Internet X.509 Public Key Infrastructure Certificate and CRL
Profile <draft-ietf-pkix-pkalgs-supp-00.txt> [SUPPALGS]
DESCRIPTION: This document supplements [RPKDS], defining specifies
algorithm identifiers and encoding formats for the representation
of emerging cryptographic algorithms and associated keys. The
document encompasses
lattice-based public key algorithms as well as digital signatures
using larger hash algorithms (e.g., SHA-256).
STATUS: Under WG review.
4.2 Operational Protocols 4.2 Operational Protocols
Operational protocols are required to deliver certificates and CRLs Operational protocols are required to deliver certificates and CRLs
(or other certificate status information) to certificate using (or other certificate status information) to certificate using
systems. Provision is needed for a variety of different means of systems. Provision is needed for a variety of different means of
certificate and CRL delivery, including distribution procedures certificate and CRL delivery, including distribution procedures based
based on DNS, LDAP, HTTP, FTP, and X.500. A limited protocol to
support AC retrieval has also been documented.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational
Protocols - LDAPv2 (RFC 2559)
DESCRIPTION: This document describes the use of LDAPv2 as a protocol
for PKI elements to publish and retrieve certificates and CRLs from
a repository. [LDAPv2] is a protocol that allows publishing and
retrieving of information.
STATUS: Proposed Standard.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2
Schema (RFC 2587)
DESCRIPTION: This document defines a minimal schema necessary to
support the use of LDAPv2 for PKC and CRL retrieval and related
functions for PKIX. This document supplements [LDAPv2] by
identifying the PKIX-related attributes that must be present.
STATUS: Proposed Standard.
Aresenault, Turner November, 2000 22 Arsenault, Turner 22
DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online on DNS, LDAP, HTTP, FTP, and X.500. A limited protocol to support AC
Certificate Status Protocol - OCSP (RFC 2560) retrieval has also been documented.
DESCRIPTION: This document specifies a protocol useful in - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
determining the current status of a certificate without the use of Operational Protocols - LDAPv2 (RFC 2559)
CRLs. A major complaint about certificate-based systems is the need
for a relying party to retrieve a current CRL as part of the
certificate validation process. Depending on the size of the CRL,
this can cause severe problems for bandwidth-challenged devices.
Depending on the frequency of CRL issuance, this can also cause
timeliness problems. (E.g., if CRLs are only published weekly, with
no interim releases, a certificate could actually have been revoked
for just short of one week without it being on the current CRL, and
thus improper use of that certificate could still be occurring.)
OCSP attempts to address those problems. It provides a mechanism DESCRIPTION: This document describes the use of LDAPv2 as a
whereby a relying party identifies one or more certificates to an protocol for PKI elements to publish and retrieve certificates and
approved OCSP "responder", and the responder sends back the current CRLs from a repository. [LDAPv2] is a protocol that allows
status of the certificate(s) - e.g., "revoked", "notRevoked", publishing and retrieving of information.
"unknown". This can dramatically reduce the bandwidth required to
transmit revocation status - a relying party does not have to
retrieve a CRL of many entries to check the status of one
certificate. It can (although it is not guaranteed to) improve the
timeliness of revocation notification, and thus reduce the window of
opportunity for someone trying to use a revoked certificate.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2
Protocols: FTP and HTTP (RFC 2585) Schema (RFC 2587)
DESCRIPTION: This document describes the use of the File Transfer DESCRIPTION: This document defines a minimal schema necessary to
Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain support the use of LDAPv2 for PKC and CRL retrieval and related
certificates and CRLs from PKI repositories. functions for PKIX. This document supplements [LDAPv2] by
identifying the PKIX-related attributes that must be present.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Diffie-Hellman Proof-of-Possession Algorithms (RFC - DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online
2875) as the basis of the signature. It allows Diffie-Hellman, a key Certificate Status Protocol - OCSP (RFC 2560)
agreement algorithm, to be used instead of requiring that the public
key being requested for certification correspond to an algorithm
that is capable of signing and encrypting. The first algorithm
generates a signature for a specific verifier where the signer and
recipient have the same public key parameters. The second algorithm
generates a signature for arbitrary verifiers where the signer and
recipient do not have the same public key parameters.
STATUS: Proposed Standard. DESCRIPTION: This document specifies a protocol useful in
determining the current status of a certificate without the use of
CRLs. A major complaint about certificate-based systems is the need
for a relying party to retrieve a current CRL as part of the
certificate validation process. Depending on the size of the CRL,
this can cause severe problems for bandwidth-challenged devices.
Depending on the frequency of CRL issuance, this can also cause
timeliness problems. (E.g., if CRLs are only published weekly, with
no interim releases, a certificate could actually have been revoked
for just short of one week without it being on the current CRL, and
thus improper use of that certificate could still be occurring.)
Aresenault, Turner November, 2000 23 OCSP attempts to address those problems. It provides a mechanism
DOCUMENT TITLE: Limited Attribute Certificate Acquisition Protocol whereby a relying party identifies one or more certificates to an
<draft-ietf-pkix-laap-01.txt> approved OCSP "responder", and the responder sends back the current
status of the certificate(s) - e.g., "revoked", "notRevoked",
"unknown". This can dramatically reduce the bandwidth required to
transmit revocation status - a relying party does not have to
retrieve a CRL of many entries to check the status of one
certificate. It can (although it is not guaranteed to) improve the
timeliness of revocation notification, and thus reduce the window
of opportunity for someone trying to use a revoked certificate.
DESCRIPTION: This document specifies a deliberately limited protocol STATUS: Proposed Standard.
for requesting ACs from a server. It is intended to be complementary
to the use of LDAP for AC retrieval, covering those cases where use
of an LDAP server is not suitable due to the type of authorization
model being employed.
STATUS: Under WG review. Arsenault, Turner 23
- DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Operational Protocols: FTP and HTTP (RFC 2585)
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Additional DESCRIPTION: This document describes the use of the File Transfer
Schema for PKIs and PMIs <draft-ietf-pkix-schema-01.txt> Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to
obtain certificates and CRLs from PKI repositories.
DESCRIPTION: This document describes the Lightweight Directory STATUS: Proposed Standard.
Access Protocol (LDAP) schema features that, in addition to RFC
2587, are needed to support a Privilege Management Infrastructure
and a Public Key Infrastructure. It also describes the schema for
the storage and matching of attribute certificates and revocation
lists in an LDAP directory server. This Internet Draft supplements,
rather than revokes, the contents of RFC 2587.
STATUS: Under WG review. - DOCUMENT TITLE: Diffie-Hellman Proof-of-Possession Algorithms (RFC
2875).
DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP) DESCRIPTION: It allows Diffie-Hellman, a key agreement algorithm,
<draft-ietf-pkix-scvp-03.txt> to be used instead of requiring that the public key being requested
for certification correspond to an algorithm that is capable of
signing and encrypting. The first algorithm generates a signature
for a specific verifier where the signer and recipient have the
same public key parameters. The second algorithm generates a
signature for arbitrary verifiers where the signer and recipient do
not have the same public key parameters.
DESCRIPTION: The SCVP protocol allows a client to offload STATUS: Proposed Standard.
certificate handling to a server. The server can give a variety of
valuable information about the
certificate, such as whether or not the certificate is valid, a
chain to a trusted root, and so on.
STATUS: Under WG review. - DOCUMENT TITLE: Limited Attribute Certificate Acquisition Protocol
<draft-ietf-pkix-laap-01.txt>
DOCUMENT TITLE: Online Certificate Status Protocol, Version 2 DESCRIPTION: This document specifies a deliberately limited
<draft-ietf-pkix-ocspv2-00.txt> protocol for requesting ACs from a server. It is intended to be
complementary to the use of LDAP for AC retrieval, covering those
cases where use of an LDAP server is not suitable due to the type
of authorization model being employed.
DESCRIPTION: This document is an update to RFC 2560. STATUS: Under WG review.
STATUS: Under WG review. - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Additional
Schema for PKIs and PMIs <draft-ietf-pkix-schema-01.txt>
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Repository DESCRIPTION: This document describes the Lightweight Directory
Locator Service <draft-ietf-pkix-pkixrep-00.txt> Access Protocol (LDAP) schema features that, in addition to RFC
2587, are needed to support a Privilege Management Infrastructure
and a Public Key Infrastructure. It also describes the schema for
the storage and matching of attribute certificates and revocation
lists in an LDAP directory server. This Internet Draft supplements,
rather than revokes, the contents of RFC 2587.
DESCRIPTION: This document defines a PKI repository locator service, STATUS: Under WG review.
which enable certificate-using systems to locate PKI repositories
based on a domain name, to identify the protocols that can be used
to access the repository, and obtain addresses for the servers that
host the repository service. The Internet Draft defines SRV records
for a PKI repository locator service to enable PKI clients to obtain
Aresenault, Turner November, 2000 24 - DOCUMENT TITLE: Delegated Path Validation and Delegated Path
necessary information to connect to a domain's repository. It also Discovery Protocol Requirements (DPV&DPD-REQ) <draft-ietf-pkix-
includes the definition of a SRV RR format for this service. dpd-dpv-req-00.txt> [DPREQ]
STATUS: Under WG review. DESCRIPTION: This document specifies requirements for two
request/response pairs. The first, called Delegated Path Validation
DOCUMENT TITLE: Delegated Path Validation <draft-ietf-pkix-ocsp- Arsenault, Turner 24
valid-00.txt> (DPV), can be used to fully delegate a path validation processing
to an DPV server. The second, called Delegated Path Discovery
(DPD), can be used to delegate development of a path, including
certificate status information, to a DPD server.
DESCRIPTION: This specification builds on the Online Certificate STATUS: Under WG review.
Status Protocol (OSCP) framework's extensibility by defining an
Internet-standard extension to OCSP that can be used to fully
delegate all path validation processing to an OCSP server. The
Delegated Path Validation (DVP) extension to OCSP described in this
document accomplishes the task of locating the certificate
validation process within a trusted server. This in turn reduces
the technical footprint of certificate-using applications and may
ease the integration of certificate path processing with other
authorized data.
STATUS: Under WG review. - DOCUMENT TITLE: Simple Certificate Validation Protocol (SCVP)
<draft-ietf-pkix-scvp-06.txt>
DOCUMENT TITLE: Delegated Path Discovery with OCSP <draft-ietf-pkix- DESCRIPTION: The SCVP protocol allows a client to offload
ocsp-path-00.txt> certificate handling to a server. The server can give a variety of
valuable information about the certificate, such as whether or not
the certificate is valid, a chain to a trusted root, and so on.
DESCRIPTION: This document establishes an Internet-standard STATUS: Under WG review.
extension that enables relying-party software to acquire
certification path data from an OCSP server rather than replicate
the same functionality. This Delegated Path Discovery (DPD)
extension delegates the acquisition process to a separate server,
thereby greatly simplifying and reducing the size of public key
based credential validation systems or other relying party software.
The DPD extension also enables such software to select from among
various trust paths in the event of the existence of multiple paths.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Protocols - LDAPv3 <draft-ietf-pkix-ldap-v3-03.txt> Operational Protocols - LDAPv3 <draft-ietf-pkix-ldap-v3-04.txt>
DESCRIPTION: This document describes the features of the Lightweight DESCRIPTION: This document describes the features of the
Directory Access Protocol (LDAP) v3 that are needed in order to Lightweight Directory Access Protocol (LDAP) v3 that are needed in
support a public key infrastructure based on x.509 certificates and order to support a public key infrastructure based on x.509
certificate revocation lists. Because LDAPv2 has a number of certificates and certificate revocation lists. Because LDAPv2 has a
deficiencies that may limit its usefulness in certain circumstances, number of deficiencies that may limit its usefulness in certain
the IETF has ceased its standardization and replaced it with LDAPv3. circumstances, the IETF has ceased its standardization and replaced
This document describes the features of LDAPv3 that are necessary, it with LDAPv3. This document describes the features of LDAPv3 that
not required, or are optional for servers to support a PKI based on are necessary, not required, or are optional for servers to support
X.509. a PKI based on X.509.
STATUS: Under WG Review. STATUS: Under WG Review.
4.3 Management Protocols 4.3 Management Protocols
Aresenault, Turner November, 2000 25
Management protocols are required to support on-line interactions Management protocols are required to support on-line interactions
between PKI user and management entities. For example, a management between PKI user and management entities. For example, a management
protocol might be used between a CA and a client system with which a protocol might be used between a CA and a client system with which a
key pair is associated, or between two CAs which cross-certify each key pair is associated, or between two CAs which cross-certify each
other. A management protocol can be used to carry user or client other. A management protocol can be used to carry user or client
system registration information, or a request for revocation of a system registration information, or a request for revocation of a
certificate. certificate.
There are two parts to a "management protocol." The first is the There are two parts to a "management protocol." The first is the
format of the messages that will be sent, and the second is the format of the messages that will be sent, and the second is the
actual protocol that governs the transmission of those messages. actual protocol that governs the transmission of those messages.
Originally, the PKIX working group developed two documents, [CRMF] Originally, the PKIX working group developed two documents, [CRMF]
and 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 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.
DOCUMENT TITLE: Certificate Management Messages over CMS (RFC 2797) Arsenault, Turner 25
- DOCUMENT TITLE: Certificate Management Messages over CMS (RFC 2797)
[CMC]
DESCRIPTION: This document defines the means by which PKI clients DESCRIPTION: This document defines the means by which PKI clients
and servers may exchange PKI messages when using S/MIME's and servers may exchange PKI messages when using S/MIME's
Cryptographic Message Syntax [CMS] as a transaction envelope. CMC Cryptographic Message Syntax [CMS] as a transaction envelope. CMC
supports the certificate request message body specified in the supports the certificate request message body specified in the
Certificate Request Message Format [CRMF] documents, as well as a Certificate Request Message Format [CRMF] documents, as well as a
variety of other certificate management messages. The primary variety of other certificate management messages. The primary
purpose of this specification is to allow the use of an existing purpose of this specification is to allow the use of an existing
protocol (S/MIME) as a PKI management protocol, without requiring protocol (S/MIME) as a PKI management protocol, without requiring
the development of an entirely new protocol such as CMP. A secondary the development of an entirely new protocol such as CMP. A
purpose is to codify in IETF standards the current industry practice secondary purpose is to codify in IETF standards the current
of using PKCS-10 messages [PKCS10] for certificate requests. industry practice of using PKCS-10 messages [PKCS10] for
certificate requests.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Internet X.509 Certificate Request Message Format - DOCUMENT TITLE: Internet X.509 Certificate Request Message Format
(RFC 2511) (RFC 2511) [CRMF]
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
needed before many of the other message formats had to be finalized, was needed before many of the other message formats had to be
and so it was put into a separate document. This document only finalized, and so it was put into a separate document. This
specifies the format of a message. Specification of a protocol to document only specifies the format of a message. Specification of a
transport that message is beyond the scope of CRMF. protocol to transport that message is beyond the scope of CRMF.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Management Protocols (RFC 2510) Certificate Management Protocols (RFC 2510) [CMP]
Aresenault, Turner November, 2000 26 DESCRIPTION: This document specifies a new protocol specifically
DESCRIPTION: This document specifies a new protocol specifically developed for the purpose of transporting messages like those
developed for the purpose of transporting messages like those specified in CRMF among PKI elements. In general, CMP will be used
specified in CRMF among PKI elements. In general, CMP will be used in conjunction with CRMF, and will then be run over a transfer
in conjunction with CRMF, and will then be run over a transfer service (e.g., S/MIME, HTTP) to provide a complete PKI management
service (e.g., S/MIME, HTTP) to provide a complete PKI management service.
service.
STATUS: Proposed Standard. STATUS: Proposed Standard.
DOCUMENT TITLE: Certificate Management Protocols <draft-ietf-pkix- - DOCUMENT TITLE: Certificate Request Message Format <draft-ietf-
rfc2510bis-01.txt> pkix- rfc2511bis-02.txt> [2511bis]
DESCRIPTION: This document is an update of [CMP]. DESCRIPTION: This document is an update of [CRMF] and reflects the
results of interoperability testing.
STATUS: Under WG review. STATUS: Awaiting documentation of Interoperability Testing results.
DOCUMENT TITLE: Transport Protocols for CMP <draft-ietf-pkix-cmp- Arsenault, Turner 26
protocols-01.txt> - DOCUMENT TITLE: Certificate Management Protocols <draft-ietf-pkix-
rfc2510bis-04.txt> [2510bis]
DESCRIPTION: This document describes how to layer Certificate DESCRIPTION: This document is an update of [CMP] and reflects the
Management Protocols (CMP) over various transport protocols. In results of interoperability testing. The document omits the
Section 5 of RFC 2510, the process of sending DER-encoded CMP transport protocols found in [CMP] which are addressed in [CMPT].
messages directly over various protocols is specified. Implementers (See below).
found that the protocol was lacking in several regards. This
document is an effort to enhance the protocol now in order to avoid
interoperability conflicts later and to make the transport section a
separate draft.
STATUS: Under WG review. STATUS: Awaiting documentation of Interoperability Testing results.
- DOCUMENT TITLE: Transport Protocols for CMP <draft-ietf-pkix-cmp-
protocols-04.txt> [CMPT]
DESCRIPTION: This document describes how to layer Certificate
Management Protocols (CMP) over various transport protocols. In
Section 5 of RFC 2510, the process of sending DER-encoded CMP
messages directly over various protocols is specified. Implementers
found that the protocol was lacking in several regards. This
document is an effort to enhance the protocol now in order to avoid
interoperability conflicts later and to make the transport section
a separate draft.
STATUS: Under WG review.
4.4 Policy Outline 4.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 problem of actually developing and implementing a secure PKI. What is
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, security, subject identification requirements, revocation policy, and
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.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Policy and Certification Practices Framework (RFC 2527) Certificate Policy and Certification Practices Framework (RFC
2527)
DESCRIPTION: As noted before, the specification and implementation DESCRIPTION: As noted before, the specification and implementation
of certificate profiles, operational protocols, and management of certificate profiles, operational protocols, and management
protocols is only part of building a PKI. Equally as important - if protocols is only part of building a PKI. Equally as important - if
not more important - is the development and enforcement of a not more important - is the development and enforcement of a
certificate security policy, and a Certification Practice Statement certificate security policy, and a Certification Practice Statement
(CPS). The purpose of this document (PKIX-4) is to establish a clear (CPS). The purpose of this document (PKIX-4) is to establish a
clear relationship between certificate policies and CPSs, and to
present a framework to assist the writers of certificate policies
or CPSs with their tasks. In particular, the framework identifies
the elements that may need to be considered in formulating a
certificate policy or a CPS. The purpose is not to define
particular certificate policies or CPSs, per se.
Aresenault, Turner November, 2000 27 Arsenault, Turner 27
relationship between certificate policies and CPSs, and to present a STATUS: Informational RFC.
framework to assist the writers of certificate policies or CPSs with
their tasks. In particular, the framework identifies the elements
that may need to be considered in formulating a certificate policy
or a CPS. The purpose is not to define particular certificate
policies or CPSs, per se.
STATUS: Informational RFC. - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework <draft-
ietf-pkix-ipki-new-rfc2527-00.txt>
DESCRIPTION: This specification is an update to RFC 2527. As above,
the purpose of this document is to establish a clear relationship
between certificate policies and CPSs, and to present a framework
to assist the writers of certificate policies or CPSs with their
tasks. The framework specified in this documents is basically a
superset of the framework specified in RFC 2527.
STATUS: Under WG Review.
4.4 Time Stamping and Data Certification 4.4 Time Stamping and Data Certification
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 appropriate because they described infrastructure services that could
could be used to provide desired security services. The first of be used to provide desired security services. The first of these is
these is time stamping, described in [TSP]. Time stamping is a time stamping, described in [TSP]. Time stamping is a service in
service in which a trusted third party - a Time Stamp Authority, or which a trusted third party - a Time Stamp Authority, or TSA - signs
TSA - signs a message, in order to provide evidence that it existed a message, in order to provide evidence that it existed prior to a
prior to a given time. Time stamping provides some support for non- given time. Time stamping provides some support for non- repudiation,
repudiation, in that a user cannot claim that a transaction was in that a user cannot claim that a transaction was later forged after
later forged after compromise of a private key, because the compromise of a private key, because the existence of the signed time
existence of the signed time stamp indicates that the transaction in stamp indicates that the transaction in question could not have been
question could not have been created after the indicated time. created after the indicated time.
[TSP] also defines the role of a Temporal Data Authority, or TDA. A [TSP] also defines the role of a Temporal Data Authority, or TDA. A
TDA is a Trusted Third Party (TTP) that creates a temporal data TDA is a Trusted Third Party (TTP) that creates a temporal data
token. This temporal data token associates a message with a token. This temporal data token associates a message with a
particular event and provides supplementary evidence for the time particular event and provides supplementary evidence for the time
included in the time stamp token. For example, a TDA could associate included in the time stamp token. For example, a TDA could associate
the message with the most recent closing value of the Dow Jones the message with the most recent closing value of the Dow Jones
Average. The temporal data with which the message is associated Average. The temporal data with which the message is associated
should be unpredictable in order to prevent forward dating of should be unpredictable in order to prevent forward dating of tokens.
tokens. The third iteration of the draft removed support for TDAs as The third iteration of the draft removed support for TDAs as no one
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 patent holder. 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
Arsenault, Turner 28
to it. It also allows the delegation of trustworthy servers and to it. It also allows the delegation of trustworthy servers and
allows for chaining of verifications. allows for chaining of verifications.
This services offered by DVCS are different from the TSP service in This services offered by DVCS are different from the TSP service in
that a TSA will not attempt to parse or verify a message sent to it that a TSA will not attempt to parse or verify a message sent to it
for certification; instead, it will merely append a reliable for certification; instead, it will merely append a reliable
indication of the current time, and sign the resulting string-of- indication of the current time, and sign the resulting string-of-
bits. This offers an indication that the given string-of-bits existed
Aresenault, Turner November, 2000 28 at a specified time; it does not offer any indication of the
bits. This offers an indication that the given string-of-bits
existed at a specified time; it does not offer any indication of the
correctness or relevance of that string of bits. By contrast, the correctness or relevance of that string of bits. By contrast, the
DVCS certifies possession of data or the validity of another DVCS certifies possession of data or the validity of another entity's
entity's signature. As part of this, the DVCS verifies the signature. As part of this, the DVCS verifies the mathematical
mathematical correctness of the actual signature value contained in correctness of the actual signature value contained in the request
the request and also checks the full certification path from the and also checks the full certification path from the signing entity
signing entity to a trusted point (e.g., the DVCS's CA, or the Root to a trusted point (e.g., the DVCS's CA, or the Root CA in a
CA in a hierarchy). 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 expires and its revocation information is no longer available on CRLs
CRLs (for example). Second, the production of a data certification (for example). Second, the production of a data certification token
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.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp The concept of a delegated signature validation server was introduced
Protocols <draft-ietf-pkix-time-stamp-11.txt> in [DSV] as an analog to the delegated path validation server. A DSV
services permits the relying party to prove they validated a
digitally signed object, including the certification path, at a
particular time.
DESCRIPTION: This document defines the specification for a time - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp
stamp service. It defines a Time Stamp Authority, or TSA, a trusted Protocols (RFC 3161)
third party who maintains a reliable time service. When the TSA
receives a time stamp request, it appends the current time to the
request and signs it into a token to certify that the original
request existed prior to the indicated time. This helps provide non-
repudiation by preventing someone (either a legitimate user or an
attacker who has successfully compromised a key) from "back-dating"
a transaction. It 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 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 meaning is unimportant, but existence is
vital.
STATUS: In WG Last. DESCRIPTION: This document defines the specification for a time
stamp service. It defines a Time Stamp Authority, or TSA, a trusted
third party who maintains a reliable time service. When the TSA
receives a time stamp request, it appends the current time to the
request and signs it into a token to certify that the original
request existed prior to the indicated time. This helps provide
non- repudiation by preventing someone (either a legitimate user or
an attacker who has successfully compromised a key) from "back-
dating" a transaction. It 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 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 meaning is unimportant, but existence
is vital.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data STATUS: Proposed Standard.
Certification Server Protocols <draft-ietf-pkix-dcs-04.txt>
DESCRIPTION: This document defines a data validation and Arsenault, Turner 29
certification service, or DVCS, which can be used to certify both - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data
the existence and correctness of a message or signature. In contrast Certification Server Protocols (RFC 3029)
to the time stamp service described above, the DVCS certifies
possession of data or the validity of another entity's signature. As
part of this, the DVCS verifies the mathematical correctness of the
actual signature value contained in the request and also checks the
full certification path from the signing entity to a trusted point
(e.g., the DVCS's CA, or the Root CA in a hierarchy).
Aresenault, Turner November, 2000 29 DESCRIPTION: This document defines a data validation and
The DVCS supports non-repudiation in two ways. First, it provides certification service, or DVCS, which can be used to certify both
evidence that a signature or public key certificate was valid at the the existence and correctness of a message or signature. In
time indicated in the token. The token can be used even after the contrast to the time stamp service described above, the DVCS
corresponding public key certificate expires and its revocation certifies possession of data or the validity of another entity's
information is no longer available on CRLs (for example). Second, signature. As part of this, the DVCS verifies the mathematical
the production of a data certification token in response to a signed correctness of the actual signature value contained in the request
request for certification of another signature or public key and also checks the full certification path from the signing entity
certificate also provides evidence that due diligence was performed to a trusted point (e.g., the DVCS's CA, or the Root CA in a
by the requester in validating the signature or public key hierarchy). The DVCS supports non-repudiation in two ways. First,
certificate. it provides evidence that a signature or public key certificate was
valid at the time indicated in the token. The token can be used
even after the corresponding public key certificate expires and its
revocation information is no longer available on CRLs (for
example). Second, the production of a data certification token in
response to a signed request for certification of another signature
or public key certificate also provides evidence that due diligence
was performed by the requester in validating the signature or
public key certificate.
STATUS: Under WG review. STATUS: Experimental RFC.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Technical - DOCUMENT TITLE: Delegated Signature Validation Protocol
Requirements for a non-Repudiation Service <draft-ietf-pkix-technr- Requirements (DSV-REQ) <draft-ietf-pkix-dsv-req-00.txt>
01.txt>
DESCRIPTION: This document describes those features of a service DESCRIPTION: This document specifies requirements to fully delegate
which processes signed documents which must be present in order for the validation of a digital signature to a DSV (Delegated Signature
that service to constitute a "technical non-repudiation" service. A Validation) server. The validation is performed using a set of
technical non-repudiation service must permit an independent rules, called a signature policy.
verifier to determine whether a given signature was applied to a
given 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.
This document is intended to clarify the definition of the "non- It also defines the requirements for two optional request/response
repudiation" service in RFC 2459. It should thus serve as a guide pairs, either for allowing to indicate to a signature validation
to when the nonRepudiation bit of the keyUsage extension should be server a signature policy, or giving the reference of a signature
set and to when a Certificate Authority is required to archive policy to obtain the details of an already defined signature
CRL's. policy.
STATUS: Under WG Review. STATUS: Under WG review.
4.5 Expired Drafts 4.5 Expired Drafts
There have been numerous drafts that have been produced by the There have been numerous drafts that have been produced by the
working group that for some reason or another did not make it to RFC working group that for some reason or another did not make it to RFC
status. The following is a list of these drafts. status. The following is a list of these drafts.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
Management Message Formats Certificate Management Message Formats
DESCRIPTION: This document contained the formats for a series of DESCRIPTION: This document contained the formats for a series of
messages important in certificate and PKI management. These messages messages important in certificate and PKI management. These
let CA's, RA's, and relying parties communicate with each other.
Note that this document only specified message formats; it did not
specify a protocol for transferring messages. That protocol could
have be either CMP or CMC, or perhaps another custom protocol.
Aresenault, Turner November, 2000 30 Arsenault, Turner 30
STATUS: Work has been discontinued. All useful information from it messages let CA's, RA's, and relying parties communicate with each
has been moved into [CMP] and [CMC]. other. Note that this document only specified message formats; it
did not specify a protocol for transferring messages. That protocol
could have be either CMP or CMC, or perhaps another custom
protocol.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced STATUS: Work has been discontinued. All useful information from it
CRL Distribution Options (OpenCDP) has been moved into [CMP] and [CMC].
DESCRIPTION: This document proposed an alternative to the CRL - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced
Distribution Point (CDP) approach documented in [FORMAT]. OCDP CRL Distribution Options (OpenCDP)
separates the CRL location function from the process of certificate
and CRL validation, and thus claimed some benefits over the CDP
approach.
STATUS: Work has been discontinued, as all useful information has DESCRIPTION: This document proposed an alternative to the CRL
been incorporated into [X.509]. An updated [FORMAT] RFC should Distribution Point (CDP) approach documented in the Internet PKI
profile the use of the CDP approach. Profile [2459bis]. OCDP separates the CRL location function from
the process of certificate and CRL validation, and thus claimed
some benefits over the CDP approach.
DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the STATUS: Work has been discontinued, as all useful information has
Online Certificate Status Protocol been incorporated into [X.509]. An updated the Internet PKI Profile
[2459bis] RFC should profile the use of the CDP approach.
DESCRIPTION: To improve the degree to which it can scale, OCSP - DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the
allows caching of responses - e.g., at intermediary servers, or even Online Certificate Status Protocol
at the relying party's end system. This document described how to
support OCSP caching at intermediary servers.
STATUS: Work has been discontinued. DESCRIPTION: To improve the degree to which it can scale, OCSP
allows caching of responses - e.g., at intermediary servers, or
even at the relying party's end system. This document described how
to support OCSP caching at intermediary servers.
DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0 STATUS: Work has been discontinued.
DESCRIPTION: This document specified a set of methods, headers, and - DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0
content-types ancillary to HTTP/1.1 to publish, retrieve X.509 PKCs
and Certificate Revocation Lists. This protocol also facilitated
determining current status of a digital certificate without the use
of CRLs. This protocol defined new methods, request and response
bodies, error codes to HTTP/1.1 protocol for securely publishing,
retrieving, and validating certificates across a firewall.
STATUS: Expired. DESCRIPTION: This document specified a set of methods, headers, and
content-types ancillary to HTTP/1.1 to publish, retrieve X.509 PKCs
and Certificate Revocation Lists. This protocol also facilitated
determining current status of a digital certificate without the use
of CRLs. This protocol defined new methods, request and response
bodies, error codes to HTTP/1.1 protocol for securely publishing,
retrieving, and validating certificates across a firewall.
DOCUMENT TITLE: Basic Event Representation Token STATUS: Expired.
DESCRIPTION: This document defined a finite method of representing a - DOCUMENT TITLE: Basic Event Representation Token
discrete instant in time as a referable event. The Basic Event
Representation Token (BERT) was a light-weight binary token designed
for use in large numbers over short periods of time. The tokens
contained only a single instance of an event stamp and the trust
process is referenced against an external reference.
STATUS: Expired. DESCRIPTION: This document defined a finite method of representing
a discrete instant in time as a referable event. The Basic Event
Representation Token (BERT) was a lightweight binary token designed
for use in large numbers over short periods of time. The tokens
contained only a single instance of an event stamp and the trust
process is referenced against an external reference.
Aresenault, Turner November, 2000 31 Arsenault, Turner 31
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending STATUS: Expired.
trust in non repudiation tokens in time
DESCRIPTION: This document described a method to maintain the trust - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending
in a token issued by a non-repudiation Trusted Third Party (NR TTP) trust in non repudiation tokens in time
(DVCS/TSA/TDA) after the key initially used to establish trust in
the token expires. The document described a general format for
storage of DVCS/TS/TDA tokens for this purpose, which establishes a
chain of custody for the data.
STATUS: Expired. DESCRIPTION: This document described 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 described a general format for
storage of DVCS/TS/TDA tokens for this purpose, which establishes a
chain of custody for the data.
DOCUMENT TITLE: Internet X.509 Public Key Infrastructure STATUS: Expired.
Representation of Elliptic Curve Digital Signature Algorithm (ECDSA)
Keys and Signatures in Internet X.509 Public Key Infrastructure
Certificates
DESCRIPTION: This document provided Object Identifiers (OIDs) and - DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
other guidance for IPKI users who use the Elliptic Curve Digital Representation of Elliptic Curve Digital Signature Algorithm
Signature Algorithm (ECDSA). It profiled the format and semantics of (ECDSA) Keys and Signatures in Internet X.509 Public Key
the subjectPublicKeyInfo field and the keyUsage extension in X.509 Infrastructure Certificates
v3 PKCs containing ECDSA keys. This document should have been used
by anyone wishing to support ECDSA; others who do not support ECDSA
are not required to comply with it.
STATUS: Finished WG Last Call. Merged into Representation of Public DESCRIPTION: This document provided Object Identifiers (OIDs) and
Keys and Digital Signatures in Internet X.509 Public Key other guidance for IPKI users who use the Elliptic Curve Digital
Infrastructure Certificates. Signature Algorithm (ECDSA). It profiled the format and semantics
of the subjectPublicKeyInfo field and the keyUsage extension in
X.509 v3 PKCs containing ECDSA keys. This document should have been
used by anyone wishing to support ECDSA; others who do not support
ECDSA are not required to comply with it.
DOCUMENT TITLE: A String Representation of General Name STATUS: Finished WG Last Call. Merged into Representation of Public
Keys and Digital Signatures in Internet X.509 Public Key
Infrastructure Certificates.
DESCRIPTION: This document specified a string format for the ASN.1 - DOCUMENT TITLE: A String Representation of General Name
construct GeneralName.
STATUS: Expired. DESCRIPTION: This document specified a string format for the ASN.1
construct GeneralName.
DOCUMENT TITLE: OCSP Extensions STATUS: Expired.
DESCRIPTION: This document defined Internet-standard extensions to - DOCUMENT TITLE: OCSP Extensions
OCSP that enable a client to delegate processing of certificate
acceptance functions to a trusted server. The client could control
the degree to which delegation takes place. In addition limited
support was provided for delegating authorization decisions.
STATUS: The work has been incorporated into [DPV] and [DPD]. DESCRIPTION: This document defined Internet-standard extensions to
OCSP that enable a client to delegate processing of certificate
acceptance functions to a trusted server. The client could control
the degree to which delegation takes place. In addition limited
support was provided for delegating authorization decisions.
DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP STATUS: The work has been incorporated into [DPV] and [DPD].
DESCRIPTION: This document described how to layer [CMP] over [HTTP]. - DOCUMENT TITLE: Using HTTP as a Transport Protocol for CMP
A simple method for doing so was described in [CMP], but that method
does not accommodate a polling mechanism, which may be required in
Aresenault, Turner November, 2000 32 DESCRIPTION: This document described how to layer [CMP] over
some environments. This document specified an alternative method [HTTP]. A simple method for doing so was described in [CMP], but
that used the polling protocol defined in [CMP]. A new Content-Type that method does not accommodate a polling mechanism, which may be
for messages was also defined.
STATUS: The work has been merged into [TPCMP]. Arsenault, Turner 32
required in some environments. This document specified an
alternative method that used the polling protocol defined in [CMP].
A new Content-Type for messages was also defined.
DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP STATUS: The work has been merged into [TPCMP].
DESCRIPTION: This document described how to layer Certificate - DOCUMENT TITLE: Using TCP as a Transport Protocol for CMP
Management Protocols [CMP] over [TCP]. A method for doing so is
described in [CMP], but that method did not solve problems
encountered by implementors. This document specified an enhanced
method which extends the protocol.
STATUS: The work has been merged into [TPCMP]. DESCRIPTION: This document described how to layer Certificate
Management Protocols [CMP] over [TCP]. A method for doing so is
described in [CMP], but that method did not solve problems
encountered by implementors. This document specified an enhanced
method which extends the protocol.
STATUS: The work has been merged into [TPCMP].
- DOCUMENT TITLE: Delegated Path Validation
DESCRIPTION: This specification builds on the Online Certificate
Status Protocol (OSCP) framework's extensibility by defining an
Internet-standard extension to OCSP that can be used to fully
delegate all path validation processing to an OCSP server. The
Delegated Path Validation (DVP) extension to OCSP described in this
document accomplishes the task of locating the certificate
validation process within a trusted server. This in turn reduces
the technical footprint of certificate-using applications and may
ease the integration of certificate path processing with other
authorized data.
STATUS: Expired.
- DOCUMENT TITLE: Delegated Path Discovery with OCSP
DESCRIPTION: This document establishes an Internet-standard
extension that enables relying-party software to acquire
certification path data from an OCSP server rather than replicate
the same functionality. This Delegated Path Discovery (DPD)
extension delegates the acquisition process to a separate server,
thereby greatly simplifying and reducing the size of public key
based credential validation systems or other relying party
software. The DPD extension also enables such software to select
from among various trust paths in the event of the existence of
multiple paths.
STATUS: Expired.
- DOCUMENT TITLE: Online Certificate Status Protocol, Version 2
DESCRIPTION: This document is an update to RFC 2560.
STATUS: Expired.
Arsenault, Turner 33
- DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Repository
Locator Service
DESCRIPTION: This document defines a PKI repository locator
service, which enable certificate-using systems to locate PKI
repositories based on a domain name, to identify the protocols that
can be used to access the repository, and obtain addresses for the
servers that host the repository service. The Internet Draft
defines SRV records for a PKI repository locator service to enable
PKI clients to obtain necessary information to connect to a
domain's repository. It also includes the definition of a SRV RR
format for this service.
STATUS: Expired.
- DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Technical
Requirements for a non-Repudiation Service
DESCRIPTION: This document describes 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. A
technical non-repudiation service must permit an independent
verifier to determine whether a given signature was applied to a
given 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.
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.
STATUS: Expired.
5 Implementation Advice 5 Implementation Advice
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 readers of the PKIX document set understand these issues, in the hope
hope of fostering greater interoperability among eventual PKIX of fostering greater interoperability among eventual PKIX
implementations. implementations.
Arsenault, Turner 34
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 least one name for the owner of a particular public key. The name can
can be an X.500 distinguished name, contained in the subjectDN field be an X.500 distinguished name, contained in the subjectDN field of
of the PKC. There can also be names such as RFC822 e-mail addresses, the PKC. There can also be names such as RFC822 e-mail addresses, DNS
DNS domain names, and uniform resource identifiers (URIs) associated domain names, and uniform resource identifiers (URIs) associated with
with the key; these attributes are kept in the subjectAltName the key; these attributes are kept in the subjectAltName extension of
extension of the PKC. A PKC must contain at least one of these name the PKC. A PKC must contain at least one of these name forms, it may
forms, it may contain multiple forms if deemed appropriate by the CA contain multiple forms if deemed appropriate by the CA based on the
based on the 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 is the subject field in the base PKC (often called the "Distinguished
"Distinguished Name" or "DN" field), and the other is in the Name" or "DN" field), and the other is in the subjectAltName
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 the Internet PKI Profile [2459bis], a CA's PKC must have
subject field, while EE's PKCs are permitted to have an empty a non-null value in the subject field, while EE's PKCs are permitted
to have an empty subject field. If a PKC has a non-null subject
Aresenault, Turner November, 2000 33 field, it MUST contain an X.500 Distinguished Name.
subject field. If a PKC has a non-null subject 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 The subjectAltName extension allows additional identities to be bound
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"). X.509- "C=US, O=University of Maryland, L=Baltimore, CN=UMBC"). X.509-
defined options for this extension include: Internet electronic mail defined options for this extension include: Internet electronic mail
addresses; DNS names; IP addresses; and URIs. Other options can addresses; DNS names; IP addresses; and URIs. Other options can
exist, including locally-defined name forms. exist, including locally-defined name forms.
A single subjectAltName extension can include multiple name forms, A single subjectAltName extension can include multiple name forms,
and multiple instances of each name form. and multiple instances of each name form.
Whenever such alternate name forms are to be bound into a PKC, the Whenever such alternate name forms are to be bound into a PKC, the
subjectAltName (or issuerAltName) extension must be used. It is subjectAltName (or issuerAltName) extension must be used. It is
technically possible to embed an alternate name form in the subject technically possible to embed an alternate name form in the subject
field. For example, one could make a DN contain an IP address via a field. For example, one could make a DN contain an IP address via a
kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this kludge such as "C=US, L=Baltimore, CN=130.85.1.3". However, this
usage is deprecated; the alternative name extension is the preferred usage is deprecated; the alternative name extension is the preferred
location for finding such information. As another example, some location for finding such information. As another example, some
Arsenault, Turner 35
legacy implementations exist where an RFC822 name is embedded in the legacy implementations exist where an RFC822 name is embedded in the
subject distinguished name as an EmailAddress attribute. Per subject distinguished name as an EmailAddress attribute. Per Internet
[FORMAT], PKIX-compliant implementations generating new PKCs with Profile [2459bis], PKIX-compliant implementations generating new
electronic mail addresses MUST use the rfc822Name in the PKCs with electronic mail addresses MUST use the rfc822Name in the
subjectAltName extension to describe such EEs. Simultaneous subjectAltName extension to describe such EEs. Simultaneous inclusion
inclusion of the EmailAddress attribute in the subject distinguished of the EmailAddress attribute in the subject distinguished name to
name to support legacy implementation is deprecated but permitted. support legacy implementation is deprecated but permitted.
In line with this, if the only subject identity included in a PKC is In line with this, if the only subject identity included in a PKC is
an alternative name form, then the subject distinguished name must an alternative name form, then the subject distinguished name must be
be empty (technically, an empty sequence), and the subjectAltName empty (technically, an empty sequence), and the subjectAltName
extension must be present. If the subject field contains an empty extension must be present. If the subject field contains an empty
sequence, the subjectAltName extension must be marked critical. sequence, the subjectAltName extension must be marked critical.
If the subjectAltName extension is present, the sequence must If the subjectAltName extension is present, the sequence must contain
contain at least one entry. Unlike the subject field, conforming CAs at least one entry. Unlike the subject field, conforming CAs shall
shall not issue PKCs with subjectAltNames containing empty not issue PKCs with subjectAltNames containing empty GeneralName
GeneralName fields. For example, an rfc822Name is represented as an fields. For example, an rfc822Name is represented as an IA5String.
IA5String. While an empty string is a valid IA5String, such an While an empty string is a valid IA5String, such an rfc822Name is not
rfc822Name is not permitted by PKIX. The behavior of clients that permitted by PKIX. The behavior of clients that encounter such a PKC
encounter such a PKC when processing a certification path is not when processing a certification path is not defined by this working
defined by this working group. group. Because the subject's alternative name is considered to be
Aresenault, Turner November, 2000 34
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 address is included as an rfc822Name. The format of an the address is included as an rfc822Name. The format of an rfc822Name
rfc822Name is an "addr-spec" as defined in [RFC-822]. An addr-spec is an "addr-spec" as defined in [RFC-822]. An addr-spec has the form
has the form local-part@domain; it does not have a phrase (such as a local-part@domain; it does not have a phrase (such as a common name)
common name) before it, or a comment (text surrounded in before it, or a comment (text surrounded in parentheses) after it,
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 significance 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, addition, while the string " " is a legal domain name, subjectAltName
subjectAltName extensions with a dNSName " " are not permitted. extensions with a dNSName " " are not permitted. Finally, the use of
Finally, the use of the DNS representation for Internet mail the DNS representation for Internet mail addresses (wpolk.nist.gov
addresses (wpolk.nist.gov instead of wpolk@nist.gov) is not instead of wpolk@nist.gov) is not permitted; such identities are to
permitted; such identities are to be encoded as rfc822Name. be encoded as rfc822Name.
5.1.1.2.3 IP addresses Arsenault, Turner 36
5.1.1.2.3 IP addresses
When the subjectAltName extension contains an iPAddress, the address When the subjectAltName extension contains an iPAddress, the address
shall be stored in the octet string in "network byte order," as shall be stored in the octet string in "network byte order," as
specified in [IP]. The least significant bit (LSB) of each octet is specified in [IP]. The least significant bit (LSB) of each octet is
the LSB of the corresponding byte in the network address. For IP the LSB of the corresponding byte in the network address. For IP
Version 4, as specified in [IP], the octet string must contain Version 4, as specified in [IP], the octet string must contain
exactly four octets. For IP Version 6, as specified in [IPv6], the exactly four octets. For IP Version 6, as specified in [IPv6], the
octet string must contain exactly sixteen octets. octet string must contain exactly sixteen octets.
5.1.1.2.4 URIs 5.1.1.2.4 URIs
[FORMAT] notes "When the subjectAltName extension contains a URI, The Internet PKI Profile [2459bis] notes "When the subjectAltName
the name MUST be stored in the uniformResourceIdentifier (an extension contains a URI, the name MUST be stored in the
IA5String). The name MUST be a non-relative URL, and MUST follow the uniformResourceIdentifier (an IA5String). The name MUST be a non-
URL syntax and encoding rules specified in [RFC 1738]. The name must relative URL, and MUST follow the URL syntax and encoding rules
include both a scheme (e.g., "http" or "ftp") and a scheme-specific- specified in [RFC 1738]. The name must include both a scheme (e.g.,
part. The scheme-specific-part must include a fully qualified domain "http" or "ftp") and a scheme-specific- part. The scheme-specific-
name or IP address as the host. As specified in [RFC 1738], the part must include a fully qualified domain name or IP address as the
scheme name is not case-sensitive (e.g., "http" is equivalent to host. As specified in [RFC 1738], the scheme name is not case-
"HTTP"). The host part is also not case-sensitive, but other sensitive (e.g., "http" is equivalent to "HTTP"). The host part is
components of the scheme-specific-part may be case-sensitive. When also not case-sensitive, but other components of the scheme-specific-
comparing URIs, conforming implementations MUST compare the scheme part may be case-sensitive. When comparing URIs, conforming
and host without regard to case, but assume the remainder of the implementations MUST compare the scheme and host without regard to
scheme-specific-part is case sensitive." case, but assume the remainder of the scheme-specific-part is case
sensitive."
Aresenault, Turner November, 2000 35
5.1.2 Scope of Names 5.1.2 Scope of Names
The original X.500 work presumed that every subject in the world The original X.500 work presumed that every subject in the world
would have a globally unique distinguished name. Thus, every subject would have a globally unique distinguished name. Thus, every subject
could be easily located, and there would never be a conflict. All could be easily located, and there would never be a conflict. All
that would be needed is a sufficiently large name space, and rules that would be needed is a sufficiently large name space, and rules
for constructing names based on subordination and location. for constructing names based on subordination and location.
Obviously, that is not practical in the real world, for a variety of Obviously, that is not practical in the real world, for a variety of
reasons. There is no single entity in the world trusted by everybody reasons. There is no single entity in the world trusted by everybody
to reside at the top of the name space, and there is no way to to reside at the top of the name space, and there is no way to
enforce uniqueness on names for all entities. (These were among the enforce uniqueness on names for all entities. (These were among the
reasons for the failure of PEM to be widely implemented.) reasons for the failure of PEM to be widely implemented.)
This does not mean, however, that a name-based PKI cannot work. It This does not mean, however, that a name-based PKI cannot work. It is
is important to recognize that the scope of names in PKIX is local; important to recognize that the scope of names in PKIX is local; they
they need to be defined and unique only within their own domain. need to be defined and unique only within their own domain.
Suppose for example that a Top CA is established with DN "O=IETF, Suppose for example that a Top CA is established with DN "O=IETF,
OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects OU=PKIX, CN=PKIX_CA". That CA will then issue PKCs for subjects
subordinate to it. The only requirement, which can be enforced subordinate to it. The only requirement, which can be enforced
procedurally, is that no two distinct entities beneath this Top CA procedurally, is that no two distinct entities beneath this Top CA
have the same name. We can't prevent somebody else in the world from have the same name. We can't prevent somebody else in the world from
creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is
Arsenault, Turner 37
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 This is analogous to the current DNS or IP address situations. On the
the Internet, there is only one node called www.ietf.org. The fact Internet, there is only one node called www.ietf.org. The fact that
that there might be 10 different intranets, each with a host given there might be 10 different intranets, each with a host given the DNS
the DNS name www.ietf.org, is irrelevant and causes no name www.ietf.org, is irrelevant and causes no interoperability
interoperability problems - those are different domains. However, if problems - those are different domains. However, if there were to be
there were to be another node on the Internet with domain name another node on the Internet with domain name www.ietf.org, then
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 the Internet each responded to the IP address 130.85.1.3, there would
would be a problem. be a problem.
5.1.3 Certificate Path Construction 5.1.3 Certificate Path Construction
Certificate path construction has been the topic of many discussions Certificate path construction has been the topic of many discussions
in the WG. The issue centered on how best to get a certificate when in the WG. The issue centered on how best to get a certificate when
the connection between the subject's name and the name of their CA, the connection between the subject's name and the name of their CA,
as well as the CA's repository (or directory), may not be obvious. as well as the CA's repository (or directory), may not be obvious.
Many proposals were put forth, including implementing a global X.500 Many proposals were put forth, including implementing a global X.500
Aresenault, Turner November, 2000 36
Directory Service, using DNS SRV records, and using an extension to Directory Service, using DNS SRV records, and using an extension to
point to the directory provider. At the end of the discussion the point to the directory provider. At the end of the discussion the
group decided to use the authority information access extension group decided to use the authority information access extension
defined in [FORMAT], which allows the CA to indicate the access defined in the Internet PKI Profile [2459bis], which allows the CA to
method and location of CA information and services. The extension indicate the access method and location of CA information and
would be included in subject's certificates and could be used to services. The extension would be included in subject's certificates
associate an Internet style identity for the location of repository and could be used to associate an Internet style identity for the
to retrieve the issuer's certificate in cases where such a location location of repository to retrieve the issuer's certificate in cases
is not related to the issuer's name. where such a location is not related to the issuer's name.
Another discussion related to certificate path construction was Another discussion related to certificate path construction was where
where to store the CA and EE PKCs in the directory (specifically to store the CA and EE PKCs in the directory (specifically LDAPv2
LDAPv2 directories). Two camps emerged with different views on where directories). Two camps emerged with different views on where to
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 and from another domain stored in the PKCs issued to and from another domain stored in the
crossCertificatePair attribute. There was a short discussion that crossCertificatePair attribute. There was a short discussion that the
the second was more efficient than first and that one solution or second was more efficient than first and that one solution or the
the other was more widely deployed. The end result was to indicate other was more widely deployed. The end result was to indicate that
that self-issued PKCs and PKCs issued to the CA by CAs in the same self-issued PKCs and PKCs issued to the CA by CAs in the same domain
domain as the CA are stored in the cACertificate attribute. The as the CA are stored in the cACertificate attribute. The
crossCertificatePair attribute's forward element will include all crossCertificatePair attribute's forward element will include all but
but self-issued PKCs issued to the CA. The reverse element may
include a subset of PKCs issued by the CA to other CAs. With this Arsenault, Turner 38
resolution both camp's implementations are supported and are free to self-issued PKCs issued to the CA. The reverse element may include a
choose the location of CA PKCs to best support their implementation. subset of PKCs issued by the CA to other CAs. With this resolution
both camp's implementations are supported and are free to choose the
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 A question that has arisen a number of times is "how does one enforce
enforce Name constraints when there is more than one name form in a Name constraints when there is more than one name form in a PKC?"
PKC?" That is, [FORMAT] states that: That is, the Internet PKI Profile [2459bis] states that:
Subject's alternative names may be constrained in the same manner as 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. 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 with an empty DN, with subjectAltName extension having dNSName set to
to "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. "PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The
The question is: are name constraints enforced on these two PKCs - question is: are name constraints enforced on these two PKCs - is the
is the name of the EE PKC considered to be properly subordinate to name of the EE PKC considered to be properly subordinate to the name
the name of the CA? of the CA?
Aresenault, Turner November, 2000 37
The answer is "yes". The general rules for deciding whether a PKC The answer is "yes". The general rules for deciding whether a PKC
meets name constraints are: meets name constraints are:
- If a PKC complies with name constraints in any one of its name - If a PKC complies with name constraints in any one of its name
forms, then the PKC is deemed to comply with name constraints. forms, then the PKC is deemed to comply with name constraints.
- If a PKC contains a name form that its issuer does not, the PKC - If a PKC contains a name form that its issuer does not, the PKC is
is deemed to comply with name constraints for that name form. deemed to comply with name constraints for that name form.
In deciding whether a name form meets name constraints, the In deciding whether a name form meets name constraints, the following
following rules apply (in all cases Name B is the name in the name rules apply (in all cases Name B is the name in the name constraints
constraints extension): extension):
5.1.4.1 rfc822Names 5.1.4.1 rfc822Names
Three variations are allowed: Three variations are allowed:
- If the name constraint is specified as "larry@mail.mit.edu", then - If the name constraint is specified as "larry@mail.mit.edu", then
Name A is subordinate to Name B (in B's subtree) if Name A Name A is subordinate to Name B (in B's subtree) if Name A
contains all of Name B's name (specifies a particular mailbox). contains all of Name B's name (specifies a particular mailbox).
For example, larry@mail.mit.edu is subordinate, but For example, larry@mail.mit.edu is subordinate, but
larry_sanders@mail.mit.edu is not. larry_sanders@mail.mit.edu is not.
- If the name constraint is specified as "mail.mit.edu", then Name - If the name constraint is specified as "mail.mit.edu", then Name A
A is subordinate to Name B (in B's subtree) if Name A contains is subordinate to Name B (in B's subtree) if Name A contains all
all of Name B's name (specified all mailboxes on host of Name B's name (specified all mailboxes on host mail.mit.edu).
mail.mit.edu). For example, curly@mail.mit.edu and For example, curly@mail.mit.edu and mo@mail.mit.edu are
mo@mail.mit.edu are subordinate, but mo@mail6.mit.edu and
curly@smtp.mail.mit.edu are not.
- If the name constraint is specified as ".mit.edu", then Name A is Arsenault, Turner 39
subordinate to Name B (in B's subtree) if Name A contains all of subordinate, but mo@mail6.mit.edu and curly@smtp.mail.mit.edu are
Name B's name, with the addition of zero or more additional host not.
or domain names to the left of Name B's name. That is,
smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu.
However, mit.edu is not subordinate to .mit.edu. When the
constraint begins with a "." it specifies any address within a
domain. In the previous example, "mit.edu" is not in the domain
of ".mit.edu".
Note: If rfc822 names are constrained, but the PKC does not - If the name constraint is specified as ".mit.edu", then Name A is
contain a subjectAltName extension, the EmailAddress attribute subordinate to Name B (in B's subtree) if Name A contains all of
will be used to constrain the name in the subject distinguished Name B's name, with the addition of zero or more additional host
name. For example (c is country, o is organization, ou is or domain names to the left of Name B's name. That is,
organizational unit, and em is EmailAddress), Name A ("c=US, smtp.mit.edu is subordinate to .mit.edu, as is pop.mit.edu.
o=MIT, ou=CS, em=curly@mail.mit.edu") is subordinate to Name B However, mit.edu is not subordinate to .mit.edu. When the
("c=US, o=MIT, ou=CS") (in B's subtree) if Name A contains all of constraint begins with a "." it specifies any address within a
Name B's names. domain. In the previous example, "mit.edu" is not in the domain of
".mit.edu".
Note: If rfc822 names are constrained, but the PKC does not contain a
subjectAltName extension, the EmailAddress attribute will be used to
constrain the name in the subject distinguished name. For example (c
is country, o is organization, ou is organizational unit, and em is
EmailAddress), Name A ("c=US, o=MIT, ou=CS, em=curly@mail.mit.edu")
is subordinate to Name B ("c=US, o=MIT, ou=CS") (in B's subtree) if
Name A contains all of Name B's names.
Aresenault, Turner November, 2000 38
5.1.4.2 dNSNames 5.1.4.2 dNSNames
Name A is subordinate to Name B (in B's subtree) if Name A contains Name A is subordinate to Name B (in B's subtree) if Name A contains
all of Name B's name, with the addition of zero or more additional all of Name B's name, with the addition of zero or more additional
domain names to the left of Name B's name. That is, www.mit.edu is domain names to the left of Name B's name. That is, www.mit.edu is
subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu subordinate to mit.edu, as is larry.cs.mit.edu. However, www.mit.edu
is not subordinate to web.mit.edu. is not subordinate to web.mit.edu.
5.1.4.3 x.400 addresses 5.1.4.3 x.400 addresses
skipping to change at line 1972 skipping to change at line 2065
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 other types case is not ignored), removing leading and trailing white
white space in PrintableString, and converting internal substrings space in PrintableString, and converting internal substrings of one
of one or more consecutive white space characters to a single space. or more consecutive white space characters to a single space. For
For example, (c is country, o is organization, ou is organizational
unit, and cn is common name):
- Assuming PrintableString types for all attribute values in Name A Arsenault, Turner 40
and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT, example, (c is country, o is organization, ou is organizational unit,
ou=cs", as is "c=US, o=MIT, ou=CS, ou=administration". Another and cn is common name):
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".
- Assuming UTF8String types for all attribute values in Name A and - Assuming PrintableString types for all attribute values in Name A
B, "c=US, o=MIT, ou=CS, ou=administration" is subordinate to and B, "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT,
"c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, ou=cs", as is "c=US, o=MIT, ou=CS, ou=administration". Another
ou=Administration". "c=US, o=MIT, ou=CS, cn= John Smith" (note example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white
the white spaces) is not subordinate to "c=US, o=MIT, ou=CS, cn= spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe".
John Smith".
- Assuming UTF8String types for all attribute values in Name A and - Assuming UTF8String types for all attribute values in Name A and B,
PrintableString types for all attribute values in Name B, "c=US, "c=US, o=MIT, ou=CS, ou=administration" is subordinate to "c=US,
o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if the o=MIT, ou=CS", but "c=US, o=MIT, ou=cs, ou=Administration". "c=US,
verification software supports the full comparison algorithm in o=MIT, ou=CS, cn= John Smith" (note the white spaces) is not
the X.500 series. "c=US, o=MIT, ou=cs" is NOT subordinate to subordinate to "c=US, o=MIT, ou=CS, cn= John Smith".
"c=US, o=MIT, ou=CS" if the verification software supports the
comparison algorithm in [FORMAT]. - Assuming UTF8String types for all attribute values in Name A and
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
verification software supports the full comparison algorithm in
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
comparison algorithm in the Internet PKI Profile [2459bis].
Aresenault, Turner November, 2000 39
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
www.mit.edu is subordinate to .mit.edu, as is curly.cs.mit.edu. is subordinate to .mit.edu, as is curly.cs.mit.edu. However,
However, mit.edu is not subordinate to .mit.edu. When the mit.edu is not subordinate to .mit.edu. When the constraint begins
constraint begins with a "." it specifies a host. 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 contains 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
name is allowed. 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 net 00 00 FF FF FF 00) (in B's subtree) if Name A falls within the net
denoted in Name B's CIDR notation. denoted in Name B's CIDR notation.
- For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded Arsenault, Turner 41
as 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is subordinate - For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762 encoded as
to Name B (4224.0.0.0.8.2048.8204.0/ 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is subordinate to
65535.65535.65535.65535.65535.65535.65535.0 encoded as Name B (4224.0.0.0.8.2048.8204.0/
10 80 00 00 00 00 00 00 00 08 08 00 20 0C 00 00 65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00 00
FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00) (in B's subtree) 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF FF FF
if Name A falls within the net denoted in Name B's CIDR notation. FF FF FF FF 00 00) (in B's subtree) if Name A falls within the net
denoted in Name B's CIDR notation.
5.1.4.8 Others 5.1.4.8 Others
As [FORMAT] does not define requirements for the name forms As the Internet PKI Profile [2459bis] does not define requirements
otherName, ediPartyName, or registeredID there are no corresponding for the name forms otherName, ediPartyName, or registeredID there are
name constraints requirements. no corresponding name constraints requirements.
5.1.5 Wildcards in Name Forms 5.1.5 Wildcards in Name Forms
A "wildcard" in a name form is a placeholder for a set of names A "wildcard" in a name form is a placeholder for a set of names
(e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and (e.g., "*.mit.edu" meaning "any domain name ending in .mit.edu", and
*@aol.com meaning "email address that uses aol.com"). There are many *@aol.com meaning "email address that uses aol.com"). There are many
people who believe that allowing wildcards in name forms in PKIX people who believe that allowing wildcards in name forms in PKIX PKCs
PKCs would be a useful thing to do, because it would allow a single would be a useful thing to do, because it would allow a single PKC to
PKC to be used by all members of a group. These members would be used by all members of a group. These members would presumably
presumably have attributes in common; e.g., access rights to some have attributes in common; e.g., access rights to some set of
resources, and so issuance of a PKC with a wildcard for the group
Aresenault, Turner November, 2000 40 would simplify management.
set of resources, and so issuance of a PKC with a wildcard for the
group would simplify management.
After much discussion, the PKIX working group decided to permit the After much discussion, the PKIX working group decided to permit the
use of wildcards in PKCs. That is, it is permissible for a PKIX- use of wildcards in PKCs. That is, it is permissible for a PKIX-
conformant CA to issue a PKC with a wildcard. However, the semantics conformant CA to issue a PKC with a wildcard. However, the semantics
of subjectAltName extension that include wildcard characters are not of subjectAltName extension that include wildcard characters are not
addressed by PKIX. Applications with specific requirements may use addressed by PKIX. Applications with specific requirements may use
such names but must define the semantics. such names but must define the semantics.
5.1.6 Name Encoding 5.1.6 Name Encoding
A very important topic that consumed much of the WG's time was the A very important topic that consumed much of the WG's time was the
implementation of the directory string choices. While the long term implementation of the directory string choices. While the long term
goal of the IETF was clear, use UTF8String, the short term goals goal of the IETF was clear, use UTF8String, the short term goals were
were not so clear. Many implementations only use PrintableString, not so clear. Many implementations only use PrintableString, others
others use BMPString, and still others use Latin1String (ISO 8859-1) use BMPString, and still others use Latin1String (ISO 8859-1) and tag
and tag it as TeletexString (there are others still). To ensure that it as TeletexString (there are others still). To ensure that there is
there is consistency with encodings [FORMAT] defines a set of rules consistency with encodings the Internet PKI Profile [2459bis] defines
for the string choices. PrintableString was kept as the first choice a set of rules for the string choices. PrintableString was kept as
because of it's widespread support by vendors. BMPString was the the first choice because of it's widespread support by vendors.
second choice, also for it's widespread vendor support. Failing BMPString was the second choice, also for it's widespread vendor
support by PrintableString and BMPString, UTF8String must be used. support. Failing support by PrintableString and BMPString, UTF8String
In keeping with the IETF mandate, UTF8String can be used at any time must be used. In keeping with the IETF mandate, UTF8String can be
if the CA supports it. Also, processing implementations that wish to used at any time if the CA supports it. Also, processing
support TeletexString should handle the entire ISO 8859-1 character implementations that wish to support TeletexString should handle the
set and not just the Latin1String subset. entire ISO 8859-1 character set and not just the Latin1String subset.
Arsenault, Turner 42
5.2 POP 5.2 POP
Proof of Possession, or POP, or also CA POP, means that the CA is Proof of Possession, or POP, or also CA POP, means that the CA is
adequately convinced that the entity requesting a PKC containing a adequately convinced that the entity requesting a PKC containing a
public key Y has access to the private key X corresponding to that public key Y has access to the private key X corresponding to that
public key. public key.
There has been some debate whether POP was or not needed. There has been some debate whether POP was or not needed.
This question needs to be addressed separately considering the This question needs to be addressed separately considering the
context of use of the key, in particular whether a key is used for context of use of the key, in particular whether a key is used for an
an authentication or non repudiation service, or in a authentication or non repudiation service, or in a confidentiality
confidentiality service. Note that this does not map to the key service. Note that this does not map to the key usage bit directly,
usage bit directly, since it is possible to use a confidentiality since it is possible to use a confidentiality key to perform an
key to perform an authentication service, e.g. by asking to decrypt authentication service, e.g. by asking to decrypt an encrypted
an encrypted challenge. 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. 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
Aresenault, Turner November, 2000 41 from Charlie containing the same public key, Y. Now without POP,
Alice uses X to sign a transaction T. Without POP, Mal could also there are two possible threats: Mal could claim to have been the real
get a PKC from Charlie containing the same public key, Y. Now signer of T; or Alice can falsely deny signing T, claiming that it
without POP, there are two possible threats: Mal could claim to have was instead Mal. Since no one can reliably prove that Mal did or did
been the real signer of T; or Alice can falsely deny signing T, not ever possess X, neither of these claims can be refuted, and thus
claiming that it was instead Mal. Since no one can reliably prove the service provided by and the confidence in the PKI has been
that Mal did or did not ever possess X, neither of these claims can defeated. (Of course, if Mal really did possess X, Alice's private
be refuted, and thus the service provided by and the confidence in key, then no POP mechanism in the world will help, but that is a
the PKI has been defeated. (Of course, if Mal really did possess X, different problem.)
Alice's private key, then no POP mechanism in the world will help,
but that is a different problem.)
Protection can be gained by having Alice, as the true signer of the Protection can be gained by having Alice, as the true signer of the
transaction, include in the signed information her PKC or an transaction, include in the signed information her PKC or an
identifier of her PKC (e.g., a hash of her PKC). This makes identifier of her PKC (e.g., a hash of her PKC). This makes
impossible for Mal to claim authorship because he does not know the impossible for Mal to claim authorship because he does not know the
private key from Alice and thus is unable to include his certificate private key from Alice and thus is unable to include his certificate
under the signature. under the signature.
The adequate protection may be obtained in the general case, by The adequate protection may be obtained in the general case, by
mandating the inclusion of a reference of the certificate every time mandating the inclusion of a reference of the certificate every time
a signature (or non repudiation) key is being used in a protocol. a signature (or non repudiation) key is being used in a protocol.
However, because all the protocols were not doing so, a conservative However, because all the protocols were not doing so, a conservative
measure has been taken by requesting POP to be performed by CAs. It measure has been taken by requesting POP to be performed by CAs. It
should thus be understood, that this measure is not strictly should thus be understood, that this measure is not strictly
necessary and is only a temporary measure to make old protocols necessary and is only a temporary measure to make old protocols
secure. New protocols or data formats are being developed. If the secure. New protocols or data formats are being developed. If the key
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 Arsenault, Turner 43
not necessary. The inclusion of the identifier of the certificate in being used is always used in a context where the identifier of the
the protocol or data format may be understood as POP being performed certificate is included in the protocol, then POP by the CA is not
at the transaction time rather than by the CA, at the registration necessary. The inclusion of the identifier of the certificate in the
time of the user in the PKI. 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
Suppose that Al is a new instructor in the Computer Science Suppose that Al is a new instructor in the Computer Science
Department of a local University. Al has created a draft final exam Department of a local University. Al has created a draft final exam
for the Introduction to Networking course he is teaching. He wants for the Introduction to Networking course he is teaching. He wants to
to send a copy of the draft final to Dorothy, the Department Head, send a copy of the draft final to Dorothy, the Department Head, for
for her review prior to giving the exam. This exam will of course be her review prior to giving the exam. This exam will of course be
encrypted, as several students have access to the computer system. encrypted, as several students have access to the computer system.
However, a quick search of the PKC repository (e.g., search the However, a quick search of the PKC repository (e.g., search the
repository for all records with subjectPublicKey=Dorothy's-value) repository for all records with subjectPublicKey=Dorothy's-value)
turns up the fact that several students have PKCs containing the turns up the fact that several students have PKCs containing the same
same public key management key as Dorothy. At this point, if no POP public key management key as Dorothy. At this point, if no POP has
has been done by the CA, Al has no way of knowing whether all of the been done by the CA, Al has no way of knowing whether all of the
students have simply created these PKCs without knowing the students have simply created these PKCs without knowing the
corresponding private key (and thus it is safe to send the encrypted corresponding private key (and thus it is safe to send the encrypted
exam to Dorothy), or whether the students have somehow acquired exam to Dorothy), or whether the students have somehow acquired
Aresenault, Turner November, 2000 42
Dorothy's private key (and thus it is certainly not safe to send the Dorothy's private key (and thus it is certainly not safe to send the
exam). exam).
The later case may seem unsafe. However, if the other students have The later case may seem unsafe. However, if the other students have
acquired the key, they do not even need to publish their acquired the key, they do not even need to publish their certificates
certificates and can simply decrypt in parallel. and can simply decrypt in parallel.
The end story is that, if the key only known to Dorothy, there is no The end story is that, if the key only known to Dorothy, there is no
problem. Thus POP by the CA is not needed. problem. Thus POP by the CA is not needed.
If the key, like a Diffie-Hellman key, is used for an authentication If the key, like a Diffie-Hellman key, is used for an authentication
service the answer depends from the protocol being used. In the service the answer depends from the protocol being used. In the
former example, the decryption was done locally and no data was sent former example, the decryption was done locally and no data was sent
back on the wire. In an authentication protocol, the story is back on the wire. In an authentication protocol, the story is
different because either some encrypted or decrypted data is sent different because either some encrypted or decrypted data is sent
back. If the data sent back contains the identifier of the back. If the data sent back contains the identifier of the
certificate in a way that it cannot be modified without that certificate in a way that it cannot be modified without that
modification being detected, then there is no need for POP. On the modification being detected, then there is no need for POP. On the
contrary, POP by the CA is needed. contrary, POP by the CA is needed.
As a conservative measure, POP for encryption keys is recommended, As a conservative measure, POP for encryption keys is recommended,
but it should be realized that it is not always needed. but it should be realized that it is not always needed.
In general it should be noticed that POP at the time of the 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 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 possible in real time to be sure that everything is correct, rather
than rely on that verification to be done at the time of than rely on that verification to be done at the time of registration
registration by the CA. Should the CA fail in that verification, by the CA. Should the CA fail in that verification, then there is a
then there is a security breach. On the contrary, doing POP at the
time of the transaction, eliminates that problem. Arsenault, Turner 44
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 a PKC requester can provide POP to either a CA or to an RA, if the RA
RA can adequately assure the CA that POP has been performed. Some of can adequately assure the CA that POP has been performed. Some of the
the acceptable ways to provide POP include: acceptable ways to provide POP include:
- Out-of-band means:
- For keys generated by the CA or an RA (e.g., on a token such as - Out-of-band means:
a smart card or PCMCIA card), possession of the token can
provide adequate proof of possession of the private key.
- For user-generated keys, another approach can be used in - For keys generated by the CA or an RA (e.g., on a token such as
environments where "key recovery" requirements force the a smart card or PCMCIA card), possession of the token can
requester to provide a copy of the private key to the CA or an provide adequate proof of possession of the private key.
RA. In this case, the CA will not issue the requested PKC until
such time as the requester has provided the private key. This
approach is in general not recommended, as it is extremely
risky (e.g., the system designers need to figure out a way to
Aresenault, Turner November, 2000 43 - For user-generated keys, another approach can be used in
protect the private keys from compromise while they are being environments where "key recovery" requirements force the
sent to the CA/RA/other authority, and how to protect them requester to provide a copy of the private key to the CA or an
there), but it can be used. RA. In this case, the CA will not issue the requested PKC until
such time as the requester has provided the private key. This
approach is in general not recommended, as it is extremely risky
(e.g., the system designers need to figure out a way to protect
the private keys from compromise while they are being sent to
the CA/RA/other authority, and how to protect them there), but
it can be used.
- On-line means: - On-line means:
- For signature keys that are generated by an EE, the requester - For signature keys that are generated by an EE, the requester of
of a PKC can be required to sign some piece of data (typically, a PKC can be required to sign some piece of data (typically, the
the PKC request itself) using the private key. The CA will then PKC request itself) using the private key. The CA will then use
use the requested public key to verify the signature. If the 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
the CA can send the user the requested public key, along with CA can send the user the requested public key, along with the
the CA's own public key, to encrypt some piece of data, and CA's own public key, to encrypt some piece of data, and send it
send it to the requester to be decrypted. For example, the CA to the requester to be decrypted. For example, the CA can
can generate some random challenge, and require some action to generate some random challenge, and require some action to be
be taken after decryption (e.g., "decrypt this encrypted random 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 Another method of providing POP for key management keys is for the CA
CA to generate the requested PKC, and then send it to the requester to generate the requested PKC, and then send it to the requester in
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 used, the CA will revoke the PKC. (This only works if the PKC is Arsenault, Turner 45
not made available to any untrusted entities until after the thus cannot use it. After some period of time in which the PKC is not
requester has successfully decrypted it.) 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
has successfully decrypted it.)
5.3 Key Usage Bits 5.3 Key Usage Bits
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. signature, certificate signing) of the key contained in the PKC. This
This extension is used when a key that could be used for more than extension is used when a key that could be used for more than one
one operation is to be restricted. For example, if a CA's RSA key operation is to be restricted. For example, if a CA's RSA key should
should be used only for signing CRLS, the cRLSign bit would be be used only for signing CRLS, the cRLSign bit would be asserted.
asserted. Likewise, when an RSA key should be used only for key Likewise, when an RSA key should be used only for key management, the
management, the keyEncipherment bit would be asserted. When used, keyEncipherment bit would be asserted. When used, this extension
this extension should be marked critical. should be marked critical.
[FORMAT] includes some text for how the bits in the KeyUsage type
are used. Developing the text for some of the bits was easy;
however, many discussions were needed to arrive at a common
agreement on the meaning of the digitalSignature (DS bit) and
nonRepudiation (NR bit) bits and when they should be set. The group
Aresenault, Turner November, 2000 44 The Internet PKI Profile [2459bis] includes some text for how the
quickly realized that key usage extension mixes services and bits in the KeyUsage type are used. Developing the text for some of
the bits was easy; however, many discussions were needed to arrive at
a common agreement on the 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 mechanisms. The DS bit indicates a mechanism - a public key used to
verify a digital signature. The NR bit indicates a service - a verify a digital signature. The NR bit indicates a service - a public
public key used to verify a digital signature and to provide a non- key used to verify a digital signature and to provide a non-
repudiation service. When trying to indicate when each bit should be repudiation service. When trying to indicate when each bit should be
indicated arguments were based on: indicated arguments were based on:
The lifetime of the object being singed. Some felt that the DS bit The lifetime of the object being singed. Some felt that the DS bit
should be set when the certificate is used to sign ephemeral objects should be set when the certificate is used to sign ephemeral objects
(e.g., bind tokens) while the NR bit should be set for things that (e.g., bind tokens) while the NR bit should be set for things that
are survive longer (e.g., documents). Of course, the problem with are survive longer (e.g., documents). Of course, the problem with
this distinction to determine how long is the time period for this distinction to determine how long is the time period for
ephemeral? ephemeral?
A conscious act taken by the signer. Many felt that the NR bit A conscious act taken by the signer. Many felt that the NR bit should
should be set only when the subject has expressly acknowledged that be set only when the subject has expressly acknowledged that they
they want to use the private key to sign an object. Signing a want to use the private key to sign an object. Signing a document say
document say where there is a conscious decision by the subject where there is a conscious decision by the subject would be
would be appropriate for the key usage extension to contain NR, but appropriate for the key usage extension to contain NR, but when the
when the key is used for authentication purposes, which can occur key is used for authentication purposes, which can occur
automatically and more frequently, the DS bit is more appropriate. automatically and more frequently, the DS bit is more appropriate.
The discussion also concluded that since some authentication schemes The discussion also concluded that since some authentication schemes
occur automatically, that the DS bit and NR bit should never be set occur automatically, that the DS bit and NR bit should never be set
together in the same certificate. Some agreed to the differentiation 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 of the bits based on the time, but did not agree that the two could
not be in the same key usage extension. not be in the same key usage extension.
The procedures followed by the CA. Some felt that NR bit was kind of The procedures followed by the CA. Some felt that NR bit was kind of
'quality mark' indicating to the verifier that the verifier could be 'quality mark' indicating to the verifier that the verifier could be
assured that the CA is implementing appropriate procedures for assured that the CA is implementing appropriate procedures for
checking the subject's identity, performing certificate archival, checking the subject's identity, performing certificate archival,
Arsenault, Turner 46
etc. Other felt that it was not entirely the CAs job and that some etc. Other felt that it was not entirely the CAs job and that some
other entity must be involved. other entity must be involved.
In the end the WG agreed to a few things: In the end the WG agreed to a few things:
- Provision of the service of non-repudiation requires more than a - Provision of the service of non-repudiation requires more than a
single bit set in a PKC. It requires an entire infrastructure of single bit set in a PKC. It requires an entire infrastructure of
components to preserve for some period of time the keys, PKCs, components to preserve for some period of time the keys, PKCs,
revocation status, signed material, etc., as well as a trusted revocation status, signed material, etc., as well as a trusted
source of time. However, the nonRepudiation key usage bit is source of time. However, the nonRepudiation key usage bit is
provided as an indicator that such keys could be used as a provided as an indicator that such keys could be used as a
component of a system providing a non-repudiation service. component of a system providing a non-repudiation service.
- The certificate policy is the appropriate place to indicate the - The certificate policy is the appropriate place to indicate the
permitted combinations of key usages. That is, a policy may permitted combinations of key usages. That is, a policy may
indicate that the DS and NR bits can not be set in the same indicate that the DS and NR bits can not be set in the same
certificate while another may say that the DS and NR bits can be certificate while another may say that the DS and NR bits can be
set in the same certificate. set in the same certificate.
[2459bis] includes new text indicating the above agreements. [2459bis] includes new text indicating the above agreements.
Aresenault, Turner November, 2000 45
5.4 Non-Repudiation 5.4 Non-Repudiation
The major benefit of the whole DS bit vs NR bit discussion is The major benefit of the whole DS bit vs NR bit discussion is
development of the Technical Requirements for Non-Repudiation development of the Technical Requirements for Non-Repudiation
[TECHNR] draft. To fill this void [TECHNR] was developed to [TECHNR] draft. To fill this void [TECHNR] was developed to "describe
"describe those features of a service which processes signed those features of a service which processes signed documents which
documents which must be present in order for that service to must be present in order for that service to constitute a 'technical
constitute a 'technical non-repudiation' service." The basic non-repudiation' service." The basic understanding of non-repudiation
understanding of non-repudiation is that it requires that a digital is that it requires that a digital signature be preserved in such a
signature be preserved in such a manner that it can convince a manner that it can convince a neutral third party that it was
neutral third party that it was actually created by someone with actually created by someone with access to the private key of a
access to the private key of a certified key pair. Whether this certified key pair. Whether this definition of non-repudiation is
definition of non-repudiation is enough to form a legally bind enough to form a legally bind agreement is still being debated.
agreement is still being debated.
5.5 Trust Models 5.5 Trust Models
An important design decision is where a particular EE's trust point An important design decision is where a particular EE's trust point
is located (i.e., where is the EE's Root CA). There are a number of is located (i.e., where is the EE's Root CA). There are a number of
models that have been developed and depending on the environment models that have been developed and depending on the environment some
some models may be more suited than others. The following provides models may be more suited than others. The following provides some
some background on the models. background on the models.
5.5.1 Hierarchical 5.5.1 Hierarchical
One of the initial trust models proposed was the hierarchical model. One of the initial trust models proposed was the hierarchical model.
In this model the trust point or root CA for an entire domain is the In this model the trust point or root CA for an entire domain is the
top most CA. The root CA in turn issues certificates to subordinate top most CA. The root CA in turn issues certificates to subordinate
CAs, and the subordinate CAs issue certificates to EEs. When CAs, and the subordinate CAs issue certificates to EEs. When
verifying a PKC, the RP must verify ever certificate in the path
from the EE's PKC to the root CA. Arsenault, Turner 47
verifying a PKC, the RP must verify ever certificate in the path from
the EE's PKC to the root CA.
The main benefit of the hierarchical model is the fact that controls The main benefit of the hierarchical model is the fact that controls
imposed from the top down. For example, name constraints can be imposed from the top down. For example, name constraints can be
included in the subordinate CAs to limit the name space in which included in the subordinate CAs to limit the name space in which they
they are allowed to issue certificates. Further, the root CA ensure are allowed to issue certificates. Further, the root CA ensure domain
domain wide policies on cross-certification (though there are no wide policies on cross-certification (though there are no controls to
controls to prevent another PKI from issuing PKCs to members of the prevent another PKI from issuing PKCs to members of the domain, but
domain, but then those members could be thought of as members of two then those members could be thought of as members of two distinct
distinct PKIs). PKIs).
Interoperability is achieved through the use of cross-certificates. Interoperability is achieved through the use of cross-certificates.
Cross-certificates can be issued by the root CA or if allowed by Cross-certificates can be issued by the root CA or if allowed by
subordinate CAs. subordinate CAs.
5.5.2 Local/Federation 5.5.2 Local/Federation
Another model that has been around a long time is the local trust Another model that has been around a long time is the local trust
model. In this model, the RPs trust the CA that issued their model. In this model, the RPs trust the CA that issued their
certificate to them. The idea is that since the CA is local and certificate to them. The idea is that since the CA is local and
Aresenault, Turner November, 2000 46
probably known to the RP, that there is more trust rather than with probably known to the RP, that there is more trust rather than with
some distant unknown CA. some distant unknown CA.
In order for EEs under different CAs to communicate the CAs issue In order for EEs under different CAs to communicate the CAs issue
each other certificates thereby creating a certification path from each other certificates thereby creating a certification path from
one EE to another. The process of the CAs issuing one another PKCs one EE to another. The process of the CAs issuing one another PKCs
forms a kind of federation forms a kind of federation
The main benefit of the local model is its flexibility. Many believe The main benefit of the local model is its flexibility. Many believe
that the local CA knows best how to support its user community and that the local CA knows best how to support its user community and
should be given cart blanche to generate certificates as it sees fit should be given cart blanche to generate certificates as it sees fit
to allow the user community to perform their functions. to allow the user community to perform their functions.
5.5.3 Root Repository 5.5.3 Root Repository
A model made famous in the web browser community is the root A model made famous in the web browser community is the root
repository. This model uses a file to store the PKCs of many CAs. repository. This model uses a file to store the PKCs of many CAs. The
The RP then trusts any PKC included in the file. The PKC included in RP then trusts any PKC included in the file. The PKC included in the
the root repository may be a root CA for some other domain or root repository may be a root CA for some other domain or subordinate
subordinate CA, but when included in the trust file whatever type of CA, but when included in the trust file whatever type of PKC it is in
PKC it is in the other domain, it becomes a root CA for the RP. the other domain, it becomes a root CA for the RP. Obviously, the
Obviously, the main advantage is the fact that cross-certification main advantage is the fact that cross-certification is not required.
is not required. If the RP does not have the root CA's certificate If the RP does not have the root CA's certificate and it is included
and it is included in with the object, the RP can just add it to the in with the object, the RP can just add it to the file to ôtrustö it
file to _trust_ it (this should only be done if the RP truly trusts (this should only be done if the RP truly trusts the root CA).
the root CA).
Arsenault, Turner 48
5.5.4 RP's Perspective 5.5.4 RP's Perspective
Another model recently getting attention is the model where instead Another model recently getting attention is the model where instead
of the CA imposing restraints on the RP (in the PKC), the RP instead of the CA imposing restraints on the RP (in the PKC), the RP instead
makes the determination as to which certificates to trust. The RP makes the determination as to which certificates to trust. The RP
determines which domain it will accept certificates from, which key determines which domain it will accept certificates from, which key
usages it will accept, etc. Cross-certification is also not required usages it will accept, etc. Cross-certification is also not required
because the RP can just chose to trust a particular PKC or domain of because the RP can just chose to trust a particular PKC or domain of
PKCs. This obviously turns the first three models on their heads. PKCs. This obviously turns the first three models on their heads.
Special care must be taken to ensure that the RP is properly Special care must be taken to ensure that the RP is properly
configured. configured.
6 Acknowledgements 6 References
A lot of the information in this document was taken from the PKIX [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
source documents; the authors of those deserve the credit for their 3", BCP 9, RFC 2026, October 1996.
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 things to say were (in alphabetical order, with apologies to
anybody we've missed): Sharon Boeyen, Santosh Chokhani, Warwick
Ford, Russ Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael
Myers, Tim Polk, Stefan Santesson, Dave Simonetti, Paul Hoffman,
Denis Pinkas, Ed Greck, Tom Gindin, Parag Namjoshi, Peter Sylvester,
and Michael Zolotarev.
Aresenault, Turner November, 2000 47 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
7 References Requirement Levels", BCP 14, RFC 2119, March 1997.
[2459bis] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet [2459bis] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and CRL Profile," X.509 Public Key Infrastructure Certificate and CRL Profile," <draft-
<draft-ietf-pkix-new-part1-02.txt>, 14 July 2000. ietf-pkix-new-part1-11.txt>, October 2001.
[2510bis] Adams, C., Farrell, S., _Internet X.509 Public Key [2510bis] Adams, C., Farrell, S., ôInternet X.509 Public Key
Infrastructure Certificate Management Protocols,_ <draft-ietf-pkix- Infrastructure Certificate Management Protocols,ö <draft-ietf-pkix-
rfc2510bis-01.txt>, July 2000. rfc2510bis-05.txt>, November 2001.
[AC] S. Farrell, R. HousleyMcNeil, M., and Glassey, T., "An Internet [2511bis] Myers, M., Adams, C., Solo, D., and Kemp D. öInternet X.509
Attribute Certificate Profile for Authorization," <draft-ietf-pkix- Public Key Infrastructure Certificate Request Message Format
ac509prof-05.txt>, 08 August 2000. (CRMF),ö <draft-ietf-pkix-rfc2511bis-03.txt>, November 2001.
[ADDSCHEMA] Chadwick, D., Legg, S., _Internet X.509 Public Key [2527bis] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and Wu,
Infrastructure Additional LDAP Schema for PKIs and PMIs,_ <draft- S., "Internet X.509 Public Key Infrastructure Certificate Policy and
ietf-pkix-ldap-schema-01.txt>, 8 September 2000. Certification Practices Framework," <draft-ietf-pkix-ipki-new-
rfc2527-00.txt>, 12 July 2001.
[AC] Farrell, S., and Housley, R., "An Internet Attribute Certificate
Profile for Authorization," <draft-ietf-pkix- ac509prof-09.txt>, June
2001.
[ADDSCHEMA] Chadwick, D., Legg, S., ôInternet X.509 Public Key
Infrastructure Additional LDAP Schema for PKIs and PMIs,ö <draft-
ietf-pkix-ldap-schema-02.txt>, November 2001.
[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," (RFC 2797), April 2000. Management Messages over CMS," (RFC 2797), April 2000.
[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.
Arsenault, Turner 49
[CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July [CMS] R. Housley, "Cryptographic Message Syntax," RFC 2630, July
1999. 1999.
[CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509 [CRMF] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet X.509
Certificate Request Message Format," RFC 2511, March 1999. Certificate Request Message Format," RFC 2511, March 1999.
[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.
[DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof- [DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-
of-Possession Algorithms," RFC 2875, July 2000 1999. of-Possession Algorithms," RFC 2875, July 2000 1999.
[DPD] Myers, M., Adams, C., Farrell, S., _Delegated Path Discovery [DPD] Myers, M., Adams, C., Farrell, S., ôDelegated Path Discovery
with OCSP,_ <draft-ietf-pkix-ocsp-path-00.txt>, September 2000. with OCSP,ö <draft-ietf-pkix-ocsp-path-00.txt>, September 2000.
[DPV] Myers, M., Adams, C., Farrell, S., _Delegated Path [DPV] Myers, M., Adams, C., Farrell, S., ôDelegated Path Validation,ö
Validation,_ <draft-ietf-pkix-ocsp-valid-00.txt>, August 2000. <draft-ietf-pkix-ocsp-valid-00.txt>, August 2000.
[DPREQ] Pinaks, D., "Delegated Path Validation and Delegated Path
Discovery Protocol Requirements (DPV&DPD-REQ)," <draft-ietf-pkix-dpv-
dpd-req-00.txt>, November 2001.
[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-05.txt>, 05 October 2000. Protocols", RFC 3029, February 2001.
[FORMAT] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and CRL Profile," RFC
2459, January 1999.
Aresenault, Turner November, 2000 48
[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.
[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.
[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 Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in
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 Attribute Certificate
Acquisition Protocol", <draft-ietf-pkix-laap-01.txt>, 14 July 2000. Acquisition Protocol", <draft-ietf-pkix-laap-01.txt>, 14 July 2000.
[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.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams,
C., "X.509 Internet Public Key Infrastructure Online Certificate C., "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP," RFC 2560, June 1999. Status Protocol - OCSP," RFC 2560, June 1999.
[OCSPv2] Myers, M., Ankney, R., Adams, C., _Online Certificate [OCSPv2] Myers, M., Ankney, R., Adams, C., ôOnline Certificate Status
Status Protocol, version 2,_ <draft-ietf-pkix-ocspv2-00.txt>, Protocol, version 2,ö <draft-ietf-pkix-ocspv2-00.txt>, September
September 2000. 2000.
Arsenault, Turner 50
[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.
[PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail: [PEM] Kent, S., "Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management," RFC 1422, February 1993. Part II: Certificate-Based Key Management," RFC 1422, February 1993.
[PI] Pinka, D., Gindin, T., _Internet X.509 Public Key [PI] Pinka, D., Gindin, T., ôInternet X.509 Public Key Infrastructure
Infrastructure Permanent Identifier,_ <draft-ietf-pkix-pi-01.txt>, Permanent Identifier,ö <draft-ietf-pkix-pi-02.txt>, April 2001.
August 2000.
[PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 [PKI-LDAPv2] Boeyen, S., Howes, T., and Richard, P., "Internet X.509
Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559, Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559,
April 1999. April 1999.
[PKI-LDAPv3] Chadwick, D.W., "Internet X.509 Public Key [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-03.txt>, 2 September 2000. ldap-v3-04.txt>, 20 November 2001.
[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.
Aresenault, Turner November, 2000 49
[QC] Santesson, S., Polk, W., Barzin, P., and Nystrom, M., "Internet [QC] Santesson, S., Polk, W., Barzin, P., and Nystrom, M., "Internet
X.509 Public Key Infrastructure Qualified Certificates," <draft- X.509 Public Key Infrastructure Qualified Certificates," RFC 3039,
ietf-pkix-qc-06.txt>, August 2000. January 2001.
[RLS] Boeyen, S., Hallam-Baker, P., _Internet X.509 Public Key [RLS] Boeyen, S., Hallam-Baker, P., ôInternet X.509 Public Key
Infrastructure Repository Locator Service,_ <draft-ietf-pkix- Infrastructure Repository Locator Service,ö <draft-ietf-pkix-
pkixrep-00.txt>, July 2000. pkixrep-00.txt>, July 2000.
[RPKDS] Bassham, L., Housley, R., Polk, N., _Internet X.509 Public [RPKDS] Bassham, L., Housley, R., Polk, W., ôInternet X.509 Public
Key Infrastructure Representation of Public Keys and Digital Key Infrastructure Representation of Public Keys and Digital
Signatures in Internet X.509 Public Key Infrastructure Signatures in Internet X.509 Public Key Infrastructure Certificates,ö
Certificates,_ <draft-ietf-pkix-ipki-pkalgs-00.txt>, 14 June, 2000. <draft-ietf-pkix-ipki-pkalgs-05.txt>, 14 June, 2001.
[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., Housley, R., and Freeman, T.,
Protocol (SCVP)," <draft-ietf-pkix-scvp-03.txt>, 12 June 2000. "Simple Certificate Validation Protocol (SCVP)," <draft-ietf-pkix-
scvp-06.txt>, July 2001.
[TECHNR] Gindin, T., _Internet X.509 Public Key Infrastructure [SUPPALGS] Singer, A., and Whyte, W., "Supplemental Algorithms and
Technical Requirements for a non-Repudiation Service,_ <draft-ietf- Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and CRL Profile,ö <draft-ietf-pkix-pkalgs-supp-00.txt>,
July 2001.
[TECHNR] Gindin, T., ôInternet X.509 Public Key Infrastructure
Technical Requirements for a non-Repudiation Service,ö <draft-ietf-
pkix-technr-01.txt>, July 2000. pkix-technr-01.txt>, July 2000.
[TPCMP] Kapoor , A., Tschal, R., _Transport Protocols for CMP,_ Arsenault, Turner 51
<draft-ietf-pkix-cmp-transport-protocols-02.txt>, 03 October 2000.
[TPCMP] Kapoor , A., Tschal, R., ôTransport Protocols for CMP,ö
<draft-ietf-pkix-cmp-transport-protocols-04.txt>, November 2000.
[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", RFC 3161,
pkix-time-stamp-11.txt>, Octoboer 2000. August 2001.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Text Messages," RFC 822, August 1982. Messages," RFC 822, August 1982.
[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.
[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology [SUPPALGS] Supplemental Algorithms and Identifiers for the Internet
- Open Systems Interconnection - The Directory: Authentication X.509 Public Key Infrastructure Certificate and CRL Profile <draft-
ietf-pkix-pkalgs-supp-00.txt>, xxx 2001.
[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology -
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
Services Industry: Extensions To Public Key Certificates And Services Industry: Extensions To Public Key Certificates And
Certificate Revocation Lists, 8 December, 1995. Certificate Revocation Lists, 8 December, 1995.
Aresenault, Turner November, 2000 50
[X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial [X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial
Services Industry: Certificate Management (Working Draft), 21 June, Services Industry: Certificate Management (Working Draft), 21 June,
1996. 1996.
[PKCS10] RSA Laboratories, "The Public-Key Cryptography [PKCS10] RSA Laboratories, "The Public-Key Cryptography
Standards(PKCS)," RSA Data Security Inc., Redwood City, California, Standards(PKCS)," RSA Data Security Inc., Redwood City, California,
November 1993 Release. November 1993 Release.
8 Security Considerations 7 Security Considerations
There are not requirements in this document. There are not requirements in this document.
9 Editor's Address 8 Acknowledgements
A lot of the information in this document was taken from the PKIX
source documents; the authors of those deserve the credit for their
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
things to say were (in alphabetical order, with apologies to anybody
we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, Russ
Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, Tim
Polk, Stefan Santesson, Dave Simonetti, Paul Hoffman, Denis Pinkas,
Arsenault, Turner 52
Ed Greck, Tom Gindin, Parag Namjoshi, Peter Sylvester, and Michael
Zolotarev.
9 Author's Addresses
Alfred W. Arsenault Alfred W. Arsenault
Diversinet Corp. Diversinet Corp.
P.O. Box 6530 P.O. Box 6530
Ellicott City, MD 21042-0530 Ellicott City, MD 21042-0530
aarsenault@dvnet.com aarsenault@dvnet.com
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
9010 Edgepark Road 9010 Edgepark Road Vienna, VA 22182
Vienna, VA 22182
(703) 628-3180 (703) 628-3180
turners@ieca.com turners@ieca.com
Expires May 2000 Expires July 2002
Aresenault, Turner November, 2000 51 Arsenault, Turner 53
 End of changes. 356 change blocks. 
1435 lines changed or deleted 1550 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/