< draft-ietf-lamps-rfc5750-bis-05.txt		draft-ietf-lamps-rfc5750-bis-06.txt >
	LAMPS J. Schaad		LAMPS J. Schaad
	Internet-Draft August Cellars		Internet-Draft August Cellars
	Obsoletes: 5750 (if approved) B. Ramsdell		Obsoletes: 5750 (if approved) B. Ramsdell
	Intended status: Standards Track Brute Squad Labs, Inc.		Intended status: Standards Track Brute Squad Labs, Inc.
	Expires: October 15, 2018 S. Turner		Expires: November 3, 2018 S. Turner
	sn3rd		sn3rd
	April 13, 2018		May 2, 2018
	Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0		Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0
	Certificate Handling		Certificate Handling
	draft-ietf-lamps-rfc5750-bis-05		draft-ietf-lamps-rfc5750-bis-06
	Abstract		Abstract
	This document specifies conventions for X.509 certificate usage by		This document specifies conventions for X.509 certificate usage by
	Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.		Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.
	S/MIME provides a method to send and receive secure MIME messages,		S/MIME provides a method to send and receive secure MIME messages,
	and certificates are an integral part of S/MIME agent processing.		and certificates are an integral part of S/MIME agent processing.
	S/MIME agents validate certificates as described in RFC 5280, the		S/MIME agents validate certificates as described in RFC 5280, the
	Internet X.509 Public Key Infrastructure Certificate and CRL Profile.		Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
	S/MIME agents must meet the certificate processing requirements in		S/MIME agents must meet the certificate processing requirements in
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on October 15, 2018.		This Internet-Draft will expire on November 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Conventions Used in This Document . . . . . . . . . . . . 4		1.2. Conventions Used in This Document . . . . . . . . . . . . 4
	1.3. Compatibility with Prior Practice S/MIME . . . . . . . . 5		1.3. Compatibility with Prior Practice S/MIME . . . . . . . . 5
	1.4. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 5		1.4. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 5
	1.5. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 6		1.5. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 6
	1.6. Changes since S/MIME 3.2 . . . . . . . . . . . . . . . . 6		1.6. Changes since S/MIME 3.2 . . . . . . . . . . . . . . . . 7
	2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 7		2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 7
	2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 7		2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 7
	2.2.1. Historical Note about CMS Certificates . . . . . . . 7		2.2.1. Historical Note about CMS Certificates . . . . . . . 8
	2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 8		2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 8
	3. Using Distinguished Names for Internet Mail . . . . . . . . . 9		3. Using Distinguished Names for Internet Mail . . . . . . . . . 9
	4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10		4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10
	4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11		4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11
	4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12		4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12
	4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 12		4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 13
	4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 13		4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 14
	4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14		4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14
	4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 14		4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 15
	4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15		4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15
	4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 15		4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 16
	5. IANA Considertions . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considertions . . . . . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	7.1. Normative References . . . . . . . . . . . . . . . . . . 18		7.1. Normative References . . . . . . . . . . . . . . . . . . 18
	7.2. Informational References . . . . . . . . . . . . . . . . 21		7.2. Informational References . . . . . . . . . . . . . . . . 21
	Appendix A. Historic Considerations . . . . . . . . . . . . . . 23		Appendix A. Historic Considerations . . . . . . . . . . . . . . 24
	A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 23		A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 24
	Appendix B. Moving S/MIME v2 Certificate Handling to Historic		Appendix B. Moving S/MIME v2 Certificate Handling to Historic
	Status . . . . . . . . . . . . . . . . . . . . . . . 25		Status . . . . . . . . . . . . . . . . . . . . . . . 25
	Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 25		Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	S/MIME (Secure/Multipurpose Internet Mail Extensions) v4.0, described		S/MIME (Secure/Multipurpose Internet Mail Extensions) v4.0, described
	in [I-D.ietf-lamps-rfc5751-bis], provides a method to send and		in [I-D.ietf-lamps-rfc5751-bis], provides a method to send and
	receive secure MIME messages. Before using a public key to provide		receive secure MIME messages. Before using a public key to provide
	security services, the S/MIME agent MUST verify that the public key		security services, the S/MIME agent MUST verify that the public key
	is valid. S/MIME agents MUST use PKIX certificates to validate		is valid. S/MIME agents MUST use PKIX certificates to validate
	public keys as described in the Internet X.509 Public Key		public keys as described in the Internet X.509 Public Key
	Infrastructure (PKIX) Certificate and CRL Profile [RFC5280]. S/MIME		Infrastructure (PKIX) Certificate and CRL Profile [RFC5280]. S/MIME
	agents MUST meet the certificate processing requirements documented		agents MUST meet the certificate processing requirements documented
	in this document in addition to those stated in [RFC5280].		in this document in addition to those stated in [RFC5280].
	This specification is compatible with the Cryptographic Message		This specification is compatible with the Cryptographic Message
	Syntax (CMS) RFC 5652 [RFC5652] in that it uses the data types		Syntax (CMS) RFC 5652 [RFC5652] in that it uses the data types
	defined by CMS. It also inherits all the varieties of architectures		defined by CMS. It also inherits all the varieties of architectures
	for certificate-based key management supported by CMS.		for certificate-based key management supported by CMS.
			This document obsoletes [RFC5750]. The most significant changes
			revolve around changes in recommendations around the cryptographic
			algorithms used by the specification. More details can be found in
			Section 1.6.
	1.1. Definitions		1.1. Definitions
	For the purposes of this document, the following definitions apply.		For the purposes of this document, the following definitions apply.
	ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680		ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680
	[X.680].		[X.680].
	Attribute certificate (AC): An X.509 AC is a separate structure from		Attribute certificate (AC): An X.509 AC is a separate structure from
	a subject's public key X.509 certificate. A subject may have		a subject's public key X.509 certificate. A subject may have
	multiple X.509 ACs associated with each of its public key X.509		multiple X.509 ACs associated with each of its public key X.509
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 37 ¶
	Sending agent: Software that creates S/MIME CMS objects, MIME body		Sending agent: Software that creates S/MIME CMS objects, MIME body
	parts that contain CMS objects, or both.		parts that contain CMS objects, or both.
	S/MIME agent: User software that is a receiving agent, a sending		S/MIME agent: User software that is a receiving agent, a sending
	agent, or both.		agent, or both.
	1.2. Conventions Used in This Document		1.2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	We define the additional requirement levels:		We define the additional requirement levels:
	SHOULD+ This term means the same as SHOULD. However, the authors		SHOULD+ This term means the same as SHOULD. However, the authors
	expect that a requirement marked as SHOULD+ will be promoted		expect that a requirement marked as SHOULD+ will be promoted
	at some future time to be a MUST.		at some future time to be a MUST.
	SHOULD- This term means the same as SHOULD. However, the authors		SHOULD- This term means the same as SHOULD. However, the authors
	expect that a requirement marked as SHOULD- will be demoted		expect that a requirement marked as SHOULD- will be demoted
	to a MAY in a future version of this document.		to a MAY in a future version of this document.
	skipping to change at page 7, line 51 ¶		skipping to change at page 8, line 15 ¶
	2.2.1. Historical Note about CMS Certificates		2.2.1. Historical Note about CMS Certificates
	The CMS message format supports a choice of certificate formats for		The CMS message format supports a choice of certificate formats for
	public key content types: PKIX, PKCS #6 extended certificates		public key content types: PKIX, PKCS #6 extended certificates
	[PKCS6], and PKIX attribute certificates.		[PKCS6], and PKIX attribute certificates.
	The PKCS #6 format is not in widespread use. In addition, PKIX		The PKCS #6 format is not in widespread use. In addition, PKIX
	certificate extensions address much of the same functionality and		certificate extensions address much of the same functionality and
	flexibility as was intended in the PKCS #6. Thus, sending and		flexibility as was intended in the PKCS #6. Thus, sending and
	receiving agents MUST NOT use PKCS #6 extended certificates.		receiving agents MUST NOT use PKCS #6 extended certificates.
	Receiving agents MUST be able to process a message containing PKCS #6		Receiving agents MUST be able to parser and process a message
	extended certificates.		containing PKCS #6 extended certificates although ignoring those
			certificates is expected behavior.
	X.509 version 1 attribute certificates are also not widely		X.509 version 1 attribute certificates are also not widely
	implemented, and have been superseded with version 2 attribute		implemented, and have been superseded with version 2 attribute
	certificates. Sending agents MUST NOT send version 1 attribute		certificates. Sending agents MUST NOT send version 1 attribute
	certificates.		certificates.
	2.3. CertificateSet		2.3. CertificateSet
	Receiving agents MUST be able to handle an arbitrary number of		Receiving agents MUST be able to handle an arbitrary number of
	certificates of arbitrary relationship to the message sender and to		certificates of arbitrary relationship to the message sender and to
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 49 ¶
	extension will include the subject's identifier and MUST be marked as		extension will include the subject's identifier and MUST be marked as
	critical.		critical.
	4. Certificate Processing		4. Certificate Processing
	S/MIME agents need to provide some certificate retrieval mechanism in		S/MIME agents need to provide some certificate retrieval mechanism in
	order to gain access to certificates for recipients of digital		order to gain access to certificates for recipients of digital
	envelopes. There are many ways to implement certificate retrieval		envelopes. There are many ways to implement certificate retrieval
	mechanisms. [X.500] directory service is an excellent example of a		mechanisms. [X.500] directory service is an excellent example of a
	certificate retrieval-only mechanism that is compatible with classic		certificate retrieval-only mechanism that is compatible with classic
	X.500 Distinguished Names. Another method under consideration by the		X.500 Distinguished Names. The IETF has published [RFC8162] which
	IETF is to provide certificate retrieval services as part of the		describes an experimental protocol to retrieve certificates from the
	existing Domain Name System (DNS). Until such mechanisms are widely		Domain Name System (DNS). Until such mechanisms are widely used,
	used, their utility may be limited by the small number of the		their utility may be limited by the small number of the
	correspondent's certificates that can be retrieved. At a minimum,		correspondent's certificates that can be retrieved. At a minimum,
	for initial S/MIME deployment, a user agent could automatically		for initial S/MIME deployment, a user agent could automatically
	generate a message to an intended recipient requesting the		generate a message to an intended recipient requesting the
	recipient's certificate in a signed return message.		recipient's certificate in 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 user to "store and protect" certificates for correspondents in such		a user to "store and protect" certificates for correspondents in such
	a way so as to guarantee their later retrieval. In many		a way so as to guarantee their later retrieval. In many
	environments, it may be desirable to link the certificate retrieval/		environments, it may be desirable to link the certificate retrieval/
	storage mechanisms together in some sort of certificate database. In		storage mechanisms together in some sort of certificate database. In
	skipping to change at page 18, line 45 ¶		skipping to change at page 19, line 18 ¶
	Processing Standards Publication 186-3, June 2009.		Processing Standards Publication 186-3, June 2009.
	[I-D.ietf-lamps-eai-addresses]		[I-D.ietf-lamps-eai-addresses]
	Melnikov, A. and W. Chuang, "Internationalized Email		Melnikov, A. and W. Chuang, "Internationalized Email
	Addresses in X.509 certificates", draft-ietf-lamps-eai-		Addresses in X.509 certificates", draft-ietf-lamps-eai-
	addresses-18 (work in progress), March 2018.		addresses-18 (work in progress), March 2018.
	[I-D.ietf-lamps-rfc5751-bis]		[I-D.ietf-lamps-rfc5751-bis]
	Schaad, J., Ramsdell, B., and S. Turner, "Secure/		Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0		Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", draft-ietf-lamps-rfc5751-bis-06		Message Specification", draft-ietf-lamps-rfc5751-bis-08
	(work in progress), April 2017.		(work in progress), May 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",		[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
	RFC 2634, DOI 10.17487/RFC2634, June 1999,		RFC 2634, DOI 10.17487/RFC2634, June 1999,
	<https://www.rfc-editor.org/info/rfc2634>.		<https://www.rfc-editor.org/info/rfc2634>.
	skipping to change at page 20, line 31 ¶		skipping to change at page 21, line 5 ¶
	Polk, "Internet X.509 Public Key Infrastructure:		Polk, "Internet X.509 Public Key Infrastructure:
	Additional Algorithms and Identifiers for DSA and ECDSA",		Additional Algorithms and Identifiers for DSA and ECDSA",
	RFC 5758, DOI 10.17487/RFC5758, January 2010,		RFC 5758, DOI 10.17487/RFC5758, January 2010,
	<https://www.rfc-editor.org/info/rfc5758>.		<https://www.rfc-editor.org/info/rfc5758>.
	[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature		[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
	Algorithm (DSA) and Elliptic Curve Digital Signature		Algorithm (DSA) and Elliptic Curve Digital Signature
	Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August		Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
	2013, <https://www.rfc-editor.org/info/rfc6979>.		2013, <https://www.rfc-editor.org/info/rfc6979>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[SMIMEv3.2]		[SMIMEv3.2]
	"S/MIME version 3.2".		"S/MIME version 3.2".
	This group of documents represents S/MIME version 3.2.		This group of documents represents S/MIME version 3.2.
	This set of documents are [RFC2634], [RFC5750], [[This		This set of documents are [RFC2634], [RFC5750], [[This
	Document]], [RFC5652], and [RFC5035].		Document]], [RFC5652], and [RFC5035].
	[SMIMEv4.0]		[SMIMEv4.0]
	"S/MIME version 4.0".		"S/MIME version 4.0".
	skipping to change at page 21, line 16 ¶		skipping to change at page 21, line 39 ¶
	[ESS] "Enhanced Security Services for S/ MIME".		[ESS] "Enhanced Security Services for S/ MIME".
	This is the set of documents dealing with enhanced		This is the set of documents dealing with enhanced
	security services and refers to [RFC2634] and [RFC5035].		security services and refers to [RFC2634] and [RFC5035].
	[I-D.ietf-curdle-pkix]		[I-D.ietf-curdle-pkix]
	Josefsson, S. and J. Schaad, "Algorithm Identifiers for		Josefsson, S. and J. Schaad, "Algorithm Identifiers for
	Ed25519, Ed448, X25519 and X448 for use in the Internet		Ed25519, Ed448, X25519 and X448 for use in the Internet
	X.509 Public Key Infrastructure", draft-ietf-curdle-		X.509 Public Key Infrastructure", draft-ietf-curdle-
	pkix-07 (work in progress), November 2017.		pkix-09 (work in progress), April 2018.
	[PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax		[PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
	Standard", November 1993.		Standard", November 1993.
	[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and		[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
	L. Repka, "S/MIME Version 2 Message Specification",		L. Repka, "S/MIME Version 2 Message Specification",
	RFC 2311, DOI 10.17487/RFC2311, March 1998,		RFC 2311, DOI 10.17487/RFC2311, March 1998,
	<https://www.rfc-editor.org/info/rfc2311>.		<https://www.rfc-editor.org/info/rfc2311>.
	[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,		[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
	skipping to change at page 22, line 52 ¶		skipping to change at page 23, line 25 ¶
	[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security		[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
	Considerations for the SHA-0 and SHA-1 Message-Digest		Considerations for the SHA-0 and SHA-1 Message-Digest
	Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,		Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
	<https://www.rfc-editor.org/info/rfc6194>.		<https://www.rfc-editor.org/info/rfc6194>.
	[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital		[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
	Signature Algorithm (EdDSA)", RFC 8032,		Signature Algorithm (EdDSA)", RFC 8032,
	DOI 10.17487/RFC8032, January 2017,		DOI 10.17487/RFC8032, January 2017,
	<https://www.rfc-editor.org/info/rfc8032>.		<https://www.rfc-editor.org/info/rfc8032>.
			[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
			Associate Certificates with Domain Names for S/MIME",
			RFC 8162, DOI 10.17487/RFC8162, May 2017,
			<https://www.rfc-editor.org/info/rfc8162>.
	[SMIMEv2] "S/MIME version v2".		[SMIMEv2] "S/MIME version v2".
	This group of documents represents S/MIME version 2. This		This group of documents represents S/MIME version 2. This
	set of documents are [RFC2311], [RFC2312], [RFC2313],		set of documents are [RFC2311], [RFC2312], [RFC2313],
	[RFC2314], and [RFC2315].		[RFC2314], and [RFC2315].
	[SMIMEv3] "S/MIME version 3".		[SMIMEv3] "S/MIME version 3".
	This group of documents represents S/MIME version 3. This		This group of documents represents S/MIME version 3. This
	set of documents are [RFC2630], [RFC2631], [RFC2632],		set of documents are [RFC2630], [RFC2631], [RFC2632],
End of changes. 19 change blocks.
	24 lines changed or deleted		41 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/