< draft-ietf-pkix-new-part1-08.txt		draft-ietf-pkix-new-part1-09.txt >
	PKIX Working Group R. Housley (RSA Laboratories)		PKIX Working Group R. Housley (RSA Laboratories)
	Internet Draft W. Ford (VeriSign)		Internet Draft W. Ford (VeriSign)
	W. Polk (NIST)		W. Polk (NIST)
	D. Solo (Citigroup)		D. Solo (Citigroup)
	expires in six months July 2001		expires in six months October 2001
	Internet X.509 Public Key Infrastructure		Internet X.509 Public Key Infrastructure
	Certificate and CRL Profile		Certificate and CRL Profile
	<draft-ietf-pkix-new-part1-08.txt>		<draft-ietf-pkix-new-part1-09.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. 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 six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html
	To view the entire list of current Internet-Drafts, please check the		To view the entire list of current Internet-Drafts, please check the
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		"1id-abstracts.txt" listing contained in the Internet-Drafts 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 (2001). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	Abstract		Abstract
	This is the eighth draft of a specification based upon RFC 2459.		This is the ninth draft of a specification based upon RFC 2459. When
	When complete, this specification will obsolete RFC 2459.		complete, this specification will obsolete RFC 2459.
	Please send comments on this document to the ietf-pkix@imc.org mail		Please send comments on this document to the ietf-pkix@imc.org mail
	list.		list.
	This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use		This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
	in the Internet. An overview of the approach and model are provided		in the Internet. An overview of the approach and model are provided
	as an introduction. The X.509 v3 certificate format is described in		as an introduction. The X.509 v3 certificate format is described in
	detail, with additional information regarding the format and		detail, with additional information regarding the format and
	semantics of Internet name forms (e.g., IP addresses). Standard		semantics of Internet name forms (e.g., IP addresses). Standard
	certificate extensions are described and one new Internet-specific		certificate extensions are described and one new Internet-specific
	skipping to change at page 13, line 35 ¶		skipping to change at page 13, line 35 ¶
	freely available in a public repository. Each revoked certificate is		freely available in a public repository. Each revoked certificate is
	identified in a CRL by its certificate serial number. When a		identified in a CRL by its certificate serial number. When a
	certificate-using system uses a certificate (e.g., for verifying a		certificate-using system uses a certificate (e.g., for verifying a
	remote user's digital signature), that system not only checks the		remote user's digital signature), that system not only checks the
	certificate signature and validity but also acquires a suitably-		certificate signature and validity but also acquires a suitably-
	recent CRL and checks that the certificate serial number is not on		recent CRL and checks that the certificate serial number is not on
	that CRL. The meaning of "suitably-recent" may vary with local		that CRL. The meaning of "suitably-recent" may vary with local
	policy, but it usually means the most recently-issued CRL. A CA		policy, but it usually means the most recently-issued CRL. A CA
	issues a new CRL on a regular periodic basis (e.g., hourly, daily, or		issues a new CRL on a regular periodic basis (e.g., hourly, daily, or
	weekly). An entry is added to the CRL as part of the next update		weekly). An entry is added to the CRL as part of the next update
	following notification of revocation. An entry may be removed from		following notification of revocation. An entry MUST NOT be removed
	the CRL after appearing on one regularly scheduled CRL issued beyond		from the CRL until it appears on one regularly scheduled CRL issued
	the revoked certificate's validity period.		beyond the revoked certificate's validity period.
	An advantage of this revocation method is that CRLs may be		An advantage of this revocation method is that CRLs may be
	distributed by exactly the same means as certificates themselves,		distributed by exactly the same means as certificates themselves,
	namely, via untrusted servers and untrusted communications.		namely, via untrusted servers and untrusted communications.
	One limitation of the CRL revocation method, using untrusted		One limitation of the CRL revocation method, using untrusted
	communications and servers, is that the time granularity of		communications and servers, is that the time granularity of
	revocation is limited to the CRL issue period. For example, if a		revocation is limited to the CRL issue period. For example, if a
	revocation is reported now, that revocation will not be reliably		revocation is reported now, that revocation will not be reliably
	notified to certificate-using systems until all currently issued CRLs		notified to certificate-using systems until all currently issued CRLs
	skipping to change at page 36, line 15 ¶		skipping to change at page 36, line 15 ¶
	When the subjectAltName extension contains a DN in the directoryName,		When the subjectAltName extension contains a DN in the directoryName,
	the DN MUST be unique for each subject entity certified by the one CA		the DN MUST be unique for each subject entity certified by the one CA
	as defined by the issuer name field. A CA MAY issue more than one		as defined by the issuer name field. A CA MAY issue more than one
	certificate with the same DN to the same subject entity.		certificate with the same DN to the same subject entity.
	The subjectAltName MAY carry additional name types through the use of		The subjectAltName MAY carry additional name types through the use of
	the otherName field. The format and semantics of the name are		the otherName field. The format and semantics of the name are
	indicated through the OBJECT IDENTIFIER in the type-id field. The		indicated through the OBJECT IDENTIFIER in the type-id field. The
	name itself is conveyed as value field in otherName. For example,		name itself is conveyed as value field in otherName. For example,
	Kerberos [RFC 1510] format names can be encoded into the otherName,		Kerberos [RFC 1510] format names can be encoded into the otherName,
	using the krb5PrincipalName OID and the KerberosName syntax as		using using a Kerberos 5 principal name OID and a SEQUENCE of the
	defined in [PKINIT].		Realm and the PrincipalName.
	Subject alternative names MAY be constrained in the same manner as		Subject alternative names MAY be constrained in the same manner as
	subject distinguished names using the name constraints extension as		subject distinguished names using the name constraints extension as
	described in section 4.2.1.11.		described in section 4.2.1.11.
	If the subjectAltName extension is present, the sequence MUST contain		If the subjectAltName extension is present, the sequence MUST contain
	at least one entry. Unlike the subject field, conforming CAs MUST		at least one entry. Unlike the subject field, conforming CAs MUST
	NOT issue certificates with subjectAltNames containing empty		NOT issue certificates with subjectAltNames containing empty
	GeneralName fields. For example, an rfc822Name is represented as an		GeneralName fields. For example, an rfc822Name is represented as an
	IA5String. While an empty string is a valid IA5String, such an		IA5String. While an empty string is a valid IA5String, such an
	skipping to change at page 41, line 48 ¶		skipping to change at page 41, line 48 ¶
	field is defined as follows:		field is defined as follows:
	id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }		id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
	ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId		ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
	KeyPurposeId ::= OBJECT IDENTIFIER		KeyPurposeId ::= OBJECT IDENTIFIER
	Key purposes may be defined by any organization with a need. Object		Key purposes may be defined by any organization with a need. Object
	identifiers used to identify key purposes MUST be assigned in		identifiers used to identify key purposes MUST be assigned in
	accordance with IANA or ITU-T Recommendation X.660.		accordance with IANA or ITU-T Recommendation X.660. [X.660]
	This extension MAY, at the option of the certificate issuer, be		This extension MAY, at the option of the certificate issuer, be
	either critical or non-critical.		either critical or non-critical.
	If the extension is flagged critical, then the certificate MUST only		If the extension is flagged critical, then the certificate MUST only
	be used for one of the purposes indicated. If multiple purposes are		be used for one of the purposes indicated. If multiple purposes are
	indicated the application need not recognize all purposes indicated,		indicated the application need not recognize all purposes indicated,
	as long as the intended purpose is present and recognized.		as long as the intended purpose is present and recognized.
	If the extension is flagged non-critical, then it indicates the		If the extension is flagged non-critical, then it indicates the
	skipping to change at page 64, line 15 ¶		skipping to change at page 64, line 15 ¶
	(a) for all x in {1, ..., n-1}, the subject of certificate x is		(a) for all x in {1, ..., n-1}, the subject of certificate x is
	the issuer of certificate x+1;		the issuer of certificate x+1;
	(b) certificate 1 is issued by the trust anchor;		(b) certificate 1 is issued by the trust anchor;
	(c) certificate n is the certificate to be validated; and		(c) certificate n is the certificate to be validated; and
	(d) for all x in {1, ..., n}, the certificate was valid at the		(d) for all x in {1, ..., n}, the certificate was valid at the
	time in question.		time in question.
			When the trust anchor is provided in the form of a self-signed
			certificate, this self-signed certificate is not included as part of
			the prospective certification path. Information about trust anchors
			are provided as inputs to the certification path validation algorithm
			(section 6.1.1).
	A particular certification path may not, however, be appropriate for		A particular certification path may not, however, be appropriate for
	all applications. Therefore, an application MAY augment this		all applications. Therefore, an application MAY augment this
	algorithm to further limit the set of valid paths. The path		algorithm to further limit the set of valid paths. The path
	validation process also determines the set of certificate policies		validation process also determines the set of certificate policies
	that are valid for this path, based on the certificate policies		that are valid for this path, based on the certificate policies
	extension, policy mapping extension, policy constraints extension,		extension, policy mapping extension, policy constraints extension,
	and inhibit any-policy extension. To achieve this, the path		and inhibit any-policy extension. To achieve this, the path
	validation algorithm constructs a valid policy tree. If the set of		validation algorithm constructs a valid policy tree. If the set of
	certificate policies that are valid for this path is not empty, then		certificate policies that are valid for this path is not empty, then
	the result will be a valid policy tree of depth n, otherwise the		the result will be a valid policy tree of depth n, otherwise the
	skipping to change at page 66, line 26 ¶		skipping to change at page 66, line 33 ¶
	parameters, then the parameters are provided along with the		parameters, then the parameters are provided along with the
	trusted public key.		trusted public key.
	(e) initial-policy-mapping-inhibit, which indicates if policy		(e) initial-policy-mapping-inhibit, which indicates if policy
	mapping is allowed in the certification path.		mapping is allowed in the certification path.
	(f) initial-explicit-policy, which indicates if the path must be		(f) initial-explicit-policy, which indicates if the path must be
	valid for at least one of the certificate policies in the user-		valid for at least one of the certificate policies in the user-
	initial-policy-set.		initial-policy-set.
	(g) initial-any-policy-inhibit, which indicates whether the any-		(g) initial-any-policy-inhibit, which indicates whether the
	policy OID should be processed if it is included in a certificate.		anyPolicy OID should be processed if it is included in a
			certificate.
	6.1.2 Initialization		6.1.2 Initialization
	The initialization phase establishes eleven state variables based		The initialization phase establishes eleven state variables based
	upon the seven inputs:		upon the seven inputs:
	(a) valid_policy_tree: A tree of certificate policies with their		(a) valid_policy_tree: A tree of certificate policies with their
	optional qualifiers; each of the leaves of the tree represents a		optional qualifiers; each of the leaves of the tree represents a
	valid policy at this stage in the certification path validation.		valid policy at this stage in the certification path validation.
	If valid policies exist at this stage in the certification path		If valid policies exist at this stage in the certification path
	skipping to change at page 69, line 16 ¶		skipping to change at page 69, line 23 ¶
	decremented for each non-self-issued certificate in the path, and		decremented for each non-self-issued certificate in the path, and
	may be reduced to the value in the path length constraint field		may be reduced to the value in the path length constraint field
	within the basic constraints extension of a CA certificate.		within the basic constraints extension of a CA certificate.
	Upon completion of the initialization steps, perform the basic		Upon completion of the initialization steps, perform the basic
	certificate processing steps specified in 6.1.3.		certificate processing steps specified in 6.1.3.
	6.1.3 Basic Certificate Processing		6.1.3 Basic Certificate Processing
	The basic path processing actions to be performed for certificate i		The basic path processing actions to be performed for certificate i
	are listed below.		(for all i in [1..n]) are listed below.
	(a) Verify the basic certificate information. The certificate		(a) Verify the basic certificate information. The certificate
	MUST satisfy each of the following:		MUST satisfy each of the following:
	(1) The certificate was signed with the		(1) The certificate was signed with the
	working_public_key_algorithm using the working_public_key and		working_public_key_algorithm using the working_public_key and
	the working_public_key_parameters.		the working_public_key_parameters.
	(2) The certificate validity period includes the current time.		(2) The certificate validity period includes the current time.
	skipping to change at page 72, line 32 ¶		skipping to change at page 72, line 32 ¶
	|-----------------| nodes of |-----------------|		|-----------------| nodes of |-----------------|
	| uninitialized | depth i | uninitialized |		| uninitialized | depth i | uninitialized |
	|-----------------| |-----------------|		|-----------------| |-----------------|
	| {Gold} | | {Silver} |		| {Gold} | | {Silver} |
	|-----------------| |-----------------|		|-----------------| |-----------------|
	Figure 5. Processing unmatched policies when a leaf node		Figure 5. Processing unmatched policies when a leaf node
	specifies any-policy		specifies any-policy
	(2) If the certificate policies extension includes the policy		(2) If the certificate policies extension includes the policy
	any-policy with the qualifier set AP-Q and inhibit_any-policy		anyPolicy with the qualifier set AP-Q and inhibit_any-policy is
	is greater than 0, then:		greater than 0, then:
	For each node in the valid_policy_tree of depth i-1, for each		For each node in the valid_policy_tree of depth i-1, for each
	value in the expected_policy_set (including any-policy) that		value in the expected_policy_set (including any-policy) that
	does not appear in a child node, create a child node with the		does not appear in a child node, create a child node with the
	following values: set the valid_policy to the value from the		following values: set the valid_policy to the value from the
	expected_policy_set in the parent node; set the qualifier_set		expected_policy_set in the parent node; set the qualifier_set
	to AP-Q, and set the expected_policy_set to the value in the		to AP-Q, and set the expected_policy_set to the value in the
	valid_policy from this node.		valid_policy from this node.
	For example, consider a valid_policy_tree with a node of depth		For example, consider a valid_policy_tree with a node of depth
	skipping to change at page 77, line 39 ¶		skipping to change at page 77, line 39 ¶
	keyCertSign bit is set.		keyCertSign bit is set.
	(o) Recognize and process any other critical extension present in		(o) Recognize and process any other critical extension present in
	the certificate. Process any other recognized non-critical		the certificate. Process any other recognized non-critical
	extension present in the certificate.		extension present in the certificate.
	If check (a), (k), (l), (n) or (o) fails, the procedure terminates,		If check (a), (k), (l), (n) or (o) fails, the procedure terminates,
	returning a failure indication and an appropriate reason.		returning a failure indication and an appropriate reason.
	If (a), (k), (l), (n) and (o) have completed successfully, increment		If (a), (k), (l), (n) and (o) have completed successfully, increment
	i and perform the basic certificate processing specified in 6.1.2.		i and perform the basic certificate processing specified in 6.1.3.
	6.1.5 Wrap-up procedure		6.1.5 Wrap-up procedure
	To complete the processing of the end entity certificate, perform the		To complete the processing of the end entity certificate, perform the
	following steps for certificate n:		following steps for certificate n:
	(a) If certificate n was not self-issued and explicit_policy is		(a) If certificate n was not self-issued and explicit_policy is
	not 0, decrement explicit_policy by 1.		not 0, decrement explicit_policy by 1.
	(b) If a policy constraints extension is included in the		(b) If a policy constraints extension is included in the
	skipping to change at page 78, line 41 ¶		skipping to change at page 78, line 41 ¶
	(ii) If the valid_policy_tree is not NULL and the user-		(ii) If the valid_policy_tree is not NULL and the user-
	initial-policy-set is any-policy, the intersection is the		initial-policy-set is any-policy, the intersection is the
	entire valid_policy_tree.		entire valid_policy_tree.
	(iii) If the valid_policy_tree is not NULL and the user-		(iii) If the valid_policy_tree is not NULL and the user-
	initial-policy-set is not any-policy, calculate the		initial-policy-set is not any-policy, calculate the
	intersection of the valid_policy_tree and the user-initial-		intersection of the valid_policy_tree and the user-initial-
	policy-set as follows:		policy-set as follows:
	1. Determine the set of policy nodes whose ancestor nodes		1. Determine the set of policy nodes whose parent nodes
	have a valid_policy of any-policy. This is the		have a valid_policy of any-policy. This is the
	valid_policy_node_set.		valid_policy_node_set.
	2. If the valid_policy of any node in the		2. If the valid_policy of any node in the
	valid_policy_node_set is not in the user-initial-policy-set		valid_policy_node_set is not in the user-initial-policy-set
	and is not any-policy, delete this node and all its		and is not any-policy, delete this node and all its
	children.		children.
	3. If there is a node in the valid_policy_tree of depth n-1		3. If there is a node in the valid_policy_tree of depth n-1
	or less without any child nodes, delete that node. Repeat		or less without any child nodes, delete that node. Repeat
	skipping to change at page 85, line 43 ¶		skipping to change at page 85, line 43 ¶
	RFC 1778, March 1995.		RFC 1778, March 1995.
	[RFC 1883] Deering, S., and R. Hinden. "Internet Protocol,		[RFC 1883] Deering, S., and R. Hinden. "Internet Protocol,
	Version 6 (IPv6) Specification", RFC 1883, December		Version 6 (IPv6) Specification", RFC 1883, December
	1995.		1995.
	[RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of		[RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of
	Unicode and ISO 10646", RFC 2044, October 1996.		Unicode and ISO 10646", RFC 2044, October 1996.
	[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		Requirement Levels", RFC 2119, March 1997.
	[RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber, and		[RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber, and
	S. Sataluri, "Using Domains in LDAP/X.500		S. Sataluri, "Using Domains in LDAP/X.500
	Distinguished Names", RFC 2247, January 1998.		Distinguished Names", RFC 2247, January 1998.
	[RFC 2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,		[RFC 2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
	"Lightweight Directory Access Protocol (v3):		"Lightweight Directory Access Protocol (v3):
	Attribute Syntax Definitions", RFC 2252,		Attribute Syntax Definitions", RFC 2252,
	December 1997.		December 1997.
	skipping to change at page 86, line 38 ¶		skipping to change at page 86, line 38 ¶
	Directory: Models, 1993.		Directory: Models, 1993.
	[X.509] ITU-T Recommendation X.509 (1997 E): Information		[X.509] ITU-T Recommendation X.509 (1997 E): Information
	Technology - Open Systems Interconnection - The		Technology - Open Systems Interconnection - The
	Directory: Authentication Framework, June 1997.		Directory: Authentication Framework, June 1997.
	[X.520] ITU-T Recommendation X.520: Information		[X.520] ITU-T Recommendation X.520: Information
	Technology - Open Systems Interconnection - The		Technology - Open Systems Interconnection - The
	Directory: Selected Attribute Types, 1993.		Directory: Selected Attribute Types, 1993.
	[X.660] ITU-T Recommendation X.660: [*** Get Info ***]		[X.660] ITU-T Recommendation X.660 Information
			Technology - Open Systems Interconnection -
			Procedures for the operation of OSI
			Registration Authorities: General procedures, 1992.
	[X9.55] ANSI X9.55-1995, Public Key Cryptography For The		[X9.55] ANSI X9.55-1995, Public Key Cryptography For The
	Financial Services Industry: Extensions To Public		Financial Services Industry: Extensions To Public
	Key Certificates And Certificate Revocation Lists,		Key Certificates And Certificate Revocation Lists,
	8 December, 1995.		8 December, 1995.
	[PKINIT] Tung, B., C. Neuman, M. Hur, A. Medvinsky,
	S. Medvinsky, J. Wray, and J. Trostle, "Public Key
	Cryptography for Initial Authentciaion in Kerberos,"
	draft-ietf-cat-kerberos-pk-init-13.txt, March 2001.
	[PKIXALGS] Bassham, L., R. Housley, and W. Polk, "Internet X.509		[PKIXALGS] Bassham, L., R. Housley, and W. Polk, "Internet X.509
	Public Key Infrastructure Representation of Public Keys		Public Key Infrastructure Representation of Public Keys
	and Digital Signatures,"		and Digital Signatures,"
	draft-ietf-pkix-ipki-pkalgs-02.txt, March 2001.		draft-ietf-pkix-ipki-pkalgs-02.txt, March 2001.
	[PKIXTSA] Cain, P., D. Pinkas, and R. Zuccherato, "Internet		[PKIXTSA] Cain, P., D. Pinkas, and R. Zuccherato, "Internet
	X.509 Public Key Infrastructure Time Stamp Protocol,"		X.509 Public Key Infrastructure Time Stamp Protocol,"
	draft-ietf-pkix-time-stamp-13.txt, January 2001.		draft-ietf-pkix-time-stamp-13.txt, January 2001.
	8 Intellectual Property Rights		8 Intellectual Property Rights
End of changes. 16 change blocks.
	25 lines changed or deleted		30 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/