draft-ietf-lamps-rfc5751-bis-07.txt		draft-ietf-lamps-rfc5751-bis-08.txt
	LAMPS J. Schaad		LAMPS J. Schaad
	Internet-Draft August Cellars		Internet-Draft August Cellars
	Obsoletes: 5751 (if approved) B. Ramsdell		Obsoletes: 5751 (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
	Message Specification		Message Specification
	draft-ietf-lamps-rfc5751-bis-07		draft-ietf-lamps-rfc5751-bis-08
	Abstract		Abstract
	This document defines Secure/Multipurpose Internet Mail Extensions		This document defines Secure/Multipurpose Internet Mail Extensions
	(S/MIME) version 4.0. S/MIME provides a consistent way to send and		(S/MIME) version 4.0. S/MIME provides a consistent way to send and
	receive secure MIME data. Digital signatures provide authentication,		receive secure MIME data. Digital signatures provide authentication,
	message integrity, and non-repudiation with proof of origin.		message integrity, and non-repudiation with proof of origin.
	Encryption provides data confidentiality. Compression can be used to		Encryption provides data confidentiality. Compression can be used to
	reduce data size. This document obsoletes RFC 5751.		reduce data size. This document obsoletes RFC 5751.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 42 ¶		skipping to change at page 2, line 42 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Specification Overview . . . . . . . . . . . . . . . . . 4		1.1. Specification Overview . . . . . . . . . . . . . . . . . 4
	1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Conventions Used in This Document . . . . . . . . . . . . 6		1.3. Conventions Used in This Document . . . . . . . . . . . . 6
	1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7		1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7
	1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 7		1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 7
	1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 8		1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 8
	1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9		1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9
	2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9		2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 10
	2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10		2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10
	2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10		2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10
	2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11		2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11
	2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12		2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12
	2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12		2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12
	2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12		2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12
	2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12		2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12
	2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12		2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12
	2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12		2.4.5. CompressedData Content Type . . . . . . . . . . . . . 13
	2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13		2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13
	2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13		2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 14
	2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14		2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14
	2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15		2.5.3. Encryption Key Preference Attribute . . . . . . . . . 16
	2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17		2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17
	2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17		2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17
	2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17		2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17
	2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19		2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19
	2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19		2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19
	3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19		3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19
	3.1. Preparing the MIME Entity for Signing, Enveloping, or		3.1. Preparing the MIME Entity for Signing, Enveloping, or
	Compressing . . . . . . . . . . . . . . . . . . . . . . . 20		Compressing . . . . . . . . . . . . . . . . . . . . . . . 20
	3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21		3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21
	3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22		3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22
	3.1.3. Transfer Encoding for Signing Using multipart/signed 22		3.1.3. Transfer Encoding for Signing Using multipart/signed 23
	3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23		3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23
	3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24		3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24
	3.2.1. The name and filename Parameters . . . . . . . . . . 25		3.2.1. The name and filename Parameters . . . . . . . . . . 25
	3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26		3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26
	3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27		3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27
	3.4. Creating an Authenticated Enveloped-Only Message . . . . 28		3.4. Creating an Authenticated Enveloped-Only Message . . . . 28
	3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29		3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29
	3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29		3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29
	3.5.2. Signing Using application/pkcs7-mime with SignedData 30		3.5.2. Signing Using application/pkcs7-mime with SignedData 30
	3.5.3. Signing Using the multipart/signed Format . . . . . . 31		3.5.3. Signing Using the multipart/signed Format . . . . . . 31
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38		4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38
	4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38		4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
	5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38		5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38
	5.2. Media Type for application/pkcs7-signature . . . . . . . 39		5.2. Media Type for application/pkcs7-signature . . . . . . . 39
	5.3. Register authEnveloped-data smime-type . . . . . . . . . 40		5.3. Register authEnveloped-data smime-type . . . . . . . . . 40
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 40		6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
	7.1. Normative References . . . . . . . . . . . . . . . . . . 44		7.1. Normative References . . . . . . . . . . . . . . . . . . 44
	7.2. Informative References . . . . . . . . . . . . . . . . . 48		7.2. Informative References . . . . . . . . . . . . . . . . . 48
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 52
	Appendix B. Historic Mail Considerations . . . . . . . . . . . . 53		Appendix B. Historic Mail Considerations . . . . . . . . . . . . 54
	B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54		B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54
	B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54		B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54
	B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56		B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56
	B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 56		B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 56
	Appendix C. Moving S/MIME v2 Message Specification to Historic		Appendix C. Moving S/MIME v2 Message Specification to Historic
	Status . . . . . . . . . . . . . . . . . . . . . . . 56		Status . . . . . . . . . . . . . . . . . . . . . . . 57
	Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57		Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
	1. Introduction		1. Introduction
	S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a		S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
	consistent way to send and receive secure MIME data. Based on the		consistent way to send and receive secure MIME data. Based on the
	popular Internet MIME standard, S/MIME provides the following		popular Internet MIME standard, S/MIME provides the following
	cryptographic security services for electronic messaging		cryptographic security services for electronic messaging
	applications: authentication, message integrity and non-repudiation		applications: authentication, message integrity and non-repudiation
	of origin (using digital signatures), and data confidentiality (using		of origin (using digital signatures), and data confidentiality (using
	encryption). As a supplementary service, S/MIME provides for message		encryption). As a supplementary service, S/MIME provides message
	compression.		compression.
	S/MIME can be used by traditional mail user agents (MUAs) to add		S/MIME can be used by traditional mail user agents (MUAs) to add
	cryptographic security services to mail that is sent, and to		cryptographic security services to mail that is sent, and to
	interpret cryptographic security services in mail that is received.		interpret cryptographic security services in mail that is received.
	However, S/MIME is not restricted to mail; it can be used with any		However, S/MIME is not restricted to mail; it can be used with any
	transport mechanism that transports MIME data, such as HTTP or SIP.		transport mechanism that transports MIME data, such as HTTP or SIP.
	As such, S/MIME takes advantage of the object-based features of MIME		As such, S/MIME takes advantage of the object-based features of MIME
	and allows secure messages to be exchanged in mixed-transport		and allows secure messages to be exchanged in mixed-transport
	systems.		systems.
	Further, S/MIME can be used in automated message transfer agents that		Further, S/MIME can be used in automated message transfer agents that
	use cryptographic security services that do not require any human		use cryptographic security services that do not require any human
	intervention, such as the signing of software-generated documents and		intervention, such as the signing of software-generated documents and
	the encryption of FAX messages sent over the Internet.		the encryption of FAX messages sent over the Internet.
			This document defines the version 4.0 of the S/MIME Message
			specification. As such this document obsoletes version 3.2 of the
			S/MIME Message specification [RFC5751].
	1.1. Specification Overview		1.1. Specification Overview
	This document describes a protocol for adding cryptographic signature		This document describes a protocol for adding cryptographic signature
	and encryption services to MIME data. The MIME standard [MIME-SPEC]		and encryption services to MIME data. The MIME standard [MIME-SPEC]
	provides a general structure for the content of Internet messages and		provides a general structure for the content of Internet messages and
	allows extensions for new content-type-based applications.		allows extensions for new content-type-based applications.
	This specification defines how to create a MIME body part that has		This specification defines how to create a MIME body part that has
	been cryptographically enhanced according to the Cryptographic		been cryptographically enhanced according to the Cryptographic
	Message Syntax (CMS) [CMS], which is derived from PKCS #7 [RFC2315].		Message Syntax (CMS) [CMS], which is derived from PKCS #7 [RFC2315].
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 44 ¶
	unauthorized changes to data by ensuring that		unauthorized changes to data by ensuring that
	changes to the data are detectable. [RFC4949]		changes to the data are detectable. [RFC4949]
	Data Confidentiality: The property that data is not disclosed to		Data Confidentiality: The property that data is not disclosed to
	system entities unless they have been authorized		system entities unless they have been authorized
	to know the data. [RFC4949]		to know the data. [RFC4949]
	1.3. Conventions Used in This Document		1.3. 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		expect that a requirement marked as SHOULD+ will be
	promoted at some future time to be a MUST.		promoted 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.
	MUST- This term means the same as MUST. However, the authors		MUST- This term means the same as MUST. However, the authors
	expect that this requirement will no longer be a MUST in a		expect that this requirement will no longer be a MUST in a
	future document. Although its status will be determined at		future document. Although its status will be determined at
	a later time, it is reasonable to expect that if a future		a later time, it is reasonable to expect that if a future
	revision of a document alters the status of a MUST-		revision of a document alters the status of a MUST-
	requirement, it will remain at least a SHOULD or a SHOULD-.		requirement, it will remain at least a SHOULD or a SHOULD-.
	The term RSA in this document almost always refers to the PKCS#1 v1.5		The term RSA in this document almost always refers to the PKCS#1 v1.5
	RSA signature or encryption algorithms even when not qualified as		RSA [RFC2313] signature or encryption algorithms even when not
	such. There are a couple of places where it refers to the general		qualified as such. There are a couple of places where it refers to
	RSA cryptographic operation, these can be determined from the context		the general RSA cryptographic operation, these can be determined from
	where it is used.		the context where it is used.
	1.4. Compatibility with Prior Practice of S/MIME		1.4. Compatibility with Prior Practice of S/MIME
	S/MIME version 4.0 agents ought to attempt to have the greatest		S/MIME version 4.0 agents ought to attempt to have the greatest
	interoperability possible with agents for prior versions of S/MIME.		interoperability possible with agents for prior versions of S/MIME.
	S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive		S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
	[SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634		[SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
	inclusive and RFC 5035 [SMIMEv3], S/MIME version 3.1 is described in		inclusive and RFC 5035 [SMIMEv3], S/MIME version 3.1 is described in
	RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1], and		RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1], and
	S/MIME version 3.2 is described in [SMIMEv3.2]. [RFC2311] also has		S/MIME version 3.2 is described in [SMIMEv3.2]. [RFC2311] also has
	historical information about the development of S/MIME.		historical information about the development of S/MIME.
	1.5. Changes from S/MIME v3 to S/MIME v3.1		1.5. Changes from S/MIME v3 to S/MIME v3.1
	The RSA public key algorithm was changed to a MUST implement key		The RSA public key algorithm was changed to a MUST implement, key
	wrapping algorithm, and the Diffie-Hellman (DH) algorithm changed to		wrap algorithm, and the Diffie-Hellman (DH) algorithm [RFC2631]
	a SHOULD implement.		changed to a SHOULD implement.
	The AES symmetric encryption algorithm has been included as a SHOULD		The AES symmetric encryption algorithm has been included as a SHOULD
	implement.		implement.
	The RSA public key algorithm was changed to a MUST implement		The RSA public key algorithm was changed to a MUST implement
	signature algorithm.		signature algorithm.
	Ambiguous language about the use of "empty" SignedData messages to		Ambiguous language about the use of "empty" SignedData messages to
	transmit certificates was clarified to reflect that transmission of		transmit certificates was clarified to reflect that transmission of
	Certificate Revocation Lists is also allowed.		Certificate Revocation Lists is also allowed.
	skipping to change at page 9, line 36 ¶		skipping to change at page 9, line 44 ¶
	1.7. Changes for S/MIME v4.0		1.7. Changes for S/MIME v4.0
	- Add the use of AuthEnvelopedData, including defining and		- Add the use of AuthEnvelopedData, including defining and
	registering an smime-type value (Section 2.4.4 and Section 3.4).		registering an smime-type value (Section 2.4.4 and Section 3.4).
	- Update the content encryption algorithms (Section 2.7 and		- Update the content encryption algorithms (Section 2.7 and
	Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove		Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove
	AES-192 CBC, mark tripleDES as historic.		AES-192 CBC, mark tripleDES as historic.
	- Update the set of signature algorithms (Section 2.2): Add EdDSA		- Update the set of signature algorithms (Section 2.2): Add Edwards-
	and ECDSA, mark DSA as historic		curve DSA (EdDSA) and ECDSA, mark DSA as historic
	- Update the set of digest algorithms (Section 2.1): Add SHA-512,		- Update the set of digest algorithms (Section 2.1): Add SHA-512,
	mark SHA-1 as historic.		mark SHA-1 as historic.
	- Update the size of keys to be used for RSA encryption and RSA		- Update the size of keys to be used for RSA encryption and RSA
	signing (Section 4).		signing (Section 4).
	- Create Appendix B which deals with considerations for dealing with		- Create Appendix B which deals with considerations for dealing with
	historic email messages.		historic email messages.
	skipping to change at page 10, line 38 ¶		skipping to change at page 10, line 47 ¶
	There are different sets of requirements placed on receiving and		There are different sets of requirements placed on receiving and
	sending agents. By having the different requirements, the maximum		sending agents. By having the different requirements, the maximum
	amount of interoperability is achieved as it allows for specialized		amount of interoperability is achieved as it allows for specialized
	protection of private key material but maximum signature validation.		protection of private key material but maximum signature validation.
	Receiving agents:		Receiving agents:
	- MUST support ECDSA with curve P-256 and SHA-256.		- MUST support ECDSA with curve P-256 and SHA-256.
	- MUST support EdDSA with curve 25519 using PureEdDSA mode.		- MUST support EdDSA with curve 25519 using Pure EdDSA mode
			[I-D.ietf-curdle-cms-eddsa-signatures].
	- MUST- support RSA PKCS#1 v1.5 with SHA-256.		- MUST- support RSA PKCS#1 v1.5 with SHA-256.
	- SHOULD support RSASSA-PSS with SHA-256.		- . SHOULD support RSASSA-PSS with SHA-256.
	Sending agents:		Sending agents:
	- MUST support at least one of the following algorithms: ECDSA with		- MUST support at least one of the following algorithms: ECDSA with
	curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA		curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA
	mode.		mode.
	- MUST- support RSA PKCS#1 v1.5 with SHA-256.		- MUST- support RSA PKCS#1 v1.5 with SHA-256.
	- SHOULD support RSASSA-PSS with SHA-256.		- SHOULD support RSASSA-PSS with SHA-256.
	Both ECDSA and EdDSA are included in the list of required algorithms		Both ECDSA and EdDSA are included in the list of required algorithms
	for political reasons. NIST is unable to provide the seeds that were		for political reasons. NIST is unable to provide the seeds that were
	used to create their standardized curves, this means that there is a		used to create their standardized curves; this means that there is a
	section of the community which believes that there might be a back		section of the community which believes that there might be a back
	door to these curves. The EdDSA curves were standardized in the IETF		door to these curves. The EdDSA curves were standardized in the IETF
	in a more transparent method. However, there are still significant		in a more transparent method. However, there are still significant
	sections of the industry which need to have NIST approved algorithms.		sections of the industry which need to have NIST approved algorithms.
	For this reason, both sets of curves are represented in the receiving		For this reason, both sets of curves are represented in the receiving
	agent list, but there is only a requirement for curve in the sending		agent list, but there is only a requirement for one curve in the
	agent list. This requirement makes sure that maximum		sending agent list. This requirement makes sure that maximum
	interoperability between receivers and senders will exist.		interoperability between receivers and senders will exist.
	See Section 4.1 for information on key size and algorithm references.		See Section 4.1 for information on key size and algorithm references.
	2.3. KeyEncryptionAlgorithmIdentifier		2.3. KeyEncryptionAlgorithmIdentifier
	Receiving and sending agents:		Receiving and sending agents:
	- MUST support ECDH ephemeral-static mode for P-256, as specified in		- MUST support ECDH ephemeral-static mode for P-256, as specified in
	[RFC5753].		[RFC5753].
	skipping to change at page 11, line 44 ¶		skipping to change at page 11, line 52 ¶
	- SHOULD+ support RSAES-OAEP, as specified in [RFC3560].		- SHOULD+ support RSAES-OAEP, as specified in [RFC3560].
	When ECDH ephemeral-static is used, a key wrap algorithm is also		When ECDH ephemeral-static is used, a key wrap algorithm is also
	specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The		specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The
	underlying encryption functions for the key wrap and content		underlying encryption functions for the key wrap and content
	encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for		encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for
	the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm		the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
	with AES-128 content encryption algorithm). As both 128 and 256 bit		with AES-128 content encryption algorithm). As both 128 and 256 bit
	AES modes are mandatory-to-implement as content encryption algorithms		AES modes are mandatory-to-implement as content encryption algorithms
	(Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST		(Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST
	be supported when ECDH ephemeral-static is used.		be supported when ECDH ephemeral-static is used. Recipients MAY
			enforce this, but MUST use the weaker of the two as part of any
			cryptographic strength computation it might do.
	Appendix B provides information on algorithms support in older		Appendix B provides information on algorithms support in older
	versions of S/MIME.		versions of S/MIME.
	2.4. General Syntax		2.4. General Syntax
	There are several CMS content types. Of these, only the Data,		There are several CMS content types. Of these, only the Data,
	SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData		SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData
	content types are currently used for S/MIME.		content types are currently used for S/MIME.
	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 42 ¶
	Sending agents MUST use the SignedData content type to apply a		Sending agents MUST use the SignedData content type to apply a
	digital signature to a message or, in a degenerate case where there		digital signature to a message or, in a degenerate case where there
	is no signature information, to convey certificates. Applying a		is no signature information, to convey certificates. Applying a
	signature to a message provides authentication, message integrity,		signature to a message provides authentication, message integrity,
	and non-repudiation of origin.		and non-repudiation of origin.
	2.4.3. EnvelopedData Content Type		2.4.3. EnvelopedData Content Type
	This content type is used to apply data confidentiality to a message.		This content type is used to apply data confidentiality to a message.
	A sender needs to have access to a public key for each intended		In order to distribute the symmetric key, a sender needs to have
	message recipient to use this service.		access to a public key for each intended message recipient to use
			this service.
	2.4.4. AuthEnvelopedData Content Type		2.4.4. AuthEnvelopedData Content Type
	This content type is used to apply data confidentiality and message		This content type is used to apply data confidentiality and message
	integrity to a message. This content type does not provide		integrity to a message. This content type does not provide
	authentication or non-repudiation. A sender needs to have access to		authentication or non-repudiation. In order to distribute the
	a public key for each intended message recipient to use this service.		symmetric key, a sender needs to have access to a public key for each
			intended message recipient to use this service.
	2.4.5. CompressedData Content Type		2.4.5. CompressedData Content Type
	This content type is used to apply data compression to a message.		This content type is used to apply data compression to a message.
	This content type does not provide authentication, message integrity,		This content type does not provide authentication, message integrity,
	non-repudiation, or data confidentiality, and is only used to reduce		non-repudiation, or data confidentiality, and is only used to reduce
	the message's size.		the message's size.
	See Section 3.7 for further guidance on the use of this type in		See Section 3.7 for further guidance on the use of this type in
	conjunction with other CMS types.		conjunction with other CMS types.
	2.5. Attributes and the SignerInfo Type		2.5. Attributes and the SignerInfo Type
	The SignerInfo type allows the inclusion of unsigned and signed		The SignerInfo type allows the inclusion of unsigned and signed
	attributes along with a signature.		attributes along with a signature. These attributes can be required
			for processing of message (i.e. Message Digest), information the
			signer supplied (i.e. SMIME Capabilities) that should be processed,
			or attributes which are not relevant in the current situation (i.e.
			mlExpansionList [RFC2634] for mail viewers).
	Receiving agents MUST be able to handle zero or one instance of each		Receiving agents MUST be able to handle zero or one instance of each
	of the signed attributes listed here. Sending agents SHOULD generate		of the signed attributes listed here. Sending agents SHOULD generate
	one instance of each of the following signed attributes in each		one instance of each of the following signed attributes in each
	S/MIME message:		S/MIME message:
	- Signing Time (Section 2.5.1 in this document)		- Signing Time (Section 2.5.1 in this document)
	- SMIME Capabilities (Section 2.5.2 in this document)		- SMIME Capabilities (Section 2.5.2 in this document)
	skipping to change at page 13, line 49 ¶		skipping to change at page 14, line 17 ¶
	values that they do not recognize in a graceful manner.		values that they do not recognize in a graceful manner.
	Interactive sending agents that include signed attributes that are		Interactive sending agents that include signed attributes that are
	not listed here SHOULD display those attributes to the user, so that		not listed here SHOULD display those attributes to the user, so that
	the user is aware of all of the data being signed.		the user is aware of all of the data being signed.
	2.5.1. Signing Time Attribute		2.5.1. Signing Time Attribute
	The signing-time attribute is used to convey the time that a message		The signing-time attribute is used to convey the time that a message
	was signed. The time of signing will most likely be created by a		was signed. The time of signing will most likely be created by a
	message originator and therefore is only as trustworthy as the		signer and therefore is only as trustworthy as that signer.
	originator.
	Sending agents MUST encode signing time through the year 2049 as		Sending agents MUST encode signing time through the year 2049 as
	UTCTime; signing times in 2050 or later MUST be encoded as		UTCTime; signing times in 2050 or later MUST be encoded as
	GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST		GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
	interpret the year field (YY) as follows:		interpret the year field (YY) as follows:
	If YY is greater than or equal to 50, the year is interpreted as		If YY is greater than or equal to 50, the year is interpreted as
	19YY; if YY is less than 50, the year is interpreted as 20YY.		19YY; if YY is less than 50, the year is interpreted as 20YY.
	Receiving agents MUST be able to process signing-time attributes that		Receiving agents MUST be able to process signing-time attributes that
	skipping to change at page 19, line 10 ¶		skipping to change at page 19, line 25 ¶
	recipient,		recipient,
	then the sending agent SHOULD use AES-256 GCM because it is a		then the sending agent SHOULD use AES-256 GCM because it is a
	stronger algorithm and is required by S/MIME v4.0. If the sending		stronger algorithm and is required by S/MIME v4.0. If the sending
	agent chooses not to use AES-256 GCM in this step, given the		agent chooses not to use AES-256 GCM in this step, given the
	presumption is that a client implementing AES-GCM would do both		presumption is that a client implementing AES-GCM would do both
	AES-256 and AES-128, it SHOULD use AES-128 CBC.		AES-256 and AES-128, it SHOULD use AES-128 CBC.
	2.7.2. Choosing Weak Encryption		2.7.2. Choosing Weak Encryption
	All algorithms that use 112-bit keys are considered by many to be		Algorithms such as RC2 are considered to be weak encryption
	weak encryption. A sending agent that is controlled by a human		algorithms. Algorithms such as TripleDES are not state of the art
	SHOULD allow a human sender to determine the risks of sending data		and are considered to be weaker algorithms than AES. A sending agent
	using a weak encryption algorithm before sending the data, and		that is controlled by a human SHOULD allow a human sender to
	possibly allow the human to use a stronger encryption method such as		determine the risks of sending data using a weaker encryption
	AES GCM or AES CBC.		algorithm before sending the data, and possibly allow the human to
			use a stronger encryption algorithm such as AES GCM or AES CBC even
			if there is a possibility that the recipient will not be able to
			process that algorithm.
	2.7.3. Multiple Recipients		2.7.3. Multiple Recipients
	If a sending agent is composing an encrypted message to a group of		If a sending agent is composing an encrypted message to a group of
	recipients where the encryption capabilities of some of the		recipients where the encryption capabilities of some of the
	recipients do not overlap, the sending agent is forced to send more		recipients do not overlap, the sending agent is forced to send more
	than one message. Please note that if the sending agent chooses to		than one message. Please note that if the sending agent chooses to
	send a message encrypted with a strong algorithm, and then send the		send a message encrypted with a strong algorithm, and then send the
	same message encrypted with a weak algorithm, someone watching the		same message encrypted with a weak algorithm, someone watching the
	communications channel could learn the contents of the strongly		communications channel could learn the contents of the strongly
	skipping to change at page 25, line 23 ¶		skipping to change at page 25, line 29 ¶
	agent to decode the ASN.1 for the object. The Content-Type header		agent to decode the ASN.1 for the object. The Content-Type header
	field of all application/pkcs7-mime objects SHOULD include the		field of all application/pkcs7-mime objects SHOULD include the
	optional "smime-type" parameter, as described in the following		optional "smime-type" parameter, as described in the following
	sections.		sections.
	3.2.1. The name and filename Parameters		3.2.1. The name and filename Parameters
	For the application/pkcs7-mime, sending agents SHOULD emit the		For the application/pkcs7-mime, sending agents SHOULD emit the
	optional "name" parameter to the Content-Type field for compatibility		optional "name" parameter to the Content-Type field for compatibility
	with older systems. Sending agents SHOULD also emit the optional		with older systems. Sending agents SHOULD also emit the optional
	Content-Disposition field [RFC2138] with the "filename" parameter.		Content-Disposition field [RFC2183] with the "filename" parameter.
	If a sending agent emits the above parameters, the value of the		If a sending agent emits the above parameters, the value of the
	parameters SHOULD be a file name with the appropriate extension:		parameters SHOULD be a file name with the appropriate extension:
	Media Type File		Media Type File
	Extension		Extension
	application/pkcs7-mime (SignedData, EnvelopedData, .p7m		application/pkcs7-mime (SignedData, EnvelopedData, .p7m
	AuthEnvelopedData)		AuthEnvelopedData)
	application/pkcs7-mime (degenerate SignedData certificate .p7c		application/pkcs7-mime (degenerate SignedData certificate .p7c
	management message)		management message)
	application/pkcs7-mime (CompressedData) .p7z		application/pkcs7-mime (CompressedData) .p7z
	skipping to change at page 28, line 10 ¶		skipping to change at page 28, line 10 ¶
	iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC		iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC
	bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip		bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip
	dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA		dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA
	gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU=		gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU=
	3.4. Creating an Authenticated Enveloped-Only Message		3.4. Creating an Authenticated Enveloped-Only Message
	This section describes the format for enveloping a MIME entity		This section describes the format for enveloping a MIME entity
	without signing it. Authenticated enveloped messages provide		without signing it. Authenticated enveloped messages provide
	confidentiality and data integrity. It is important to note that		confidentiality and data integrity. It is important to note that
	sending authenticated enveloped messages does not provide for		sending authenticated enveloped messages does not provide for proof
	origination when using S/MIME. It is possible for a third party to		of origination when using S/MIME. It is possible for a third party
	replace ciphertext in such a way that the processed message will		to replace ciphertext in such a way that the processed message will
	still be valid, but the meaning can be altered. However this is		still be valid, but the meaning can be altered. However this is
	substantially more difficult than it is for an enveloped-only message		substantially more difficult than it is for an enveloped-only message
	as the algorithm does provide a level of authentication. Any		as the algorithm does provide a level of authentication. Any
	recipient for whom the message is encrypted can replace it without		recipient for whom the message is encrypted can replace it without
	detection.		detection.
	Step 1. The MIME entity to be enveloped is prepared according to		Step 1. The MIME entity to be enveloped is prepared according to
	Section 3.1.		Section 3.1.
	Step 2. The MIME entity and other required data is processed into a		Step 2. The MIME entity and other required data is processed into a
	skipping to change at page 45, line 16 ¶		skipping to change at page 45, line 16 ¶
	National Institute of Standards and Technology (NIST),		National Institute of Standards and Technology (NIST),
	"Digital Signature Standard (DSS)", Federal Information		"Digital Signature Standard (DSS)", Federal Information
	Processing Standards Publication 186-4, July 2013.		Processing Standards Publication 186-4, July 2013.
	[I-D.ietf-curdle-cms-ecdh-new-curves]		[I-D.ietf-curdle-cms-ecdh-new-curves]
	Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key		Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
	Agreement Algorithm with X25519 and X448 in the		Agreement Algorithm with X25519 and X448 in the
	Cryptographic Message Syntax (CMS)", draft-ietf-curdle-		Cryptographic Message Syntax (CMS)", draft-ietf-curdle-
	cms-ecdh-new-curves-10 (work in progress), August 2017.		cms-ecdh-new-curves-10 (work in progress), August 2017.
			[I-D.ietf-curdle-cms-eddsa-signatures]
			Housley, R., "Use of EdDSA Signatures in the Cryptographic
			Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
			signatures-08 (work in progress), October 2017.
	[I-D.ietf-lamps-rfc5750-bis]		[I-D.ietf-lamps-rfc5750-bis]
	Schaad, J., Ramsdell, B., and S. Turner, "Secure/		Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/ MIME) Version		Multipurpose Internet Mail Extensions (S/ MIME) Version
	4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-04		4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-05
	(work in progress), April 2017.		(work in progress), April 2018.
	[MIME-SPEC]		[MIME-SPEC]
	"MIME Message Specifications".		"MIME Message Specifications".
	This is the set of documents that define how to use MIME.		This is the set of documents that define how to use MIME.
	This set of documents is [RFC2045], [RFC2046], [RFC2047],		This set of documents is [RFC2045], [RFC2046], [RFC2047],
	[RFC2049], [RFC4288], and [RFC4289].		[RFC2049], [RFC6838], and [RFC4289].
	[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,		[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
	"Security Multiparts for MIME: Multipart/Signed and		"Security Multiparts for MIME: Multipart/Signed and
	Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,		Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
	October 1995, <https://www.rfc-editor.org/info/rfc1847>.		October 1995, <https://www.rfc-editor.org/info/rfc1847>.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,		Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
	<https://www.rfc-editor.org/info/rfc2045>.		<https://www.rfc-editor.org/info/rfc2045>.
	skipping to change at page 46, line 10 ¶		skipping to change at page 46, line 15 ¶
	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Five: Conformance Criteria and		Extensions (MIME) Part Five: Conformance Criteria and
	Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,		Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
	<https://www.rfc-editor.org/info/rfc2049>.		<https://www.rfc-editor.org/info/rfc2049>.
	[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>.
	[RFC2138] Rigney, C., Rubens, A., Simpson, W., and S. Willens,		[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
	"Remote Authentication Dial In User Service (RADIUS)",		Presentation Information in Internet Messages: The
	RFC 2138, DOI 10.17487/RFC2138, April 1997,		Content-Disposition Header Field", RFC 2183,
	<https://www.rfc-editor.org/info/rfc2138>.		DOI 10.17487/RFC2183, August 1997,
			<https://www.rfc-editor.org/info/rfc2183>.
	[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>.
	[RFC3274] Gutmann, P., "Compressed Data Content Type for		[RFC3274] Gutmann, P., "Compressed Data Content Type for
	Cryptographic Message Syntax (CMS)", RFC 3274,		Cryptographic Message Syntax (CMS)", RFC 3274,
	DOI 10.17487/RFC3274, June 2002,		DOI 10.17487/RFC3274, June 2002,
	<https://www.rfc-editor.org/info/rfc3274>.		<https://www.rfc-editor.org/info/rfc3274>.
	skipping to change at page 46, line 48 ¶		skipping to change at page 47, line 5 ¶
	[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in		[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
	Cryptographic Message Syntax (CMS)", RFC 4056,		Cryptographic Message Syntax (CMS)", RFC 4056,
	DOI 10.17487/RFC4056, June 2005,		DOI 10.17487/RFC4056, June 2005,
	<https://www.rfc-editor.org/info/rfc4056>.		<https://www.rfc-editor.org/info/rfc4056>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", RFC 4288, DOI 10.17487/RFC4288,
	December 2005, <https://www.rfc-editor.org/info/rfc4288>.
	[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail		[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
	Extensions (MIME) Part Four: Registration Procedures",		Extensions (MIME) Part Four: Registration Procedures",
	BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,		BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
	<https://www.rfc-editor.org/info/rfc4289>.		<https://www.rfc-editor.org/info/rfc4289>.
	[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:		[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
	Adding CertID Algorithm Agility", RFC 5035,		Adding CertID Algorithm Agility", RFC 5035,
	DOI 10.17487/RFC5035, August 2007,		DOI 10.17487/RFC5035, August 2007,
	<https://www.rfc-editor.org/info/rfc5035>.		<https://www.rfc-editor.org/info/rfc5035>.
	skipping to change at page 47, line 38 ¶		skipping to change at page 47, line 38 ¶
	[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve		[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
	Cryptography (ECC) Algorithms in Cryptographic Message		Cryptography (ECC) Algorithms in Cryptographic Message
	Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January		Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
	2010, <https://www.rfc-editor.org/info/rfc5753>.		2010, <https://www.rfc-editor.org/info/rfc5753>.
	[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic		[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
	Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January		Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
	2010, <https://www.rfc-editor.org/info/rfc5754>.		2010, <https://www.rfc-editor.org/info/rfc5754>.
			[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
			Specifications and Registration Procedures", BCP 13,
			RFC 6838, DOI 10.17487/RFC6838, January 2013,
			<https://www.rfc-editor.org/info/rfc6838>.
			[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>.
	[SMIMEv4.0]		[SMIMEv4.0]
	"S/MIME version 4.0".		"S/MIME version 4.0".
	This group of documents represents S/MIME version 4.0.		This group of documents represents S/MIME version 4.0.
	This set of documents are [RFC2634],		This set of documents are [RFC2634],
	[I-D.ietf-lamps-rfc5750-bis], [[This Document]],		[I-D.ietf-lamps-rfc5750-bis], [[This Document]],
	[RFC5652], and [RFC5035].		[RFC5652], and [RFC5035].
	[X.680] "Information Technology - Abstract Syntax Notation One		[X.680] "Information Technology - Abstract Syntax Notation One
	(ASN.1): Specification of basic notation. ITU-T		(ASN.1): Specification of basic notation. ITU-T
	Recommendation X.680 (2002)", ITU-T X.680, ISO/		Recommendation X.680 (2002)", ITU-T X.680, ISO/
	IEC 8824-1:2008, November 2008.		IEC 8824-1:2008, November 2008.
	[X.681] "Information Technology - Abstract Syntax Notation One		[X.681] "Information Technology - Abstract Syntax Notation One
	(ASN.1): Information object specification", ITU-T X.681,		(ASN.1): Information object specification", ITU-T X.681,
End of changes. 36 change blocks.
	58 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/