< draft-ietf-pkix-roadmap-01.txt		draft-ietf-pkix-roadmap-02.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 22 March 1999		Expires in six months from June 23, 1999
	Internet X.509 Public Key Infrastructure		Internet X.509 Public Key Infrastructure
	PKIX Roadmap		PKIX Roadmap
	<draft-ietf-pkix-roadmap-01.txt>		<draft-ietf-pkix-roadmap-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance with
	with all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of 6 months		Internet-Drafts are draft documents valid for a maximum of 6 months
	and may be updated, replaced, or may become obsolete by other		and may be updated, replaced, or may become obsolete by other
	documents at any time. It is inappropriate to use Internet-Drafts as		documents at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as work in progress. To		reference material or to cite them other than as work in progress. To
	view the entire list of current Internet-Drafts, please check		view the entire list of current Internet-Drafts, please check the
	the"1id-abstracts.txt" listing contained in the Internet-Drafts		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern		Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
	Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific		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).		Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
	Copyright (C) The Internet Society (date). All Rights Reserved.		Copyright (C) The Internet Society (date). All Rights Reserved.
			The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document provides an overview or 'roadmap' of the work done by		This document provides an overview or 'roadmap' of the work done by
	the IETF PKIX working group. It describes some of the terminology		the IETF PKIX working group. It describes some of the terminology
	used in the working group's documents, and the theory behind an		used in the working group's documents, and the theory behind an
	X.509-based PKI. It identifies each document developed by the PKIX		X.509-based PKI. It identifies each document developed by the PKIX
	working group, and describes the relationships among the various		working group, and describes the relationships among the various
	documents. It also provides advice to would-be PKIX implementors		documents. It also provides advice to would-be PKIX implementors
	about some of the issues discussed at length during PKIX development,		about some of the issues discussed at length during PKIX development,
	in hopes of making it easier to build implementations that will		in hopes of making it easier to build implementations that will
	actually interoperate.		actually interoperate.
	TABLE OF CONTENTS
	1 Introduction.................................................2
	1.1 This Document................................................2
	1.2 Changes Since the Last Version...............................3
	2 Terminology..................................................3
	3 PKIX Theory..................................................4
	3.1 Certificate-using Systems and PKIs...........................4
	3.2 PKIX History.................................................5
	3.3 Overview of the PKIX Approach................................5
	3.4 X.509 certificates...........................................6
	3.5 Functions of a PKI...........................................7
	3.5.1 Registration.................................................7
	3.5.2 Initialization...............................................7
	3.5.3 Certification................................................7
	3.5.4 Key Pair Recovery............................................7
	3.5.5 Key Generation...............................................8
	3.5.6 Key Update...................................................8
	3.5.7 Cross-certification..........................................9
	3.5.8 Revocation...................................................9
	3.5.9 Certificate and Revocation Notice Distribution/Publication..10
	3.6 Parts of PKIX...............................................10
	3.6.1 Profile.....................................................11
	3.6.2 Operational Protocols.......................................11
	3.6.3 Management Protocols........................................11
	3.6.4 Policy Outline..............................................12
	3.6.5 Time-Stamp and Data Certification Services..................12
	4 PKIX Documents..............................................13
	4.1 Profile.....................................................13
	4.2 Operational Protocols.......................................14
	4.3 Management Protocols........................................16
	4.4 Policy Outline..............................................17
	4.5 Time-Stamp and Data Certification Services..................17
	5 Advice to Implementors......................................19
	5.1 Names.......................................................19
	5.1.1 Name Forms..................................................19
	5.1.2 Scope of Names..............................................21
	5.1.3 Certificate Path Construction...............................22
	5.1.4 Name Constraints............................................22
	5.1.5 Wildcards in Name Forms.....................................23
	5.1.6 Name Encoding...............................................23
	5.2 POP.........................................................23
	5.3 Key Usage Bits..............................................25
	5.4 Trust Models................................................27
	6 Acknowledgements............................................28
	7 References..................................................28
	8 Security Considerations.....................................30
	9 Editor's Address............................................30
	10 Disclaimer..................................................30
	1 Introduction		1 Introduction
	1.1 This Document		1.1 This Document
	This document is an informational Internet draft that provides a		This document is an informational Internet draft that provides a
	"roadmap" to the documents produced by the PKIX working group. It is		"roadmap" to the documents produced by the PKIX working group. It is
	intended to provide information; there are no requirements or		intended to provide information; there are no requirements or
	specifications in this document.		specifications in this document.
	Section 2 of this document defines key terms used in this document.		Section 2 of this document defines key terms used in this document.
	skipping to change at page 3, line 25 ¶		skipping to change at page 2, line 32 ¶
	and specifications say what they say. This should cut down on the		and specifications say what they say. This should cut down on the
	number of misinterpretations of the documents, and help developers		number of misinterpretations of the documents, and help developers
	build interoperable implementations. Section 6 contains a list of		build interoperable implementations. Section 6 contains a list of
	references. Section 7 discusses security considerations, and Section		references. Section 7 discusses security considerations, and Section
	8 provides contact information for the editors.		8 provides contact information for the editors.
	1.2 Changes Since the Last Version		1.2 Changes Since the Last Version
	The major changes in this document since version -00 include:		The major changes in this document since version -00 include:
	inclusion of a section on "PKIX History" the definition and usage of		- QC text was updated (section 3.6.1).
	"root CA" were changed to be consistent with CMP, in line with the
	discussion on the PKIX mailing list updates on the status of all		- Name constraints text was updated (section 5.1.4).
	major documents addition of descriptions of documents covering work
	items that are new to PKIX since September 1998 a number of sections		- Name encoding text was added (section 5.1.6).
	that had been left unspecified have now been completed (e.g., the
	Proof of Possession (POP) section; rules on name constraints for		- Added Attribute Certificate Profile for Authorizations and DH
	different name types) The old section 4.5, which attempted to		PoP Algorithms to Profile section (section 4.1).
	graphically depict document relationships, has been deleted because
	it didn't seem to add any value.		- Added descriptions for BERT and Extending trust in non-
			repudiation tokens in time to Time Stamp and DCS section (section
			4.5).
			- Replaced references to CMP with RFC 2510, CRMF with RFC 2511,
			PKIX-4 with RFC 2527, KEA with RFC 2528, LDAP with RFC 2559, FTP
			with RFC 2585, SCHEMA with RFC 2587.
			- Updates references to current drafts.
			- Added sections for D-H PoP, Attribute Certificate Profile for
			Authorizations, Basic Event Representation Token v1, Extending
			Trust in Non-repudiation tokens in time.
	2 Terminology		2 Terminology
	There are a number of terms used and misused throughout PKI-related		There are a number of terms used and misused throughout PKI-related
	literature. To limit confusion caused by some of those terms,		literature. To limit confusion caused by some of those terms,
	throughout this document, we will use the following terms in the		throughout this document, we will use the following terms in the
	following ways:		following ways:
	- Certification Authority (CA) - an authority trusted by one or more		- Certification Authority (CA) - an authority trusted by one or
	users to create and assign certificates. Optionally the		more users to create and assign certificates. Optionally the
	certification authority may create the user's keys. (It is important		certification authority may create the user's keys. (It is
	to note that the CA is responsible for the certificates during their		important to note that the CA is responsible for the certificates
	whole lifetime, not just for issuing them.)		during their whole lifetime, not just for issuing them.)
	- Certificate policy - a named set of rules that indicates the		- Certificate policy - a named set of rules that indicates the
	applicability of a certificate to a particular community and/or class		applicability of a certificate to a particular community and/or
	of application with common security requirements. For example, a		class of application with common security requirements. For
	particular certificate policy might indicate applicability of a type		example, a particular certificate policy might indicate
	of certificate to the authentication of electronic data interchange		applicability of a type of certificate to the authentication of
	transaction s for the trading of goods within a given price range.		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,		- Root CA - a CA that is directly trusted by an end entity; that
	securely acquiring the value of a root CA public key requires some		is, securely acquiring the value of a root CA public key requires
	out-of-band step(s). This term is not meant to imply that a root CA		some out-of-band step(s). This term is not meant to imply that a
	is necessarily at the top of any hierarchy, simply that the CA in		root CA is necessarily at the top of any hierarchy, simply that
	question is trusted directly.		the CA in question is trusted directly.
	- Top CA - a CA that is at the top of a PKI hierarchy.		- Top CA - a CA that is at the top of a PKI hierarchy.
	Note that this is often also called a "root CA", from since in		Note: this is often also called a "root CA", from since in data
	data structures terms and in graph theory, the node at the top		structures terms and in graph theory, the node at the top of a
	of a tree is the "root". However, to minimize confusion in this		tree is the "root". However, to minimize confusion in this
	document, we elect to call this node a "Top CA," and reserve		document, we elect to call this node a "Top CA," and reserve
	"root CA" for the CA directly trusted by the user. Readers new		"root CA" for the CA directly trusted by the user. Readers new
	to PKIX should be aware that these terms are not used		to PKIX should be aware that these terms are not used
	consistently throughout the PKIX documents, as [RFC2459] uses		consistently throughout the PKIX documents, as [RFC2459] uses
	"root CA" to refer to what this and other documents call a "top		"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		CA", and "most-trusted CA" to refer to what this and other
	documents call a "root CA".		documents call a "root CA".
	- Subordinate CA - A "subordinate CA" is one that is not a root CA		- Subordinate CA - A "subordinate CA" is one that is not a root CA
	for the end entity in question. Often, a subordinate CA will not		for the end entity in question. Often, a subordinate CA will not
	be a root CA for any entity but this is not mandatory		be a root CA for any entity but this is not mandatory
	- Registration Authority (RA) - an optional entity given		- Registration Authority (RA) - an optional entity given
	responsibility for performing some of the administrative tasks		responsibility for performing some of the administrative tasks
	necessary in the registration of subjects, such as: confirming		necessary in the registration of subjects, such as: confirming the
	the subject's identity; validating that the subject is entitled		subject's identity; validating that the subject is entitled to
	to have the attributes requested in a certificate; and verifying		have the attributes requested in a certificate; and verifying that
	that the subject has possession of the private key associated		the subject has possession of the private key associated with the
	with the public key requested for a certificate.		public key requested for a certificate.
	- End-entity - a subject of a certificate who is not a CA.		- End-entity - a subject of a certificate who is not a CA.
	- Relying party - a user or agent (e.g., a client or server) who		- Relying party - a user or agent (e.g., a client or server) who
	relies on the data in a certificate in making decisions.		relies on the data in a certificate in making decisions.
	- Subject - a subject is the entity (CA or end-entity) named in a		- Subject - a subject is the entity (CA or end-entity) named in a
	certificate. Subjects can be human users, computers (as		certificate. Subjects can be human users, computers (as
	represented by DNS names or IP addresses), or even software		represented by DNS names or IP addresses), or even software
	agents.		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		At the heart of recent efforts to improve Internet security are a
	group of security protocols such as S/MIME, TLS, and IPSec. All of		group of security protocols such as S/MIME, TLS, and IPSec. All of
	these protocols rely on public-key cryptography to provide services		these protocols rely on public-key cryptography to provide services
	such as confidentiality, data integrity, data origin authentication,		such as confidentiality, data integrity, data origin authentication,
	and 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
	skipping to change at page 5, line 37 ¶		skipping to change at page 4, line 48 ¶
	signed contents. Because a certificate's signature and timeliness		signed contents. Because a certificate's signature and timeliness
	can be independently checked by a certificate-using client,		can be independently checked by a certificate-using client,
	certificates can be distributed via untrusted communications and		certificates can be distributed via untrusted communications and
	server systems, and can be cached in unsecured storage in		server systems, and can be cached in unsecured storage in
	certificate-using systems.		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:		process works as follows:
	(Note: there is no specific order in which the checks listed		Note: there is no specific order in which the checks listed below
	below must be made; implementers are free to implement them in the		must be made; implementers are free to implement them in the most
	most efficient way for their systems)		efficient way for their systems.
	- the recipient of signed data verifies that the claimed identity of		- the recipient of signed data verifies that the claimed identity
	the user is in accordance wit the identity contained in the		of the user is in accordance wit the identity contained in the
	certificate;		certificate;
	- the recipient validates that no certificate in the path has been		- the recipient validates that no certificate in the path has been
	revoked (e.g., by retrieving a suitably-current Certificate		revoked (e.g., by retrieving a suitably-current Certificate
	Revocation List (CRL) or querying an on-line certificate status		Revocation List (CRL) or querying an on-line certificate status
	responder), and that all certificates were within their validity		responder), and that all certificates were within their validity
	periods at the time the data were signed;		periods at the time the data were signed;
	- the recipient verifies that the data are not claimed to have any		- the recipient verifies that the data are not claimed to have any
	attributes for which the certificate indicates that the signer is		attributes for which the certificate indicates that the signer is
	not authorized;		not authorized;
	- the recipient verifies that the data have not been altered since		- the recipient verifies that the data have not been altered since
	signing, by using the public key in the certificate.		signing, by using the public key in the certificate.
	If all of these checks pass, the recipient can accept that the data		If all of these checks pass, the recipient can accept that the data
	were signed by the purported signer. The process for keys used for		were signed by the purported signer. The process for keys used for
	encryption is similar.		encryption is similar.
	Note: it is of course possible that the data were signed by		Note: it is of course possible that the data were signed by
	someone very different from the signer, if for example the		someone very different from the signer, if for example the
	purported signer's private key was compromised. Security depends		purported signer's private key was compromised. Security depends
	on all parts of the certificate-using SYSTEM, including but not		on all parts of the certificate-using SYSTEM, including but not
	limited to: physical security of the place the computer resides;		limited to: physical security of the place the computer resides;
	personnel security (i.e., the trustworthiness of the people who		personnel security (i.e., the trustworthiness of the people who
	actually develop, install, run, and maintain the system); the		actually develop, install, run, and maintain the system); the
	security provided by the operating system on which the private key		security provided by the operating system on which the private key
	is used; and the security provided the CA. A failure in any one		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		of these areas can cause the entire system security to fail. PKIX
	is limited in scope, however, and only directly addresses issues		is limited in scope, however, and only directly addresses issues
	related to the operation of the PKI subsystem. For guidance in		related to the operation of the PKI subsystem. For guidance in
	many of the other areas, see [PKIX-4].		many of the other areas, see [RFC 2527].
	A collection of certificates, with their issuing CA's, subjects,		A collection of certificates, with their issuing CA's, subjects,
	relying parties, RA's, and repositories, is referred to as a Public		relying parties, RA's, and repositories, is referred to as a Public
	Key Infrastructure, or PKI.		Key Infrastructure, or PKI.
	3.2 PKIX History		3.2 PKIX History
	[This still needs more work.]		[This still needs more work.]
	In the beginning there was ITU-T Recommendation X.509. It defines a		In the beginning there was ITU-T Recommendation X.509. It defines a
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 15 ¶
	nor for certain data values. PKIX was formed in October 1995 to		nor for certain data values. PKIX was formed in October 1995 to
	deliver a profile for the Internet PKI of X.509 version 3		deliver a profile for the Internet PKI of X.509 version 3
	certificates and version 2 CRLs. The Internet PKI profile [RFC 2459]		certificates and version 2 CRLs. The Internet PKI profile [RFC 2459]
	went through eleven draft versions before becoming an RFC. Other		went through eleven draft versions before becoming an RFC. Other
	profiles have been developed in PKIX for particular algorithms to		profiles have been developed in PKIX for particular algorithms to
	make use of [RFC 2459]. There has been no sense of conflict between		make use of [RFC 2459]. There has been no sense of conflict between
	the groups that developed these profiles as they are seen as		the groups that developed these profiles as they are seen as
	complimentary.		complimentary.
	The development of the management protocols has not been so		The development of the management protocols has not been so
	straightforward. [CMP] was developed to define a message protocol		straightforward. [RFC 2510] was developed to define a message
	that is used between entities in a PKI. The demand for an enrollment		protocol that is used between entities in a PKI. The demand for an
	protocol and the desire to use PKCS-10 message format as the		enrollment protocol and the desire to use PKCS-10 message format as
	certificate request syntax lead to the development of two different		the certificate request syntax lead to the development of two
	documents in two different groups. The Certificate Request Syntax		different documents in two different groups. The Certificate Request
	[CRS] draft was developed in the SMIME WG which used PKCS10 [PKCS10]		Syntax [CRS] draft was developed in the SMIME WG which used PKCS10
	as the certification request message format. Certificate Request		[PKCS10] as the certification request message format. Certificate
	Message Format [CRMF] draft was also developed but in the PKIX WG.		Request Message Format [RFC 2511] draft was also developed but in the
	It was to define a simple enrollment protocol that would subsume both		PKIX WG. It was to define a simple enrollment protocol that would
	the [CMP] and [CRS] enrollment protocols, but it did not use PKCS10		subsume both the [RFC 2510] and [CRS] enrollment protocols, but it
	as the certificate request message format. Then, [CMMF] was		did not use PKCS10 as the certificate request message format. Then,
	developed to define an extended set of management messages that flow		[CMMF] was developed to define an extended set of management messages
	between the components of the Internet PKI. CMMF over CMS [CMC] was		that flow between the components of the Internet PKI. CMMF over CMS
	developed to allow the use of an existing protocol (S/MIME) as a PKI		[CMC] was developed to allow the use of an existing protocol (S/MIME)
	management protocol, without requiring the development of an entirely		as a PKI management protocol, without requiring the development of an
	new protocol such as CMP [CMP]. It also included [PKCS10] as the		entirely new protocol such as CMP [RFC 2510]. It also included
	certificate request syntax, which caused work on [CRS] to stop.		[PKCS10] as the certificate request syntax, which caused work on
	Information from [CMMF] has been moved into [CMP] and [CMC] so [CMMF]		[CRS] to stop. Information from [CMMF] has been moved into [RFC
	is being discontinued.		2510] and [CMC] so [CMMF] is being discontinued.
	Development of the operational protocols has been slightly more		Development of the operational protocols has been slightly more
	straightforward. Two documents for LDAPv2 have been developed one		straightforward. Two documents for LDAPv2 have been developed one
	for defining LDAPv2 as an access protocol to repositories [LDAP] and		for defining LDAPv2 as an access protocol to repositories [RFC 2559]
	one for storing PKI information in an LDAP directory [SCHEMA]. Using		and one for storing PKI information in an LDAP directory [RFC 2587].
	FTP and HTTP to retrieve certificates and CRL from PKI repositories		Using FTP and HTTP to retrieve certificates and CRL from PKI
	was documented without a fight in [FTP]. Likewise, methods, headers,		repositories was documented without a fight in [RFC 2585]. Likewise,
	and content-types ancillary to HTTP/1.1 to publish and retrieve X.509		methods, headers, and content-types ancillary to HTTP/1.1 to publish
	certificates and CRLs was documented in [WEB] without much argument.		and retrieve X.509 certificates and CRLs was documented in [WEB]
			without much argument.
	[Need to add text about OpenCDP vs DistributionPoints, Why DCP was		[Need to add text about OpenCDP vs DistributionPoints, Why DCP was
	started, information on TSP, and OCSP, and caching OCSP.]		started, information on TSP, and OCSP, and caching OCSP.]
	3.3 Overview of the PKIX Approach		3.3 Overview of the PKIX Approach
	PKIX is an effort to develop specifications for a Public Key		PKIX is an effort to develop specifications for a Public Key
	Infrastructure for the Internet using X.509 certificates. The PKIX		Infrastructure for the Internet using X.509 certificates. The PKIX
	working group was initially chartered in 1995. A Public Key		working group was initially chartered in 1995. A Public Key
	Infrastructure, or PKI, is defined as:		Infrastructure, or PKI, is defined as:
	The set of hardware, software, people, policies and procedures needed		The set of hardware, software, people, policies and procedures needed
	to create, manage, store, distribute, and revoke certificates based		to create, manage, store, distribute, and revoke certificates based
	on public-key cryptography.		on public-key cryptography.
	A PKI consists of five types of components [MISPC]:		A PKI consists of five types of components [MISPC]:
	- Certification Authorities (CAs) that issue and revoke certificates;		- Certification Authorities (CAs) that issue and revoke
	- Organizational Registration Authorities (ORAs) that vouch for the		certificates;
	binding between public keys and certificate holder identities and
	other attributes; - Certificate holders that are issued certificates		- Organizational Registration Authorities (ORAs) that vouch for
	and can sign digital documents; - Clients that validate digital		the binding between public keys and certificate holder identities
	signatures and their certification paths from a known public key of a		and other attributes;
	trusted CA; - Repositories that store and make available certificates
	and Certificate Revocation Lists (CRLs).		- 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		Figure 1 is a simplified view of the architectural model assumed by
	the PKIX Working Group.		the PKIX Working Group.
	+---+		+---+
	| C | +------------+		| C | +------------+
	| e | <-------------------->| End entity |		| e | <-------------------->| End entity |
	| r | Operational +------------+		| r | Operational +------------+
	| t | transactions ^		| t | transactions ^
	| | and management | Management		| | and management | Management
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 28 ¶
	certificate-using applications, should allow for appropriate keys to		certificate-using applications, should allow for appropriate keys to
	work before and after the transition. There are a number of ways 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		do this; see [insert appropriate reference here] for an example of
	one. In the case of a key compromise, the transition will not be		one. In the case of a key compromise, the transition will not be
	"graceful" in that there will be an unplanned switch of certificates		"graceful" in that there will be an unplanned switch of certificates
	and keys; users will not have known in advance what was about to		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		happen. Still, the PKI must support the ability to declare that the
	previous certificate is now invalid and shall not be used, and to		previous certificate is now invalid and shall not be used, and to
	announce the validity and availability of the new certificate.		announce the validity and availability of the new certificate.
	Note that compromise of a private key associated with a rootCA is		Note: compromise of a private key associated with a rootCA is
	catastrophic for users relying on that rootCA. If a rootCA's		catastrophic for users relying on that rootCA. If a rootCA's
	private key is compromised, that CA must be taken down and brought		private key is compromised, that CA must be taken down and brought
	up again with a new key. Until such time as the rootCA is brought		up again with a new key. Until such time as the rootCA is brought
	back up, though, users relying on that rootCA are cut off from the		back up, though, users relying on that rootCA are cut off from the
	rest of the system, as there is no way to develop a valid		rest of the system, as there is no way to develop a valid
	certification path back to a trusted node.		certification path back to a trusted node.
	Further, users will likely have to be notified by out-of-band		Further, users will likely have to be notified by out-of-band
	mechanisms about the change in CA keys. If the old key is		mechanisms about the change in CA keys. If the old key is
	compromised, any "update" message telling subordinates to switch to a		compromised, any "update" message telling subordinates to switch to a
	skipping to change at page 14, line 51 ¶		skipping to change at page 14, line 51 ¶
	[RFC 2459] also provides a profile for Version 2 CRLs for use in the		[RFC 2459] also provides a profile for Version 2 CRLs for use in the
	Internet PKI. CRLs, like certificates, have a number of optional		Internet PKI. CRLs, like certificates, have a number of optional
	extensions. In order to promote interoperability, it is necessary to		extensions. In order to promote interoperability, it is necessary to
	constrain the choices an implementor supports.		constrain the choices an implementor supports.
	In addition to profiling the certificate and CRL formats, it is		In addition to profiling the certificate and CRL formats, it is
	necessary to specify particular Object Identifiers (OIDs) for certain		necessary to specify particular Object Identifiers (OIDs) for certain
	encryption algorithms, because there are a variety of OIDs registered		encryption algorithms, because there are a variety of OIDs registered
	for some algorithm suites. Thus, PKIX has produced two documents		for some algorithm suites. Thus, PKIX has produced two documents
	([ECDSA] and [KEA]) which provide guidance on the proper		([ECDSA] and [RFC 2528]) which provide guidance on the proper
	implementation of specific algorithms.		implementation of specific algorithms.
	Certain organizations, such as countries, have recently mandated		Certain countries are in a process of updating their legal frameworks
	certain restrictions on certificates (such as that the subject of a		in order to regulate and incorporate recognition of signatures in
	certificate must be a natural person, or that the country of		electronic form. Many of these frameworks introduce certain basic
	citizenship and/or country of residence of the subject must be		requirements on certificates, often termed Qualified Certificates,
	included in the certificate). A certificate which meets these		supporting these types of "legal" signatures. Partly as a result of
	restrictions is deemed a "qualified certificate." In December 1998,		this there is a need for a specific certificate profile providing
	PKIX adopted as a work item the development of a refinement of		standardized support for certain related issues such as a common
	[RFC2459] that further profiles PKIX certificates into qualified		structure for expressing unambiguous identities of certified subjects
	certificates. This work is reflected in [QC].		(unmistakable identity). 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		3.6.2 Operational Protocols
	Operational protocols are required to deliver certificates and CRLs		Operational protocols are required to deliver certificates and CRLs
	(or other certificate status information) to certificate using		(or other certificate status information) to certificate using
	systems. Provision is needed for a variety of different means of		systems. Provision is needed for a variety of different means of
	certificate and CRL delivery, including distribution procedures based		certificate and CRL delivery, including distribution procedures based
	on LDAP, HTTP, FTP, and X.500. Operational protocols supporting		on LDAP, HTTP, FTP, and X.500. Operational protocols supporting
	these functions are defined in [FTP], [OCSP], [LDAP], and [WEB].		these functions are defined in [RFC 2585], [OCSP], [RFC 2559], and
			[WEB].
	3.6.3 Management Protocols		3.6.3 Management Protocols
	Management protocols are required to support on-line interactions		Management protocols are required to support on-line interactions
	between PKI user and management entities. For example, a management		between PKI user and management entities. For example, a management
	protocol might be used between a CA and a client system with which a		protocol might be used between a CA and a client system with which a
	key pair is associated, or between two CAs which cross-certify each		key pair is associated, or between two CAs which cross-certify each
	other. A management protocol can be used to carry user or client		other. A management protocol can be used to carry user or client
	system registration information, or a request for revocation of a		system registration information, or a request for revocation of a
	certificate.		certificate.
	There are two parts to a "management protocol". The first is the		There are two parts to a "management protocol". The first is the
	format of the messages that will be sent, and the second is the		format of the messages that will be sent, and the second is the
	actual protocol that governs the transmission of those messages.		actual protocol that governs the transmission of those messages.
	Originally, the PKIX working group developed two documents ([CRMF]		Originally, the PKIX working group developed two documents ([RFC
	and [CMMF]) that together described the necessary set of message		2511] and [CMMF]) that together described the necessary set of
	formats, and two other documents ([CMP] and [CMC]) that described		message formats, and two other documents ([RFC 2510] and [CMC]) that
	protocols for exchanging those messages. However, the message		described protocols for exchanging those messages. However, the
	formats defined in [CMMF] were inserted into both [CMP] and [CMC],		message formats defined in [CMMF] were inserted into both [RFC 2510]
	and thus [CMMF] will be dropped as a PKIX document.		and [CMC], and thus [CMMF] will be dropped as a PKIX document.
	3.6.4 Policy Outline		3.6.4 Policy Outline
	As mentioned before, profiling certificates and specifying		As mentioned before, profiling certificates and specifying
	operational and management protocols only addresses a part of the		operational and management protocols only addresses a part of the
	problem of actually developing and implementing a secure PKI. What is		problem of actually developing and implementing a secure PKI. What is
	also needed is the development of a certificate policy and		also needed is the development of a certificate policy and
	certification practice statement, and then following those documents.		certification practice statement, and then following those documents.
	The CP and CPS should address physical and personnel security,		The CP and CPS should address physical and personnel security,
	subject identification requirements, revocation policy, and a number		subject identification requirements, revocation policy, and a number
	of other topics. [PKIX-4] provides a framework for certification		of other topics. [RFC 2527] provides a framework for certification
	practice statements.		practice statements.
	3.6.5 Time-Stamp and Data Certification Services		3.6.5 Time-Stamp and Data Certification Services
	In late 1998, the PKIX working group began two efforts that were not		In late 1998, the PKIX working group began two efforts that were not
	in the original working group charter, but were deemed to be		in the original working group charter, but were deemed to be
	appropriate because they described infrastructure services that could		appropriate because they described infrastructure services that could
	be used to provide desired security services. The first of these is		be used to provide desired security services. The first of these is
	time stamping, described in [TSP]. Time stamping is a service in		time stamping, described in [TSP]. Time stamping is a service in
	which a trusted third party - a Time Stamp Authority, or TSA - signs		which a trusted third party - a Time Stamp Authority, or TSA - signs
	skipping to change at page 16, line 29 ¶		skipping to change at page 16, line 34 ¶
	[TSP] also defines the role of a Temporal Data Authority, or TDA. A		[TSP] also defines the role of a Temporal Data Authority, or TDA. A
	TDA is a TTP that creates a temporal data token. This temporal data		TDA is a TTP that creates a temporal data token. This temporal data
	token associates a message with a particular event and provides		token associates a message with a particular event and provides
	supplementary evidence for the time included in the time stamp token.		supplementary evidence for the time included in the time stamp token.
	For example, a TDA could associate the message with the most recent		For example, a TDA could associate the message with the most recent
	closing value of the Dow Jones Average. The temporal data with which		closing value of the Dow Jones Average. The temporal data with which
	the message is associated should be unpredictable in order to prevent		the message is associated should be unpredictable in order to prevent
	forward dating of tokens.		forward dating of tokens.
			At the Minneapolis IETF meeting, it was disclosed that the materials
			covered in the Timestamp Internet draft may be covered by patent(s).
			Use of the material covered by the patent(s) in question has not be
			granted by the patentholder. Thus, anyone interested in implementing
			the PKIX Timestamp draft must be aware of this intellectual property
			issue.
	The second new effort is the definition of a Data Certification		The second new effort is the definition of a Data Certification
	Server, or DCS, protocol [DCS]. A DCS is a Trusted Third Party that		Server, or DCS, protocol [DCS]. A DCS is a Trusted Third Party that
	verifies the correctness of specific data submitted to it.		verifies the correctness of specific data submitted to it.
	This is different from the TSP service in that a TSA will not attempt		This is different from the TSP service in that a TSA will not attempt
	to parse and/or verify a message sent to it for certification;		to parse and/or verify a message sent to it for certification;
	instead, it will merely append a reliable indication of the current		instead, it will merely append a reliable indication of the current
	time, and sign the resulting string-of-bits. This offers an		time, and sign the resulting string-of-bits. This offers an
	indication that the given string-of-bits existed at a specified time;		indication that the given string-of-bits existed at a specified time;
	it does not offer any indication of the correctness or relevance of		it does not offer any indication of the correctness or relevance of
	skipping to change at page 17, line 43 ¶		skipping to change at page 18, line 6 ¶
	[RFC 2459] 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		The procedures are provided as examples only. Implementations are
	not required to use the procedures provided; they may implement		not required to use the procedures provided; they may implement
	whichever procedures are efficient for their situation. However,		whichever procedures are efficient for their situation. However,
	implementations are required to derive the same results as the		implementations are required to derive the same results as the
	example procedures.		example procedures.
	STATUS: Proposed Standard; approved 29 September 1998.		STATUS: Proposed Standard.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure:		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure:
	Representation of Elliptic Curve Digital Signature Algorithm (ECDSA)		Representation of Elliptic Curve Digital Signature Algorithm (ECDSA)
	Keys and Signatures in Internet X.509 Public Key Infrastructure		Keys and Signatures in Internet X.509 Public Key Infrastructure
	Certificates <draft-ietf-pkix-ipki-ecdsa-01.txt>		Certificates <draft-ietf-pkix-ipki-ecdsa-01.txt>
	DESCRIPTION: This document provides Object Identifiers (OIDs) and		DESCRIPTION: This document provides Object Identifiers (OIDs) and
	other guidance for IPKI users who use the Elliptic Curve Digital		other guidance for IPKI users who use the Elliptic Curve Digital
	Signature Algorithm (ECDSA). It profiles the format and semantics of		Signature Algorithm (ECDSA). It profiles the format and semantics of
	the subjectPublicKeyInfo field and the keyUsage extension in X.509 V3		the subjectPublicKeyInfo field and the keyUsage extension in X.509 V3
	certificates containing ECDSA keys. This document should be used by		certificates containing ECDSA keys. This document should be used by
	anyone wishing to support ECDSA; others who do not support ECDSA are		anyone wishing to support ECDSA; others who do not support ECDSA are
	not required to comply with it.		not required to comply with it.
	STATUS:		STATUS: WG Last Call.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure
	Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509		Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509
	Public Key Infrastructure Certificates (RFC ####)		Public Key Infrastructure Certificates (RFC 2528)
	DESCRIPTION: This document provides Object Identifiers (OIDs) and		DESCRIPTION: This document provides Object Identifiers (OIDs) and
	other guidance for IPKI users who use the Key Exchange Algorithm		other guidance for IPKI users who use the Key Exchange Algorithm
	(KEA). It profiles the format and semantics of the		(KEA). It profiles the format and semantics of the
	subjectPublicKeyInfo field and the keyUsage extension in X.509 V3		subjectPublicKeyInfo field and the keyUsage extension in X.509 V3
	certificates containing KEA keys. This document should be used by		certificates containing KEA keys. This document should be used by
	anyone wishing to support KEA; others who do not support ECDSA are		anyone wishing to support KEA; others who do not support ECDSA are
	not required to comply with it.		not required to comply with it.
	STATUS: Informational RFC; approved 22 January 1999.		STATUS: Informational RFC.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Enhanced CRL
	Distribution Options (OpenCDP) <draft-ietf-pkix-ocdp-01.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 [RFC 2459]. OCDP		Distribution Point (CDP) approach documented in [RFC 2459]. OCDP
	separates the CRL location function from the process of certificate		separates the CRL location function from the process of certificate
	and CRL validation, and thus claims some benefits over the CDP		and CRL validation, and thus claims some benefits over the CDP
	approach.		approach.
	STATUS:		STATUS: Under WG review.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Qualified
	Certificates <draft-ietf-pkix-qc-00.txt>		Certificates <draft-ietf-pkix-qc-00.txt>
	DESCRIPTION: This document profiles the format for and defines		DESCRIPTION: This document profiles the format for and defines
	requirements on information content in a specific type of		requirements on information content in a specific type of
	certificates called Qualified Certificates. A "Qualified Certificate"		certificates called Qualified Certificates. A "Qualified Certificate"
	is a certificate that is issued to a natural person (i.e., a living		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		human being); contains an unmistakable identity based on a real name
	or a pseudonym of the subject; exclusively indicates non-repudiation		or a pseudonym of the subject; exclusively indicates non-repudiation
	as the key usage for the certificate's public key; and meets a number		as the key usage for the certificate's public key; and meets a number
	of requirements.		of requirements.
	STATUS:		STATUS: Under WG review.
			DOCUMENT TITLE: An Internet AttributeCertificate Profile for
			Authorizations <draft-ietf-pkix-acx509prof-00.txt>
			DESCRIPTION: This document profiles the format for an defines
			requirements on X.509 Attribute Certificates to support authorization
			services required by various Internet protocols (TLS, CMS, and the
			consumers of CMS, etc.). Two profiles are defined on that supports
			basic authorizations and on the supports proxiable services.
			STATUS: Under WG review.
			DOCUMENT TITLE: Diffie-Hellman Proof-of-Possesion Algorithms <draft-
			ietf-pkix-dhpop-00.txt>
			DESCRIPTION: This documents describes two signing algorithms using
			the Diffie-Hellman key agreement process to provide a shared secret
			as the basis of the signature. It allows Diffie-Hellman a key
			agreement algorithm to be used instead of requiring that the public
			key being requested for certification correspond to an algorithm that
			is capable of signing and/or encrypting. The first algorithm
			generates a signature for a specific verifier where the signer and
			recipient have the same public key parameters. The second algorithm
			generates a signature for arbitrary verifiers where the signer and
			recipient do not have the same public key parameters.
			STATUS: Under WG review.
	4.2 Operational Protocols		4.2 Operational Protocols
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational
	Protocols - LDAPv2 <draft-ietf-pkix-ipki2opp-08.txt>		Protocols - LDAPv2 (RFC 2559)
	DESCRIPTION: This document describes the use of LDAPv2 as a protocol		DESCRIPTION: This document describes the use of LDAPv2 as a protocol
	for PKI elements to publish and retrieve certificates and CRLs from a		for PKI elements to publish and retrieve certificates and CRLs from a
	certificate repository. LDAPv2 [RFC 1777] is a protocol that allows		certificate repository. LDAPv2 [RFC 1777] is a protocol that allows
	publishing and retrieving of information.		publishing and retrieving of information.
	STATUS:		STATUS: Proposed Standard.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure LDAPv2
	Schema <draft-ietf-pkix-ldapv2-schema-02.txt>		Schema (RFC 2587)
	DESCRIPTION: This document defines a minimal schema necessary to		DESCRIPTION: This document defines a minimal schema necessary to
	support the use of LDAPv2 for certificate and CRL retrieval and		support the use of LDAPv2 for certificate and CRL retrieval and
	related functions for PKIX. This document supplements [LDAP] by		related functions for PKIX. This document supplements [RFC 1777] by
	identifying the PKIX-related attributes that must be present.		identifying the PKIX-related attributes that must be present.
	STATUS:		STATUS: Proposed Standard.
	DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online		DOCUMENT TITLE: X.509 Internet Public Key Infrastructure Online
	Certificate Status Protocol - OCSP <draft-ietf-pkix-ocsp-07.txt>		Certificate Status Protocol - OCSP <draft-ietf-pkix-ocsp-08.txt>
	DESCRIPTION: This document specifies a protocol useful in		DESCRIPTION: This document specifies a protocol useful in
	determining the current status of a certificate without the use of		determining the current status of a certificate without the use of
	CRLs. A major complaint about certificate-based systems is the need		CRLs. A major complaint about certificate-based systems is the need
	for a relying party to retrieve a current CRL as part of the		for a relying party to retrieve a current CRL as part of the
	certificate validation process. Depending on the size of the CRL,		certificate validation process. Depending on the size of the CRL,
	this can cause severe problems for bandwidth-challenged devices.		this can cause severe problems for bandwidth-challenged devices.
	Depending on the frequency of CRL issuance, this can also cause		Depending on the frequency of CRL issuance, this can also cause
	timeliness problems. (E.g., if CRLs are only published weekly, with		timeliness problems. (E.g., if CRLs are only published weekly, with
	no interim releases, a certificate could actually have been revoked		no interim releases, a certificate could actually have been revoked
	skipping to change at page 19, line 53 ¶		skipping to change at page 20, line 43 ¶
	whereby a relying party identifies one or more certificates to an		whereby a relying party identifies one or more certificates to an
	approved OCSP "responder", and the responder sends back the current		approved OCSP "responder", and the responder sends back the current
	status of the certificate(s) - e.g., "revoked", "notRevoked",		status of the certificate(s) - e.g., "revoked", "notRevoked",
	"unknown". This can dramatically reduce the bandwidth required to		"unknown". This can dramatically reduce the bandwidth required to
	transmit revocation status - a relying party does not have to		transmit revocation status - a relying party does not have to
	retrieve a CRL of many entries to check the status of one		retrieve a CRL of many entries to check the status of one
	certificate. It can (although it is not guaranteed to) improve the		certificate. It can (although it is not guaranteed to) improve the
	timeliness of revocation notification, and thus reduce the window of		timeliness of revocation notification, and thus reduce the window of
	opportunity for someone trying to use a revoked certificate.		opportunity for someone trying to use a revoked certificate.
	STATUS:		STATUS: Approved as Proposed Standard.
	DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the		DOCUMENT TITLE: Internet Public Key Infrastructure: Caching the
	Online Certificate Status Protocol <draft-ietf-pkix-ocsp-		Online Certificate Status Protocol <draft-ietf-pkix-ocsp-
	caching-00.txt>		caching-00.txt>
	DESCRIPTION: To improve the degree to which it can scale, OCSP		DESCRIPTION: To improve the degree to which it can scale, OCSP
	allows caching of responses - e.g., at intermediary servers, or even		allows caching of responses - e.g., at intermediary servers, or even
	at the relying party's end system. This document describes how to		at the relying party's end system. This document describes how to
	support OCSP caching at intermediary servers.		support OCSP caching at intermediary servers.
	STATUS:		STATUS: ???
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Operational
	Protocols: FTP and HTTP <draft-ietf-pkix-opp-ftp-http-04.txt>		Protocols: FTP and HTTP (RFC 2585)
	DESCRIPTION: This document describes the use of the File Transfer		DESCRIPTION: This document describes the use of the File Transfer
	Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain		Protocol (FTP) and the Hyper-text Transfer Protocol (HTTP) to obtain
	certificates and CRLs from PKI repositories.		certificates and CRLs from PKI repositories.
	STATUS:		STATUS: Proposed Standard.
	DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0		DOCUMENT TITLE: WEB based Certificate Access Protocol-- WebCAP/1.0
			<draft-ietf-pix-webcap-00.txt>
	DESCRIPTION: This document specifies a set of methods, headers, and		DESCRIPTION: This document specifies a set of methods, headers, and
	content-types ancillary to HTTP/1.1 to publish, retrieve X.509		content-types ancillary to HTTP/1.1 to publish, retrieve X.509
	certificates and Certificate Revocation Lists. This protocol also		certificates and Certificate Revocation Lists. This protocol also
	facilitates determining current status of a digital certificate		facilitates determining current status of a digital certificate
	without the use of CRLs. This protocol defines new methods, request		without the use of CRLs. This protocol defines new methods, request
	and response bodies, error codes to HTTP/1.1 protocol for securely		and response bodies, error codes to HTTP/1.1 protocol for securely
	publishing, retrieving, and validating certificates across a		publishing, retrieving, and validating certificates across a
	firewall.		firewall.
	STATUS:		STATUS: Has been discontinued.
	4.3 Management Protocols		4.3 Management Protocols
	DOCUMENT TITLE: Certificate Management Messages over CMS <draft-ietf-		DOCUMENT TITLE: Certificate Management Messages over CMS <draft-
	pkix-cmc-02.txt>		ietf-pkix-cmc-04.txt>
	DESCRIPTION: This document defines the means by which PKI clients and		DESCRIPTION: This document defines the means by which PKI clients and
	servers may exchange PKI messages when using S/MIME's Cryptographic		servers may exchange PKI messages when using S/MIME's Cryptographic
	Message Syntax [CMS]as a transaction envelope. CMC supports the		Message Syntax [CMS]as a transaction envelope. CMC supports the
	certificate request message body specified in the Certificate Request		certificate request message body specified in the Certificate Request
	Message Format [CRMF] documents, as well as a variety of other		Message Format [RFC 2511] documents, as well as a variety of other
	certificate management messages. The primary purpose of this		certificate management messages. The primary purpose of this
	specification is to allow the use of an existing protocol (S/MIME)as		specification is to allow the use of an existing protocol (S/MIME)as
	a PKI management protocol, without requiring the development of an		a PKI management protocol, without requiring the development of an
	entirely new protocol such as CMP. A secondary purpose is to codify		entirely new protocol such as CMP. A secondary purpose is to codify
	in IETF standards the current industry practice of using PKCS 10		in IETF standards the current industry practice of using PKCS 10
	messages [PKCS10] for certificate requests. DOCUMENT TITLE: Internet		messages [PKCS10] for certificate requests.
	X.509 Public Key Infrastructure Certificate Management Message
	Formats <draft-ietf-pkix-cmmf-02.txt>		STATUS: Under WG review.
			DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
			Management Message Formats <draft-ietf-pkix-cmmf-02.txt>
	DESCRIPTION: This document contains the formats for a series of		DESCRIPTION: This document contains the formats for a series of
	messages important in certificate/PKI management. These messages let		messages important in certificate/PKI management. These messages let
	CA's, RA's, and relying parties communicate with each other. Note		CA's, RA's, and relying parties communicate with each other. Note
	that this document only specifies message formats; it does not		that this document only specifies message formats; it does not
	specify a protocol for transferring messages. That protocol can be		specify a protocol for transferring messages. That protocol can be
	either CMP or CMC, or perhaps another custom protocol.		either CMP or CMC, or perhaps another custom protocol.
	STATUS: Will be discontinued, as all useful information from it has		STATUS: Has been discontinued, as all useful information from it has
	been moved into [CMP] and [CMC].		been moved into [RFC 2510] and [CMC].
	DOCUMENT TITLE: Internet X.509 Certificate Request Message Format		DOCUMENT TITLE: Internet X.509 Certificate Request Message Format
	(RFC####)		(RFC 2511)
	DESCRIPTION: CRMF specifies a format recommended for use whenever a		DESCRIPTION: CRMF specifies a format recommended for use whenever a
	relying party is requesting a certificate from a CA or requesting		relying party is requesting a certificate from a CA or requesting
	that an RA help it get a certificate. This document is distinct from		that an RA help it get a certificate. This document is distinct from
	CMMF for historical reasons - the request message format was needed		CMMF for historical reasons - the request message format was needed
	before many of the other message formats had to be finalized, and so		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		it was put into a separate document. Like CMMF, this document only
	specifies the format of a message. Specification of a protocol to		specifies the format of a message. Specification of a protocol to
	transport that message is beyond the scope of CRMF.		transport that message is beyond the scope of CRMF.
	STATUS: Proposed Standard; approved 22 January 1999.		STATUS: Proposed Standard.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
	Management Protocols (RFC ####)		Management Protocols (RFC 2510)
	DESCRIPTION: This document specifies a new protocol specifically		DESCRIPTION: This document specifies a new protocol specifically
	developed for the purpose of transporting messages like those		developed for the purpose of transporting messages like those
	specified in CMMF and CRMF among PKI elements. In general, CMP will		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		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		a transfer service (e.g., S/MIME, HTTP) to provide a complete PKI
	management service.		management service.
	STATUS: Proposed Standard; approved 22 January 1999.		STATUS: Proposed Standard.
	4.4 Policy Outline		4.4 Policy Outline
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Certificate
	Policy and Certification Practices Framework (RFC ####)		Policy and Certification Practices Framework (RFC 2527)
	DESCRIPTION: As noted before, the specification and implementation of		DESCRIPTION: As noted before, the specification and implementation of
	certificate profiles, operational protocols, and management protocols		certificate profiles, operational protocols, and management protocols
	is only part of building a PKI. Equally as important - if not more		is only part of building a PKI. Equally as important - if not more
	important - is the development and enforcement of a certificate		important - is the development and enforcement of a certificate
	security policy, and a Certification Practice Statement (CPS). The		security policy, and a Certification Practice Statement (CPS). The
	purpose of this document (PKIX-4) is to establish a clear		purpose of this document (PKIX-4) is to establish a clear
	relationship between certificate policies and(CPSs), and to present a		relationship between certificate policies and(CPSs), and to present a
	framework to assist the writers of certificate policies or CPSs with		framework to assist the writers of certificate policies or CPSs with
	their tasks. In particular, the framework identifies the elements		their tasks. In particular, the framework identifies the elements
	that may need to be considered in formulating a certificate policy or		that may need to be considered in formulating a certificate policy or
	a CPS. The purpose is not to define particular certificate policies		a CPS. The purpose is not to define particular certificate policies
	or CPSs, per se.		or CPSs, per se.
	STATUS: Informational RFC, approved 22 January 1999.		STATUS: Informational RFC.
	4.5 Time-Stamp and Data Certification Services		4.5 Time-Stamp and Data Certification Services
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Time Stamp
	Protocols <draft-ietf-pkix-time-stamp-00.txt>		Protocols <draft-ietf-pkix-time-stamp-01.txt>
	DESCRIPTION: This document defines the specification for a time stamp		DESCRIPTION: This document defines the specification for a time stamp
	service. It defines a Time Stamp Authority, or TSA, a trusted third		service. It defines a Time Stamp Authority, or TSA, a trusted third
	party who maintains a reliable time service. When the TSA receives a		party who maintains a reliable time service. When the TSA receives a
	time stamp request, it appends the current time to the request and		time stamp request, it appends the current time to the request and
	signs it into a token to certify that the original request existed		signs it into a token to certify that the original request existed
	prior to the indicated time. This helps provide non-repudiation by		prior to the indicated time. This helps provide non-repudiation by
	preventing someone (either a legitimate user or an attacker who has		preventing someone (either a legitimate user or an attacker who has
	successfully compromised a key) from "back-dating" a transaction. It		successfully compromised a key) from "back-dating" a transaction. It
	also makes it more difficult to challenge a transaction by asserting		also makes it more difficult to challenge a transaction by asserting
	that it has been back-dated. Note that the TSA does not provide any		that it has been back-dated. Note that the TSA does not provide any
	data parsing service; that is, the TSA does not attempt to validate		data parsing service; that is, the TSA does not attempt to validate
	that which it signs; it merely regards it as a string of bits whose		that which it signs; it merely regards it as a string of bits whose
	meaning is unimportant, but existence is vital.		meaning is unimportant, but existence is vital.
	STATUS:		STATUS: Under WG review.
	DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data		DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Data
	Certification Server Protocols <draft-ietf-pkix-dcs-00.txt>		Certification Server Protocols <draft-ietf-pkix-dcs-00.txt>
	DESCRIPTION: This document defines a data certification service, or		DESCRIPTION: This document defines a data certification service, or
	DCS, which can be used to certify both the existence and correctness		DCS, which can be used to certify both the existence and correctness
	of a message or signature. In contrast to the time stamp service		of a message or signature. In contrast to the time stamp service
	described above, the DCS certifies possession of data or the validity		described above, the DCS certifies possession of data or the validity
	of another entity's signature. As part of this, the DCS verifies the		of another entity's signature. As part of this, the DCS verifies the
	mathematical correctness of the actual signature value contained in		mathematical correctness of the actual signature value contained in
	skipping to change at page 23, line 13 ¶		skipping to change at page 24, line 8 ¶
	evidence that a signature or public key certificate was valid at the		evidence that a signature or public key certificate was valid at the
	time indicated in the token. The token can be used even after the		time indicated in the token. The token can be used even after the
	corresponding public key certificate expires and its revocation		corresponding public key certificate expires and its revocation
	information is no longer available on CRLs (for example). Second, the		information is no longer available on CRLs (for example). Second, the
	production of a data certification token in response to a signed		production of a data certification token in response to a signed
	request for certification of another signature or public key		request for certification of another signature or public key
	certificate also provides evidence that due diligence was performed		certificate also provides evidence that due diligence was performed
	by the requester in validating the signature or public key		by the requester in validating the signature or public key
	certificate.		certificate.
	STATUS:		STATUS: Under WG review.
			DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
			bert1-01.txt>
			DESCRIPTION: This document defines a finite method of representing a
			discrete instant in time as a referable event. The Basic Event
			Representation Token (BERT) is a light-weight binary token designed
			for use in large numbers over short periods of time. The tokens
			contain only a single instance of an event stamp and the trust
			process is referenced against an external reference.
			STATUS: Under WG review.
			DOCUMENT TITLE: Internet X.509 Public Key Infrastructure Extending
			trust in non repudiation tokens in time <draft-ietf-pkix-extend-
			trust-non-repudiation-token-00.txt>
			DESCRIPTION: This document describes a method to maintain the trust
			in a token issued by a non-repudiation Trusted Third Party (NR TTP)
			(DCS/TSA/TDA) after the key initially used to establish trust in the
			token expires. The document describes a general format for storage
			of DCS/TS/TDA tokens for this purpose, which establishes a chain of
			custody for the data.
			STATUS: Under WG review.
	5 Advice to Implementors		5 Advice to Implementors
	This section provides guidance to those who would implement various		This section provides guidance to those who would implement various
	parts of the PKIX suite of documents. The topics discussed in this		parts of the PKIX suite of documents. The topics discussed in this
	section engendered significant discussion in the working group, and		section engendered significant discussion in the working group, and
	there was at times either widespread disagreement or widespread		there was at times either widespread disagreement or widespread
	misunderstanding of them. Thus, this discussion is provided to help		misunderstanding of them. Thus, this discussion is provided to help
	readers of the PKIX document set understand these issues, in the hope		readers of the PKIX document set understand these issues, in the hope
	of fostering greater interoperability among eventual PKIX		of fostering greater interoperability among eventual PKIX
	skipping to change at page 27, line 10 ¶		skipping to change at page 28, line 30 ¶
	The same applies for IP addresses. As long as only one node on the		The same applies for IP addresses. As long as only one node on the
	Internet responds to the IP address 130.85.1.3, there is no problem,		Internet responds to the IP address 130.85.1.3, there is no problem,
	despite the fact that there are 100 different corporate Intranets,		despite the fact that there are 100 different corporate Intranets,
	each using that same IP address. However, if two different nodes on		each using that same IP address. However, if two different nodes on
	the Internet each responded to the IP address 130.85.1.3, there would		the Internet each responded to the IP address 130.85.1.3, there would
	be a problem.		be a problem.
	5.1.3 Certificate Path Construction		5.1.3 Certificate Path Construction
	Path construction - make point that there is no single best way to		Certificate path construction has been the topic of many discussions
	construct a path. Implementors can pick the way that is most		in the WG. The issue centered around how best to get a certificate
	efficient for them. Discuss some of the issues being hashed out in		when the connection between the subject's name and the name of their
	the "ldap" discussion on the mail list. If there is ever a		CA, as well as the CA's repository (or directory), may not be
	resolution, include it in this section.		obvious. Many proposals were put forth, including implementing a
			global X.500 Directory Service, using DNS SRV records, and using an
			attribute to point to the directory provider. At the end of the
			discussion the group decided to use the authority information access
			extension defined in [RFC 2459], which allows the CA to indicate the
			access method and location of CA information and services. The
			extension would be included in subject's certificates and could be
			used to associate an Internet style identity for the location of
			repository to retrieve the issuer's certificate in cases where such a
			location is not related to the issuer's name.
	5.1.4 Name Constraints		Another discussion related to certificate path construction was where
			to store the CA and end-entity certificates in the directory
			(specifically LDAPv2 directories). Two camps emerged with different
			views on where to store CA and cross-certificates. In the CA's
			directory entry, one camp wanted self-issued certificates stored in
			the cACertificate attribute, certificates issued to this CA stored in
			the forward element of the crossCertificatePair, and certificates
			issued from this CA for other CAs in the reverse element of the
			crossCertificatePair attribute. The other camp wanted all CA
			certificates stored in the cACertificate attribute, and certificates
			issued to/from another domain stored in the crossCertificatePair
			attribute. There was a short discussion that the second was more
			efficient than first, and that one solution or the other was more
			widely deployed. The end result was to indicate that self-issued
			certificates and certificates issued to the CA by CAs in the same
			domain as the CA are stored in the cACertificate attribute. The
			crossCertificatePair attribute's forward element will include all but
			self-issued certificates issued to the CA. The reverse element may
			include a subset of certificates issued by the CA to other CAs. With
			this resolution both camp's implementations are supported and are
			free to chose the location of CA certificates to best support their
			implementation.
	(Note: this section still needs a lot of work.)		5.1.4 Name Constraints
	A question that has arisen a number of times is "how does one enforce		A question that has arisen a number of times is "how does one enforce
	Name constraints when there is more than one name form in a		Name constraints when there is more than one name form in a
	certificate?" That is, [RFC 2459] 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
	described in section 4.2.1.11.		as described in section 4.2.1.11.
	What does this mean? Suppose that there is a CA with DN "O=IETF,		What does this mean? Suppose that there is a CA with DN "O=IETF,
	OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having		OU=PKIX, CN=PKIX_CA", with the subjectAltName extension having
	dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a		dNSName "PKIX_CA.IETF.ORG". Suppose that that CA has issued a
	certificate with an empty DN, with subjectAltName extension having		certificate with an empty DN, with subjectAltName extension having
	dNSName set to "PKIX_CA.IETF.ORG", and rfc822Name set to		dNSName set to "PKIX_CA.IETF.ORG", and rfc822Name set to
	Steve@PKIX_CA.IETF.ORG. The question is, are name constraints		Steve@PKIX_CA.IETF.ORG. The question is, are name constraints
	enforced on these two certificates - is the name of the end-entity		enforced on these two certificates - is the name of the end-entity
	certificate considered to be properly subordinate to the name of the		certificate considered to be properly subordinate to the name of the
	CA?		CA?
	skipping to change at page 27, line 50 ¶		skipping to change at page 30, line 4 ¶
	If a certificate complies with name constraints in any one of its		If a certificate complies with name constraints in any one of its
	name forms, then the certificate is deemed to comply with name		name forms, then the certificate is deemed to comply with name
	constraints.		constraints.
	If a certificate contains a name form that its issuer does not,		If a certificate contains a name form that its issuer does not,
	the certificate is deemed to comply with name constraints for that		the certificate is deemed to comply with name constraints for that
	name form.		name form.
	In deciding whether a name form meets name constraints, the following		In deciding whether a name form meets name constraints, the following
	rules apply:		rules apply (in all cases Name B is the name in the name constraints
			extension):
	- for DNs: - for rfc822Names: - for dNSNames: Name A is subordinate		- rfc822Names: Three variations are allowed:
	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		- If the name constraint is specified as "larry@mail.mit.edu",
	of Name B's name. That is, www.mit.edu is subordinate to mit.edu, as		then Name A is subordinate to Name B (in B's subtree) if Name A
	is larry.cs.mit.edu. However, www.mit.edu is not subordinate to		contains all of Name B's name (specifies a particular mailbox).
	web.mit.edu. - for URIs: - for iPaddresses: Name A is subordinate to		For example, larry@mail.mit.edu is subordinate, but
	Name B if...		larry_sanders@mail.mit.edu is not.
			- If the name constraint is specified as "mail.mit.edu", then
			Name A is subordinate to Name B (in B's subtree) if Name A
			contains all of Name B's name (specified all mailboxes on host
			mail.mit.edu). For example, curly@mail.mit.edu and
			mo@mail.mit.edu are subordinate, but mo@mail6.mit.edu and
			curly@smtp.mail.mit.edu are not.
			- If the name constraint is specified as ".mit.edu", then Name
			A is subordinate to Name B (in B's subtree) if Name A contains
			all of Name B's name, with the addition of zero or more
			additional host or domain names to the left of Name B's name.
			That is, smtp.mit.edu is subordinate to .mit.edu, as is
			pop.mit.edu. However, mit.edu is not subordinate to .mit.edu.
			When the constraint begins with a "." it specifies any address
			within a domain. In the previous example, "mit.edu" is not in
			the domain of ".mit.edu".
			Note: If rfc822 names are constrained, but the certificate does
			not contain a subject alternative name, the EmailAddress
			attribute will be used to constrain the name in the subject
			distinguished name. For example (c is country, o is
			organization, ou is organizational unit, and em is
			EmailAddress), Name A ("c=US, o=MIT, ou=CS,
			em=curly@mail.mit.edu") is subordinate to Name B ("c=US, o=MIT,
			ou=CS") (in B's subtree) if Name A contains all of Name B's
			names.
			- 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.
			- x.400 addresses: Name A is subordinate to Name B (in B's
			subtree) if Name A contains all of Name B's name. For example (c
			is country-name, admd is administrative-domain-name, and o is
			orgnaization-name, ou is organizational-unit-name, pn is personal-
			name, sn=surname, and gn is given-name in both Name A and B), the
			mneumonic X.400 address (using PrintableString choices for c and
			admd) "c=US, admd=AT&T, o=MIT, ou=cs, pn='sn=Doe,gn=John'" is
			subordinate to "c=US, admd=AT&T, o=MIT, ou=cs" and "c=US,
			admd=AT&T, o=MIT, pn='sn=DOE,gn=JOHN'" (pn is a SET that includes,
			among other things, sn and gn).
			- DNs: Name A is subordinate to Name B (in B's subtree), if Name A
			contains all of Name B's name, treating attribute values encoded
			in different types as different strings, ignoring case in
			PrintableString (in all other types case is not ignored), removing
			leading and trailing white space in PrintableString, and
			converting internal substrings of one or more consecutive white
			space characters to a single space. For example, (c is country, o
			is organization, ou is organizational unit, and cn is common
			name):
			(Assuming PrinatString types for all attribute values in Name A
			and B) "c=US, o=MIT, ou=CS" is subordinate to "c=us, o=MIT,
			ou=cs", as is "c=US, o=MIT, ou=CS, ou=adminstration". Another
			example, "c=US, o=MIT, ou=CS, cn= John Doe" (note the white
			spaces) is subordinate to "c=US, o=MIT, ou=CS, cn=John Doe".
			(Assuming UTF8String types for all attribute values in Name A
			and B) "c=US, o=MIT, ou=CS, ou=administration" is subordinate
			to "c=US, o=MIT, ou=CS", but "c=US, o=MIT, ou=cs,
			ou=Adminstration". "c=US, o=MIT, ou=CS, cn= John Smith" (note
			the white spaces) is not subordinate to "c=US, o=MIT, ou=CS,
			cn= John Smith".
			(Assuming UTF8String types for all attribute values in Name A
			and PrintableString types for all attribute values in Name B)
			"c=US, o=MIT, ou=cs" is subordinate to "c=US, o=MIT, ou=CS" if
			the verification software supports the full comparison
			algorithm in the X.500 series. "c=US, o=MIT, ou=cs" is NOT
			subordinate to "c=US, o=MIT, ou=CS" if the verification
			software supports the comparison algorithm in [RFC 2459].
			- URIs: The constraints apply only to the host part of the
			name. Two variations are allowed:
			- If the name constraint is specified as ".mit.edu", then Name
			A is subordinate to Name B (in B's subtree) if Name A contains
			all of Name B's name, with the addition of zero or more
			additional host or domain names to the left of Name B's name.
			That is, www.mit.edu is subordinate to .mit.edu, as is
			curly.cs.mit.edu. However, mit.edu is not subordinate to
			.mit.edu. When the constraint begins with a "." it specifies a
			host.
			- If the name constraint is specified as "abc.mit.edu", then
			Name A is subordinate to Name B (in B's subtree) if Name A
			conatins all of Name B's name. No leftward expansion of the
			host or domain name is allowed.
			- iPaddresses: Two variations are allowed depending on the IP
			version:
			For IPv4 addresses: Name A (128.32.1.1 encoded as 80 20 01 01)
			is subordinate to Name B (128.32.1.0/255.255.255.0 encoded as
			80 20 00 00 FF FF FF 00) (in B's subtree) if Name A falls
			within the net denoted in Name B's CIDR notation.
			For IPv6 addresses: Name A (4224.0.0.0.8.2048.8204.16762
			encoded as 10 80 00 00 00 00 00 00 00 08 08 00 20 0C 41 7A) is
			subordinate to Name B (4224.0.0.0.8.2048.8204.0/
			65535.65535.65535.65535.65535.65535.65535.0 encoded as 10 80 00
			00 00 00 00 00 00 08 08 00 20 0C 00 00 FF FF FF FF FF FF FF FF
			FF FF FF FF FF FF 00 00) (in B's subtree) if Name A falls
			within the net denoted in Name B's CIDR notation.
			As [RFC 2459] does not define requirements for the name forms
			otherName, ediPartyName, or registeredID there are no corresponding
			name constraints requirements.
	5.1.5 Wildcards in Name Forms		5.1.5 Wildcards in Name Forms
	A "wildcard" in a name form is a placeholder for a set of names; e.g.		A "wildcard" in a name form is a placeholder for a set of names; e.g.
	"*.mit.edu" meaning "any domain name ending in .mit.edu", and		"*.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		single certificate to be used by all members of a group. These
	members would presumably have attributes in common; e.g., access		members would presumably have attributes in common; e.g., access
	skipping to change at page 28, line 34 ¶		skipping to change at page 33, line 7 ¶
	After much discussion, the PKIX working group decided to permit the		After much discussion, the PKIX working group decided to permit the
	use of wildcards in certificates. That is, it is permissible for a		use of wildcards in 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:)		A very important topic that consumed much of the WG's time was the
	- UTF8 is the long-term goal for IETF, and is mandatory in 2003 and		implementation of the directory string choices. While the long term
	later - BMPString is presently supported by most vendors -		goal of the IETF was clear, use UTF8String, the short term goals were
	Teletexstring containing ISO 8859-1 is also used by many CA's		not so clear. Many implementations only use PrintableString, others
			use BMPString, and still others use Latin1String (ISO 8859-1) and tag
			it as TeletexString (there are others still). To ensure that there
			is consistency with encodings [RFC 2459] defines a set of rules for
			the string choices. PrintableString was kept as the first choice
			because of it's widespread support by vendors. BMPString was the
			second choice, also for it's widespread vendor support. Failing
			support by PrintableString and BMPString, UTF8String must be used.
			In keeping with the IETF mandate, UTF8String can be used at any time
			if the CA supports it. Also, processing implementations that wish to
			support TeletexString should handle the entire ISO 8859-1 character
			set and not just the Latin1String subset.
	5.2 POP		5.2 POP
	Proof of Possession, or POP, means that the CA is adequately		Proof of Possession, or POP, means that the CA is adequately
	convinced that the entity requesting a certificate containing a		convinced that the entity requesting a certificate containing a
	public key Y has access to the private key X corresponding to that		public key Y has access to the private key X corresponding to that
	public key.		public key.
	POP is important because it provides an appropriate level of		POP is important because it provides an appropriate level of
	assurance in the correct operation of the PKI as a whole. At its		assurance in the correct operation of the PKI as a whole. At its
	skipping to change at page 29, line 21 ¶		skipping to change at page 33, line 54 ¶
	Charlie containing the same public key, Y. Now, there are two		Charlie containing the same public key, Y. Now, there are two
	possible threats: Mal could claim to have been the real signer of		possible threats: Mal could claim to have been the real signer of
	T; or Alice can falsely deny signing T, claiming that it was		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		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		not ever possess X, neither of these claims can be refuted, and
	thus the service provided by and the confidence in the PKI has		thus the service provided by and the confidence in the PKI has
	been defeated. (Of course, if Mal really did possess X, Alice's		been defeated. (Of course, if Mal really did possess X, Alice's
	private key, then no POP mechanism in the world will help, but		private key, then no POP mechanism in the world will help, but
	that is a different problem.)		that is a different problem.)
	Note that one level of protection can be gained by having Alice,		One level of protection can be gained by having Alice, as the true
	as the true signer of the transaction, include in the signed		signer of the transaction, include in the signed information her
	information her certificate or an identifier of her certificate		certificate or an identifier of her certificate (e.g., a hash of
	(e.g., a hash of her certificate). This might make it more		her certificate). This might make it more difficult for Mal to
	difficult for Mal to claim authorship - he would have to assert		claim authorship - he would have to assert that he incorrectly
	that he incorrectly included Alice's certificate, rather than his		included Alice's certificate, rather than his own. However, it
	own. However, it would not stop Alice from falsely repudiating		would not stop Alice from falsely repudiating her actions. Since
	her actions. Since the certificate itself is a public item, Mal		the certificate itself is a public item, Mal indeed could have
	indeed could have inserted Alice's certificate into the signed		inserted Alice's certificate into the signed transaction, and thus
	transaction, and thus its presence does not indicate that Alice		its presence does not indicate that Alice was the one who
	was the one who participated in the now-repudiated transaction.		participated in the now-repudiated transaction. The only reliable
	The only reliable way to stop this attack is to require that Mal		way to stop this attack is to require that Mal prove he possesses
	prove he possesses X before his certificate is issued.		X before his certificate is issued.
	For signing keys used only for authentication, and not for non-		For signing keys used only for authentication, and not for non-
	repudiation, the threat is lower because users may not care about		repudiation, the threat is lower because users may not care about
	Alice's after-the-fact repudiation, and thus POP becomes less		Alice's after-the-fact repudiation, and thus POP becomes less
	important. However, POP SHOULD still be done wherever feasible in		important. However, POP SHOULD still be done wherever feasible in
	this environment, by either off-line or on-line means.		this environment, by either off-line or on-line means.
	POP for key management keys: Similarly, POP for key management keys		POP for key management keys: Similarly, POP for key management keys
	(that is, keys used for either key agreement or key exchange) can		(that is, keys used for either key agreement or key exchange) can
	help to prevent undermining confidence in the PKI. Suppose that Al		help to prevent undermining confidence in the PKI. Suppose that Al
	skipping to change at page 31, line 8 ¶		skipping to change at page 35, line 38 ¶
	key. The CA will then use the requested public key to verify the		key. The CA will then use the requested public key to verify the
	signature. If the signature verification works, the CA can safely		signature. If the signature verification works, the CA can safely
	conclude that the requester had access to the private key. If the		conclude that the requester had access to the private key. If the
	signature verification process fails, the CA can conclude that the		signature verification process fails, the CA can conclude that the
	requester did not have access to the correct private key, and		requester did not have access to the correct private key, and
	reject the request.		reject the request.
	For key management keys that are generated by the requester, the		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		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		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		requester to be decrypted. For example, the CA can generate some
	random challenge, and require some action to be taken after		random challenge, and require some action to be taken after
	decryption (e.g., "decrypt this encrypted random number and send		decryption (e.g., "decrypt this encrypted random number and send
	it back to me"). If the requester does not take the requested		it back to me"). If the requester does not take the requested
	action, the CA concludes that the requester did not possess the		action, the CA concludes that the requester did not possess the
	private key, and the certificate is not issued.		private key, and the certificate is not issued.
	Another method of providing POP for key management keys is for the		Another method of providing POP for key management keys is for the
	CA to generate the requested certificate, and then send it to the		CA to generate the requested certificate, and then send it to the
	requester in encrypted form. If the requester does not have		requester in encrypted form. If the requester does not have
	access to the appropriate private key, the requester cannot		access to the appropriate private key, the requester cannot
	skipping to change at page 31, line 39 ¶		skipping to change at page 36, line 21 ¶
	certificate. This extension is used when a key that could be used for		certificate. This extension is used when a key that could be used for
	more than one operation is to be restricted. For example, when an		more than one operation is to be restricted. For example, when an
	RSA key should be used only for signing, the digitalSignature and/or		RSA key should be used only for signing, the digitalSignature and/or
	nonRepudiation bits would be asserted. Likewise, when an RSA key		nonRepudiation bits would be asserted. Likewise, when an RSA key
	should be used only for key management, the keyEncipherment bit would		should be used only for key management, the keyEncipherment bit would
	be asserted. When used, this 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		The eight bits defined for this extension identify seven mechanisms
	and one service, namely:		and one service, namely:
	- digitalSignature - nonRepudiation - keyEncipherment -		- digitalSignature - nonRepudiation - keyEncipherment -
	dataEncipherment - keyAgreement - keyCertSign - cRLSign -		dataEncipherment - keyAgreement - keyCertSign - cRLSign -
	encipherOnly - decipherOnly		encipherOnly - decipherOnly
	According to [RFC 2459], bits in the KeyUsage type are used as		According to [RFC 2459], bits in the KeyUsage type are used as
	follows:		follows:
	The digitalSignature bit is asserted when the subject public key		- The digitalSignature bit is asserted when the subject public key
	is used to verify digital signatures that have purposes other than		is used to verify digital signatures that have purposes other than
	non-repudiation, certificate signature, and CRL signature. For		non-repudiation, certificate signature, and CRL signature. For
	example, the digitalSignature bit is asserted when the subject		example, the digitalSignature bit is asserted when the subject
	public key is used to provide authentication via the signing of		public key is used to provide authentication via the signing of
	ephemeral data.		ephemeral data.
	The nonRepudiation bit is asserted when the subject public key is		- The nonRepudiation bit is asserted when the subject public key
	used to verify digital signatures used to provide a non-		is used to verify digital signatures used to provide a non-
	repudiation service which protects against the signing entity		repudiation service which protects against the signing entity
	falsely denying some action, excluding certificate or CRL signing.		falsely denying some action, excluding certificate or CRL signing.
	The keyEncipherment bit is asserted when the subject public key is		- The keyEncipherment bit is asserted when the subject public key
	used for key transport. For example, when an RSA key is to be		is used for key transport. For example, when an RSA key is to be
	used for key management, this bit must asserted.		used for key management, this bit must asserted.
	The dataEncipherment bit is asserted when the subject public key		- The dataEncipherment bit is asserted when the subject public key
	is used for enciphering user data, other than cryptographic keys.		is used for enciphering user data, other than cryptographic keys.
	The keyAgreement bit is asserted when the subject public key is		- The keyAgreement bit is asserted when the subject public key is
	used for key agreement. For example, when a Diffie-Hellman key is		used for key agreement. For example, when a Diffie-Hellman key is
	to be used for key management, this bit must asserted.		to be used for key management, this bit must asserted.
	The keyCertSign bit is asserted when the subject public key is		- The keyCertSign bit is asserted when the subject public key is
	used for verifying a signature on certificates. This bit may only		used for verifying a signature on certificates. This bit may only
	be asserted in CA certificates.		be asserted in CA certificates.
	The cRLSign bit is asserted when the subject public key is used		- The cRLSign bit is asserted when the subject public key is used
	for verifying a signature on revocation information (e.g., a CRL).		for verifying a signature on revocation information (e.g., a CRL).
	The meaning of the encipherOnly bit is undefined in the absence of		- The meaning of the encipherOnly bit is undefined in the absence
	the keyAgreement bit. When the encipherOnly bit is asserted and		of the keyAgreement bit. When the encipherOnly bit is asserted
	the keyAgreement bit is also set, the subject public key may be		and the keyAgreement bit is also set, the subject public key may
	used only for enciphering data while performing key agreement.		be used only for enciphering data while performing key agreement.
	The meaning of the decipherOnly bit is undefined in the absence of		- The meaning of the decipherOnly bit is undefined in the absence
	the keyAgreement bit. When the decipherOnly bit is asserted and		of the keyAgreement bit. When the decipherOnly bit is asserted
	the keyAgreement bit is also set, the subject public key may be		and the keyAgreement bit is also set, the subject public key may
	used only for deciphering data while performing key agreement.		be used only for deciphering data while performing key agreement.
	PKIX does not restrict the combinations of bits that may be set in an		PKIX does not restrict the combinations of bits that may be set in an
	instantiation of the keyUsage extension.		instantiation of the keyUsage extension.
	The discussion on the PKIX mailing list has centered on the		The discussion on the PKIX mailing list has centered on the
	digitalSignature bit and the nonRepudiation bit. The question has		digitalSignature bit and the nonRepudiation bit. The question has
	come down to something like: When support for the service of non-		come down to something like: When support for the service of non-
	repudiation is desired, should both the digitalSignature and		repudiation is desired, should both the digitalSignature and
	nonRepudiation bits be set, or just the nonRepudiation bit?		nonRepudiation bits be set, or just the nonRepudiation bit?
	skipping to change at page 34, line 13 ¶		skipping to change at page 38, line 44 ¶
	request certificates with the appropriate bits set.		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		support. It is important to note that PKIX is bound to neither a
	pure hierarchical model a la PEM, nor a web of trust model a la PGP.		pure hierarchical model a la PEM, nor a web of trust model a la PGP.
	PKIX can support either of those models, or any flavor in between.		PKIX can support either of those models, or any flavor in between.
	The implications of different trust models should be described:		The implications of different trust models should be described:
	- efficiency of revocation - certification path building - etc.)		- efficiency of revocation
			- certification path building
			- etc.)
	6 Acknowledgements		6 Acknowledgements
	A lot of the information in this document was taken from the PKIX		A lot of the information in this document was taken from the PKIX
	source documents; the authors of those deserve the credit for their		source documents; the authors of those deserve the credit for their
	own words. Other good material was taken from mail posted to the		own words. Other good material was taken from mail posted to the PKIX
	PKIX working group mail list (ietf-pkix@imc.org). Among those with		working group mail list (ietf-pkix@imc.org). Among those with good
	good things to say were (in alphabetical order, with apologies to		things to say were (in alphabetical order, with apologies to anybody
	anybody we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford,		we've missed): Sharon Boeyen, Santosh Chokhani, Warwick Ford, Russ
	Russ Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers,		Housley, Steve Kent, Ambarish Malpani, Matt Fite, Michael Myers, Tim
	Tim Polk, Stefan Santesson, Dave Simonetti, and.		Polk, Stefan Santesson, Dave Simonetti, and.
	7 References		7 References
			[BERT1] McNeil, M., and Glassey, T., "Basic Event Representation
			Token," <draft-ietf-pkix-bert1-01.txt>, May 1999.
	[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		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-02.txt>, November		Management Messages over CMS," <draft-ieft-pkix-cmc-04.txt>, May
	1998		1999.
	[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," <draft-ietf-		Infrastructure Certificate Management Message Formats," <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		Note: This following document has expired.
	Certificate Request Message Format," RFC 2511, March 1999
	[CRS] Myers, M., Liu X., Fox B., Prafullchandra H., Weinstein J., "		[CRS] Myers, M., Liu X., Fox B., Prafullchandra H., Weinstein J., "
	Certificate Request Syntax," <draft-ietf-smime-crs-00.txt>, November		Certificate Request Syntax," <draft-ietf-smime-crs-00.txt>, November
	1997		1997.
	[CMP] Adams, C., and Farrell, S., "Internet X.509 Public Key
	Infrastructure Certificate Management Protocols," RFC 2510, March
	1999
	[CMS] R. Housley, "Cryptographic Message Syntax," <draft-ietf-smime-		[CMS] R. Housley, "Cryptographic Message Syntax," <draft-ietf-smime-
	cms-10.txt>, December 1998		cms-13.txt>, April 1999.
	[DCS] Adams, C., and Zuccherato, R., "Internet X.509 Public Key		[DCS] Adams, C., and Zuccherato, R., "Internet X.509 Public Key
	Infrastructure Data Certification Server Protocols", <draft-ietf-		Infrastructure Data Certification Server Protocols", <draft-ietf-
	pkix-dcs-00.txt>, 23 September 1998.		pkix-dcs-00.txt>, 23 September 1998.
	[ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509		[ECDSA] Bassham, L., Johnson, D., and Polk, W., "Internet x.509
	Public Key Infrastructure: Representation of Elliptic Curve Digital		Public Key Infrastructure: Representation of Elliptic Curve Digital
	Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509		Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509
	Public Key Infrastructure Certificates," <draft-ietf-pkix-ipki-		Public Key Infrastructure Certificates," <draft-ietf-pkix-ipki-
	ecdsa-01.txt>, November 1997		ecdsa-01.txt>, November 1997
	[FTP] Housley, R., and Hoffman, P., "Internet X.509 Public Key		[ETNPT] Namjoshi, P., "Internet X.509 Public Key Infrastructure
	Infrastructure Operational Protocols: FTP and HTTP," <draft-ietf-		Extending trust in non repudiation tokens in time," <draft-ietf-pkix-
	pkix-opp-ftp-http-04.txt>, July 1998		extend-trust-non-repudiation-token-00.txt>, May 1999.
	[KEA] Housley, R., and Polk, W., "Internet X.509 Public Key
	Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in
	Internet X.509 Public Key Infrastructure Certificates," RFC ####,
	date TBD.
	[LDAP] Boeyen, S., Howes, T., and Richard, P., "Internet X.509 Public
	Key Infrastructure Operational Protocols - LDAPv2," <draft-ietf-pkix-
	ipki2opp-08.txt>, September 1998.
	[MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC		[MISPC] Burr, W., Dodson, D., Nazario, N., and Polk, W., "MISPC
	Minimum Interoperability Specification for PKI Components, Version		Minimum Interoperability Specification for PKI Components, Version
	1", September 3, 1997		1", September 3, 1997
	[OCDP] Hallam-Baker, P., and Ford, W., "Internet X.509 Public Key		[OCDP] Hallam-Baker, P., and Ford, W., "Internet X.509 Public Key
	Infrastructure Enhanced CRL Distribution Options (OpenCDP)," <draft-		Infrastructure Enhanced CRL Distribution Options (OpenCDP)," <draft-
	ietf-pkix-ocdp-01.txt>, August 7, 1998		ietf-pkix-ocdp-01.txt>, August 7, 1998
	[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams,		[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams,
	C., "X.509 Internet Public Key Infrastructure Online Certificate		C., "X.509 Internet Public Key Infrastructure Online Certificate
	Status Protocol - OCSP," <draft-ietf-pkix-ocsp-07.txt>, September		Status Protocol - OCSP," <draft-ietf-pkix-ocsp-08.txt>, March 1999.
	1998.
	[PKCS10] "Certification Request Syntax Standard", Public Key		[PKCS10] RSA Laboratories, "The Public-Key Cryptography
	Cryptography Standard #10, RSA Laboratories.		Standards(PKCS)", RSA Data Security Inc., Redwood City, California,
			November 1993 Release.
	[PKIX-4] Chokhani, S., and Ford, W., "Internet X.509 Public Key		[DHPOP] Prafullchandra, H., and Schaad, J., "Diffie-Hellman Proof-of-
	Infrastructure Certificate Policy and Certification Practices		Possession Algorithms," <draft-ietf-pkix-dhpop-00.txt>, February
	Framework," RFC 2527, March 1999.		1999.
	[QC] Santesson, S., Polk, W., and Gloeckner, P., "Internet X.509		[QC] Santesson, S., Polk, W., and Gloeckner, P., "Internet X.509
	Public Key Infrastructure Qualified Certificates", <draft-ietf-pkix-		Public Key Infrastructure Qualified Certificates", <draft-ietf-pkix-
	qc-00.txt>, 3 February 1999.		qc-00.txt>, 3 February 1999.
	[RFC 791] Postel, J., "Internet Protocol", September 1981.		[RFC 791] Postel, J., "Internet Protocol", September 1981.
	[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text		[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text
	Messages", August 1982.		Messages", August 1982.
	skipping to change at page 36, line 24 ¶		skipping to change at page 40, line 47 ¶
	[RFC 1777] Yeong, Y., Howes, T., and Kille, S., "Lightweight		[RFC 1777] Yeong, Y., Howes, T., and Kille, S., "Lightweight
	Directory Access Protocol", March 1995		Directory Access Protocol", March 1995
	[RFC 1883] Deering, S., and Hinden, R., "Internet Protocol, Version 6		[RFC 1883] Deering, S., and Hinden, R., "Internet Protocol, Version 6
	[IPv6] Specification", December 1995.		[IPv6] Specification", December 1995.
	[RFC 2459] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet		[RFC 2459] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet
	X.509 Public Key Infrastructure Certificate and CRL Profile," January		X.509 Public Key Infrastructure Certificate and CRL Profile," January
	1999.		1999.
	[SCHEMA] Boeyen, S., Howes, T., and Richard, P., "Internet X.509		[RFC 2510] Adams, C., Farrell, S., "Internet X.509 Public Key
	Public Key Infrastructure LDAPv2 Schema," <draft-ietf-pkix-		Infrastructure Certificate Management Protocols", March 1999.
	ldapv2-schema-02.txt>, September 1998
			[RFC 2511] Myers, M., Adams, C., Solo, D., and Kemp, D., "Internet
			X.509 Certificate Request Message Format," RFC 2510, March 1999.
			[RFC 2527] Chokhani, S., and Ford, W., "Internet X.509 Public Key
			Infrastructure Certificate Policy and Certification Practices
			Framework," RFC 2527, March 1999.
			[RFC 2528] Housley, R., and Polk, W., "Internet X.509 Public Key
			Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in
			Internet X.509 Public Key Infrastructure Certificates," RFC 2528,
			March 1999.
			[RFC 2559] Boeyen, S., Howes, T., and Richard, P., "Internet X.509
			Public Key Infrastructure Operational Protocols - LDAPv2," RFC 2559,
			April 1999.
			[RFC 2585] Housley, R., and Hoffman, P., "Internet X.509 Public Key
			Infrastructure Operational Protocols: FTP and HTTP," RFC 2585, July
			1998.
			[RFC 2587] Boeyen, S., Howes, T., and Richard, P., "Internet X.509
			Public Key Infrastructure LDAPv2 Schema," RFC 2587, June 1999.
	[SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf-		[SIMONETTI] Simonetti, D., "Re: German Key Usage", posting to ietf-
	pkix@imc.org mailing list, 12 August 1998		pkix@imc.org mailing list, 12 August 1998
	[TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet		[TSP] Adams, C., Cain, P., Pinkas, D., and Zuccherato, R., "Internet
	X.509 Public Key Infrastructure Time Stamp Protocols", <draft-ietf-		X.509 Public Key Infrastructure Time Stamp Protocols", <draft-ietf-
	pkix-time-stamp-00.txt>, 23 September 1998.		pkix-time-stamp-02.txt>, May 1999.
	[WEB] Reddy, S., "WEB based Certificate Access Protocol--		[WEB] Reddy, S., "WEB based Certificate Access Protocol--
	WebCAP/1.0," <draft-ietf-pkix-webcap-00.txt>, April 19, 1998		WebCAP/1.0," <draft-ietf-pkix-webcap-00.txt>, April 19, 1998
	[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology		[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology
	- Open Systems Interconnection - The Directory: Authentication		- Open Systems Interconnection - The Directory: Authentication
	Framework, June 1997.		Framework, June 1997.
	[X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial		[X9.42] ANSI X9.42-199x, Public Key Cryptography for The Financial
	Services Industry: Agreement of Symmetric Algorithm Keys Using		Services Industry: Agreement of Symmetric Algorithm Keys Using
	skipping to change at page 37, line 11 ¶		skipping to change at page 42, line 11 ¶
	[X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial		[X9.57] ANSI X9.57-199x, Public Key Cryptography For The Financial
	Services Industry: Certificate Management (Working Draft), 21 June,		Services Industry: Certificate Management (Working Draft), 21 June,
	1996.		1996.
	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 9800 Savage Road Suite
	U. S. Department of Defense		6734 Fort George G. Meade, MD 20755-6734 (410) 684-7114
	9800 Savage Road Suite
	6734 Fort George G. Meade, MD 20755-6734
	(410) 684-7114
	awarsen@missi.ncsc.mil		awarsen@missi.ncsc.mil
	Sean Turner		Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 (703)
	IECA, Inc.		628-3180 turners@ieca.com
	9010 Edgepark Road Vienna, VA 22182
	(703) 358-9113
	turners@ieca.com
	10 Disclaimer		10 Disclaimer
	This work constitutes the opinion of the editors only, and may not		This work constitutes the opinion of the editors only, and may not
	reflect the opinions or policies of their employers.		reflect the opinions or policies of their employers.
End of changes. 102 change blocks.
	311 lines changed or deleted		516 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/