< draft-ietf-pkix-roadmap-00.txt		draft-ietf-pkix-roadmap-01.txt >
	PKIX Working Group A. Arsenault		PKIX Working Group A. Arsenault
	INTERNET DRAFT DOD		INTERNET DRAFT DOD
	S. Turner		S. Turner
	IECA		IECA
	Expires in six months from September 8,1998		Expires in six months from 22 March 1999
	Internet X.509 Public Key Infrastructure		Internet X.509 Public Key Infrastructure
	PKIX Roadmap		PKIX Roadmap
	<draft-ietf-pkix-roadmap-00.txt>		<draft-ietf-pkix-roadmap-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance
	documents of the Internet Engineering Task Force (IETF), its areas,		with all provisions of Section 10 of RFC2026.
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of 6 months and
	may be updated, replaced, or may become obsolete by other documents at
	any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as work in progress.
	To view the entire list of current Internet-Drafts, please check the		This document is an Internet-Draft. Internet-Drafts are working
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		documents of the Internet Engineering Task Force (IETF), its areas,
	Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern		and its working groups. Note that other groups may also distribute
	Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific		working documents as Internet-Drafts.
	Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
	Copyright (C) The Internet Society (date). All Rights Reserved.		Internet-Drafts are draft documents valid for a maximum of 6 months
			and may be updated, replaced, or may become obsolete by other
			documents at any time. It is inappropriate to use Internet-Drafts as
			reference material or to cite them other than as work in progress. To
			view the entire list of current Internet-Drafts, please check
			the"1id-abstracts.txt" listing contained in the Internet-Drafts
			Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
			Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
			Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
			Copyright (C) The Internet Society (date). All Rights Reserved.
	Abstract		Abstract
	This document provides an overview or 'roadmap' of the work done by the		This document provides an overview or 'roadmap' of the work done by
	IETF PKIX working group. It describes some of the terminology used in		the IETF PKIX working group. It describes some of the terminology
	the working group's documents, and the theory behind an X.509-based PKI.		used in the working group's documents, and the theory behind an
	It identifies each document developed by the PKIX working group, and		X.509-based PKI. It identifies each document developed by the PKIX
	describes the relationships among the various document. It also		working group, and describes the relationships among the various
	provides advice to would-be PKIX implementors about some of the issues		documents. It also provides advice to would-be PKIX implementors
	discussed at length during PKIX development, in hopes of making it		about some of the issues discussed at length during PKIX development,
	easier to build implementations that will actually interoperate.		in hopes of making it easier to build implementations that will
			actually interoperate.
	TABLE OF CONTENTS		TABLE OF CONTENTS
	1 INTRODUCTION 2		1 Introduction.................................................2
	2 Terminology 3		1.1 This Document................................................2
	3 PKIX Theory 3		1.2 Changes Since the Last Version...............................3
	3.1 Certificate-using Systems and PKIs 3		2 Terminology..................................................3
	3.2 Overview of the PKIX Approach 4		3 PKIX Theory..................................................4
	3.3 X.509 certificates 6		3.1 Certificate-using Systems and PKIs...........................4
	3.4 Functions of a PKI 6		3.2 PKIX History.................................................5
	3.4.1 Registration 6		3.3 Overview of the PKIX Approach................................5
	3.4.2 Initialization 7		3.4 X.509 certificates...........................................6
	3.4.3 Certification 7		3.5 Functions of a PKI...........................................7
	3.4.4 Key Pair Recovery 7		3.5.1 Registration.................................................7
	3.4.5 Key Generation 7		3.5.2 Initialization...............................................7
	3.4.6 Key Update 7		3.5.3 Certification................................................7
	3.4.7 Cross-certification 8		3.5.4 Key Pair Recovery............................................7
	3.4.8 Revocation 8		3.5.5 Key Generation...............................................8
	3.4.9 Certificate and Revocation Notice Distribution/Publication 10		3.5.6 Key Update...................................................8
	3.5 Parts of PKIX 10		3.5.7 Cross-certification..........................................9
	3.5.1 Profile 10		3.5.8 Revocation...................................................9
	3.5.2 Operational Protocols 11		3.5.9 Certificate and Revocation Notice Distribution/Publication..10
	3.5.3 Management Protocols 11		3.6 Parts of PKIX...............................................10
	3.5.4 Policy Outline 11		3.6.1 Profile.....................................................11
	4 PKIX Documents 11		3.6.2 Operational Protocols.......................................11
	4.1 Profile 11		3.6.3 Management Protocols........................................11
	4.2 Operational Protocols 13		3.6.4 Policy Outline..............................................12
	4.3 Management Protocols 14		3.6.5 Time-Stamp and Data Certification Services..................12
	4.4 Policy Outline 15		4 PKIX Documents..............................................13
	4.5 DOCUMENT RELATIONSHIPS 16		4.1 Profile.....................................................13
	5 Advice to Implementors 17		4.2 Operational Protocols.......................................14
	5.1 Names 17		4.3 Management Protocols........................................16
	5.1.1 Name Forms 17		4.4 Policy Outline..............................................17
	5.1.2 Scope of Names 19		4.5 Time-Stamp and Data Certification Services..................17
	5.1.3 Certificate Path Construction 19		5 Advice to Implementors......................................19
	5.1.4 Name Constraints 20		5.1 Names.......................................................19
	5.1.5 Wildcards in Name Forms 20		5.1.1 Name Forms..................................................19
	5.1.6 Name Encoding 21		5.1.2 Scope of Names..............................................21
	5.2 POP 21		5.1.3 Certificate Path Construction...............................22
	5.3 Key Usage Bits 21		5.1.4 Name Constraints............................................22
	5.4 Trust Models 23		5.1.5 Wildcards in Name Forms.....................................23
	6 Acknowledgements 23		5.1.6 Name Encoding...............................................23
	7 References 24		5.2 POP.........................................................23
	8 Security Considerations 25		5.3 Key Usage Bits..............................................25
	9 Editor's Address 26		5.4 Trust Models................................................27
	10 Disclaimer 26		6 Acknowledgements............................................28
			7 References..................................................28
			8 Security Considerations.....................................30
			9 Editor's Address............................................30
			10 Disclaimer..................................................30
	1 INTRODUCTION		1 Introduction
	This document is an informational Internet draft that provides a		1.1 This Document
	"roadmap" to the documents produced by the PKIX working group. It is
	intended to provide information; there are no requirements or
	specifications in this document.
	Section 2 of this document defines key terms used in this document.		This document is an informational Internet draft that provides a
	Section 3 covers "PKIX theory"; it explains what the PKIX working		"roadmap" to the documents produced by the PKIX working group. It is
	group's basic assumptions were. Section 4 provides an overview of the		intended to provide information; there are no requirements or
	various PKIX documents. It identifies which documents address which		specifications in this document.
	areas, and describes the relationships among the various documents.
	Section 5 contains "Advice to implementors". Its primary purpose is to
	capture some of the major issues discussed by the PKIX working group, as
	a way of explaining WHY some of the requirements and specifications say
	what they say. This should cut down on the number of misinterpretations
	of the documents, and help developers build interoperable
	implementations. Section 6 contains a list of references. Section 7
	discusses security considerations, and Section 8 provides contact
	information for the editors.
	2 Terminology		Section 2 of this document defines key terms used in this document.
			Section 3 covers "PKIX theory"; it explains what the PKIX working
			group's basic assumptions were. Section 4 provides an overview of
			the various PKIX documents. It identifies which documents address
			which areas, and describes the relationships among the various
			documents. Section 5 contains "Advice to implementors". Its primary
			purpose is to capture some of the major issues discussed by the PKIX
			working group, as a way of explaining WHY some of the requirements
			and specifications say what they say. This should cut down on the
			number of misinterpretations of the documents, and help developers
			build interoperable implementations. Section 6 contains a list of
			references. Section 7 discusses security considerations, and Section
			8 provides contact information for the editors.
	There are a number of terms used and misused throughout PKI-related		1.2 Changes Since the Last Version
	literature. To limit confusion caused by some of those terms, throughout
	this document, we will use the following terms in the following ways:
	- Certification Authority (CA) - an authority trusted by one or		The major changes in this document since version -00 include:
	more users to create and assign certificates. Optionally the
	certification authority may create the users' key'. (It is		inclusion of a section on "PKIX History" the definition and usage of
	important to note that the CA is responsible for the certificates		"root CA" were changed to be consistent with CMP, in line with the
	during their whole lifetime, not just for issuing them.)		discussion on the PKIX mailing list updates on the status of all
	- Certificate policy - a named set of rules that indicates the		major documents addition of descriptions of documents covering work
	applicability of a certificate to a particular community and/or		items that are new to PKIX since September 1998 a number of sections
	class of application with common security requirements. For		that had been left unspecified have now been completed (e.g., the
	example, a particular certificate policy might indicate		Proof of Possession (POP) section; rules on name constraints for
	applicability of a type of certificate to the authentication of		different name types) The old section 4.5, which attempted to
	electronic data interchange transaction s for the trading of		graphically depict document relationships, has been deleted because
	goods within a given price range.		it didn't seem to add any value.
	- Root CA - a CA whose certificate is self-signed; that is, the
	issuer and subject are the same entity.		2 Terminology
	- Registration Agent (RA) - an optional entity given responsibility
	for performing some of the administrative tasks necessary in the		There are a number of terms used and misused throughout PKI-related
	registration of subjects, such as: confirming the subject's		literature. To limit confusion caused by some of those terms,
	identity; validating that the subject is entitled to have the		throughout this document, we will use the following terms in the
	attributes requested in a certificate; and verifying that the		following ways:
	subject has possession of the private key associated with the
	public key requested for a certificate.		- Certification Authority (CA) - an authority trusted by one or more
	- End-entity - a subject of a certificate who is not a CA.		users to create and assign certificates. Optionally the
	- Relying party - a user or agent (e.g., a client or server) who		certification authority may create the user's keys. (It is important
	relies on the data in a certificate in making decisions.		to note that the CA is responsible for the certificates during their
	- Subject - a subject is the entity (CA or end-entity) named in a		whole lifetime, not just for issuing them.)
	certificate. Subjects can be human users, computers (as
	represented by DNS names or IP addresses), or even software		- Certificate policy - a named set of rules that indicates the
	agents.		applicability of a certificate to a particular community and/or class
			of application with common security requirements. For example, a
			particular certificate policy might indicate applicability of a type
			of certificate to the authentication of electronic data interchange
			transaction s for the trading of goods within a given price range.
			- Root CA - a CA that is directly trusted by an end entity; that is,
			securely acquiring the value of a root CA public key requires some
			out-of-band step(s). This term is not meant to imply that a root CA
			is necessarily at the top of any hierarchy, simply that the CA in
			question is trusted directly.
			- Top CA - a CA that is at the top of a PKI hierarchy.
			Note that this is often also called a "root CA", from since in
			data structures terms and in graph theory, the node at the top
			of a tree is the "root". However, to minimize confusion in this
			document, we elect to call this node a "Top CA," and reserve
			"root CA" for the CA directly trusted by the user. Readers new
			to PKIX should be aware that these terms are not used
			consistently throughout the PKIX documents, as [RFC2459] uses
			"root CA" to refer to what this and other documents call a "top
			CA", and "most-trusted CA" to refer to what this and other
			documents call a "root CA".
			- Subordinate CA - A "subordinate CA" is one that is not a root CA
			for the end entity in question. Often, a subordinate CA will not
			be a root CA for any entity but this is not mandatory
			- Registration Authority (RA) - an optional entity given
			responsibility for performing some of the administrative tasks
			necessary in the registration of subjects, such as: confirming
			the subject's identity; validating that the subject is entitled
			to have the attributes requested in a certificate; and verifying
			that the subject has possession of the private key associated
			with the public key requested for a certificate.
			- End-entity - a subject of a certificate who is not a CA.
			- Relying party - a user or agent (e.g., a client or server) who
			relies on the data in a certificate in making decisions.
			- Subject - a subject is the entity (CA or end-entity) named in a
			certificate. Subjects can be human users, computers (as
			represented by DNS names or IP addresses), or even software
			agents.
	3 PKIX Theory		3 PKIX Theory
	3.1 Certificate-using Systems and PKIs		3.1 Certificate-using Systems and PKIs
	At the heart of recent efforts to improve Internet security are a group		At the heart of recent efforts to improve Internet security are a
	of security protocols such as S/MIME, TLS, and IPSec. All of these		group of security protocols such as S/MIME, TLS, and IPSec. All of
	protocols rely on public-key cryptography to provide services such as		these protocols rely on public-key cryptography to provide services
	confidentiality, data integrity, data origin authentication, and		such as confidentiality, data integrity, data origin authentication,
	non-repudiation. The purpose of a PKI is to provide trusted and		and non-repudiation. The purpose of a PKI is to provide trusted and
	efficient key- and certificate management, thus enabling the use of		efficient key- and certificate management, thus enabling the use of
	authentication, non-repudiation, and confidentiality.		authentication, non-repudiation, and confidentiality.
	Users of public key-based systems must be confident that, any time they		Users of public key-based systems must be confident that, any time
	rely on a public key, the associated private key is owned by the subject		they rely on a public key, the associated private key is owned by the
	with which they are communicating. (This applies whether an encryption		subject with which they are communicating. (This applies whether an
	or digital signature mechanism is used.) This confidence is obtained		encryption or digital signature mechanism is used.) This confidence
	through the use of public key certificates, which are data structures		is obtained through the use of public key certificates, which are
	that bind public key values to subjects. The binding is achieved by		data structures that bind public key values to subjects. The binding
	having a trusted CA verify the subject's identity and digitally sign		is achieved by having a trusted CA verify the subject's identity and
	each certificate.		digitally sign each certificate.
	A certificate has a limited valid lifetime which is indicated in its		A certificate has a limited valid lifetime which is indicated in its
	signed contents. Because a certificate's signature and timeliness can		signed contents. Because a certificate's signature and timeliness
	be independently checked by a certificate-using client, certificates can		can be independently checked by a certificate-using client,
	be distributed via untrusted communications and server systems, and can		certificates can be distributed via untrusted communications and
	be cached in unsecured storage in certificate-using systems.		server systems, and can be cached in unsecured storage in
			certificate-using systems.
	Certificates are used in the process of validating signed data.		Certificates are used in the process of validating signed data.
	Specifics vary according to which algorithm is used, but the general		Specifics vary according to which algorithm is used, but the general
	process works as follows: (note: there is no specific order in which		process works as follows:
	the checks listed below must be made; implementors are free to implement
	them in the most efficient way for their systems)
	- the recipient of signed data verifies that the claimed identity		(Note: there is no specific order in which the checks listed
	of the user is in accordance wit the identity contained in the		below must be made; implementers are free to implement them in the
	certificate;		most efficient way for their systems)
	- the recipient validates that no certificate in the path has been
	revoked (e.g., by retrieving a suitably-current Certificate
	Revocation List (CRL) or querying an on-line certificate status
	responder), and that all certificates were within their validity
	periods at the time the data were signed;
	- the recipient verifies that the data are not claimed to have any
	attributes for which the certificate indicates that the signer is
	not authorized;
	- the recipient verifies that the data have not been altered since
	signing, by using the public key in the certificate.
	If all of these checks pass, the recipient can accept that the data were		- the recipient of signed data verifies that the claimed identity of
	signed by the purported signer. The process for keys used for		the user is in accordance wit the identity contained in the
	encryption is similar.		certificate;
	(Note: it is of course possible that data were signed by someone very		- the recipient validates that no certificate in the path has been
	different from the signer, if for example the purported signer's private		revoked (e.g., by retrieving a suitably-current Certificate
	key was compromised. Security depends on all parts of the		Revocation List (CRL) or querying an on-line certificate status
	certificate-using SYSTEM, including but not limited to: physical		responder), and that all certificates were within their validity
	security of the place the computer resides; personnel security (i.e.,		periods at the time the data were signed;
	the trustworthiness of the people who actually develop, install, run,
	and maintain the system); the security provided by the operating system
	on which the private key is used; and the security provided the CA. A
	failure in any one of these areas can cause the entire system security
	to fail. PKIX is limited in scope, however, and only directly addresses
	issues related to the operation of the PKI subsystem. For guidance in
	many of the other areas, see [PKIX-4].)
	A collection of certificates, with their issuing CA's, subjects, relying		- the recipient verifies that the data are not claimed to have any
	parties, RA's, and repositories, is referred to as a Public Key		attributes for which the certificate indicates that the signer is
	Infrastructure, or PKI.		not authorized;
	3.2 Overview of the PKIX Approach		- the recipient verifies that the data have not been altered since
			signing, by using the public key in the certificate.
	PKIX is an effort to develop specifications for a Public Key		If all of these checks pass, the recipient can accept that the data
	Infrastructure for the Internet using X.509 certificates. The PKIX		were signed by the purported signer. The process for keys used for
	working group was initially chartered in 1995. A Public Key		encryption is similar.
	Infrastructure, or PKI, is defined as:
	The set of hardware, software, people, policies and procedures needed		Note: it is of course possible that the data were signed by
	to create, manage, store, distribute, and revoke certificates based on		someone very different from the signer, if for example the
	public-key cryptography.		purported signer's private key was compromised. Security depends
			on all parts of the certificate-using SYSTEM, including but not
			limited to: physical security of the place the computer resides;
			personnel security (i.e., the trustworthiness of the people who
			actually develop, install, run, and maintain the system); the
			security provided by the operating system on which the private key
			is used; and the security provided the CA. A failure in any one
			of these areas can cause the entire system security to fail. PKIX
			is limited in scope, however, and only directly addresses issues
			related to the operation of the PKI subsystem. For guidance in
			many of the other areas, see [PKIX-4].
	A PKI consists five types of components[MISPC]:		A collection of certificates, with their issuing CA's, subjects,
	* Certification Authorities (CAs) that issue and revoke		relying parties, RA's, and repositories, is referred to as a Public
	certificates;		Key Infrastructure, or PKI.
	* Organizational Registration Authorities (ORAs) that vouch for the
	binding between public keys and certificate holder identities and
	other attributes;
	* Certificate holders that are issued certificates and can sign
	digital documents;
	* Clients that validate digital signatures and their certification
	paths from a known public key of a trusted CA;
	* Repositories that store and make available certificates and
	Certificate Revocation Lists (CRLs).
	Figure 1 is a simplified view of the architectural model assumed by the		3.2 PKIX History
	PKIX Working Group.
	+---+		[This still needs more work.]
	| C | +------------+
	| e | <-------------------->| End entity |
	| r | Operational +------------+
	| t | transactions ^
	| | and management | Management
	| / | transactions | transactions
	| | | PKI users
	| C | v
	| R | -------------------+--+-----------+----------------
	| L | ^ ^
	| | | | PKI management
	| | v | entities
	| R | +------+ |
	| e | <---------------------| RA | <---+ |
	| p | Publish certificate +------+ | |
	| o | | |
	| s | | |
	| I | v v
	| t | +------------+
	| o | <------------------------------| CA |
	| r | Publish certificate +------------+
	| y | Publish CRL ^
	| | |
	+---+ Management |
	transactions |
	v
	+------+
	| CA |
	+------+
	Figure 1 - PKI Entities
	3.3 X.509 certificates		In the beginning there was ITU-T Recommendation X.509. It defines a
			widely accepted basis for a public-key infrastructure, including data
			formats and procedures related to distribution of public keys via
			certificates digitally signed by CAs. X.509 does not however include
			a profile to specify the support requirements for many of the
			certificate data structure's sub-fields, for any of the extensions,
			nor for certain data values. PKIX was formed in October 1995 to
			deliver a profile for the Internet PKI of X.509 version 3
			certificates and version 2 CRLs. The Internet PKI profile [RFC 2459]
			went through eleven draft versions before becoming an RFC. Other
			profiles have been developed in PKIX for particular algorithms to
			make use of [RFC 2459]. There has been no sense of conflict between
			the groups that developed these profiles as they are seen as
			complimentary.
	ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was		The development of the management protocols has not been so
	first published in 1988 as part of the X.500 Directory recommendations,		straightforward. [CMP] was developed to define a message protocol
	defines a standard certificate format [X.509]. The certificate format in		that is used between entities in a PKI. The demand for an enrollment
	the 1988 standard is called the version 1 (v1) format.		protocol and the desire to use PKCS-10 message format as the
			certificate request syntax lead to the development of two different
			documents in two different groups. The Certificate Request Syntax
			[CRS] draft was developed in the SMIME WG which used PKCS10 [PKCS10]
			as the certification request message format. Certificate Request
			Message Format [CRMF] draft was also developed but in the PKIX WG.
			It was to define a simple enrollment protocol that would subsume both
			the [CMP] and [CRS] enrollment protocols, but it did not use PKCS10
			as the certificate request message format. Then, [CMMF] was
			developed to define an extended set of management messages that flow
			between the components of the Internet PKI. CMMF over CMS [CMC] was
			developed to allow the use of an existing protocol (S/MIME) as a PKI
			management protocol, without requiring the development of an entirely
			new protocol such as CMP [CMP]. It also included [PKCS10] as the
			certificate request syntax, which caused work on [CRS] to stop.
			Information from [CMMF] has been moved into [CMP] and [CMC] so [CMMF]
			is being discontinued.
	When X.500 was revised in 1993, two more fields were added, resulting in		Development of the operational protocols has been slightly more
	the version 2 (v2) format. These two fields may be used to support		straightforward. Two documents for LDAPv2 have been developed one
	directory access control.		for defining LDAPv2 as an access protocol to repositories [LDAP] and
			one for storing PKI information in an LDAP directory [SCHEMA]. Using
			FTP and HTTP to retrieve certificates and CRL from PKI repositories
			was documented without a fight in [FTP]. Likewise, methods, headers,
			and content-types ancillary to HTTP/1.1 to publish and retrieve X.509
			certificates and CRLs was documented in [WEB] without much argument.
	The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,		[Need to add text about OpenCDP vs DistributionPoints, Why DCP was
	include specifications for a public key infrastructure based on X.509v1		started, information on TSP, and OCSP, and caching OCSP.]
	certificates [RFC 1422]. The experience gained in attempts to deploy
	RFC 1422 made it clear that the v1 and v2 certificate formats are
	deficient in several respects. Most importantly, more fields were
	needed to carry information which PEM design and implementation
	experience has proven necessary. In response to these new requirements,
	ISO/IEC/ITU and ANSI X9 developed the X.509 version 3 (v3) certificate
	format. The v3 format extends the v2 format by adding provision for
	additional extension fields. Particular extension field types may be
	specified in standards or may be defined and registered by any
	organization or community. In June 1996, standardization of the basic v3
	format was completed [X.509].
	ISO/IEC/ITU and ANSI X9 have also developed standard extensions for use		3.3 Overview of the PKIX Approach
	in the v3 extensions field [X.509][X9.55]. These extensions can convey
	such data as additional subject identification information, key
	attribute information, policy information, and certification path
	constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions
	are very broad in their applicability. In order to develop
	interoperable implementations of X.509 v3 systems for Internet use, it
	is necessary to specify a profile for use of the X.509 v3 extensions
	tailored for the Internet. It is one goal of PKIX to specify a profile
	for Internet WWW, electronic mail, and IPsec applications. Environments
	with additional requirements may build on this profile or may replace it.
	3.4 Functions of a PKI		PKIX is an effort to develop specifications for a Public Key
			Infrastructure for the Internet using X.509 certificates. The PKIX
			working group was initially chartered in 1995. A Public Key
			Infrastructure, or PKI, is defined as:
	This section describes the major functions of a PKI. In some cases,		The set of hardware, software, people, policies and procedures needed
	PKIs may provide extra functions.		to create, manage, store, distribute, and revoke certificates based
			on public-key cryptography.
	3.4.1 Registration		A PKI consists of five types of components [MISPC]:
	This is the process whereby a subject first makes itself known to a CA		- Certification Authorities (CAs) that issue and revoke certificates;
	(directly, or through an RA), prior to that CA issuing a certificate or		- Organizational Registration Authorities (ORAs) that vouch for the
	certificates for that subject. Registration involves the subject		binding between public keys and certificate holder identities and
	providing its name (e.g., common name, fully-qualified domain name, IP		other attributes; - Certificate holders that are issued certificates
	address), and other attributes to be put in the certificate, followed		and can sign digital documents; - Clients that validate digital
	by the CA (possibly with help from the RA) verifying in accordance with		signatures and their certification paths from a known public key of a
	its CPS that the name and other attributes are correct.		trusted CA; - Repositories that store and make available certificates
			and Certificate Revocation Lists (CRLs).
	3.4.2 Initialization		Figure 1 is a simplified view of the architectural model assumed by
			the PKIX Working Group.
	Initialization is when the subject - e.g., the user or client system -		+---+
	gets the values needed to begin communicating with the PKI. For		| C | +------------+
	example, initialization can involve providing the client system with the		| e | <-------------------->| End entity |
	public key and/or certificate of a CA, or generating the client system's		| r | Operational +------------+
	own public/private key pair.		| t | transactions ^
			| | and management | Management
			| / | transactions | transactions
			| | | PKI users
			| C | v
			| R | -------------------+--+-----------+----------------
			| L | ^ ^
			| | | | PKI management
			| | v | entities
			| R | +------+ |
			| e | <---------------------| RA | <---+ |
			| p | Publish certificate +------+ | |
			| o | | |
			| s | | |
			| I | v v
			| t | +------------+
			| o | <------------------------------| CA |
			| r | Publish certificate +------------+
			| y | Publish CRL ^
			| | |
			+---+ Management |
			transactions |
			v
			+------+
			| CA |
			+------+
			Figure 1 - PKI Entities
	3.4.3 Certification		3.4 X.509 certificates
	This is the process in which a CA issues a certificate for a subject's		ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was
	public key, and returns that certificate to the subject and/or posts		first published in 1988 as part of the X.500 Directory
	that certificate in a repository.		recommendations, defines a standard certificate format [X.509]. The
			certificate format in the 1988 standard is called the version 1 (v1)
			format.
	3.4.4 Key Pair Recovery		When X.500 was revised in 1993, two more fields were added, resulting
			in the version 2 (v2) format. These two fields may be used to support
			directory access control.
	In some implementations, key exchange or encryption keys will be		The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
	required by local policy to be "backed up", or recoverable in case the		include specifications for a public key infrastructure based on
	key is lost and access to previously-encrypted information is needed.		X.509v1 certificates [RFC 1422]. The experience gained in attempts
	Such implementations can include those where the private key exchange		to deploy RFC 1422 made it clear that the v1 and v2 certificate
	key is stored on a hardware token which can be lost or broken, or when		formats are deficient in several respects. Most importantly, more
	a private key file is protected by a password which can be forgotten.		fields were needed to carry information which PEM design and
	Often, a company is concerned about being able to read mail encrypted		implementation experience has proven necessary. In response to these
	by or for a particular employee when that employee is no longer		new requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version
	available because she is ill or no longer works for the company.		3 (v3) certificate format. The v3 format extends the v2 format by
			adding provision for additional extension fields. Particular
			extension field types may be specified in standards or may be defined
			and registered by any organization or community. In June 1996,
			standardization of the basic v3 format was completed [X.509].
	In these cases, the user's private key can be backed up by a CA or by a		ISO/IEC/ITU and ANSI X9 have also developed standard extensions for
	separate key backup system. If a user or her employer needs to recover		use in the v3 extensions field [X.509][X9.55]. These extensions can
	these backed up key materials, the PKI must provide a system that		convey such data as additional subject identification information,
	permits the recovery WITHOUT providing an unacceptable risk of		key attribute information, policy information, and certification path
	compromise of the private key.		constraints. However, the ISO/IEC/ITU and ANSI X9 standard
			extensions are very broad in their applicability. In order to
			develop interoperable implementations of X.509 v3 systems for
			Internet use, it is necessary to specify a profile for use of the
			X.509 v3 extensions tailored for the Internet. It is one goal of
			PKIX to specify a profile for Internet WWW, electronic mail, and
			IPsec applications. Environments with additional requirements may
			build on this profile or may replace it.
	3.4.5 Key Generation		3.5 Functions of a PKI
	Depending on the CA's policy, the private/public key pair can either be		This section describes the major functions of a PKI. In some cases,
	generated by the user in his local environment, or generated by the CA.		PKIs may provide extra functions.
	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 card or PCMCIA
	card.
	3.4.6 Key Update		3.5.1 Registration
	All key pairs need to be updated regularly, i.e., replaced with a new		This is the process whereby a subject first makes itself known to a
	key pair, and new certificates issued. This will happen in two cases:		CA (directly, or through an RA), prior to that CA issuing a
	normally, when a key has passed its maximum usable lifetime; and		certificate or certificates for that subject. Registration involves
	exceptionally, when a key has been compromised and must be replaced.		the subject providing its name (e.g., common name, fully-qualified
			domain name, IP address), and other attributes to be put in the
			certificate, followed by the CA (possibly with help from the RA)
			verifying in accordance with its CPS that the name and other
			attributes are correct.
	In the normal case, a PKI needs to provide a facility to gracefully		3.5.2 Initialization
	transition from a certificate with an existing key to a new certificate
	with a new 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
	certain date; the PKI, working together with certificate-using
	applications, should allow for appropriate keys to work before and after
	the transition. There are a number of ways to do this; see [insert
	appropriate reference here] for an example of one.
	In the case of a key compromise, the transition will not be "graceful"		Initialization is when the subject - e.g., the user or client system
	in that there will be an unplanned switch of certificates and keys;		- gets the values needed to begin communicating with the PKI. For
	users will not have known in advance what was about to happen. Still,		example, initialization can involve providing the client system with
	the PKI must support the ability to declare that the previous		the public key and/or certificate of a CA, or generating the client
	certificate is now invalid and shall not be used, and to announce the		system's own public/private key pair.
	validity and availability of the new certificate.
	Note, however, that the compromise of a private key associated with a		3.5.3 Certification
	self-signed rootCA certificate is always catastrophic. That is, once
	the rootCA's private signature key has been compromised, there is no way
	to reliably convince users and subordinate CA's to accept a new key for
	the rootCA. If the key is compromised, any "update" message telling
	subordinates to switch to a 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 already has the private key.
	When a rootCA's private signature key is compromised, the only option is		This is the process in which a CA issues a certificate for a
	dismantling the entire infrastructure subordinate to that rootCA and		subject's public key, and returns that certificate to the subject
	starting over again from scratch. It is possible to have anticipated		and/or posts that certificate in a repository.
	this event, and "pre-placed" replacement rootCA keys with all relying
	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
	replacement key has not been compromised.
	3.4.7 Cross-certification		3.5.4 Key Pair Recovery
	A cross-certificate is a certificate issued by one CA to another CA		In some implementations, key exchange or encryption keys will be
	which contains a public CA key associated with the private CA signature		required by local policy to be "backed up", or recoverable in case
	key used for issuing certificates. Typically, a cross-certificate is		the key is lost and access to previously-encrypted information is
	used to allow client systems/end entities in one administrative domain		needed. Such implementations can include those where the private key
	to communicate security with client systems/end users in another		exchange key is stored on a hardware token which can be lost or
	administrative domain. Use of a cross-certificate issued from CA_1 to		broken, or when a private key file is protected by a password which
	CA_2 allows user Alice, who trusts CA_1, to accept a certificate used by		can be forgotten. Often, a company is concerned about being able to
	Bob, which was issued by CA_2. (Note: cross-certificates can also be		read mail encrypted by or for a particular employee when that
	issued from one CA to another CA in the same administrative domain, if		employee is no longer available because she is ill or no longer works
	required.)		for the company.
	Cross-certificates can be issued in only one direction, or in both		In these cases, the user's private key can be backed up by a CA or by
	directions, between two CA's. That is, just because CA_1 issues a		a separate key backup system. If a user or her employer needs to
	cross-certificate for CA_2 does not require CA_2 to issue a		recover these backed up key materials, the PKI must provide a system
	cross-certificate for CA_1.		that permits the recovery WITHOUT providing an unacceptable risk of
			compromise of the private key.
	3.4.8 Revocation		3.5.5 Key Generation
	When a certificate is issued, it is expected to be in use for its entire		Depending on the CA's policy, the private/public key pair can either
	validity period. However, various circumstances may cause a certificate		be generated by the user in his local environment, or generated by
	to become invalid prior to the expiration of the validity period. Such		the CA. In the latter case, the key material may be distributed to
	circumstances include change of name, change of association between		the user in an encrypted file or on a physical token - e.g., a smart
	subject and CA (e.g., an employee terminates employment with an		card or PCMCIA card.
	organization), and compromise or suspected compromise of the
	corresponding private key. Under such circumstances, the CA needs to
	revoke the certificate.
	X.509 defines one method of certificate revocation. This method		3.5.6 Key Update
	involves each CA periodically issuing a signed data structure called a
	certificate revocation list (CRL). A CRL is a time stamped list
	identifying revoked certificates which is signed by a CA and made freely
	available in a public repository. Each revoked certificate is
	identified in a CRL by its certificate serial number. When a
	certificate-using system uses a certificate (e.g., for verifying a
	remote user's digital signature), that system not only checks the
	certificate signature and validity but also acquires a suitably-recent
	CRL and checks that the certificate serial number is not on that CRL.
	The meaning of "suitably-recent" may vary with local policy, but it
	usually means the most recently-issued CRL. A CA issues a new CRL on a
	regular periodic basis (e.g., hourly, daily, or weekly). CA's may also
	issue CRLs aperiodically; e.g., if an important key is deemed
	compromised, the CA may issue a new CRL to expedite notification of that
	fact, even if the next CRL does not have to be issued for some time.
	(A problem of aperiodic CRL issuance is that end-entities may not know
	that a new CRL has been issued, and thus may not retrieve it from a
	repository.)
	An entry is added to the CRL as part of the next update following		All key pairs need to be updated regularly, i.e., replaced with a new
	notification of revocation. An entry may be removed from the CRL after		key pair, and new certificates issued. This will happen in two
	appearing on one regularly scheduled CRL issued beyond the revoked		cases: normally, when a key has passed its maximum usable lifetime;
	certificate's validity period.		and exceptionally, when a key has been compromised and must be
			replaced.
	An advantage of the CRL revocation method is that CRLs may be		In the normal case, a PKI needs to provide a facility to gracefully
	distributed by exactly the same means as certificates themselves,		transition from a certificate with an existing key to a new
	namely, via untrusted communications and server systems.		certificate with a new 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 certain date; the PKI, working together with
			certificate-using applications, should allow for appropriate keys to
			work before and after the transition. There are a number of ways to
			do this; see [insert appropriate reference here] for an example of
			one. In the case of a key compromise, the transition will not be
			"graceful" in that there will be an unplanned switch of certificates
			and keys; users will not have known in advance what was about to
			happen. Still, the PKI must support the ability to declare that the
			previous certificate is now invalid and shall not be used, and to
			announce the validity and availability of the new certificate.
	One limitation of the CRL revocation method, using untrusted		Note that compromise of a private key associated with a rootCA is
	communications and servers, is that the time granularity of revocation		catastrophic for users relying on that rootCA. If a rootCA's
	is limited to the CRL issue period. For example, if a revocation is		private key is compromised, that CA must be taken down and brought
	reported now, that revocation will not be reliably notified to		up again with a new key. Until such time as the rootCA is brought
	certificate-using systems until the next CRL is issued -- this may be up		back up, though, users relying on that rootCA are cut off from the
	to one hour, one day, or one week depending on the frequency that the CA		rest of the system, as there is no way to develop a valid
	issues CRLs.		certification path back to a trusted node.
	As with the X.509 v3 certificate format, in order to facilitate		Further, users will likely have to be notified by out-of-band
	interoperable implementations from multiple vendors, the X.509 v2 CRL		mechanisms about the change in CA keys. If the old key is
	format needs to be profiled for Internet use. It is one goal of PKIX to		compromised, any "update" message telling subordinates to switch to a
	specify that profile. However, PKIX does not require CAs to issue CRLs.		new key could have come from an attacker in possession of the old
	Message formats and protocols supporting on-line revocation notification		key, and could point to a new public key for which the attacker
	may be defined in other PKIX specifications. On-line methods of		already has the private key. It is possible to have anticipated this
	revocation notification may be applicable in some environments as an		event, and "pre-placed" replacement rootCA keys with all relying
	alternative to the X.509 CRL.		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
			replacement key has not been compromised.
	On-line revocation checking may significantly reduce the latency		Additionally, once the rootCA is brought back up with a new key, it
	between a revocation report and the distribution of the information		will likely be necessary to re-issue certificates, signed with the
	to relying parties. Once the CA accepts the report as authentic and		new key, to all subordinate users, since their current certificate
	valid, any query to the on-line service will correctly reflect the		would be signed with a now-revoked key.
	certificate validation impacts of the revocation. However, these
	methods impose new security requirements; the certificate validator
	must trust the on-line validation service while the repository does not
	need to be trusted.
	3.4.9 Certificate and Revocation Notice Distribution/Publication		3.5.7 Cross-certification
	As alluded to in sections 3.4.3 and 3.4.8 above, the PKI is responsible		A cross-certificate is a certificate issued by one CA to another CA
	for the distribution of certificates and certificate revocation notices		which contains a public CA key associated with the private CA
	(whether in CRL form or in some other form) in the system.		signature key used for issuing certificates. Typically, a cross-
	"Distribution" of certificates includes transmission of the certificate		certificate is used to allow client systems/end entities in one
	to its owner, and may also include publication of the certificate in a		administrative domain to communicate security with client systems/end
	repository. "Distribution" of revocation notices may involve posting		users in another administrative domain. Use of a cross-certificate
	CRLs in a repository, transmitting them to end-entities, and/or		issued from CA_1 to CA_2 allows user Alice, who trusts CA_1, to
	forwarding them to on-line responders.		accept a certificate used by Bob, which was issued by CA_2.
	3.5 Parts of PKIX		Note: cross-certificates can also be issued from one CA to another
			CA in the same administrative domain, if required.
	This section identifies the four different areas in which the PKIX		Cross-certificates can be issued in only one direction, or in both
	working group has developed documents. The first area involves profiles		directions, between two CA's. That is, just because CA_1 issues a
	of the X.509 v3 certificate standards and the X.509v2 CRL standards for		cross-certificate for CA_2 does not require CA_2 to issue a cross-
	the Internet. The second area involves operational protocols, in which		certificate for CA_1.
	relying parties can obtain information such as certificates or
	certificate status. The third area covers management protocols, in
	which different entities in the system exchange information needed for
	proper management of the PKI. The last area provides information about
	certificate policies and certificate practice statements, covering the
	areas of PKI security not directly addressed in the rest of PKIX.
	3.5.1 Profile		3.5.8 Revocation
	An X.509v3 certificate is a very complex data structure. It consists of		When a certificate is issued, it is expected to be in use for its
	basic information fields, plus a number of optional certificate		entire validity period. However, various circumstances may cause a
	extensions. Many of the fields and numerous extensions can take on a		certificate to become invalid prior to the expiration of the validity
	wide range of options. This provides an enormous degree of flexibility,		period. Such circumstances include change of name, change of
	which allows the X.509v3 certificate format to be used with a wide range		association between subject and CA (e.g., an employee terminates
	of applications in a wide range of environments. Unfortunately, this		employment with an organization), and compromise or suspected
	same flexibility makes it extremely difficult to produce independent		compromise of the corresponding private key. Under such
	implementations that will actually interoperate with one another. In		circumstances, the CA needs to revoke the certificate.
	order to build an Internet PKI based on X.509v3 certificates, the PKIX
	working group had to develop a profile of the X.509v3 specification.
	A profile of the X.509v3 specification is a description of the contents		X.509 defines one method of certificate revocation. This method
	of the certificate and which certificate extensions must be supported,		involves each CA periodically issuing a signed data structure called
	which extensions may be supported, and which extensions may not be		a certificate revocation list (CRL). A CRL is a time stamped list
	supported. [PKIX-1] provides such a profile of X.509v3 for the Internet		identifying revoked certificates which is signed by a CA and made
	PKI. In addition, [PKIX-1] suggests ranges of values for many of the		freely available in a public repository. Each revoked certificate is
	extensions.		identified in a CRL by its certificate serial number. When a
			certificate-using system uses a certificate (e.g., for verifying a
			remote user's digital signature), that system not only checks the
			certificate signature and validity but also acquires a suitably-
			recent CRL and checks that the certificate serial number is not on
			that CRL. The meaning of "suitably-recent" may vary with local
			policy, but it usually means the most recently-issued CRL. A CA
			issues a new CRL on a regular periodic basis (e.g., hourly, daily, or
			weekly). CA's may also issue CRLs aperiodically; e.g., if an
			important key is deemed compromised, the CA may issue a new CRL to
			expedite notification of that fact, even if the next CRL does not
			have to be issued for some time. (A problem of aperiodic CRL issuance
			is that end-entities may not know that a new CRL has been issued, and
			thus may not retrieve it from a repository.)
			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
			after appearing on one regularly scheduled CRL issued beyond the
			revoked certificate's validity period.
	[PKIX-1] also provides a profile for Version 2 CRLs for use in the		An advantage of the CRL revocation method is that CRLs may be
	Internet PKI. CRLs, like certificates, have a number of optional		distributed by exactly the same means as certificates themselves,
	extensions. In order to promote interoperability, it is necessary to		namely, via untrusted communications and server systems.
	constrain the choices an implementor supports.
	In addition to profiling the certificate and CRL formats, it is		One limitation of the CRL revocation method, using untrusted
	necessary to specify particular Object Identifiers (OIDs) for certain		communications and servers, is that the time granularity of
	encryption algorithms, because there are a variety of OIDs registered		revocation is limited to the CRL issue period. For example, if a
	for some algorithm suites. Thus, PKIX has produced at least two		revocation is reported now, that revocation will not be reliably
	documents ([ECDSA] and [KEA]) which provide guidance on the proper		notified to certificate-using systems until the next CRL is issued --
	implementation of specific algorithms.		this may be up to one hour, one day, or one week depending on the
			frequency that the CA issues CRLs.
	3.5.2 Operational Protocols		As with the X.509 v3 certificate format, in order to facilitate
			interoperable implementations from multiple vendors, the X.509 v2 CRL
			format needed to be profiled for Internet use. This was done as part
			of [RFC 2459]. However, PKIX does not require CAs to issue CRLs. On-
			line methods of revocation notification may be applicable in some
			environments as an alternative to the X.509 CRL. PKIX defines a
			protocol known as OCSP [OCSP] to facilitate on-line checking of the
			status of certificates.
	Operational protocols are required to deliver certificates and CRLs		On-line revocation checking may significantly reduce the latency
	(or other certificate status information) to certificate using systems.		between a revocation report and the distribution of the information
	Provision is needed for a variety of different means of certificate and		to relying parties. Once the CA accepts the report as authentic and
	CRL delivery, including distribution procedures based on LDAP, HTTP,		valid, any query to the on-line service will correctly reflect the
	FTP, and X.500. Operational protocols supporting these functions are		certificate validation impacts of the revocation. However, these
	defined in other [FTP], [OCSP],[LDAP], and [WEB].		methods impose new security requirements; the certificate validator
			must trust the on-line validation service while the repository does
			not need to be trusted.
	3.5.3 Management Protocols		3.5.9 Certificate and Revocation Notice Distribution/Publication
	Management protocols are required to support on-line interactions		As alluded to in sections x and y above, the PKI is responsible for
	between PKI user and management entities. For example, a management		the distribution of certificates and certificate revocation notices
	protocol might be used between a CA and a client system with which a		(whether in CRL form or in some other form) in the system.
	key pair is associated, or between two CAs which cross-certify each		"Distribution" of certificates includes transmission of the
	other. A management protocol can be used to carry user or client		certificate to its owner, and may also include publication of the
	system registration information, or a request for revocation of a		certificate in a repository. "Distribution" of revocation notices
	certificate.		may involve posting CRLs in a repository, transmitting them to end-
			entities, and/or forwarding them to on-line responders.
	There are two parts to a "management protocol". The first is the format		3.6 Parts of PKIX
	of the messages that will be sent, and the second is the actual protocol
	that governs the transmission of those messages. The PKIX working group
	has developed two documents ([CRMF] and [CMMF]) that together describe
	the necessary set of message, and two other documents ([CMP] and [CMC])
	that describe protocols for exchanging those messages.
	3.5.4 Policy Outline		This section identifies the five different areas in which the PKIX
			working group has developed documents. The first area involves
			profiles of the X.509 v3 certificate standards and the X.509v2 CRL
			standards for the Internet. The second area involves operational
			protocols, in which relying parties can obtain information such as
			certificates or certificate status. The third area covers management
			protocols, in which different entities in the system exchange
			information needed for proper management of the PKI. The fourth area
			provides information about certificate policies and certificate
			practice statements, covering the areas of PKI security not directly
			addressed in the rest of PKIX. The fifth area deals with providing
			time stamping and data certification services, which can be used to
			build such services as non-repudiation.
	As mentioned before, profiling certificates and specifying operational		3.6.1 Profile
	and management protocols only addresses a part of the problem of
	actually developing and implementing a secure PKI. What is also needed		An X.509v3 certificate is a very complex data structure. It consists
	is the development of a certificate policy and certification practice		of basic information fields, plus a number of optional certificate
	statement, and then following those documents. The CP and CPS should		extensions. Many of the fields and numerous extensions can take on a
	address physical and personnel security, subject identification		wide range of options. This provides an enormous degree of
	requirements, revocation policy, and a number of other topics. [PKIX-4]		flexibility, which allows the X.509v3 certificate format to be used
	provides a framework for certification practice statements.		with a wide range of applications in a wide range of environments.
			Unfortunately, this same flexibility makes it extremely difficult to
			produce independent implementations that will actually interoperate
			with one another. In order to build an Internet PKI based on X.509v3
			certificates, the PKIX working group had to develop a profile of the
			X.509v3 specification.
			A profile of the X.509v3 specification is a description of the
			contents of the certificate and which certificate extensions must be
			supported, which extensions may be supported, and which extensions
			may not be supported. [RFC 2459] provides such a profile of X.509v3
			for the Internet PKI. In addition, [RFC 2459] suggests ranges of
			values for many of the extensions.
			[RFC 2459] also provides a profile for Version 2 CRLs for use in the
			Internet PKI. CRLs, like certificates, have a number of optional
			extensions. In order to promote interoperability, it is necessary to
			constrain the choices an implementor supports.
			In addition to profiling the certificate and CRL formats, it is
			necessary to specify particular Object Identifiers (OIDs) for certain
			encryption algorithms, because there are a variety of OIDs registered
			for some algorithm suites. Thus, PKIX has produced two documents
			([ECDSA] and [KEA]) which provide guidance on the proper
			implementation of specific algorithms.
			Certain organizations, such as countries, have recently mandated
			certain restrictions on certificates (such as that the subject of a
			certificate must be a natural person, or that the country of
			citizenship and/or country of residence of the subject must be
			included in the certificate). A certificate which meets these
			restrictions is deemed a "qualified certificate." In December 1998,
			PKIX adopted as a work item the development of a refinement of
			[RFC2459] that further profiles PKIX certificates into qualified
			certificates. This work is reflected in [QC].
			3.6.2 Operational Protocols
			Operational protocols are required to deliver certificates and CRLs
			(or other certificate status information) to certificate using
			systems. Provision is needed for a variety of different means of
			certificate and CRL delivery, including distribution procedures based
			on LDAP, HTTP, FTP, and X.500. Operational protocols supporting
			these functions are defined in [FTP], [OCSP], [LDAP], and [WEB].
			3.6.3 Management Protocols
			Management protocols are required to support on-line interactions
			between PKI user and management entities. For example, a management
			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
			other. A management protocol can be used to carry user or client
			system registration information, or a request for revocation of a
			certificate.
			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
			actual protocol that governs the transmission of those messages.
			Originally, the PKIX working group developed two documents ([CRMF]
			and [CMMF]) that together described the necessary set of message
			formats, and two other documents ([CMP] and [CMC]) that described
			protocols for exchanging those messages. However, the message
			formats defined in [CMMF] were inserted into both [CMP] and [CMC],
			and thus [CMMF] will be dropped as a PKIX document.
			3.6.4 Policy Outline
			As mentioned before, profiling certificates and specifying
			operational and management protocols only addresses a part of the
			problem of actually developing and implementing a secure PKI. What is
			also needed is the development of a certificate policy and
			certification practice statement, and then following those documents.
			The CP and CPS should address physical and personnel security,
			subject identification requirements, revocation policy, and a number
			of other topics. [PKIX-4] provides a framework for certification
			practice statements.
			3.6.5 Time-Stamp and Data Certification Services
			In late 1998, the PKIX working group began two efforts that were not
			in the original working group charter, but were deemed to be
			appropriate because they described infrastructure services that could
			be used to provide desired security services. The first of these is
			time stamping, described in [TSP]. Time stamping is a service in
			which a trusted third party - a Time Stamp Authority, or TSA - signs
			a message, in order to provide evidence that it existed prior to a
			given time. Time stamping provides some support for non-repudiation,
			in that a user cannot claim that a transaction was later forged after
			compromise of a private key, because the existence of the signed time
			stamp indicates that the transaction in question could not have been
			created after the indicated time.
			[TSP] also defines the role of a Temporal Data Authority, or TDA. A
			TDA is a TTP that creates a temporal data token. This temporal data
			token associates a message with a particular event and provides
			supplementary evidence for the time included in the time stamp token.
			For example, a TDA could associate the message with the most recent
			closing value of the Dow Jones Average. The temporal data with which
			the message is associated should be unpredictable in order to prevent
			forward dating of tokens.
			The second new effort is the definition of a Data Certification
			Server, or DCS, protocol [DCS]. A DCS is a Trusted Third Party that
			verifies the correctness of specific data submitted to it.
			This is different from the TSP service in that a TSA will not attempt
			to parse and/or verify a message sent to it for certification;
			instead, it will merely append a reliable indication of the current
			time, and sign the resulting string-of-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 DCS certifies possession of
			data or the validity of another entity's signature. As part of this,
			the DCS 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 DCS's CA,
			or the root CA in a hierarchy).
			The DCS supports non-repudiation in two ways. First, 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.
	4 PKIX Documents		4 PKIX Documents
	This section describes each of the documents written by the PKIX working		This section describes each of the documents written by the PKIX
	group. As PKIX progresses, this section will need to be continually		working group. As PKIX progresses, this section will need to be
	updated to reflect the status of each document (e.g., Proposed Standard,		continually updated to reflect the status of each document (e.g.,
	Draft Standard, Standard, Informational Draft, Informational RFC,		Proposed Standard, Draft Standard, Standard, Informational Draft,
	something-that-was-just-thrown-out-for-consideration, etc.)		Informational RFC, something-that-was-just-thrown-out-for-
			consideration, etc.)
	4.1 Profile		4.1 Profile
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate and		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
	CRL Profile <draft-ietf-pkix-ipki-part1-08.txt>		and CRL Profile (RFC 2459)
	DESCRIPTION: This document describes the profiles to be used for		DESCRIPTION: This document describes the profiles to be used for
	X.509v3 certificates and version2 CRLs by Internet PKI participants. The		X.509v3 certificates and version2 CRLs by Internet PKI participants.
	profiles include the identification of ISO/IEC/ITU and ANSI extensions		The profiles include the identification of ISO/IEC/ITU and ANSI
	which may be useful in the Internet PKI. The profiles are presented in		extensions which may be useful in the Internet PKI. The profiles are
	the 1988 Abstract Syntax Notation One (ASN.1) rather than the 1994		presented in the 1988 Abstract Syntax Notation One (ASN.1) rather
	syntax used in the ISO/IEC/ITU standards. Would-be PKIX implementors		than the 1994 syntax used in the ISO/IEC/ITU standards. Would-be
	and developers of certificate-using applications should start with		PKIX implementors and developers of certificate-using applications
	[PKIX-1] to ensure that their systems will be able to interoperate with		should start with [RFC 2459] to ensure that their systems will be
	other users of the PKI.		able to interoperate with other users of the PKI.
	[PKIX-1]also includes path validation procedures. The procedures		[RFC 2459] also includes path validation procedures. The procedures
	presented are based upon the ISO/IEC/ITU definition, but the		presented are based upon the ISO/IEC/ITU definition, but the
	presentation assumes one or more self-signed trusted CA certificates.		presentation assumes one or more self-signed trusted CA certificates.
	The procedures are provided as examples only. Implementations are not		The procedures are provided as examples only. Implementations are
	required to use the procedures provided; they may implement whichever		not required to use the procedures provided; they may implement
	procedures are efficient for their situation. However, implementations		whichever procedures are efficient for their situation. However,
	are required to derive the same results as the example procedures.		implementations are required to derive the same results as the
			example procedures.
	STATUS:		STATUS: Proposed Standard; approved 29 September 1998.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure:		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure:
	Representation of Elliptic Curve Digital Signature Algorithm (ECDSA)		Representation of Elliptic Curve Digital Signature Algorithm (ECDSA)
	Keys and Signatures in Internet X.509 Public Key Infrastructure		Keys and Signatures in Internet X.509 Public Key Infrastructure
	Certificates <draft-ietf-pkix-ipki-ecdsa-01.txt>		Certificates <draft-ietf-pkix-ipki-ecdsa-01.txt>
	DESCRIPTION: This document provides Object Identifiers (OIDs) and other		DESCRIPTION: This document provides Object Identifiers (OIDs) and
	guidance for IPKI users who use the Elliptic Curve Digital Signature		other guidance for IPKI users who use the Elliptic Curve Digital
	Algorithm (ECDSA). It profiles the format and semantics of the		Signature Algorithm (ECDSA). It profiles the format and semantics of
	subjectPublicKeyInfo field and the keyUsage extension in X.509 V3		the subjectPublicKeyInfo field and the keyUsage extension in X.509 V3
	certificates containing ECDSA keys. This document should be used by		certificates containing ECDSA keys. This document should be used by
	anyone wishing to support ECDSA; others who do not support ECDSA are not		anyone wishing to support ECDSA; others who do not support ECDSA are
	required to comply with it.		not required to comply with it.
	STATUS:		STATUS:
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Representation		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
	of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key		Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509
	Infrastructure Certificates		Public Key Infrastructure Certificates (RFC ####)
	DESCRIPTION: This document provides Object Identifiers (OIDs) and other		DESCRIPTION: This document provides Object Identifiers (OIDs) and
	guidance for IPKI users who use the Key Exchange Algorithm (KEA). It		other guidance for IPKI users who use the Key Exchange Algorithm
	profiles the format and semantics of the subjectPublicKeyInfo field and		(KEA). It profiles the format and semantics of the
	the keyUsage extension in X.509 V3 certificates containing KEA keys.		subjectPublicKeyInfo field and the keyUsage extension in X.509 V3
	This document should be used by anyone wishing to support KEA; others		certificates containing KEA keys. This document should be used by
	who do not support ECDSA are not required to comply with it.		anyone wishing to support KEA; others who do not support ECDSA are
			not required to comply with it.
	STATUS:		STATUS: Informational RFC; approved 22 January 1999.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure OPEN CRL		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL
	DISTRIBUTION PROCESS (OpenCDP) <draft-ietf-pkix-ocdp-00.txt>		Distribution Options (OpenCDP) <draft-ietf-pkix-ocdp-01.txt>
	DESCRIPTION: This document proposes an alternative to the CRL		DESCRIPTION: This document proposes an alternative to the CRL
	Distribution Point (CDP) approach documented in [PKIX-1]. OCDP separates		Distribution Point (CDP) approach documented in [RFC 2459]. OCDP
	the CRL location function from the process of certificate and CRL		separates the CRL location function from the process of certificate
	validation, and thus claims some benefits over the CDP approach.		and CRL validation, and thus claims some benefits over the CDP
			approach.
	STATUS:		STATUS:
	4.2 Operational Protocols		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified
			Certificates <draft-ietf-pkix-qc-00.txt>
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational		DESCRIPTION: This document profiles the format for and defines
	Protocols - LDAPv2 <draft-ietf-pkix-ipki2opp-07.txt>		requirements on information content in a specific type of
			certificates called Qualified Certificates. A "Qualified Certificate"
			is a certificate 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.
	DESCRIPTION: This document describes the use of LDAPv2 as a protocol		STATUS:
	for PKI elements to publish and retrieve certificates and CRLs from a
	certificate repository. LDAPv2 [RFC abcd] is a protocol that allows
	publishing and retrieving of information.
	STATUS:		4.2 Operational Protocols
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2 Schema		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational
	<draft-ietf-pkix-ldapv2-schema-00.txt>		Protocols - LDAPv2 <draft-ietf-pkix-ipki2opp-08.txt>
	DESCRIPTION: This document defines a minimal schema necessary to		DESCRIPTION: This document describes the use of LDAPv2 as a protocol
	support the use of LDAPv2 for certificate and CRL retrieval and related		for PKI elements to publish and retrieve certificates and CRLs from a
	functions for PKIX. This document supplements [LDAP] by identifying the		certificate repository. LDAPv2 [RFC 1777] is a protocol that allows
	PKIX-related attributes that must be present.		publishing and retrieving of information.
	STATUS:		STATUS:
	DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2
	Certificate Status Protocol - OCSP <draft-ietf-pkix-ocsp-04.txt>		Schema <draft-ietf-pkix-ldapv2-schema-02.txt>
	DESCRIPTION: This document specifies a protocol useful in determining		DESCRIPTION: This document defines a minimal schema necessary to
	the current status of a certificate without the use of CRLs. A major		support the use of LDAPv2 for certificate and CRL retrieval and
	complaint about certificate-based systems is the need for a relying		related functions for PKIX. This document supplements [LDAP] by
	party to retrieve a current CRL as part of the certificate validation		identifying the PKIX-related attributes that must be present.
	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		STATUS:
	whereby a relying party identifies one or more certificates to an
	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.
	STATUS:		DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online
			Certificate Status Protocol - OCSP <draft-ietf-pkix-ocsp-07.txt>
	DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the Online		DESCRIPTION: This document specifies a protocol useful in
	Certificate Status Protocol <draft-ietf-pkix-ocsp-caching-00.txt>		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.)
	DESCRIPTION: To improve the degree to which it can scale, OCSP allows		OCSP attempts to address those problems. It provides a mechanism
	caching of responses - e.g., at intermediary servers, or even at the		whereby a relying party identifies one or more certificates to an
	relying party's end system. This document describes how to support OCSP		approved OCSP "responder", and the responder sends back the current
	caching at intermediary servers.		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.
	STATUS:		STATUS:
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational		DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the
	Protocols: FTP and HTTP <draft-ietf-pkix-opp-ftp-http-04.txt>		Online Certificate Status Protocol <draft-ietf-pkix-ocsp-
			caching-00.txt>
	DESCRIPTION: This document describes the use of the File Transfer		DESCRIPTION: To improve the degree to which it can scale, OCSP
	Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain		allows caching of responses - e.g., at intermediary servers, or even
	certificates and CRLs from PKI repositories.		at the relying party's end system. This document describes how to
			support OCSP caching at intermediary servers.
	STATUS:		STATUS:
	DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational
			Protocols: FTP and HTTP <draft-ietf-pkix-opp-ftp-http-04.txt>
	DESCRIPTION: This document specifies a set of methods, headers, and		DESCRIPTION: This document describes the use of the File Transfer
	content-types ancillary to HTTP/1.1 to publish, retrieve X.509		Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain
	certificates and Certificate Revocation Lists. This protocol also		certificates and CRLs from PKI repositories.
	facilitates determining current status of a digital certificate without
	the use of CRLs. This protocol defines new methods, request and
	response bodies, error codes to HTTP/1.1 protocol for securely
	publishing, retrieving, and validating certificates across a firewall.
	STATUS:		STATUS:
	4.3 Management Protocols		DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0
	DOCUMENT TITLE: Certificate Management Messages over CMS		DESCRIPTION: This document specifies a set of methods, headers, and
	<draft-ietf-pkix-cmc-00.txt>		content-types ancillary to HTTP/1.1 to publish, retrieve X.509
			certificates and Certificate Revocation Lists. This protocol also
			facilitates determining current status of a digital certificate
			without the use of CRLs. This protocol defines new methods, request
			and response bodies, error codes to HTTP/1.1 protocol for securely
			publishing, retrieving, and validating certificates across a
			firewall.
	DESCRIPTION: This document defines the means by which PKI clients and		STATUS:
	servers may exchange PKI messages when using S/MIME's Cryptographic
	Message Syntax [CMS]as a transaction envelope. CMC supports message
	bodies specified in the Certificate Management Message Formats [CMMF]
	and Certificate Request Message Format [CRMF] documents. The purpose of
	this specification is to allow the use of an existing protocol (S/MIME)
	as a PKI management protocol, rather than requiring the development of a
	new, custom protocol for the task.
	STATUS:		4.3 Management Protocols
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate		DOCUMENT TITLE: Certificate Management Messages over CMS <draft-ietf-
	Management Message Formats <draft-ietf-pkix-cmmf-02.txt>		pkix-cmc-02.txt>
	DESCRIPTION: This document contains the formats for a series of		DESCRIPTION: This document defines the means by which PKI clients and
	messages important in certificate/PKI management. These messages let		servers may exchange PKI messages when using S/MIME's Cryptographic
	CA's, RA's, and relying parties communicate with each other. Note that		Message Syntax [CMS]as a transaction envelope. CMC supports the
	this document only specifies message formats; it does not specify a		certificate request message body specified in the Certificate Request
	protocol for transferring messages. That protocol can be either CMP or		Message Format [CRMF] documents, as well as a variety of other
	CMC, or perhaps another custom protocol.		certificate management messages. The primary purpose of this
			specification is to allow the use of an existing protocol (S/MIME)as
			a PKI management protocol, without requiring the development of an
			entirely new protocol such as CMP. A secondary purpose is to codify
			in IETF standards the current industry practice of using PKCS 10
			messages [PKCS10] for certificate requests. DOCUMENT TITLE: Internet
			X.509 Public Key Infrastructure Certificate Management Message
			Formats <draft-ietf-pkix-cmmf-02.txt>
	STATUS:		DESCRIPTION: This document contains the formats for a series of
			messages important in certificate/PKI management. These messages let
			CA's, RA's, and relying parties communicate with each other. Note
			that this document only specifies message formats; it does not
			specify a protocol for transferring messages. That protocol can be
			either CMP or CMC, or perhaps another custom protocol.
	DOCUMENT TITLE: Internet X.509 Certificate Request Message Format		STATUS: Will be discontinued, as all useful information from it has
	<draft-ietf-pkix-crmf-01.txt>		been moved into [CMP] and [CMC].
	DESCRIPTION: CRMF specifies a format recommended for use whenever a		DOCUMENT TITLE: Internet X.509 Certificate Request Message Format
	relying party is requesting a certificate from a CA or requesting that		(RFC####)
	an RA help it get a certificate. This document is distinct from CMMF
	for historical reasons - the request message format was needed before
	many of the other message formats had to be finalized, and so it was put
	into a separate document. Like CMMF, this document only specifies the
	format of a message. Specification of a protocol to transport that
	message is beyond the scope of CRMF.
	STATUS:		DESCRIPTION: CRMF specifies a format recommended for use whenever a
			relying party is requesting a certificate from a CA or requesting
			that an RA help it get a certificate. This document is distinct from
			CMMF for historical reasons - the request message format was needed
			before many of the other message formats had to be finalized, and so
			it was put into a separate document. Like CMMF, this document only
			specifies the format of a message. Specification of a protocol to
			transport that message is beyond the scope of CRMF.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate		STATUS: Proposed Standard; approved 22 January 1999.
	Management Protocols <draft-ietf-pkix-ipki3cmp-08.txt>
	DESCRIPTION: This document specifies a new protocol specifically		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
	developed for the purpose of transporting messages like those specified		Management Protocols (RFC ####)
	in CMMF and CRMF among PKI elements. In general, CMP will be used in
	conjunction with CMMF and CRMF, and will then be run over a transfer
	service (e.g., S/MIME, HTTP) to provide a complete PKI management
	service.
	STATUS:		DESCRIPTION: This document specifies a new protocol specifically
			developed for the purpose of transporting messages like those
			specified in CMMF and CRMF among PKI elements. In general, CMP will
			be used in conjunction with CMMF and CRMF, and will then be run over
			a transfer service (e.g., S/MIME, HTTP) to provide a complete PKI
			management service.
			STATUS: Proposed Standard; approved 22 January 1999.
	4.4 Policy Outline		4.4 Policy Outline
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
	Policy and Certification Practices Framework		Policy and Certification Practices Framework (RFC ####)
	<draft-ietf-pkix-ipki-part4-03.txt>
	DESCRIPTION: As noted before, the specification and implementation of		DESCRIPTION: As noted before, the specification and implementation of
	certificate profiles, operational protocols, and management protocols		certificate profiles, operational protocols, and management protocols
	is only part of building a PKI. Equally as important - if not more		is only part of building a PKI. Equally as important - if not more
	important - is the development and enforcement of a certificate security		important - is the development and enforcement of a certificate
	policy, and a Certification Practice Statement (CPS). The purpose of		security policy, and a Certification Practice Statement (CPS). The
	this document (PKIX-4) is to establish a clear relationship between		purpose of this document (PKIX-4) is to establish a clear
	certificate policies and(CPSs), and to present a framework to assist the		relationship between certificate policies and(CPSs), and to present a
	writers of certificate policies or CPSs with their tasks. In		framework to assist the writers of certificate policies or CPSs with
	particular, the framework identifies the elements that may need to be		their tasks. In particular, the framework identifies the elements
	considered in formulating a certificate policy or a CPS. The purpose is		that may need to be considered in formulating a certificate policy or
	not to define particular certificate policies or CPSs, per se.		a CPS. The purpose is not to define particular certificate policies
			or CPSs, per se.
	STATUS:		STATUS: Informational RFC, approved 22 January 1999.
	4.5 DOCUMENT RELATIONSHIPS		4.5 Time-Stamp and Data Certification Services
	Figure 2 shows graphically the relationships among the PKIX documents.		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp
			Protocols <draft-ietf-pkix-time-stamp-00.txt>
	CERT and CRL PROFILES		DESCRIPTION: This document defines the specification for a time stamp
	Certificate and CRL Profile		service. It defines a Time Stamp Authority, or TSA, a trusted third
	|		party who maintains a reliable time service. When the TSA receives a
	+--- Representation of Elliptic Curve Digital Signature Algorithm		time stamp request, it appends the current time to the request and
	| (ECDSA)Keys and Signatures in Internet X.509		signs it into a token to certify that the original request existed
	| Public Key Infrastructure Certificates		prior to the indicated time. This helps provide non-repudiation by
	+--- Representation of Key Exchange Algorithm (KEA) Keys in		preventing someone (either a legitimate user or an attacker who has
	| Internet X.509 Public Key Infrastructure Certificates		successfully compromised a key) from "back-dating" a transaction. It
	+--- OPEN CRL DISTRIBUTION PROCESS (OpenCDP)		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.
	Operational Protocols		STATUS:
	|
	+---------- Internet X.509 Public Key Infrastructure Operational
	| Protocols - LDAPv2 <draft-ietf-pkix-ipki2opp-07.txt>
	| |
	| +----- Internet X.509 Public Key Infrastructure LDAPv2
	| Schema <draft-ietf-pkix-ldapv2-schema-00.txt>
	|
	+--+- X.509 Internet Public Key Infrastructure Online Certificate
	| | Status Protocol - OCSP <draft-ietf-pkix-ocsp-04.txt>
	| |
	| +-- Internet Public Key Infrastructure: Caching the Online
	| Certificate Status Protocol <draft-ietf-pkix-ocsp-caching-00.txt>
	|
	+------- Internet X.509 Public Key Infrastructure Operational
	| Protocols: FTP and HTTP <draft-ietf-pkix-opp-ftp-http-04.txt>
	|
	+------- WEB based Certificate Access Protocol-- WebCAP/1.0
	Management Protocols		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data
	|		Certification Server Protocols <draft-ietf-pkix-dcs-00.txt>
	+--- Message Formats
	| |
	| +--- Internet X.509 Public Key Infrastructure Certificate
	| | Management Message Formats
	| +--- Internet X.509 Certificate Request Message Format
	| <draft-ietf-pkix-crmf-01.txt>
	|
	+--- Protocols
	|
	+--- Internet X.509 Public Key Infrastructure Certificate
	| Management Protocols
	+--- Certificate Management Messages over CMS
	<draft-ietf-pkix-cmc-00.txt>
	Policy Outline		DESCRIPTION: This document defines a data certification service, or
	|		DCS, which can be used to certify both the existence and correctness
	+-- Internet X.509 Public Key Infrastructure Certificate Policy and		of a message or signature. In contrast to the time stamp service
	Certification Practices Framework		described above, the DCS certifies possession of data or the validity
			of another entity's signature. As part of this, the DCS 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 DCS's CA, or the root CA
			in a hierarchy).
	Figure 2: Document Relationships		The DCS supports non-repudiation in two ways. First, 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.
	5 Advice to Implementors		STATUS:
	This section provides guidance to those who would implement various		5 Advice to Implementors
	parts of the PKIX suite of documents. The topics discussed in this
	section engendered significant discussion in the working group, and
	there was at times either widespread disagreement or widespread
	misunderstanding of them. Thus, this discussion is provided to help
	readers of the PKIX document set understand these issues, in the hope of
	fostering greater interoperability among eventual PKIX implementations.
	5.1 Names		This section provides guidance to those who would implement various
			parts of the PKIX suite of documents. The topics discussed in this
			section engendered significant discussion in the working group, and
			there was at times either widespread disagreement or widespread
			misunderstanding of them. Thus, this discussion is provided to help
			readers of the PKIX document set understand these issues, in the hope
			of fostering greater interoperability among eventual PKIX
			implementations.
	PKIX has been referred to as a "name-centric" PKI because the		5.1 Names
	certificates associate public keys with names of entities. Each
	certificate contains at least one name for the owner of a particular		PKIX has been referred to as a "name-centric" PKI because the
	public key. The name can be an X.500 distinguished name, contained in		certificates associate public keys with names of entities. Each
	the subjectDN field of the certificate. There can also be names such as		certificate contains at least one name for the owner of a particular
	RFC822 e-mail addresses, DNS domain names, and URIs associated with the		public key. The name can be an X.500 distinguished name, contained
	key; these attributes are kept in the subjectAltName extension of the		in the subjectDN field of the certificate. There can also be names
	certificate. A certificate must contain at least one of these name		such as RFC822 e-mail addresses, DNS domain names, and URIs
	forms, it may contain multiple forms if deemed appropriate by the CA		associated with the key; these attributes are kept in the
	based on the intended usage of the certificate.		subjectAltName extension of the certificate. A certificate must
			contain at least one of these name forms, it may contain multiple
			forms if deemed appropriate by the CA based on the intended usage of
			the certificate.
	5.1.1 Name Forms		5.1.1 Name Forms
	There are two possible places to put a name in an X.509v3 certificate.		There are two possible places to put a name in an X.509v3
	One is the subject field in the base certificate (often called the		certificate. One is the subject field in the base certificate (often
	"Distinguished Name" or "DN" field), and the other is in the		called the "Distinguished Name" or "DN" field), and the other is in
	subjectAltName extension.		the subjectAltName extension.
	5.1.1.1 Distinguished Names		5.1.1.1 Distinguished Names
	According to [PKIX-1], a PKIX certificate must have a non-null value in		According to [RFC 2459], a PKIX certificate must have a non-null
	the Distinguished Name field, except for an end-entity certificate,		value in the Subject field, except for an end-entity certificate,
	which is permitted to have an empty DN field.		which is permitted to have an empty subject field. Furthermore, if a
			certificate 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 certificate may have one or more values in		In addition to the DN, a PKIX certificate may have one or more values
	the subjectAltName extension.		in the subjectAltName extension.
	The subjectAltName extension allows additional identities to be bound to		The subjectAltName extension allows additional identities to be bound
	the subject of the certificate - e.g., it allows "umbc.edu" and		to the subject of the certificate - e.g., it allows "umbc.edu" and
	"130.85.1.3" to be associated with a particular subject, as well as		"130.85.1.3" to be associated with a particular subject, as well as
	"C=US, O=University of Maryland, L=Baltimore, CN=UMBC". X.509-defined		"C=US, O=University of Maryland, L=Baltimore, CN=UMBC".
	options for this extension include: Internet electronic mail addresses;		X.509-defined options for this extension include: Internet
	DNS names; IP addresses; and uniform resource indentifiers (URIs).		electronic mail addresses; DNS names; IP addresses; and uniform
	Other options can exist, including locally-defined name forms.		resource indentifiers (URIs). Other options can exist, including
			locally-defined name forms.
	A single subjectAltName extension can include multiple name forms, and		A single subjectAltName extension can include multiple name forms,
	multiple instances of each name form.		and multiple instances of each name form.
	Note: whenever such Alternate Name forms are to be bound into a		Whenever such Alternate Name forms are to be bound into a
	certificate, the subject alternative name (or issuer alternative name)		certificate, the subject alternative name (or issuer alternative
	extension must be used. It is technically possible to embed an		name) extension must be used. It is technically possible to embed an
	Alternate Name Form in the subject field. For example, one could make a		Alternate Name Form in the subject field. For example, one could
	DN contain an IP address via a kludge such as "C=US, L=Baltimore,		make a DN contain an IP address via a kludge such as "C=US,
	CN=130.85.1.3". However, this usage is deprecated; the alternative name		L=Baltimore, CN=130.85.1.3". However, this usage is deprecated; the
	extension is the preferred location for finding such information.)		alternative name extension is the preferred location for finding such
			information. As another example, some legacy implementations exist
			where an RFC822 name is embedded in the subject distinguished name as
			an EmailAddress attribute. Per [RFC 2459], PKIX-compliant
			implementations generating new certificates with electronic mail
			addresses MUST use the rfc822Name in the subject alternative name
			field to describe such entities. Simultaneous inclusion of the
			EmailAddress attribute in the subject distinguished name to support
			legacy implementation is deprecated but permitted.
	In line with this, if the only subject identity included in a		In line with this, if the only subject identity included in a
	certificate is an alternative name form, then the subject distinguished		certificate is an alternative name form, then the subject
	name must be empty (technically, an empty sequence), and the		distinguished name must be empty (technically, an empty sequence),
	subjectAltName extension must be present. If the subject field contains		and the subjectAltName extension must be present. If the subject
	an empty sequence, the subjectAltName extension must be marked critical.		field contains an empty sequence, the subjectAltName extension must
			be marked critical.
	If the subjectAltName extension is present, the sequence must contain at		If the subjectAltName extension is present, the sequence must contain
	least one entry. Unlike the subject field, conforming CAs shall not		at least one entry. Unlike the subject field, conforming CAs shall
	issue certificates with subjectAltNames containing empty GeneralName		not issue certificates with subjectAltNames containing empty
	fields. For example, an rfc822Name is represented as an IA5String. While		GeneralName fields. For example, an rfc822Name is represented as an
	an empty string is a valid IA5String, such an rfc822Name is not		IA5String. While an empty string is a valid IA5String, such an
	permitted by PKIX. The behavior of clients that encounter such a		rfc822Name is not permitted by PKIX. The behavior of clients that
	certificate when processing a certification path is not defined by this		encounter such a certificate when processing a certification path is
	working group.		not defined by this working group.
	Because the subject alternative name is considered to be definitively		Because the subject alternative name is considered to be definitively
	bound to the public key, all parts of the subject alternative name must		bound to the public key, all parts of the subject alternative name
	be verified by the CA.		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, the		When the subjectAltName extension contains an Internet mail address,
	adress is included as an rfc822Name. The format of an rfc822Name is an		the adress is included as an rfc822Name. The format of an rfc822Name
	"addr-spec" as defined in RFC 822 [RFC 822]. An addr-spec has the form		is an "addr-spec" as defined in RFC 822 [RFC 822]. An addr-spec has
	local-part@domain; it does not have a phrase (such as a common name)		the form local-part@domain; it does not have a phrase (such as a
	before it, or a comment (text surrounded in parentheses) after it, and		common name) before it, or a comment (text surrounded in parentheses)
	it is not surrounded by "<" and ">".		after it, 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 label,		When the subjectAltName extension contains a domain name service
	the domain name is stored in the dNSName attribute(an IA5String). The		label, the domain name is stored in the dNSName attribute(an
	string shall be in the "preferred name syntax," as specified by RFC 1034		IA5String). The string shall be in the "preferred name syntax," as
	[RFC 1034]. Note that while upper and lower case letters are allowed in		specified by RFC 1034 [RFC 1034]. Note that while upper and lower
	domain names, no signifigance is attached to the case. In addition,		case letters are allowed in domain names, no signifigance is attached
	while the string " " is a legal domain name, subjectAltName extensions		to the case. In addition, while the string " " is a legal domain
	with a dNSName " " are not permitted. Finally, the use of the DNS		name, subjectAltName extensions with a dNSName " " are not permitted.
	representation for Internet mail addresses (wpolk.nist.gov instead of		Finally, the use of the DNS representation for Internet mail
	wpolk@nist.gov) is not permitted; such identities are to be encoded as		addresses (wpolk.nist.gov instead of wpolk@nist.gov) is not
	rfc822Name.		permitted; such identities are to be encoded as rfc822Name.
	5.1.1.2.3 IP addresses		5.1.1.2.3 IP addresses
	When the subjectAltName extension contains an iPAddress, the address		When the subjectAltName extension contains an iPAddress, the address
	shall be stored in the octet string in "network byte order," as		shall be stored in the octet string in "network byte order," as
	specified in RFC 791 [RFC 791]. The least significant bit (LSB) of each		specified in RFC 791 [RFC 791]. The least significant bit (LSB) of
	octet is the LSB of the corresponding byte in the network address. For		each octet is the LSB of the corresponding byte in the network
	IP Version 4, as specified in RFC 791, the octet string must contain		address. For IP Version 4, as specified in RFC 791, the octet string
	exactly four octets. For IP Version 6, as specified in RFC 1883, the		must contain exactly four octets. For IP Version 6, as specified in
	octet string must contain exactly sixteen octets [RFC1883].		RFC 1883, the octet string must contain exactly sixteen octets
			[RFC1883].
	5.1.1.2.4 URIs		5.1.1.2.4 URIs
	(is there any guidance about URIs as name forms?)		[RFC 2459] notes "When the subjectAltName extension contains a URI,
			the name MUST be stored in the uniformResourceIdentifier (an
			IA5String). The name MUST be a non-relative URL, and MUST follow the
			URL syntax and encoding rules specified in [RFC 1738]. The name must
			include both a scheme (e.g., "http" or "ftp") and a scheme-specific-
			part. The scheme-specific-part must include a fully qualified domain
			name or IP address as the host. As specified in [RFC 1738], the
			scheme name is not case-sensitive (e.g., "http" is equivalent to
			"HTTP"). The host part is also not case-sensitive, but other
			components of the scheme-specific-part may be case-sensitive. When
			comparing URIs, conforming implementations MUST compare the scheme
			and host without regard to case, but assume the remainder of the
			scheme-specific-part is case sensitive."
	5.1.2 Scope of Names		5.1.2 Scope of Names
	The original X.500 work presumed that every subject in the world would		The original X.500 work presumed that every subject in the world
	have a globally-unique distinguished name. Thus, every subject could		would have a globally-unique distinguished name. Thus, every subject
	be easily located, and there would never be a conflict. All that would		could be easily located, and there would never be a conflict. All
	be needed is a sufficiently-large name space, and rules for constructing		that would be needed is a sufficiently-large name space, and rules
	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 to		reasons. There is no single entity in the world trusted by everybody
	reside at the top of the name space, and there is no way to enforce		to reside at the top of the name space, and there is no way to
	uniqueness on names for all entities. (These were among the reasons for		enforce uniqueness on names for all entities. (These were among the
	the failure of PEM to be widely implemented.)		reasons for the failure of PEM to be widely implemented.)
	This does not mean, however, that a name-based PKI cannot work. It is		This does not mean, however, that a name-based PKI cannot work. It
	important to recognize that the scope of names in PKIX is local; they		is important to recognize that the scope of names in PKIX is local;
	need to be defined and unique only within their own domain.		they need to be defined and unique only within their own domain.
	Suppose for example that a rootCA is established with DN "O=IETF,		Suppose for example that a rootCA is established with DN "O=IETF,
	OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for names		OU=PKIX, CN=PKIX_CA". That CA will then issue certificates for users
	subordinate to it. The only requirement - and this can be enforced		subordinate to it. The only requirement - and this can be enforced
	procedurally - is that no two distinct entities beneath this rootCA have		procedurally - is that no two distinct entities beneath this rootCA
	the same name. We can't prevent somebody else in the world from creating		have the same name. We can't prevent somebody else in the world from
	her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is not		creating her own CA, called "O=IETF, OU=PKIX, CN=PKIX_CA", and it is
	necessary to do so. Within the domain of the original rootCA, there		not necessary to do so. Within the domain of the original rootCA,
	will be no conflict, and the fact that there is another CA of the same		there will be no conflict, and the fact that there is another CA of
	name in some other domain is irrelevant.		the same name in some other domain is irrelevant.
	This is analogous to the current DNS or IP address situations. On the		This is analogous to the current DNS or IP address situations. On
	Internet, there is only one node called www.ietf.org. The fact that		the Internet, there is only one node called www.ietf.org. The fact
	there might be 10 different intranets, each with a host given the DNS		that there might be 10 different intranets, each with a host given
	name www.ieft.org, is irrelevant and causes no interoperability problems		the DNS name www.ieft.org, is irrelevant and causes no
	- those are different domains. However, if there were to be another		interoperability problems - those are different domains. However, if
	node on the Internet with domain name www.ietf.org, then there would be		there were to be another node on the Internet with domain name
	a problem due to name duplication.		www.ietf.org, then 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, each		despite the fact that there are 100 different corporate Intranets,
	using that same IP address. However, if two different nodes on the		each using that same IP address. However, if two different nodes on
	Internet each responded to the IP address 130.85.1.3, there would be a		the Internet each responded to the IP address 130.85.1.3, there would
	problem.		be a problem.
	5.1.3 Certificate Path Construction		5.1.3 Certificate Path Construction
	Path construction - make point that there is no single best way to		Path construction - make point that there is no single best way to
	construct a path. Implementors can pick the way that is most efficient		construct a path. Implementors can pick the way that is most
	for them. Discuss some of the issues being hashed out in the "ldap"		efficient for them. Discuss some of the issues being hashed out in
	discussion on the mail list. If there is ever a resolution, include it		the "ldap" discussion on the mail list. If there is ever a
	in this section.		resolution, include it in this section.
	5.1.4 Name Constraints		5.1.4 Name Constraints
	(Note: this section still needs a lot of work.)		(Note: this section still needs a lot of work.)
	A question that has arisen a number of times is "how does one enforce		A question that has arisen a number of times is "how does one enforce
	Name constraints when there is more than one name form in a		Name constraints when there is more than one name form in a
	certificate?" That is, [PKIX-1] states that:		certificate?" That is, [RFC 2459] states that:
	Subject alternative names may be constrained in the same manner as		Subject 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 dNSName		OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having
	"PKIX_CA.IETF.ORG". Suppose that that CA has issued a certificate with		dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a
	an empty DN, with subjectAltName extension having dNSName set to		certificate with an empty DN, with subjectAltName extension having
	"PKIX_CA.IETF.ORG", and rfc822Name set to Steve@PKIX_CA.IETF.ORG. The		dNSName set to "PKIX_CA.IETF.ORG", and rfc822Name set to
	question is, are name constraints enforced on these two certificates -		Steve@PKIX_CA.IETF.ORG. The question is, are name constraints
	is the name of the end-entity certificate considered to be properly		enforced on these two certificates - is the name of the end-entity
	subordinate to the name of the CA?		certificate considered to be properly subordinate to the name of the
			CA?
	The answer is "yes". In deciding whether a name form meets name		The answer is "yes". The general rules for deciding whether a
	constraints, the following rules apply:		certificate meets name constraints are:
	- for DNs:
	- for rfc822Names:
	- for dNSNames:
	- for URIs:
	- for iPaddresses
	The general rules are:		If a certificate complies with name constraints in any one of its
			name forms, then the certificate is deemed to comply with name
			constraints.
	If a certificate complies with name constraints in any one of its name		If a certificate contains a name form that its issuer does not,
	forms, then the certificate is deemed to comply with name constraints.		the certificate is deemed to comply with name constraints for that
			name form.
	If a certificate contains a name form that its issuer does not, the		In deciding whether a name form meets name constraints, the following
	certificate is deemed to comply with name constraints for that name		rules apply:
	form.
			- for DNs: - for rfc822Names: - for dNSNames: 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 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 is not subordinate to
			web.mit.edu. - for URIs: - for iPaddresses: Name A is subordinate to
			Name B if...
	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.
	e.g. "*.mit.edu" meaning "any domain name ending in .mit.edu", and		"*.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
	certificates would be a useful thing to do, because it would allow a		certificates would be a useful thing to do, because it would allow a
	single certificate to be used by all members of a group. These members		single certificate to be used by all members of a group. These
	would presumably have attributes in common; e.g., access rights to some		members would presumably have attributes in common; e.g., access
	set of resources, and so issuance of a certificate with a wildcard for		rights to some set of resources, and so issuance of a certificate
	the group would simplify management.		with a wildcard for the group would simplify management.
	After much discussion, the PKIX working group decided to permit the use		After much discussion, the PKIX working group decided to permit the
	of wildcards in certificates. That is, it is permissible for a		use of wildcards in certificates. That is, it is permissible for a
	PKIX-conformant CA to issue a certificate with a wildcard. However,		PKIX-conformant CA to issue a certificate with a wildcard. However,
	the semantics of subject alternative names that include wildcard		the semantics of subject alternative names that include wildcard
	characters are not addressed by PKIX. Applications with specific		characters are not addressed by PKIX. Applications with specific
	requirements may use such names but must define the semantics.		requirements may use such names but must define the semantics.
	5.1.6 Name Encoding		5.1.6 Name Encoding
	(insert a section on encoding non-ASCII names. Key points to make:)		(insert a section on encoding non-ASCII names. Key points to make:)
	- UTF8 is the long-term goal for IETF, and is mandatory in 2003 and		- UTF8 is the long-term goal for IETF, and is mandatory in 2003 and
	later		later - BMPString is presently supported by most vendors -
	- BMPString is presently supported by most vendors		Teletexstring containing ISO 8859-1 is also used by many CA's
	- Teletexstring containing ISO 8859-1 is also used by many CA's
	5.2 POP		5.2 POP
	- The importance of PoP		Proof of Possession, or POP, means that the CA is adequately
	- PoP for signature keys vs. PoP for key-management keys		convinced that the entity requesting a certificate containing a
	- What the CA/RA has to do		public key Y has access to the private key X corresponding to that
	- Different ways of accomplishing this		public key.
			POP is important because it provides an appropriate level of
			assurance in the correct operation of the PKI as a whole. At its
			lowest level, POP counters the "self-inflicted denial of service";
			that is, an entity voluntarily getting a certificate that cannot be
			used to sign or encrypt/decrypt information. However, as the
			following two examples demonstrate, POP also counters less direct,
			but more severe, threats:
			POP for signing keys: it is important to provide POP for keys used
			to sign material, in order to provide non-repudiation of
			transactions. For example, suppose Alice legitimately has private
			key X and its corresponding public key Y. Alice has a certificate
			from Charlie, a CA, containing Y. Alice uses X to sign a
			transaction T. Without POP, Mal could also get a certificate from
			Charlie containing the same public key, Y. Now, there are two
			possible threats: Mal could claim to have been the real signer of
			T; or Alice can falsely deny signing T, claiming that it was
			instead Mal. Since no one can reliably prove that Mal did or did
			not ever possess X, neither of these claims can be refuted, and
			thus the service provided by and the confidence in the PKI has
			been defeated. (Of course, if Mal really did possess X, Alice's
			private key, then no POP mechanism in the world will help, but
			that is a different problem.)
			Note that one level of protection can be gained by having Alice,
			as the true signer of the transaction, include in the signed
			information her certificate or an identifier of her certificate
			(e.g., a hash of her certificate). This might make it more
			difficult for Mal to claim authorship - he would have to assert
			that he incorrectly included Alice's certificate, rather than his
			own. However, it would not stop Alice from falsely repudiating
			her actions. Since the certificate itself is a public item, Mal
			indeed could have inserted Alice's certificate into the signed
			transaction, and thus its presence does not indicate that Alice
			was the one who participated in the now-repudiated transaction.
			The only reliable way to stop this attack is to require that Mal
			prove he possesses X before his certificate is issued.
			For signing keys used only for authentication, and not for non-
			repudiation, the threat is lower because users may not care about
			Alice's after-the-fact repudiation, and thus POP becomes less
			important. However, POP SHOULD still be done wherever feasible in
			this environment, by either off-line or on-line means.
			POP for key management keys: Similarly, POP for key management keys
			(that is, keys used for either key agreement or key exchange) can
			help to prevent undermining confidence in the PKI. Suppose that Al
			is a new instructor in the Computer Science Department of a local
			University. Al has created a draft final exam for the Introduction
			to Networking course he is teaching. He wants to send a copy of the
			draft final to Dorothy, the Department Head, for her review prior to
			giving the exam. This exam will of course be encrypted, as several
			students have access to the computer system. However, a quick search
			of the certificate repository (e.g., search the repository for all
			records with subjectPublicKey=Dorothy's-value) turns up the fact that
			several students have certificates containing the same public key
			management key as Dorothy. At this point, if no POP has been done by
			the CA, Al has no way of knowing whether all of the students have
			simply created these certificates without knowing the corresponding
			private key (and thus it is safe to send the encrypted exam to
			Dorothy), or whether the students have somehow acquired Dorothy's
			private key (and thus it is certainly not safe to send the exam).
			Thus, the service to be provided by the PKI - allowing users to
			communicate with one another, with confidence in who they are
			communicating with - has been totally defeated. If the CA is
			providing POP, then either no students will have such certificates,
			or Al can know with certainty that the students do indeed know
			Dorothy's private key, and act accordingly.
			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
			POP, and the choice of which to use is a local matter. Additionally,
			a certificate requester can provide POP to either a CA or to an RA,
			if the RA can adequately assure the CA that POP has been performed.
			Some of the 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 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
			environments where "key recovery" requirements force the requester
			to provide a copy of the private key to the CA or an RA. In this
			case, the CA will not issue the requested certificate 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:
			For signature keys that are generated by an end-entity, the
			requester of a certificate can be required to sign some piece of
			data (typically, the certificate request itself) using the private
			key. The CA will then use the requested public key to verify the
			signature. If the signature verification works, the CA can safely
			conclude that the requester had access to the private key. If the
			signature verification process fails, the CA can conclude that the
			requester did not have access to the correct private key, and
			reject the request.
			For key management keys that are generated by the requester, the
			CA can send the user the requested public key, along with the CA's
			own private key, to encrypt some piece of data, and send it to the
			requester to be decrypted. For example, the CA can generate some
			random challenge, and require some action to be taken after
			decryption (e.g., "decrypt this encrypted random number and send
			it back to me"). If the requester does not take the requested
			action, the CA concludes that the requester did not possess the
			private key, and the certificate is not issued.
			Another method of providing POP for key management keys is for the
			CA to generate the requested certificate, and then send it to the
			requester in encrypted form. If the requester does not have
			access to the appropriate private key, the requester cannot
			decrypt the certificate, and thus cannot use it. After some period
			of time in which the certificate is not used, the CA will revoke
			the certificate. (This only works if the certificate 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 certificate.		signature, certificate signing) of the key contained in the
	This extension is used when a key that could be used for more than one		certificate. This extension is used when a key that could be used for
	operation is to be restricted. For example, when an RSA key should be		more than one operation is to be restricted. For example, when an
	used only for signing, the digitalSignature and/or nonRepudiation bits		RSA key should be used only for signing, the digitalSignature and/or
	would be asserted. Likewise, when an RSA key should be used only for key		nonRepudiation bits would be asserted. Likewise, when an RSA key
	management, the keyEncipherment bit would be asserted. When used, this		should be used only for key management, the keyEncipherment bit would
	extension should be marked critical.		be asserted. When used, this extension should be marked critical.
	The eight bits defined for this extension identify seven mechanisms and		The eight bits defined for this extension identify seven mechanisms
	one service, namely:		and one service, namely:
	- digitalSignature
	- nonRepudiation
	- keyEncipherment
	- dataEncipherment
	- keyAgreement
	- keyCertSign
	- cRLSign
	- encipherOnly
	- decipherOnly
	According to [PKIX-1], bits in the KeyUsage type are used as follows:		- digitalSignature - nonRepudiation - keyEncipherment -
			dataEncipherment - keyAgreement - keyCertSign - cRLSign -
			encipherOnly - decipherOnly
	The digitalSignature bit is asserted when the subject public key is used		According to [RFC 2459], bits in the KeyUsage type are used as
	to verify digital signatures that have purposes other than		follows:
	non-repudiation, certificate signature, and CRL signature. For example,
	the digitalSignature bit is asserted when the subject public key is used
	to provide authentication via the signing of ephemeral data.
	The nonRepudiation bit is asserted when the subject public key is used		The digitalSignature bit is asserted when the subject public key
	to verify digital signatures used to provide a non-repudiation service		is used to verify digital signatures that have purposes other than
	which protects against the signing entity falsely denying some action,		non-repudiation, certificate signature, and CRL signature. For
	excluding certificate or CRL signing.		example, the digitalSignature bit is asserted when the subject
			public key is used to provide authentication via the signing of
			ephemeral data.
	The keyEncipherment bit is asserted when the subject public key is used		The nonRepudiation bit is asserted when the subject public key is
	for key transport. For example, when an RSA key is to be used for key		used to verify digital signatures used to provide a non-
	management, this bit must asserted.		repudiation service which protects against the signing entity
			falsely denying some action, excluding certificate or CRL signing.
	The dataEncipherment bit is asserted when the subject public key is		The keyEncipherment bit is asserted when the subject public key is
	used for enciphering user data, other than cryptographic keys.		used for key transport. For example, when an RSA key is to be
			used for key management, this bit must asserted.
	The keyAgreement bit is asserted when the subject public key is used for		The dataEncipherment bit is asserted when the subject public key
	key agreement. For example, when a Diffie-Hellman key is to be used for		is used for enciphering user data, other than cryptographic keys.
	key management, this bit must asserted.
	The keyCertSign bit is asserted when the subject public key is used for		The keyAgreement bit is asserted when the subject public key is
	verifying a signature on certificates. This bit may only be asserted in		used for key agreement. For example, when a Diffie-Hellman key is
	CA certificates.		to be used for key management, this bit must asserted.
	The cRLSign bit is asserted when the subject public key is used for		The keyCertSign bit is asserted when the subject public key is
	verifying a signature on revocation information (e.g., a CRL).		used for verifying a signature on certificates. This bit may only
			be asserted in CA certificates.
	The meaning of the encipherOnly bit is undefined in the absence of the		The cRLSign bit is asserted when the subject public key is used
	keyAgreement bit. When the encipherOnly bit is asserted and the		for verifying a signature on revocation information (e.g., a CRL).
	keyAgreement bit is also set, the subject public key may be used only
	for enciphering data while performing key agreement.
	The meaning of the decipherOnly bit is undefined in the absence of the		The meaning of the encipherOnly bit is undefined in the absence of
	keyAgreement bit. When the decipherOnly bit is asserted and the		the keyAgreement bit. When the encipherOnly bit is asserted and
	keyAgreement bit is also set, the subject public key may be used only		the keyAgreement bit is also set, the subject public key may be
	for deciphering data while performing key agreement.		used only for enciphering data while performing key agreement.
	PKIX does not restrict the combinations of bits that may be set in an		The meaning of the decipherOnly bit is undefined in the absence of
	instantiation of the keyUsage extension.		the keyAgreement bit. When the decipherOnly bit is asserted and
			the keyAgreement bit is also set, the subject public key may be
			used only for deciphering data while performing key agreement.
	The discussion on the PKIX mailing list has centered on the		PKIX does not restrict the combinations of bits that may be set in an
	digitalSignature bit and the nonRepudiation bit. The question has come		instantiation of the keyUsage extension.
	down to something like: When support for the service of non-repudiation
	is desired, should both the digitalSignature and nonRepudiation bits be
	set, or just the nonRepudiation bit?
	(It is noted that provision of the service of non-repudiation requires		The discussion on the PKIX mailing list has centered on the
	more than a single bit set in a certificate. It requires an entire		digitalSignature bit and the nonRepudiation bit. The question has
	infrastructure of components to preserve for some period of time the		come down to something like: When support for the service of non-
	keys, certificates, revocation status, signed material, etc., as well as		repudiation is desired, should both the digitalSignature and
	a trusted source of time. However, the nonRepudiation key usage bit is		nonRepudiation bits be set, or just the nonRepudiation bit?
	provided as an indicator that such keys should not be used as a
	component of a system providing a non-repudiation service.)
	According to [SIMONETTI], the intent is that the digitalSignature bit		(It is noted that provision of the service of non-repudiation
	should be set when what is desired is the ability to sign ephemeral		requires more than a single bit set in a certificate. It requires an
	transactions; e.g., for a single session authentication. These		entire infrastructure of components to preserve for some period of
	transactions are "ephemeral" in the sense that they are important only		time the keys, certificates, revocation status, signed material,
	while they are in existence; after the session is terminated, there is		etc., as well as a trusted source of time. However, the
	no long-term record of the digital signature and its properties kept.		nonRepudiation key usage bit is provided as an indicator that such
	When something is intended to be kept for some period of time, the		keys should not be used as a component of a system providing a non-
	nonRepudiation bit should be set. This generally implies that an		repudiation service.)
	application will digitally sign something; thus, some implementors turn
	on the digitalSignature bit as well. Other implementors, however, keep
	the two bits mutually exclusive, to prevent a single key from being used
	for both ephemeral and long-term signing.
	While [PKIX-1] is silent on this specific issue, the working group's		According to [SIMONETTI], the intent is that the digitalSignature bit
	general conclusion is that a certificate may have either or both bits		should be set when what is desired is the ability to sign ephemeral
	set. If only the nonRepudiation bit is set, the key should not be used		transactions; e.g., for a single session authentication. These
	for ephemeral transactions. If only the digitalSignature bit is set,		transactions are "ephemeral" in the sense that they are important
	the key should not be used for long-term signing. If both bits are set,		only while they are in existence; after the session is terminated,
	the key may be used for either purpose.		there is no long-term record of the digital signature and its
			properties kept. When something is intended to be kept for some
			period of time, the nonRepudiation bit should be set. This generally
			implies that an application will digitally sign something; thus, some
			implementors turn on the digitalSignature bit as well. Other
			implementors, however, keep the two bits mutually exclusive, to
			prevent a single key from being used for both ephemeral and long-term
			signing.
	To actually enforce this requires that an application understands		While [RFC 2459] is silent on this specific issue, the working
	whether it is signing ephemeral transactions or for the long-term. The		group's general conclusion is that a certificate may have either or
	application developers will have to understand the difference, and set		both bits set. If only the nonRepudiation bit is set, the key should
	up their checks on the key usage bits field accordingly. For example,		not be used for ephemeral transactions. If only the digitalSignature
	TLS implementors should check only the digitalSignature bit, and ignore		bit is set, the key should not be used for long-term signing. If
	the nonRepudiation bit. S/MIME implementors, though, will have a		both bits are set, the key may be used for either purpose.
	difficult choice to make, since their application could be used for
	either purpose, and they will generally accept signing using keys
	associated with certificates having either or both bits being turned on.
	Certification Authorities should know what applications they are
	providing certificates for, and provide certificates according to the
	requirements of those applications. If CA's are tied into
	non-repudiation systems, they may treat certificates differently when
	the nonRepudiation bit is turned on (e.g., store information associated
	with the certificate - like the user's identification provided during
	certificate registration, or certificate generation date/time stamps -
	for longer periods of time, in more secure environments).
	The bottom line is that this is an area where PKI implementors are		To actually enforce this requires that an application understands
	somewhat limited in what they can do. The onus is on developers of		whether it is signing ephemeral transactions or for the long-term.
	certificate-using systems to understand their requirements, and request		The application developers will have to understand the difference,
	certificates with the appropriate bits set.		and set up their checks on the key usage bits field accordingly. For
			example, TLS implementors should check only the digitalSignature bit,
			and ignore the nonRepudiation bit. S/MIME implementors, though, will
			have a difficult choice to make, since their application could be
			used for either purpose, and they will generally accept signing using
			keys associated with certificates having either or both bits being
			turned on. Certification Authorities should know what applications
			they are providing certificates for, and provide certificates
			according to the requirements of those applications. If CA's are
			tied into non-repudiation systems, they may treat certificates
			differently when the nonRepudiation bit is turned on (e.g., store
			information associated with the certificate - like the user's
			identification provided during certificate registration, or
			certificate generation date/time stamps - for longer periods of time,
			in more secure environments).
			The bottom line is that this is an area where PKI implementors are
			somewhat limited in what they can do. The onus is on developers of
			certificate-using systems to understand their requirements and
			request certificates with the appropriate bits set.
	5.4 Trust Models		5.4 Trust Models
	(This section will describe the various trust models that PKIX can		(This section will describe the various trust models that PKIX can
	support. It is important to note that PKIX is bound to neither a pure		support. It is important to note that PKIX is bound to neither a
	hierarchical model a la PEM, nor a web of trust model a la PGP. PKIX		pure hierarchical model a la PEM, nor a web of trust model a la PGP.
	can support either of those models, or any flavor in between. The		PKIX can support either of those models, or any flavor in between.
	implications of different trust models should be described:		The implications of different trust models should be described:
	- efficiency of revocation
	- certification path building		- efficiency of revocation - certification path building - etc.)
	- etc.)
	6 Acknowledgements		6 Acknowledgements
	A lot of the information in this document was taken from the PKIX source		A lot of the information in this document was taken from the PKIX
	documents; the authors of those deserve the credit for their own words.		source documents; the authors of those deserve the credit for their
	Other good material was taken from mail posted to the PKIX working group		own words. Other good material was taken from mail posted to the
	mail list (ietf-pkix@imc.org). Among those with good things to say were		PKIX working group mail list (ietf-pkix@imc.org). Among those with
	(in alphabetical order, with apologies to anybody I've missed): Sharon		good things to say were (in alphabetical order, with apologies to
	Boeyen, Santosh Chokhani, Warwick Ford, Russ Housley, Steve Kent,		anybody we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford,
	Ambarish Malpani, Michael Myers, Tim Polk, Stefan Santesson,		Russ Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers,
	Dave Simonetti,		Tim Polk, Stefan Santesson, Dave Simonetti, and.
	7 References		7 References
	[CACHE] "Internet Public Key Infrastructure: Caching the Online		[CACHE] "Internet Public Key Infrastructure: Caching the Online
	Certificate Status Protocol," <draft-ieft-pkix-ocsp-caching-00.txt>		Certificate Status Protocol," <draft-ieft-pkix-ocsp-caching-00.txt>,
			April 1998
	[CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate		[CMC] Myers, M., Liu, X., Fox, B., and Weinstein, J., "Certificate
	Management Messages over CMS," <draft-ieft-pkix-cmc-00.txt>, March 1998		Management Messages over CMS," <draft-ieft-pkix-cmc-02.txt>, November
			1998
	[CMMF] Adams, C., and Myers, M., "Internet X.509 Public Key		[CMMF] Adams, C., and Myers, M., "Internet X.509 Public Key
	Infrastructure Certificate Management Message Formats,"		Infrastructure Certificate Management Message Formats," <draft-ietf-
	<draft-ietf-pkixx-cmmf-02.txt>, July 1998		pkixx-cmmf-02.txt>, July 1998
	[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," <draft-ieft-pkix-crmf-01.txt>,		Certificate Request Message Format," RFC 2511, March 1999
	May 1998
	[CMP] Adams, C., and Farrell, S., "Internet X.509 Public Key		[CRS] Myers, M., Liu X., Fox B., Prafullchandra H., Weinstein J., "
	Infrastructure Certificate Management Protocols,"		Certificate Request Syntax," <draft-ietf-smime-crs-00.txt>, November
	<draft-ietf-pkix-ipki3cmp-08.txt>, May 1998		1997
	[ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509 Public		[CMP] Adams, C., and Farrell, S., "Internet X.509 Public Key
	Key Infrastructure: Representation of Elliptic Curve Digital Signature		Infrastructure Certificate Management Protocols," RFC 2510, March
	Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key		1999
	Infrastructure Certificates," <draft-ietf-pkix-ipki-ecdsa-01.txt>,
	November 1997
	[FTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key		[CMS] R. Housley, "Cryptographic Message Syntax," <draft-ietf-smime-
	Infrastructure Operational Protocols: FTP and HTTP,"		cms-10.txt>, December 1998
	<draft-ietf-pkix-opp-ftp-http-04.txt>, July 1998
	[KEA] Housley, R., and Polk, W., "Internet X.509 Public Key		[DCS] Adams, C., and Zuccherato, R., "Internet X.509 Public Key
	Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in		Infrastructure Data Certification Server Protocols", <draft-ietf-
	Internet X.509 Public Key Infrastructure Certificates,"		pkix-dcs-00.txt>, 23 September 1998.
	<draft-ietf-pkix-ipki-kea-02.txt>, 5 August 1998.
	[LDAP] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 Public		[ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509
	Key Infrastructure Operational Protocols - LDAPv2,"		Public Key Infrastructure: Representation of Elliptic Curve Digital
	<draft-ietf-pkix-ipki2opp-07.txt>, March 1998.		Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509
			Public Key Infrastructure Certificates," <draft-ietf-pkix-ipki-
			ecdsa-01.txt>, November 1997
	[MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC Minimum		[FTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key
	Interoperability Specification for PKI Components, Version 1", September		Infrastructure Operational Protocols: FTP and HTTP," <draft-ietf-
	3, 1997		pkix-opp-ftp-http-04.txt>, July 1998
	[OCDP] Hallam-Baker, P., and Ford, W., "Internet X.509 Public Key		[KEA] Housley, R., and Polk, W., "Internet X.509 Public Key
	Infrastructure Open CRL Distribution Process (OpenCDP),"		Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in
	<draft-ietf-pkix-ocdp-00.txt>, April 1998		Internet X.509 Public Key Infrastructure Certificates," RFC ####,
			date TBD.
	[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, C.,		[LDAP] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 Public
	"X.509 Internet Public Key Infrastructure Online Certificate Status		Key Infrastructure Operational Protocols - LDAPv2," <draft-ietf-pkix-
	Protocol - OCSP," <draft-ietf-pkix-ocsp-05.txt>, June 1998.		ipki2opp-08.txt>, September 1998.
	[PKIX-1] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet X.509		[MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC
	Public Key Infrastructure Certificate and CRL Profile,"		Minimum Interoperability Specification for PKI Components, Version
	<draft-ietf-pkix-ipki-part1-09.txt>, July 28, 1998.		1", September 3, 1997
	[PKIX-4] Chokhani, S., and Ford, W., "Internet X.509 Public Key		[OCDP] Hallam-Baker, P., and Ford, W., "Internet X.509 Public Key
	Infrastructure Certificate Policy and Certification Practices		Infrastructure Enhanced CRL Distribution Options (OpenCDP)," <draft-
	Framework," <draft-ietf-pkix-ipki-part4-03.txt>; 25 April 1998.		ietf-pkix-ocdp-01.txt>, August 7, 1998
	[RFC 791] Postel, J., "Internet Protocol", September 1981.		[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams,
			C., "X.509 Internet Public Key Infrastructure Online Certificate
			Status Protocol - OCSP," <draft-ietf-pkix-ocsp-07.txt>, September
			1998.
	[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text		[PKCS10] "Certification Request Syntax Standard", Public Key
	Messages", August 1982.		Cryptography Standard #10, RSA Laboratories.
	[RFC 1034] Mockapetris, P.V., "Domain names - concepts and facilities",		[PKIX-4] Chokhani, S., and Ford, W., "Internet X.509 Public Key
	November 1987.		Infrastructure Certificate Policy and Certification Practices
			Framework," RFC 2527, March 1999.
	[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic		[QC] Santesson, S., Polk, W., and Gloeckner, P., "Internet X.509
	Mail: Part II: Certificate-Based Key Management," February 1993.		Public Key Infrastructure Qualified Certificates", <draft-ietf-pkix-
			qc-00.txt>, 3 February 1999.
	[RFC 1777] Yeong, Y., Howes, T., and Kille, S., "Lightweight Directory		[RFC 791] Postel, J., "Internet Protocol", September 1981.
	Access Protocol", March 1995
	[RFC 1883] Deering, S., and Hinden, R., "Internet Protocol, Version 6		[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text
	[IPv6] Specification", December 1995.		Messages", August 1982.
	[SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 Public		[RFC 1034] Mockapetris, P.V., "Domain names - concepts and
	Key Infrastructure LDAPv2 Schema,"		facilities", November 1987.
	<draft-ietf-pkix-ldapv2-schema-00.txt>, March 1998
	[SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to		[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
	ietf-pkix@imc.org mailing list, 12 August 1998		Mail: Part II: Certificate-Based Key Management," February 1993.
	[WEB] Reddy, S., "WEB based Certificate Access Protocol-- WebCAP/1.0,"		[RFC 1777] Yeong, Y., Howes, T., and Kille, S., "Lightweight
	<draft-ietf-pkix-webcap-00.txt>, April 19, 1998		Directory Access Protocol", March 1995
	[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology -		[RFC 1883] Deering, S., and Hinden, R., "Internet Protocol, Version 6
	Open Systems Interconnection - The Directory: Authentication Framework,		[IPv6] Specification", December 1995.
	June 1997.
	[X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial		[RFC 2459] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet
	Services Industry: Agreement of Symmetric Algorithm Keys Using		X.509 Public Key Infrastructure Certificate and CRL Profile," January
	Diffie-Hellman (Working Draft), December 1997.		1999.
	[X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial		[SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509
	Services Industry: Extensions To Public Key Certificates And Certificate		Public Key Infrastructure LDAPv2 Schema," <draft-ietf-pkix-
	Revocation Lists, 8 December, 1995.		ldapv2-schema-02.txt>, September 1998
	[X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial		[SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf-
	Services Industry: Certificate Management (Working Draft), 21 June, 1996.		pkix@imc.org mailing list, 12 August 1998
			[TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet
			X.509 Public Key Infrastructure Time Stamp Protocols", <draft-ietf-
			pkix-time-stamp-00.txt>, 23 September 1998.
			[WEB] Reddy, S., "WEB based Certificate Access Protocol--
			WebCAP/1.0," <draft-ietf-pkix-webcap-00.txt>, April 19, 1998
			[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology
			- Open Systems Interconnection - The Directory: Authentication
			Framework, June 1997.
			[X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial
			Services Industry: Agreement of Symmetric Algorithm Keys Using
			Diffie-Hellman (Working Draft), December 1997.
			[X9.55] ANSI X9.55-1995, Public Key Cryptography For The Financial
			Services Industry: Extensions To Public Key Certificates And
			Certificate Revocation Lists, 8 December, 1995.
			[X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial
			Services Industry: Certificate Management (Working Draft), 21 June,
			1996.
	8 Security Considerations		8 Security Considerations
	TBSL		TBSL
	9 Editor's Address		9 Editor's Address
	Alfred Arsenault		Alfred Arsenault
	U. S. Department of Defense		U. S. Department of Defense
	9800 Savage Road Suite 6734		9800 Savage Road Suite
	Fort George G. Meade, MD 20755-6734		6734 Fort George G. Meade, MD 20755-6734
	(410) 684-7114		(410) 684-7114
	awarsen@missi.ncsc.mil		awarsen@missi.ncsc.mil
	Sean Turner		Sean Turner
	IECA, Inc.		IECA, Inc.
	9010 Edgepark Road		9010 Edgepark Road Vienna, VA 22182
	Vienna, VA 22182		(703) 358-9113
	(703) 358-9113		turners@ieca.com
	turners@ieca.com
	10 Disclaimer		10 Disclaimer
	This work constitutes the opinion of the editor only, and may not		This work constitutes the opinion of the editors only, and may not
	reflect the opinions or policies of his employer.		reflect the opinions or policies of their employers.
End of changes. 226 change blocks.
	1088 lines changed or deleted		1469 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/