< draft-dusse-smime-cert-04.txt		draft-dusse-smime-cert-05.txt >
	Internet Draft Steve Dusse,		Internet Draft Steve Dusse,
	draft-dusse-smime-cert-04.txt RSA Data Security		draft-dusse-smime-cert-05.txt RSA Data Security
	October 19, 1997 Paul Hoffman,		November 08, 1997 Paul Hoffman,
	Expires in six months Internet Mail Consortium		Expires in six months Internet Mail Consortium
	Blake Ramsdell,		Blake Ramsdell,
	Worldtalk		Worldtalk
	Jeff Weinstein,		Jeff Weinstein,
	Netscape		Netscape
	S/MIME Certificate Handling		S/MIME Certificate Handling
	Status of this memo		Status of this memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working documents
	documents of the Internet Engineering Task Force (IETF), its areas,		of the Internet Engineering Task Force (IETF), its areas, and its working
	and its working groups. Note that other groups may also distribute		groups. Note that other groups may also distribute working documents as
	working documents as Internet-Drafts.		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
	and may be updated, replaced, or obsoleted by other documents at any		may be updated, replaced, or obsoleted by other documents at any time. It
	time. It is inappropriate to use Internet-Drafts as reference material		is inappropriate to use Internet-Drafts as reference material or to cite
	or to cite them other than as "work in progress."		them other than as "work in progress."
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, 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), nic.nordu.net (Europe),		Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or		(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West
	ftp.isi.edu (US West Coast).		Coast).
	1. Overview		1. Overview
	S/MIME (Secure/Multipurpose Internet Mail Extensions), described in		S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
	[SMIME-MSG], provides a method to send and receive secure MIME		[SMIME-MSG], provides a method to send and receive secure MIME messages. In
	messages. In order to validate the keys of a message sent to it, an		order to validate the keys of a message sent to it, an S/MIME agent needs
	S/MIME agent needs to certify that the key is valid. This draft		to certify that the key is valid. This draft describes the mechanisms
	describes the mechanisms S/MIME uses to create and validate keys using		S/MIME uses to create and validate keys using certificates.
	certificates.
	This specification is compatible with PKCS #7 in that it uses the data		This specification is compatible with PKCS #7 in that it uses the data
	types defined by PKCS #7. It also inherits all the varieties of		types defined by PKCS #7. It also inherits all the varieties of
	architectures for certificate-based key management supported by PKCS		architectures for certificate-based key management supported by PKCS #7.
	#7. Note that the method S/MIME messages make certificate requests is		Note that the method S/MIME messages make certificate requests is defined
	defined in [SMIME-MSG].		in [SMIME-MSG].
	In order to handle S/MIME certificates, an agent has to follow		In order to handle S/MIME certificates, an agent has to follow
	specifications in this draft, as well as some of the specifications		specifications in this draft, as well as some of the specifications listed
	listed in the following documents:		in the following documents:
	- "PKCS #1: RSA Encryption", [PKCS-1].		- "PKCS #1: RSA Encryption", [PKCS-1].
	- "PKCS #7: Cryptographic Message Syntax", [PKCS-7]		- "PKCS #7: Cryptographic Message Syntax", [PKCS-7]
	- "PKCS #10: Certification Request Syntax", [PKCS-10].		- "PKCS #10: Certification Request Syntax", [PKCS-10].
	1.1 Definitions		1.1 Definitions
	For the purposes of this draft, the following definitions apply.		For the purposes of this draft, the following definitions apply.
	ASN.1: Abstract Syntax Notation One, as defined in CCITT X.680-689.		ASN.1: Abstract Syntax Notation One, as defined in CCITT X.680-689.
	BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.690.		BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.690.
	Certificate: A type that binds an entity's distinguished name to a		Certificate: A type that binds an entity's distinguished name to a public
	public key with a digital signature. This type is defined in CCITT		key with a digital signature. This type is defined in CCITT X.509 [X.509].
	X.509 [X.509]. This type also contains the distinguished name of the		This type also contains the distinguished name of the certificate issuer
	certificate issuer (the signer), an issuer-specific serial number, the		(the signer), an issuer-specific serial number, the issuer's signature
	issuer's signature algorithm identifier, and a validity period.		algorithm identifier, and a validity period.
	Certificate Revocation List (CRL): A type that contains information		Certificate Revocation List (CRL): A type that contains information about
	about certificates whose validity an issuer has prematurely revoked.		certificates whose validity an issuer has prematurely revoked. The
	The information consists of an issuer name, the time of issue, the		information consists of an issuer name, the time of issue, the next
	next scheduled time of issue, and a list of certificate serial numbers		scheduled time of issue, and a list of certificate serial numbers and their
	and their associated revocation times. The CRL is signed by the		associated revocation times. The CRL is signed by the issuer. The type
	issuer. The type intended by this specification is the one defined in		intended by this specification is the one defined in [KEYM].
	[KEYM].
	DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT		DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT X.690.
	X.690.
	1.2 Compatibility with Prior Practice of S/MIME		1.2 Compatibility with Prior Practice of S/MIME
	Appendix C contains important information about how S/MIME agents		Appendix C contains important information about how S/MIME agents following
	following this specification should act in order to have the greatest		this specification should act in order to have the greatest
	interoperability with earlier implementations of S/MIME.		interoperability with earlier implementations of S/MIME.
	1.3 Terminology		1.3 Terminology
	Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD		Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are
	NOT are used in capital letters. This conforms to the definitions in		used in capital letters. This conforms to the definitions in [MUSTSHOULD].
	[MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help		[MUSTSHOULD] defines the use of these key words to help make the intent of
	make the intent of standards track documents as clear as possible. The		standards track documents as clear as possible. The same key words are used
	same key words are used in this document to help implementors achieve		in this document to help implementors achieve interoperability.
	interoperability.
	1.4 Discussion of This Draft		1.4 Discussion of This Draft
	This draft is being discussed on the "ietf-smime" mailing list.		This draft is being discussed on the "ietf-smime" mailing list.
	To subscribe, send a message to:		To subscribe, send a message to:
	ietf-smime-request@imc.org		ietf-smime-request@imc.org
	with the single word		with the single word
	subscribe		subscribe
	in the body of the message. There is a Web site for the mailing list		in the body of the message. There is a Web site for the mailing list
	at <http://www.imc.org/ietf-smime/>.		at <http://www.imc.org/ietf-smime/>.
	2. PKCS #7 Options		2. PKCS #7 Options
	The PKCS #7 message format allows for a wide variety of options in		The PKCS #7 message format allows for a wide variety of options in content
	content and algorithm support. This section puts forth a number of		and algorithm support. This section puts forth a number of support
	support requirements and recommendations in order to achieve a base		requirements and recommendations in order to achieve a base level of
	level of interoperability among all S/MIME implementations. Most of		interoperability among all S/MIME implementations. Most of the PKCS #7
	the PKCS #7 format for S/MIME messages is defined in [SMIME-MSG].		format for S/MIME messages is defined in [SMIME-MSG].
	2.1 CertificateRevocationLists		2.1 CertificateRevocationLists
	Receiving agents MUST support for the Certificate Revocation List		Receiving agents MUST support for the Certificate Revocation List (CRL)
	(CRL) format defined in [KEYM]. If sending agents include CRLs in		format defined in [KEYM]. If sending agents include CRLs in outgoing
	outgoing messages, the CRL format defined in [KEYM] MUST be used.		messages, the CRL format defined in [KEYM] MUST be used.
	All agents MUST validate CRLs and check certificates against CRLs, if		All agents MUST validate CRLs and check certificates against CRLs, if
	available, in accordance with [KEYM]. All agents SHOULD check the		available, in accordance with [KEYM]. All agents SHOULD check the
	nextUpdate field in the CRL against the current time. If the current		nextUpdate field in the CRL against the current time. If the current time
	time is later than the nextUpdate time, the action that the agent		is later than the nextUpdate time, the action that the agent takes is a
	takes is a local decision. For instance, it could warn a human user,		local decision. For instance, it could warn a human user, it could
	it could retrieve a new CRL if able, and so on.		retrieve a new CRL if able, and so on.
	Receiving agents MUST recognize CRLs in received S/MIME messages.		Receiving agents MUST recognize CRLs in received S/MIME messages.
	Clients MUST use revocation information included as a CRL in an S/MIME		Clients MUST use revocation information included as a CRL in an S/MIME
	message when verifying the signature and certificate path validity in		message when verifying the signature and certificate path validity in that
	that message. Clients SHOULD store CRLs received in messages for use		message. Clients SHOULD store CRLs received in messages for use in
	in processing later messages.		processing later messages.
	Clients MUST handle multiple valid Certificate Authority (CA)		Clients MUST handle multiple valid Certificate Authority (CA) certificates
	certificates containing the same subject name and the same public keys		containing the same subject name and the same public keys but with
	but with overlapping validity intervals.		overlapping validity intervals.
	2.2 ExtendedCertificateOrCertificate		2.2 ExtendedCertificateOrCertificate
	Receiving agents MUST support X.509 v1 and X.509 v3 certificates. See		Receiving agents MUST support X.509 v1 and X.509 v3 certificates. See
	[KEYM] for details about the profile for certificate formats.		[KEYM] for details about the profile for certificate formats. End entity
	Certificates MUST include an Internet mail address, as described in		certificates MUST include an Internet mail address, as described in section
	section 3.1.		3.1.
	2.2.1 Historical Note About PKCS #7 Certificates		2.2.1 Historical Note About PKCS #7 Certificates
	The PKCS #7 message format supports a choice of certificate two		The PKCS #7 message format supports a choice of certificate two formats for
	formats for public key content types: X.509 and PKCS #6 Extended		public key content types: X.509 and PKCS #6 Extended Certificates. The PKCS
	Certificates. The PKCS #6 format is not in widespread use. In		#6 format is not in widespread use. In addition, proposed revisions of
	addition, proposed revisions of X.509 certificates address much of the		X.509 certificates address much of the same functionality and flexibility
	same functionality and flexibility as was intended in the PKCS #6.		as was intended in the PKCS #6. Thus, sending and receiving agents MUST NOT
	Thus, sending and receiving agents MUST NOT use PKCS #6 extended		use PKCS #6 extended certificates.
	certificates.
	2.3 ExtendedCertificateAndCertificates		2.3 ExtendedCertificateAndCertificates
	Receiving agents MUST be able to handle an arbitrary number of		Receiving agents MUST be able to handle an arbitrary number of certificates
	certificates of arbitrary relationship to the message sender and to		of arbitrary relationship to the message sender and to each other in
	each other in arbitrary order. In many cases, the certificates		arbitrary order. In many cases, the certificates included in a signed
	included in a signed message may represent a chain of certification		message may represent a chain of certification from the sender to a
	from the sender to a particular root. There may be, however,		particular root. There may be, however, situations where the certificates
	situations where the certificates in a signed message may be unrelated		in a signed message may be unrelated and included for convenience.
	and included for convenience.
	Certificates MUST include an Internet mail address, as described in
	section 3.1.
	Sending agents SHOULD include any certificates for the user's public		Sending agents SHOULD include any certificates for the user's public key(s)
	key(s) and associated issuer certificates. This increases the		and associated issuer certificates. This increases the likelihood that the
	likelihood that the intended recipient can establish trust in the		intended recipient can establish trust in the originator's public key(s).
	originator's public key(s). This is especially important when sending		This is especially important when sending a message to recipients that may
	a message to recipients that may not have access to the sender's		not have access to the sender's public key through any other means or when
	public key through any other means or when sending a signed message to		sending a signed message to a new recipient. The inclusion of certificates
	a new recipient. The inclusion of certificates in outgoing messages		in outgoing messages can be omitted if S/MIME objects are sent within a
	can be omitted if S/MIME objects are sent within a group of		group of correspondents that has established access to each other's
	correspondents that has established access to each other's
	certificates by some other means such as a shared directory or manual		certificates by some other means such as a shared directory or manual
	certificate distribution. Receiving S/MIME agents SHOULD be able to		certificate distribution. Receiving S/MIME agents SHOULD be able to handle
	handle messages without certificates using a database or directory		messages without certificates using a database or directory lookup scheme.
	lookup scheme.
	A sending agent SHOULD include at least one chain of certificates up		A sending agent SHOULD include at least one chain of certificates up to,
	to, but not including, a Certificate Authority (CA) that it believes		but not including, a Certificate Authority (CA) that it believes that the
	that the recipient may trust as authoritative. A receiving agent		recipient may trust as authoritative. A receiving agent SHOULD be able to
	SHOULD be able to handle an arbitrarily large number of certificates		handle an arbitrarily large number of certificates and chains.
	and chains.
	Clients MAY send CA certificates, that is, certificates that are		Clients MAY send CA certificates, that is, certificates that are
	self-signed and can be considered the "root" of other chains. Note		self-signed and can be considered the "root" of other chains. Note that
	that receiving agents SHOULD NOT simply trust any self-signed		receiving agents SHOULD NOT simply trust any self-signed certificates as
	certificates as valid CAs, but SHOULD use some other mechanism to		valid CAs, but SHOULD use some other mechanism to determine if this is a CA
	determine if this is a CA that should be trusted.		that should be trusted.
	Receiving agenst MUST support chaining based on the distinguished name		Receiving agents MUST support chaining based on the distinguished name
	and SHOULD support chaining based on the subjectAltName field.		fields. Other methods of building certificate chains may be supported but
			are not currently recommended.
	3. Distinguished Names in Certificates		3. Distinguished Names in Certificates
	3.1 Using Distinguished Names for Internet Mail		3.1 Using Distinguished Names for Internet Mail
	The format of an X.509 certificate includes fields for the subject		The format of an X.509 certificate includes fields for the subject name and
	name and issuer name. The subject name identifies the owner of a		issuer name. The subject name identifies the owner of a particular public
	particular public key/private key pair while the issuer name is meant		key/private key pair while the issuer name is meant to identify the entity
	to identify the entity that "certified" the subject (that is, who		that "certified" the subject (that is, who signed the subject's
	signed the subject's certificate). The subject name and issuer name		certificate). The subject name and issuer name are defined by X.509 as
	are defined by X.509 as Distinguished Names.		Distinguished Names.
	Distinguished Names are defined by a CCITT standard X.501 [X.501]. A		Distinguished Names are defined by a CCITT standard X.501 [X.501]. A
	Distinguished Name is broken into one or more Relative Distinguished		Distinguished Name is broken into one or more Relative Distinguished Names.
	Names. Each Relative Distinguished Name is comprised of one or more		Each Relative Distinguished Name is comprised of one or more
	Attribute-Value Assertions. Each Attribute-Value Assertion consists of		Attribute-Value Assertions. Each Attribute-Value Assertion consists of a
	a Attribute Identifier and its corresponding value information, such		Attribute Identifier and its corresponding value information, such as
	as CountryName=US. Distinguished Names were intended to identify		CountryName=US. Distinguished Names were intended to identify entities in
	entities in the X.500 directory tree [X.500]. Each Relative		the X.500 directory tree [X.500]. Each Relative Distinguished Name can be
	Distinguished Name can be thought of as a node in the tree which is		thought of as a node in the tree which is described by some collection of
	described by some collection of Attribute-Value Assertions. The entire		Attribute-Value Assertions. The entire Distinguished Name is some
	Distinguished Name is some collection of nodes in the tree that		collection of nodes in the tree that traverse a path from the root of the
	traverse a path from the root of the tree to some end node which		tree to some end node which represents a particular entity.
	represents a particular entity.
	The goal of the directory was to provide an infrastructure to uniquely		The goal of the directory was to provide an infrastructure to uniquely name
	name every communications entity everywhere. However, adoption of a		every communications entity everywhere. However, adoption of a global X.500
	global X.500 directory infrastructure has been slower than expected.		directory infrastructure has been slower than expected. Consequently, there
	Consequently, there is no requirement for X.500 directory service		is no requirement for X.500 directory service provision in the S/MIME
	provision in the S/MIME environment, although such provision would		environment, although such provision would almost undoubtedly be of great
	almost undoubtedly be of great value in facilitating key management		value in facilitating key management for S/MIME.
	for S/MIME.
	The use of Distinguished Names in accordance with the X.500 directory		The use of Distinguished Names in accordance with the X.500 directory is
	is not very widespread. By contrast, Internet mail addresses, as		not very widespread. By contrast, Internet mail addresses, as described in
	described in RFC 822 [RFC-822], are used almost exclusively in the		RFC 822 [RFC-822], are used almost exclusively in the Internet environment
	Internet environment to identify originators and recipients of		to identify originators and recipients of messages. However, Internet mail
	messages. However, Internet mail addresses bear no resemblance to		addresses bear no resemblance to X.500 Distinguished Names (except,
	X.500 Distinguished Names (except, perhaps, that they are both		perhaps, that they are both hierarchical in nature). Some method is needed
	hierarchical in nature). Some method is needed to map Internet mail		to map Internet mail addresses to entities that hold public keys. Some
	addresses to entities that hold public keys. Some people have		people have suggested that the X.509 certificate format should be abandoned
	suggested that the X.509 certificate format should be abandoned in		in favor of other binding mechanisms. Instead, S/MIME keeps the X.509
	favor of other binding mechanisms. Instead, S/MIME keeps the X.509		certificate and Distinguished Name mechanisms while tailoring the content
	certificate and Distinguished Name mechanisms while tailoring the		of the naming information to suit the Internet mail environment.
	content of the naming information to suit the Internet mail
	environment.
	End-entity certificates MUST contain an Internet mail address as		End-entity certificates MUST contain an Internet mail address as described
	described in [RFC-822]. The address must be an "addr-spec" as defined		in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1
	in Section 6.1 of that specification.		of that specification.
	Receiving agents MUST recognize email addresses in the subjectAltName		Receiving agents MUST recognize email addresses in the subjectAltName
	field. Receiving agents MUST recognize email addresses in the		field. Receiving agents MUST recognize email addresses in the Distinguished
	Distinguished Name field.		Name field.
	Sending agents SHOULD make the address in the From header in a mail		Sending agents SHOULD make the address in the From header in a mail message
	message match an Internet mail address in the signer's certificate.		match an Internet mail address in the signer's certificate. Receiving
	Receiving agents MUST check that the address in the From header of a		agents MUST check that the address in the From header of a mail message
	mail message matches an Internet mail address in the signer's		matches an Internet mail address in the signer's certificate. A receiving
	certificate. A receiving agent MUST provide some explicit alternate		agent MUST provide some explicit alternate processing of the message if
	processing of the message if this comparison fails, which may be to		this comparison fails, which may be to reject the message.
	reject the message.
	3.2 Required Name Attributes		3.2 Required Name Attributes
	Receiving agents MUST support parsing of zero, one, or more instances		Receiving agents MUST support parsing of zero, one, or more instances of
	of each of the following set of name attributes within the		each of the following set of name attributes within the Distinguished Names
	Distinguished Names in certificates.		in certificates.
	Sending agents SHOULD include the Internet mail address during		Sending agents MUST include the Internet mail address during Distinguished
	Distinguished Name creation. Guidelines for the inclusion, omission,		Name creation. Guidelines for the inclusion, omission, and ordering of the
	and ordering of the remaining name attributes during the creation of a		remaining name attributes during the creation of a distinguished name will
	distinguished name will most likely be dictated by the policies		most likely be dictated by the policies associated with the certification
	associated with the certification service which will certify the		service which will certify the corresponding name and public key.
	corresponding name and public key.
	CountryName		CountryName
	StateOrProvinceName		StateOrProvinceName
	Locality		Locality
	CommonName		CommonName
	Title		Title
	Organization		Organization
	OrganizationalUnit		OrganizationalUnit
	StreetAddress		StreetAddress
	PostalCode		PostalCode
	PhoneNumber		PhoneNumber
	EmailAddress		EmailAddress
	All attributes other than EmailAddress are described in X.520 [X.520].		All attributes other than EmailAddress are described in X.520 [X.520].
	EmailAddress is an IA5String that can have multiple attribute values.		EmailAddress is an IA5String that can have multiple attribute values.
	4. Certificate Processing		4. Certificate Processing
	A receiving agent needs to provide some certificate retrieval		A receiving agent needs to provide some certificate retrieval mechanism in
	mechanism in order to gain access to certificates for recipients of		order to gain access to certificates for recipients of digital envelopes.
	digital envelopes. There are many ways to implement certificate		There are many ways to implement certificate retrieval mechanisms. X.500
	retrieval mechanisms. X.500 directory service is an excellent example		directory service is an excellent example of a certificate retrieval-only
	of a certificate retrieval-only mechanism that is compatible with		mechanism that is compatible with classic X.500 Distinguished Names. The
	classic X.500 Distinguished Names. The PKIX Working Group is		PKIX Working Group is investigating other mechanisms. Another method under
	investigating other mechanisms. Another method under consideration by		consideration by the IETF is to provide certificate retrieval services as
	the IETF is to provide certificate retrieval services as part of the		part of the existing Domain Name System (DNS). Until such mechanisms are
	existing Domain Name System (DNS). Until such mechanisms are widely		widely used, their utility may be limited by the small number of
	used, their utility may be limited by the small number of
	correspondent's certificates that can be retrieved. At a minimum, for		correspondent's certificates that can be retrieved. At a minimum, for
	initial S/MIME deployment, a user agent could automatically generate a		initial S/MIME deployment, a user agent could automatically generate a
	message to an intended recipient requesting that recipient's		message to an intended recipient requesting that recipient's certificate in
	certificate in a signed return message.		a signed return message.
	Receiving and sending agents SHOULD also provide a mechanism to allow		Receiving and sending agents SHOULD also provide a mechanism to allow a
	a user to "store and protect" certificates for correspondents in such		user to "store and protect" certificates for correspondents in such a way
	a way so as to guarantee their later retrieval. In many environments,		so as to guarantee their later retrieval. In many environments, it may be
	it may be desirable to link the certificate retrieval/storage		desirable to link the certificate retrieval/storage mechanisms together in
	mechanisms together in some sort of certificate database. In its		some sort of certificate database. In its simplest form, a certificate
	simplest form, a certificate database would be local to a particular		database would be local to a particular user and would function in a
	user and would function in a similar way as a "address book" that		similar way as a "address book" that stores a user's frequent
	stores a user's frequent correspondents. In this way, the certificate		correspondents. In this way, the certificate retrieval mechanism would be
	retrieval mechanism would be limited to the certificates that a user		limited to the certificates that a user has stored (presumably from
	has stored (presumably from incoming messages). A comprehensive		incoming messages). A comprehensive certificate retrieval/storage solution
	certificate retrieval/storage solution may combine two or more		may combine two or more mechanisms to allow the greatest flexibility and
	mechanisms to allow the greatest flexibility and utility to the user.		utility to the user. For instance, a secure Internet mail agent may resort
	For instance, a secure Internet mail agent may resort to checking a		to checking a centralized certificate retrieval mechanism for a certificate
	centralized certificate retrieval mechanism for a certificate if it		if it can not be found in a user's local certificate storage/retrieval
	can not be found in a user's local certificate storage/retrieval
	database.		database.
	Receiving and sending agents SHOULD provide a mechanism for the import		Receiving and sending agents SHOULD provide a mechanism for the import and
	and export of certificates, using a PKCS #7 certs-only message. This		export of certificates, using a PKCS #7 certs-only message. This allows for
	allows for import and export of full certificate chains as opposed to		import and export of full certificate chains as opposed to just a single
	just a single certificate. This is described in [SMIME-MSG].		certificate. This is described in [SMIME-MSG].
	4.1 Certificate Revocation Lists		4.1 Certificate Revocation Lists
	A receiving agent SHOULD have access to some certificate-revocation		A receiving agent SHOULD have access to some certificate-revocation list
	list (CRL) retrieval mechanism in order to gain access to		(CRL) retrieval mechanism in order to gain access to certificate-revocation
	certificate-revocation information when validating certificate chains.		information when validating certificate chains. A receiving or sending
	A receiving or sending agent SHOULD also provide a mechanism to allow		agent SHOULD also provide a mechanism to allow a user to store incoming
	a user to store incoming certificate-revocation information for		certificate-revocation information for correspondents in such a way so as
	correspondents in such a way so as to guarantee its later retrieval.		to guarantee its later retrieval. However, it is always better to get the
	However, it is always better to get the latest information from the CA		latest information from the CA than to get information stored away from
	than to get information stored away from incoming messages.		incoming messages.
	Receiving and sending agents SHOULD retrieve and utilize CRL		Receiving and sending agents SHOULD retrieve and utilize CRL information
	information every time a certificate is verified as part of a		every time a certificate is verified as part of a certificate chain
	certificate chain validation even if the certificate was already		validation even if the certificate was already verified in the past.
	verified in the past. However, in many instances (such as off-line		However, in many instances (such as off-line verification) access to the
	verification) access to the latest CRL information may be difficult or		latest CRL information may be difficult or impossible. The use of CRL
	impossible. The use of CRL information, therefore, may be dictated		information, therefore, may be dictated by the value of the information
	by the value of the information that is protected. The value of the		that is protected. The value of the CRL information in a particular context
	CRL information in a particular context is beyond the scope of this		is beyond the scope of this draft but may be governed by the policies
	draft but may be governed by the policies associated with particular		associated with particular certificate hierarchies.
	certificate hierarchies.
	4.2 Certificate Chain Validation		4.2 Certificate Chain Validation
	In creating a user agent for secure messaging, certificate, CRL, and		In creating a user agent for secure messaging, certificate, CRL, and
	certificate chain validation SHOULD be highly automated while still		certificate chain validation SHOULD be highly automated while still acting
	acting in the best interests of the user. Certificate, CRL, and chain		in the best interests of the user. Certificate, CRL, and chain validation
	validation MUST be performed when validating a correspondent's public		MUST be performed when validating a correspondent's public key. This is
	key. This is necessary when a) verifying a signature from a		necessary when a) verifying a signature from a correspondent and, b)
	correspondent and, b) creating a digital envelope with the		creating a digital envelope with the correspondent as the intended
	correspondent as the intended recipient.		recipient.
	Certificates and CRLs are made available to the chain validation		Certificates and CRLs are made available to the chain validation procedure
	procedure in two ways: a) incoming messages, and b) certificate and		in two ways: a) incoming messages, and b) certificate and CRL retrieval
	CRL retrieval mechanisms. Certificates and CRLs in incoming messages		mechanisms. Certificates and CRLs in incoming messages are not required to
	are not required to be in any particular order nor are they required		be in any particular order nor are they required to be in any way related
	to be in any way related to the sender or recipient of the message		to the sender or recipient of the message (although in most cases they will
	(although in most cases they will be related to the sender). Incoming		be related to the sender). Incoming certificates and CRLs SHOULD be cached
	certificates and CRLs SHOULD be cached for use in chain validation and		for use in chain validation and optionally stored for later use. This
	optionally stored for later use. This temporary certificate and CRL		temporary certificate and CRL cache SHOULD be used to augment any other
	cache SHOULD be used to augment any other certificate and CRL		certificate and CRL retrieval mechanisms for chain validation on incoming
	retrieval mechanisms for chain validation on incoming signed messages.		signed messages.
	4.3 Certificate and CRL Signing Algorithms		4.3 Certificate and CRL Signing Algorithms
	Certificates and Certificate-Revocation Lists (CRLs) are signed by the		Certificates and Certificate-Revocation Lists (CRLs) are signed by the
	certificate issuer. A receiving agent MUST be capable of verifying the		certificate issuer. A receiving agent MUST be capable of verifying the
	signatures on certificates and CRLs made with the		signatures on certificates andCRLs made with md5WithRSAEncryption and
	md2WithRSAEncryption, md5WithRSAEncryption and sha-1WithRSAEncryption		sha-1WithRSAEncryption signature algorithms with key sizes from 512 bits to
	signature algorithms with key sizes from 512 bits to 2048 bits		2048 bits described in [SMIME-MSG].  A receiving agent SHOULD be capable of
	described in [SMIME-MSG].		verifying the signatures on certificates and CRLs made with the
			md2WithRSAEncryption signature algorithm with key sizes from 512 bits to
			2048 bits.
	4.4 X.509 Version 3 Certificate Extensions		4.4 X.509 Version 3 Certificate Extensions
	The X.509 v3 standard describes an extensible framework in which the		The X.509 v3 standard describes an extensible framework in which the basic
	basic certificate information can be extended and how such extensions		certificate information can be extended and how such extensions can be used
	can be used to control the process of issuing and validating		to control the process of issuing and validating certificates. The PKIX
	certificates. The PKIX Working Group has ongoing efforts to identify		Working Group has ongoing efforts to identify and create extensions which
	and create extensions which have value in particular certification		have value in particular certification environments. As such, there is
	environments. As such, there is still a fair amount of profiling work		still a fair amount of profiling work to be done before there is widespread
	to be done before there is widespread agreement on which v3 extensions		agreement on which v3 extensions will be used. Further, there are active
	will be used. Further, there are active efforts underway to issue		efforts underway to issue X.509 v3 certificates for business purposes. This
	X.509 v3 certificates for business purposes. This draft identifies the		draft identifies the minumum required set of certificate extensions which
	minumum required set of certificate extensions which have the greatest value		have the greatest value in the S/MIME environment. The basicConstraints,
	in the S/MIME environment. The basicConstraints, keyUsage, and		and keyUsage extensions are defined in [X.509].
	certificatePolicies extensions are defined in [X.509].
	Sending and receiving agents MUST correctly handle the v3 Basic		Sending and receiving agents MUST correctly handle the v3 Basic Constraints
	Constraints Certificate Extension, the Key Usage Certificate		Certificate Extension, the Key Usage Certificate Extension, authorityKeyID,
	Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when		subjectKeyID, and the subjectAltNames when they appear in end-user
	they appear in end-user certificates. Some mechanism SHOULD exist to		certificates. Some mechanism SHOULD exist to handle the defined v3
	handle the defined v3 certificate extensions when they appear in		certificate extensions when they appear in intermediate or CA certificates.
	intermediate or CA certificates.
	Certificates issued for the S/MIME environment SHOULD NOT contain any		Certificates issued for the S/MIME environment SHOULD NOT contain any
	critical extensions other than those listed here. These extensions SHOULD		critical extensions other than those listed here. These extensions SHOULD
	be marked as non-critical unless the proper handling of the extension is		be marked as non-critical unless the proper handling of the extension is
	deemed critical to the correct interpretation of the associated certificate.		deemed critical to the correct interpretation of the associated
	Other extensions may be included, but those extensions SHOULD NOT be marked as		certificate. Other extensions may be included, but those extensions SHOULD
	critical.		NOT be marked as critical.
	4.4.1 Basic Constraints Certificate Extension		4.4.1 Basic Constraints Certificate Extension
	The basic constraints extension serves to delimit the role and		The basic constraints extension serves to delimit the role and position of
	position of an issuing authority or end-user certificate plays in a		an issuing authority or end-user certificate plays in a chain of
	chain of certificates.		certificates.
	For example, certificates issued to CAs and subordinate CAs contain a		For example, certificates issued to CAs and subordinate CAs contain a basic
	basic constraint extension that identifies them as issuing authority		constraint extension that identifies them as issuing authority
	certificates. End-user subscriber certificates contain an extension		certificates. End-user subscriber certificates contain an extension that
	that constrains the certificate from being an issuing authority		constrains the certificate from being an issuing authority certificate.
	certificate.
	Certificates SHOULD contain a basicContstraints extension.		Certificates SHOULD contain a basicContstraints extension.
	4.4.2 Key Usage Certificate Extension		4.4.2 Key Usage Certificate Extension
	The key usage extension serves to limit the technical purposes for		The key usage extension serves to limit the technical purposes for which a
	which a public key listed in a valid certificate may be used. Issuing		public key listed in a valid certificate may be used. Issuing authority
	authority certificates may contain a key usage extension that		certificates may contain a key usage extension that restricts the key to
	restricts the key to signing certificates, certificate revocation		signing certificates, certificate revocation lists and other data.
	lists and other data.
	For example, a certification authority may create subordinate issuer		For example, a certification authority may create subordinate issuer
	certificates which contain a keyUsage extension which specifies that		certificates which contain a keyUsage extension which specifies that the
	the corresponding public key can be used to sign end user certs and		corresponding public key can be used to sign end user certs and sign CRLs.
	sign CRLs.
	5. Generating Keys and Certification Requests		5. Generating Keys and Certification Requests
	5.1 Binding Names and Keys		5.1 Binding Names and Keys
	An S/MIME agent or some related administrative utility or function		An S/MIME agent or some related administrative utility or function MUST be
	MUST be capable of generating a certification request given a user's		capable of generating a certification request given a user's public key and
	public key and associated name information. In most cases, the user's		associated name information. In most cases, the user's public key/private
	public key/private key pair will be generated simultaneously. However,		key pair will be generated simultaneously. However, there are cases where
	there are cases where the keying information may be generated by an		the keying information may be generated by an external process (such as
	external process (such as when a key pair is generated on a		when a key pair is generated on a cryptographic token or by a "key
	cryptographic token or by a "key recovery" service).		recovery" service).
	There SHOULD NOT be multiple valid (that is, non-expired and		There SHOULD NOT be multiple valid (that is, non-expired and non-revoked)
	non-revoked) certificates for the same key pair bound to different		certificates for the same key pair bound to different Distinguished Names.
	Distinguished Names. Otherwise, a security flaw exists where an		Otherwise, a security flaw exists where an attacker can substitute one
	attacker can substitute one valid certificate for another in such a		valid certificate for another in such a way that can not be detected by a
	way that can not be detected by a message recipient. If a users wishes		message recipient. If a users wishes to change their name (or create an
	to change their name (or create an alternate name), the user agent		alternate name), the user agent SHOULD generate a new key pair. If the user
	SHOULD generate a new key pair. If the user wishes to reuse an		wishes to reuse an existing key pair with a new or alternate name, the user
	existing key pair with a new or alternate name, the user SHOULD first		SHOULD first have any valid certificates for the existing public key
	have any valid certificates for the existing public key revoked.		revoked.
	In general, it is possible for a user to request certification for the		In general, it is possible for a user to request certification for the same
	same name and different public key from the same or different		name and different public key from the same or different certification
	certification authorities. This is acceptable both for end-entity and		authorities. This is acceptable both for end-entity and issuer
	issuer certificates and can be useful in supporting a change of issuer		certificates and can be useful in supporting a change of issuer keys in a
	keys in a smooth fashion.		smooth fashion.
	CAs that re-use their own name with distinct keys MUST include the		CAs that re-use their own name with distinct keys MUST include the
	AuthorityKeyIdentifier extension in certificates that they issue, and		AuthorityKeyIdentifier extension in certificates that they issue, and MUST
	MUST have the SubjectKeyIdentifier extension in their own certificate.		have the SubjectKeyIdentifier extension in their own certificate. CAs
	CAs SHOULD use these extensions uniformly.		SHOULD use these extensions uniformly.
	Clients MUST handle multiple valid CA certificates that certify		Clients SHOULD handle multiple valid CA certificates that certify different
	different public keys but contain the same subject name (in this case,		public keys but contain the same subject name (in this case, that CA's
	that CA's name).		name).
	When selecting an appropriate issuer's certificate to use to verify a		When selecting an appropriate issuer's certificate to use to verify a given
	given certificate, clients SHOULD process the AuthorityKeyIdentifier		certificate, clients SHOULD process the AuthorityKeyIdentifier and
	and SubjectKeyIdentifier extensions.		SubjectKeyIdentifier extensions.
	5.2 Using PKCS #10 for Certification Requests		5.2 Using PKCS #10 for Certification Requests
	PKCS #10 is a flexible and extensible message format for representing		PKCS #10 is a flexible and extensible message format for representing the
	the results of cryptographic operations on some data. The choice of		results of cryptographic operations on some data. The choice of naming
	naming information is largely dictated by the policies and procedures		information is largely dictated by the policies and procedures associated
	associated with the intended certification service.		with the intended certification service.
	In addition to key and naming information, the PKCS #10 format		In addition to key and naming information, the PKCS #10 format supports the
	supports the inclusion of optional attributes, signed by the entity		inclusion of optional attributes, signed by the entity requesting
	requesting certification. This allows for information to be conveyed		certification. This allows for information to be conveyed in a
	in a certification request which may be useful to the request process,		certification request which may be useful to the request process, but not
	but not necessarily part of the Distinguished Name being certified.		necessarily part of the Distinguished Name being certified.
	Receiving agents MUST support the identification of an RSA key with		Receiving agents MUST support the identification of an RSA key with the rsa
	the rsa defined in X.509 and the rsaEncryption OID. Certification		defined in X.509 and the rsaEncryption OID. Certification authorities MUST
	authorities MUST also support the verification of signatures on		support sha-1WithRSAEncryption and md5WithRSAEncryption and SHOULD support
	certificate requests made with sha-1WithRSAEncryption,		MD2WithRSAEncryption for verification of signatures on certificate requests
	md5WithRSAEncryption, and MD2WithRSAEncryption signature algorithms		as described in [SMIME-MSG].
	described in [SMIME-MSG].
	For the creation and submission of certification-requests, RSA keys		For the creation and submission of certification-requests, RSA keys SHOULD
	SHOULD be identified with the rsaEncryption OID and signed with the		be identified with the rsaEncryption OID and signed with the
	sha-1WithRSAEncryption signature algorithm.		sha-1WithRSAEncryption signature algorithm.  Certification-requests MUST
			NOT be signed with the md2WithRSAEncryption signature algorithm.
	Certification authorities MUST support parsing of zero or one instance		Certification requests MUST include a valid Internet mail address, either
	of each of the following set of certification-request attributes on		as part of the certificate (as described in 3.2) or as part of the PKCS #10
	incoming messages. Inclusion of the following attributes during the		attribute list. Certification authorities MUST check that the address in
	creation and submission of a certification-request will most likely be		the "From:" header matches either of these addresses. CAs SHOULD allow the
	dictated by the policies associated with the certification service		CA operator to configure processing of messages whose addresses do not
	which will certify the corresponding name and public key.		match.
			Certification authorities SHOULD support parsing of zero or one instance of
			each of the following set of certification-request attributes on incoming
			messages. Attributes that a particular implementation does not support may
			generate a warning message to the requestor, or may be silently ignored.
			Inclusion of the following attributes during the creation and submission of
			a certification-request will most likely be dictated by the policies
			associated with the certification service which will certify the
			corresponding name and public key.
	postalAddress		postalAddress
	challengePassword		challengePassword
	unstructuredAddress		unstructuredAddress
	postalAddress is described in [X.520].		postalAddress is described in [X.520].
	5.2.1 Challenge Password		5.2.1 Challenge Password
	The challenge-password attribute type specifies a password by which an		The challenge-password attribute type specifies a password by which an
	entity may request certificate revocation. The interpretation of the		entity may request certificate revocation. The interpretation of the
	password is intended to be specified by the issuer of the certificate;		password is intended to be specified by the issuer of the certificate; no
	no particular interpretation is required. The challenge-password		particular interpretation is required. The challenge-password attribute
	attribute type is intended for PKCS #10 certification requests.		type is intended for PKCS #10 certification requests.
	Challenge-password attribute values have ASN.1 type ChallengePassword:		Challenge-password attribute values have ASN.1 type ChallengePassword:
	ChallengePassword ::= CHOICE {		ChallengePassword ::= CHOICE {
	PrintableString, T61String }		PrintableString, T61String }
	A challenge-password attribute must have a single attribute value.		A challenge-password attribute must have a single attribute value.
	It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL		It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL STRING),
	STRING), ChallengePassword will become a CHOICE type:		ChallengePassword will become a CHOICE type:
	ChallengePassword ::= CHOICE {		ChallengePassword ::= CHOICE {
	PrintableString, T61String, UNIVERSAL STRING }		PrintableString, T61String, UNIVERSAL STRING }
	5.2.2 Unstructured Address		5.2.2 Unstructured Address
	The unstructured-address attribute type specifies the address or		The unstructured-address attribute type specifies the address or addresses
	addresses of the subject of a certificate as an unstructured ASCII or		of the subject of a certificate as an unstructured ASCII or T.61 string.
	T.61 string. The interpretation of the addresses is intended to be		The interpretation of the addresses is intended to be specified by the
	specified by the issuer of the certificate; no particular		issuer of the certificate; no particular interpretation is required. A
	interpretation is required. A likely interpretation is as an		likely interpretation is as an alternative to the X.520 postalAddress
	alternative to the X.520 postalAddress attribute type. The		attribute type. The unstructured-address attribute type is intended for
	unstructured-address attribute type is intended for PKCS #10		PKCS #10 certification requests.
	certification requests.
	Unstructured-address attribute values have ASN.1 type		Unstructured-address attribute values have ASN.1 type UnstructuredAddress:
	UnstructuredAddress:
	UnstructuredAddress ::= CHOICE {		UnstructuredAddress ::= CHOICE {
	PrintableString, T61String }		PrintableString, T61String }
	An unstructured-address attribute can have multiple attribute values.		An unstructured-address attribute can have multiple attribute values.
	Note: T.61's newline character (hexadecimal code 0d) is recommended as		Note: T.61's newline character (hexadecimal code 0d) is recommended as a
	a line separator in multi-line addresses.		line separator in multi-line addresses.
	It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL		It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL STRING),
	STRING), UnstructuredAddress will become a CHOICE type:		UnstructuredAddress will become a CHOICE type:
	UnstructuredAddress ::= CHOICE {		UnstructuredAddress ::= CHOICE {
	PrintableString, T61String, UNIVERSAL STRING }		PrintableString, T61String, UNIVERSAL STRING }
	5.3 Fulfilling a Certification Request		5.3 Fulfilling a Certification Request
	Certification authorities SHOULD use the sha-1WithRSAEncryption		Certification authorities SHOULD use the sha-1WithRSAEncryption
	signature algorithms when signing certificates.		signature algorithms when signing certificates.
	5.4 Using PKCS #7 for Fulfilled Certificate Response		5.4 Using PKCS #7 for Fulfilled Certificate Response
	[PKCS-7] supports a degenerate case of the SignedData content type		[PKCS-7] supports a degenerate case of the SignedData content type where
	where there are no signers on the content (and hence, the content		there are no signers on the content (and hence, the content value is
	value is "irrelevant"). This degenerate case is used to convey		"irrelevant"). This degenerate case is used to convey certificate and CRL
	certificate and CRL information. Certification authorities MUST use		information. Certification authorities MUST use this format for returning
	this format for returning certificate information resulting from the		certificate information resulting from the successful fulfillment of a
	successful fulfillment of a certification request. At a minimum, the		certification request. At a minimum, the fulfilled certificate response
	fulfilled certificate response MUST include the actual subject		MUST include the actual subject certificate (corresponding to the
	certificate (corresponding to the information in the certification		information in the certification request). The response SHOULD include
	request). The response SHOULD include other certificates which link		other certificates which link the issuer to higher level certification
	the issuer to higher level certification authorities and corresponding		authorities and corresponding certificate-revocation lists. Unrelated
	certificate-revocation lists. Unrelated certificates and revocation		certificates and revocation information is also acceptable.
	information is also acceptable.
	Receiving agents MUST parse this degenerate PKCS #7 message type and		Receiving agents MUST parse this degenerate PKCS #7 message type and handle
	handle the certificates and CRLs according to the requirements and		the certificates and CRLs according to the requirements and recommendations
	recommendations in Section 4.		in Section 4.
	6. Security Considerations		6. Security Considerations
	All of the security issues faced by any cryptographic application must		All of the security issues faced by any cryptographic application must be
	be faced by a S/MIME agent. Among these issues are protecting the		faced by a S/MIME agent. Among these issues are protecting the user's
	user's private key, preventing various attacks, and helping the user		private key, preventing various attacks, and helping the user avoid
	avoid mistakes such as inadvertently encrypting a message for the		mistakes such as inadvertently encrypting a message for the wrong
	wrong recipient. The entire list of security considerations is beyond		recipient. The entire list of security considerations is beyond the scope
	the scope of this document, but some significant concerns are listed		of this document, but some significant concerns are listed here.
	here.
	When processing certificates, there are many situations where the		When processing certificates, there are many situations where the
	processing might fail. Because the processing may be done by a user		processing might fail. Because the processing may be done by a user agent,
	agent, a security gateway, or other program, there is no single way to		a security gateway, or other program, there is no single way to handle such
	handle such failures. Just because the methods to handle the failures		failures. Just because the methods to handle the failures has not been
	has not been listed, however, the reader should not assume that they		listed, however, the reader should not assume that they are not important.
	are not important. The opposite is true: if a certificate is not		The opposite is true: if a certificate is not provably valid and associated
	provably valid and associated with the message, the processing		with the message, the processing software should take immediate and
	software should take immediate and noticable steps to inform the end		noticable steps to inform the end user about it.
	user about it.
	Some of the many places where signature and certificate checking might		Some of the many places where signature and certificate checking might fail
	fail include:		include:
	- no Internet mail addresses in a certificate match the sender of		- no Internet mail addresses in a certificate match the sender of a message
	a message
	- no certificate chain leads to a trusted CA		- no certificate chain leads to a trusted CA
	no Internet mail addresses in a certificate match the sender of a message
	- no ability to check the CRL for a certificate		- no ability to check the CRL for a certificate
	- an invalid CRL was received		- an invalid CRL was received
	- the CRL being checked is expired		- the CRL being checked is expired
	- the certificate is expired		- the certificate is expired
	- the certificate has been revoked		- the certificate has been revoked
	There are certainly other instances where a certificate may be		There are certainly other instances where a certificate may be invalid, and
	invalid, and it is the responsibility of the processing software to		it is the responsibility of the processing software to check them all
	check them all thoroughly, and to decide what to do if the check		thoroughly, and to decide what to do if the check fails.
	fails.
	A. Object Identifiers and Syntax		A. Object Identifiers and Syntax
	Sections A.1 through A.4 are adopted from [SMIME-MSG].		Sections A.1 through A.4 are adopted from [SMIME-MSG].
	A.5 Name Attributes		A.5 Name Attributes
	emailAddress OBJECT IDENTIFIER ::=		emailAddress OBJECT IDENTIFIER ::=
	{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1}		{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1}
	skipping to change at line 704 ¶		skipping to change at line 683 ¶
	digitalSignature (0),		digitalSignature (0),
	nonRepudiation (1),		nonRepudiation (1),
	keyEncipherment (2),		keyEncipherment (2),
	dataEncipherment (3),		dataEncipherment (3),
	keyAgreement (4),		keyAgreement (4),
	keyCertSign (5),		keyCertSign (5),
	cRLSign (6)}		cRLSign (6)}
	B. References		B. References
	[KEYM] PKIX Part 1. At the time of this writing, PKIX is in Internet		[KEYM] PKIX Part 1. At the time of this writing, PKIX is in Internet Draft
	Draft stage, but it is expected that there will be standards-track		stage, but it is expected that there will be standards-track RFCs at some
	RFCs at some point in the future.		point in the future.
	[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement		[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement Levels",
	Levels", RFC 2119		RFC 2119
	[PKCS-1], "PKCS #1: RSA Encryption", draft has been submitted for RFC		[PKCS-1], "PKCS #1: RSA Encryption", draft has been submitted for RFC
	status		status
	[PKCS-7], "PKCS #7: Cryptographic Message Syntax", draft has been		[PKCS-7], "PKCS #7: Cryptographic Message Syntax", draft has been submitted
	submitted for RFC status		for RFC status
	[PKCS-10], "PKCS #10: Certification Request Syntax", draft has been		[PKCS-10], "PKCS #10: Certification Request Syntax", draft has been
	submitted for RFC status		submitted for RFC status
	[RFC-822], "Standard For The Format Of ARPA Internet Text Messages",		[RFC-822], "Standard For The Format Of ARPA Internet Text Messages", RFC
	RFC 822.		822.
	[SMIME-MSG] "S/MIME Message Specification", Internet Draft		[SMIME-MSG] "S/MIME Message Specification", Internet Draft
	draft-dusse-smime-msg-xx.		draft-dusse-smime-msg-xx.
	[X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,		[X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
	Information technology - Open Systems Interconnection - The Directory:		Information technology - Open Systems Interconnection - The Directory:
	Overview of concepts, models and services		Overview of concepts, models and services
	[X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997,		[X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997,
	Information technology - Open Systems Interconnection - The Directory:		Information technology - Open Systems Interconnection - The Directory:
	skipping to change at line 744 ¶		skipping to change at line 723 ¶
	[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,		[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
	Information technology - Open Systems Interconnection - The Directory:		Information technology - Open Systems Interconnection - The Directory:
	Authentication framework		Authentication framework
	[X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,		[X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,
	Information technology - Open Systems Interconnection - The Directory:		Information technology - Open Systems Interconnection - The Directory:
	Selected attribute types.		Selected attribute types.
	C. Compatibility with Prior Practice in S/MIME		C. Compatibility with Prior Practice in S/MIME
	S/MIME was originally developed by RSA Data Security, Inc. Many		S/MIME was originally developed by RSA Data Security, Inc. Many developers
	developers implemented S/MIME agents before this document was		implemented S/MIME agents before this document was published. All S/MIME
	published. All S/MIME receiving agents SHOULD make every attempt to		receiving agents SHOULD make every attempt to interoperate with these
	interoperate with these earlier implementations of S/MIME.		earlier implementations of S/MIME.
	D. Revision History		D. Revision History
	The following changes were made between the -03 and -04 revisions of		The following changes were made between the -04 and -05 revisions of this
	this draft:		draft:
	In 2.1, changed "revocation time" to "nextUpdate time".		There was general agreement that this draft should reflect reality of
			S/MIME v2 implementations and not what "should be", which is left to S/MIME
			v3. The changes listed here are to bring this draft back to what is being
			deployed today.
	In 2.1, removed the somewhat ambiguous sentence about agents retrieving		Changed the end of 2.3 to only require DN chaining.
	CRLs in any fashion they are provided.
	In 2.3, added "Clients MUST support chaining based on the		Changed the MUST to SHOULD for MD2 hashing in 4.3 and 5.2.
	distinguished name and SHOULD support chaining based on the
	subjectAltName field."
	In 4.4, replaced last paragraph with explanation of what should and		Made the "certificates" in 2.2 "end entity" certificates.
	shouldn't be marked as critical.
	In 4.4.1, added "Certificates SHOULD contain a basicContstraints		Removed certificatePolicies from 4.4.
	extension."
	Open issue: what is the OID being referred to in 5.2?		In 5.1, changed "Clients MUST handle multiple valid CA certificates" to
			"Clients SHOULD...".
			In 5.2, changed the MUST to SHOULD for the certification-request
			attributes.
			In 3.2, changed the SHOULD to MUS for including the email address during DN
			creation. Added text in 5.2 to support this.
	E. Acknowledgements		E. Acknowledgements
	Significant contributions to the content of this draft were made by		Significant contributions to the content of this draft were made by many
	many people, including David Solo, Anil Gangolli, Jeff Thompson, and		people, including David Solo, Anil Gangolli, Jeff Thompson, and Lisa Repka.
	Lisa Repka.
	F. Authors' addresses		F. Authors' addresses
	Steve Dusse		Steve Dusse
	RSA Data Security, Inc.		RSA Data Security, Inc.
	100 Marine Parkway, #500		100 Marine Parkway, #500
	Redwood City, CA 94065 USA		Redwood City, CA 94065 USA
	(415) 595-8782		(415) 595-8782
	spock@rsa.com		spock@rsa.com
End of changes. 87 change blocks.
	417 lines changed or deleted		399 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/