< draft-ietf-lamps-rfc5750-bis-04.txt		draft-ietf-lamps-rfc5750-bis-05.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 9, 2017 S. Turner		Expires: October 15, 2018 S. Turner
	sn3rd		sn3rd
	April 7, 2017		April 13, 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-04		draft-ietf-lamps-rfc5750-bis-05
	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 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	be discussed on the LAMPS mailing list.		be discussed on the LAMPS mailing list.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://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 9, 2017.		This Internet-Draft will expire on October 15, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 50 ¶
	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 . . . . . . . . . . . . . . . . 6
	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 . . . . . . . 7
	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 . . . . . . . . . . . . . . . 11		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 . . 12
	4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 13		4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 13
	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 . . . . . . . . . . . 14
	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 . . . . . . . . . . . . 15
	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 . . . . . . . . . . . . . . . . 20		7.2. Informational References . . . . . . . . . . . . . . . . 21
	Appendix A. Historic Considerations . . . . . . . . . . . . . . 23		Appendix A. Historic Considerations . . . . . . . . . . . . . . 23
	A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 23		A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 23
	Appendix B. Moving S/MIME v2 Certificate Handling to Historic		Appendix B. Moving S/MIME v2 Certificate Handling to Historic
	Status . . . . . . . . . . . . . . . . . . . . . . . 24		Status . . . . . . . . . . . . . . . . . . . . . . . 25
	Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 24		Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	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
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 22 ¶
	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], and S/MIME version 3.1 is described		inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described
	in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1].		in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1].
	RFC 2311 also has historical information about the development of		RFC 2311 also has historical information about the development of
	S/MIME.		S/MIME.
	Appendix A contains information about algorithms are were used for		Appendix A contains information about algorithms that were used for
	prior versions of S/MIME but are no longer considered to meet modern		prior versions of S/MIME but are no longer considered to meet modern
	security standards. Support of these algorithms may be needed to		security standards. Support of these algorithms may be needed to
	support historic S/MIME messages but SHOULD NOT be used for new mail.		support historic S/MIME messages but SHOULD NOT be used for new mail.
	1.4. Changes from S/MIME v3 to S/MIME v3.1		1.4. Changes from S/MIME v3 to S/MIME v3.1
	Version 1 and version 2 CRLs MUST be supported.		Version 1 and version 2 CRLs MUST be supported.
	Multiple certification authority (CA) certificates with the same		Multiple certification authority (CA) certificates with the same
	subject and public key, but with overlapping validity periods, MUST		subject and public key, but with overlapping validity periods, MUST
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 49 ¶
	discouraged, and security language was added.		discouraged, and security language was added.
	Clarified use of email address use in certificates. Certificates		Clarified use of email address use in certificates. Certificates
	that do not contain an email address have no requirements for		that do not contain an email address have no requirements for
	verifying the email address associated with the certificate.		verifying the email address associated with the certificate.
	Receiving agents SHOULD display certificate information when		Receiving agents SHOULD display certificate information when
	displaying the results of signature verification.		displaying the results of signature verification.
	Receiving agents MUST NOT accept a signature made with a certificate		Receiving agents MUST NOT accept a signature made with a certificate
	that does not have the digitalSignature or nonRepudiation bit set.		that does not have at least one of the the digitalSignature or
			nonRepudiation bits set.
	Clarifications for the interpretation of the key usage and extended		Clarifications for the interpretation of the key usage and extended
	key usage extensions.		key usage extensions.
	1.5. Changes from S/MIME v3.1 to S/MIME v3.2		1.5. Changes from S/MIME v3.1 to S/MIME v3.2
	Conventions Used in This Document: Moved to Section 1.2. Added		Conventions Used in This Document: Moved to Section 1.2. Added
	definitions for SHOULD+, SHOULD-, and MUST-.		definitions for SHOULD+, SHOULD-, and MUST-.
	Section 1.1: Updated ASN.1 definition and reference.		Section 1.1: Updated ASN.1 definition and reference.
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 21 ¶
	content and algorithm support. This section puts forth a number of		content and algorithm support. This section puts forth a number of
	support requirements and recommendations in order to achieve a base		support requirements and recommendations in order to achieve a base
	level of interoperability among all S/MIME implementations. Most of		level of interoperability among all S/MIME implementations. Most of
	the CMS format for S/MIME messages is defined in [RFC5751].		the CMS format for S/MIME messages is defined in [RFC5751].
	2.1. Certificate Revocation Lists		2.1. Certificate Revocation Lists
	Receiving agents MUST support the Certificate Revocation List (CRL)		Receiving agents MUST support the Certificate Revocation List (CRL)
	format defined in [RFC5280]. If sending agents include CRLs in		format defined in [RFC5280]. If sending agents include CRLs in
	outgoing messages, the CRL format defined in [RFC5280] MUST be used.		outgoing messages, the CRL format defined in [RFC5280] MUST be used.
	In all cases, both v1 and v2 CRLs MUST be supported.		Receiving agents MUST support both v1 and v2 CRLs.
	All agents MUST be capable of performing revocation checks using CRLs		All agents MUST be capable of performing revocation checks using CRLs
	as specified in [RFC5280]. All agents MUST perform revocation status		as specified in [RFC5280]. All agents MUST perform revocation status
	checking in accordance with [RFC5280]. Receiving agents MUST		checking in accordance with [RFC5280]. Receiving agents MUST
	recognize CRLs in received S/MIME messages.		recognize CRLs in received S/MIME messages.
	Agents SHOULD store CRLs received in messages for use in processing		Agents SHOULD store CRLs received in messages for use in processing
	later messages.		later messages.
	2.2. Certificate Choices		2.2. Certificate Choices
	skipping to change at page 7, line 48 ¶		skipping to change at page 7, line 51 ¶
	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
			extended certificates.
	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 9, line 11 ¶		skipping to change at page 9, line 18 ¶
	Receiving agents SHOULD support the decoding of X.509 attribute		Receiving agents SHOULD support the decoding of X.509 attribute
	certificates included in CMS objects. All other issues regarding the		certificates included in CMS objects. All other issues regarding the
	generation and use of X.509 attribute certificates are outside of the		generation and use of X.509 attribute certificates are outside of the
	scope of this specification. One specification that addresses		scope of this specification. One specification that addresses
	attribute certificate use is defined in [RFC3114].		attribute certificate use is defined in [RFC3114].
	3. Using Distinguished Names for Internet Mail		3. Using Distinguished Names for Internet Mail
	End-entity certificates MAY contain an Internet mail address. Email		End-entity certificates MAY contain an Internet mail address. Email
	addresses retricted to 7-bit ASCII characters are encoded as		addresses restricted to 7-bit ASCII characters use the pkcs-9-at-
	described in Section 4.2.1.6 of [RFC5280]. Internationalized Email		emailAddress OID (see below) and are encoded as described in
	address names are encoded as described in		Section 4.2.1.6 of [RFC5280]. Internationalized Email address names
	[I-D.ietf-lamps-eai-addresses]. The email address SHOULD be in the		use the OID defined in [I-D.ietf-lamps-eai-addresses] and are encoded
			as described there. The email address SHOULD be in the
	subjectAltName extension, and SHOULD NOT be in the subject		subjectAltName extension, and SHOULD NOT be in the subject
	distinguished name.		distinguished name.
	Receiving agents MUST recognize and accept certificates that contain		Receiving agents MUST recognize and accept certificates that contain
	no email address. Agents are allowed to provide an alternative		no email address. Agents are allowed to provide an alternative
	mechanism for associating an email address with a certificate that		mechanism for associating an email address with a certificate that
	does not contain an email address, such as through the use of the		does not contain an email address, such as through the use of the
	agent's address book, if available. Receiving agents MUST recognize		agent's address book, if available. Receiving agents MUST recognize
	both ASCII and internationalized email addresses in the		both ASCII and internationalized email addresses in the
	subjectAltName field. Receiving agents MUST recognize email		subjectAltName field. Receiving agents MUST recognize email
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 11 ¶
	transformations on the local name component before doing the		transformations on the local name component before doing the
	comparison, however an S/MIME client cannot know what specific		comparison, however an S/MIME client cannot know what specific
	localities do.		localities do.
	Sending agents SHOULD make the address in the From or Sender header		Sending agents SHOULD make the address in the From or Sender header
	in a mail message match an Internet mail address in the signer's		in a mail message match an Internet mail address in the signer's
	certificate. Receiving agents MUST check that the address in the		certificate. Receiving agents MUST check that the address in the
	From or Sender header of a mail message matches an Internet mail		From or Sender header of a mail message matches an Internet mail
	address in the signer's certificate, if mail addresses are present in		address in the signer's certificate, if mail addresses are present in
	the certificate. A receiving agent SHOULD provide some explicit		the certificate. A receiving agent SHOULD provide some explicit
	alternate processing of the message if this comparison fails, which		alternate processing of the message if this comparison fails, this
	may be to display a message that shows the recipient the addresses in		might be done by displaying or logging a message that shows the
	the certificate or other certificate details.		recipient the mail addresses in the certificate or other certificate
			details.
	A receiving agent SHOULD display a subject name or other certificate		A receiving agent SHOULD display a subject name or other certificate
	details when displaying an indication of successful or unsuccessful		details when displaying an indication of successful or unsuccessful
	signature verification.		signature verification.
	All subject and issuer names MUST be populated (i.e., not an empty		All subject and issuer names MUST be populated (i.e., not an empty
	SEQUENCE) in S/MIME-compliant X.509 certificates, except that the		SEQUENCE) in S/MIME-compliant X.509 certificates, except that the
	subject distinguished name (DN) in a user's (i.e., end-entity)		subject distinguished name (DN) in a user's (i.e., end-entity)
	certificate MAY be an empty SEQUENCE in which case the subjectAltName		certificate MAY be an empty SEQUENCE in which case the subjectAltName
	extension will include the subject's identifier and MUST be marked as		extension will include the subject's identifier and MUST be marked as
	skipping to change at page 10, line 45 ¶		skipping to change at page 11, line 4 ¶
	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
	its simplest form, a certificate database would be local to a		its simplest form, a certificate database would be local to a
	particular user and would function in a similar way as an "address		particular user and would function in a similar way as an "address
	book" that stores a user's frequent correspondents. In this way, the		book" that stores a user's frequent correspondents. In this way, the
	certificate retrieval mechanism would be limited to the certificates		certificate retrieval mechanism would be limited to the certificates
	that a user has stored (presumably from incoming messages). A		that a user has stored (presumably from incoming messages). A
	comprehensive certificate retrieval/storage solution may combine two		comprehensive certificate retrieval/storage solution might combine
	or more mechanisms to allow the greatest flexibility and utility to		two or more mechanisms to allow the greatest flexibility and utility
	the user. For instance, a secure Internet mail agent may resort to		to the user. For instance, a secure Internet mail agent might resort
	checking a centralized certificate retrieval mechanism for a		to checking a centralized certificate retrieval mechanism for a
	certificate if it cannot be found in a user's local certificate		certificate if it cannot be found in a user's local certificate
	storage/retrieval database.		storage/retrieval database.
	Receiving and sending agents SHOULD provide a mechanism for the		Receiving and sending agents SHOULD provide a mechanism for the
	import and export of certificates, using a CMS certs-only message.		import and export of certificates, using a CMS certs-only message.
	This allows for import and export of full certificate chains as		This allows for import and export of full certificate chains as
	opposed to just a single certificate. This is described in		opposed to just a single certificate. This is described in
	[RFC5751].		[RFC5751].
	Agents MUST handle multiple valid certification authority (CA)		Agents MUST handle multiple valid certification authority (CA)
	skipping to change at page 12, line 42 ¶		skipping to change at page 13, line 5 ¶
	4.3. Certificate and CRL Signing Algorithms and Key Sizes		4.3. Certificate and CRL Signing Algorithms and Key Sizes
	Certificates and Certificate Revocation Lists (CRLs) are signed by		Certificates and Certificate Revocation Lists (CRLs) are signed by
	the certificate issuer. Receiving agents:		the certificate issuer. Receiving agents:
	- MUST support ECDSA with curve P-256 with SHA-256.		- MUST support ECDSA with curve P-256 with SHA-256.
	- MUST support EdDSA with curve 25519 using PureEdDSA mode.		- MUST support EdDSA with curve 25519 using PureEdDSA mode.
	- MUST- support RSA 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.
	- MUST NOT support EdDSA using Pre-hash mode.
	Implementations SHOULD use deterministic generation for the parameter		Implementations SHOULD use deterministic generation for the parameter
	'k' for ECDSA as outlined in [RFC6979]. EdDSA is defined to generate		'k' for ECDSA as outlined in [RFC6979]. EdDSA is defined to generate
	this parameter deterministically.		this parameter deterministically.
	The following are the RSA and RSASSA-PSS key size requirements for		The following are the RSA and RSASSA-PSS key size requirements for
	S/MIME receiving agents during certificate and CRL signature		S/MIME receiving agents during certificate and CRL signature
	verification:		verification:
	key size <= 2047 : SHOULD NOT (see Historic Considerations)		key size <= 2047 : SHOULD NOT (see Historic Considerations)
	2048 <= key size <= 4096 : MUST (see Security Considerations)		2048 <= key size <= 4096 : MUST (see Security Considerations)
	skipping to change at page 14, line 25 ¶		skipping to change at page 14, line 32 ¶
	Interpretation and syntax for all extensions MUST follow [RFC5280],		Interpretation and syntax for all extensions MUST follow [RFC5280],
	unless otherwise specified here.		unless otherwise specified here.
	4.4.1. Basic Constraints		4.4.1. Basic Constraints
	The basic constraints extension serves to delimit the role and		The basic constraints extension serves to delimit the role and
	position that an issuing authority or end-entity certificate plays in		position that an issuing authority or end-entity certificate plays in
	a certification path.		a certification path.
	For example, certificates issued to CAs and subordinate CAs contain a		For example, certificates issued to CAs and subordinate CAs contain a
	basic constraint extension that identifies them as issuing authority		basic constraints extension that identifies them as issuing authority
	certificates. End-entity certificates contain the key usage		certificates. End-entity certificates contain the key usage
	extension that restrains end entities from using the key when		extension that restrains end-entities from using the key when
	performing issuing authority operations (see Section 4.4.2).		performing issuing authority operations (see Section 4.4.2).
	As per [RFC5280], certificates MUST contain a basicConstraints		As per [RFC5280], certificates MUST contain a basicConstraints
	extension in CA certificates, and SHOULD NOT contain that extension		extension in CA certificates, and SHOULD NOT contain that extension
	in end- entity certificates.		in end-entity certificates.
	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 public key listed in a valid certificate may be used.		which a public key listed in a valid certificate may be used.
	Issuing authority certificates may contain a key usage extension that		Issuing authority certificates may contain a key usage extension that
	restricts the key to signing certificates, certificate revocation		restricts the key to 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 that contain a key usage extension that specifies that		certificates that contain a key usage extension that specifies that
	the corresponding public key can be used to sign end user		the corresponding public key can be used to sign end user
	certificates and sign CRLs.		certificates and sign CRLs.
	If a key usage extension is included in a PKIX certificate, then it		If a key usage extension is included in a PKIX certificate, then it
	MUST be marked as critical.		MUST be marked as critical.
	S/MIME receiving agents MUST NOT accept the signature of a message if		S/MIME receiving agents MUST NOT accept the signature of a message if
	it was verified using a certificate that contains the key usage		it was verified using a certificate that contains the key usage
	extension without either the digitalSignature or nonRepudiation bit		extension without at least one of the digitalSignature or
	set. Sometimes S/MIME is used as a secure message transport for		nonRepudiation bits set. Sometimes S/MIME is used as a secure
	applications beyond interpersonal messaging. In such cases, the		message transport for applications beyond interpersonal messaging; in
	S/MIME-enabled application can specify additional requirements		such cases, the S/MIME-enabled application can specify additional
	concerning the digitalSignature or nonRepudiation bits within this		requirements concerning the digitalSignature or nonRepudiation bits
	extension.		within this extension.
	If the key usage extension is not specified, receiving clients MUST		If the key usage extension is not specified, receiving clients MUST
	presume that the digitalSignature and nonRepudiation bits are set.		presume that both the digitalSignature and nonRepudiation bits are
			set.
	4.4.3. Subject Alternative Name		4.4.3. Subject Alternative Name
	The subject alternative name extension is used in S/MIME as the		The subject alternative name extension is used in S/MIME as the
	preferred means to convey the email address(es) that correspond(s) to		preferred means to convey the email address(es) that correspond(s) to
	the entity for this certificate. Any ASCII email addresses present		the entity for this certificate. If the local portion of the email
	MUST be encoded using the rfc822Name CHOICE of the GeneralName type		address is ASCII, it MUST be encoded using the rfc822Name CHOICE of
	as described in [RFC5280], Section 4.2.1.6. Any internationalized		the GeneralName type as described in [RFC5280], Section 4.2.1.6. If
	email addresses present MUST be encoded using the otherName CHOICE of		the local portion of the email address is not ASCII, it MUST be
	the GeneralName type as described in [I-D.ietf-lamps-eai-addresses],		encoded using the otherName CHOICE of the GeneralName type as
	Section 3. Since the SubjectAltName type is a SEQUENCE OF		described in [I-D.ietf-lamps-eai-addresses], Section 3. Since the
	GeneralName, multiple email addresses MAY be present.		SubjectAltName type is a SEQUENCE OF GeneralName, multiple email
			addresses MAY be present.
	4.4.4. Extended Key Usage Extension		4.4.4. Extended Key Usage Extension
	The extended key usage extension also serves to limit the technical		The extended key usage extension also serves to limit the technical
	purposes for which a public key listed in a valid certificate may be		purposes for which a public key listed in a valid certificate may be
	used. The set of technical purposes for the certificate therefore		used. The set of technical purposes for the certificate therefore
	are the intersection of the uses indicated in the key usage and		are the intersection of the uses indicated in the key usage and
	extended key usage extensions.		extended key usage extensions.
	For example, if the certificate contains a key usage extension		For example, if the certificate contains a key usage extension
	skipping to change at page 16, line 46 ¶		skipping to change at page 17, line 4 ¶
	- 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 it is the responsibility of the processing software to		invalid, and it is the responsibility of the processing software to
	check them all thoroughly, and to decide what to do if the check		check them all thoroughly, and to decide what to do if the check
	fails.		fails.
	It is possible for there to be multiple unexpired CRLs for a CA. If		It is possible for there to be multiple unexpired CRLs for a CA. If
	an agent is consulting CRLs for certificate validation, it SHOULD		an agent is consulting CRLs for certificate validation, it SHOULD
	make sure that the most recently issued CRL for that CA is consulted,		make sure that the most recently issued CRL for that CA is consulted,
	since an S/MIME message sender could deliberately include an older		since an S/MIME message sender could deliberately include an older
	unexpired CRL in an S/MIME message. This older CRL might not include		unexpired CRL in an S/MIME message. This older CRL might not include
	recently revoked certificates, which might lead an agent to accept a		recently revoked certificates, which might lead an agent to accept a
	certificate that has been revoked in a subsequent CRL.		certificate that has been revoked in a subsequent CRL.
	When determining the time for a certificate validity check, agents		When determining the time for a certificate validity check, agents
	have to be careful to use a reliable time. Unless it is from a		have to be careful to use a reliable time. In most cases the time
	trusted agent, this time MUST NOT be the SigningTime attribute found		used SHOULD be the current time, some exceptions to this would be:
	in an S/MIME message. For most sending agents, the SigningTime
	attribute could be deliberately set to direct the receiving agent to		- The time the message was received is stored in a secure manner and
	check a CRL that could have out-of-date revocation status for a		is used at a later time to validate the message.
	certificate, or cause an improper result when checking the Validity
	field of a certificate.		- The time in a SigningTime attribute found in a counter signature
			attribute which has been successfully validated.
			The SigningTime attribute could be deliberately set to direct the
			receiving agent to check a CRL that could have out-of-date revocation
			status for a certificate, or cause an improper result when checking
			the Validity field of a certificate. This could be done either by
			the sender of the message, or an attacker which has compromised the
			key of the sender.
	In addition to the Security Considerations identified in [RFC5280],		In addition to the Security Considerations identified in [RFC5280],
	caution should be taken when processing certificates that have not		caution should be taken when processing certificates that have not
	first been validated to a trust anchor. Certificates could be		first been validated to a trust anchor. Certificates could be
	manufactured by untrusted sources for the purpose of mounting denial		manufactured by untrusted sources for the purpose of mounting denial
	of service or other attacks. For example, keys selected to require		of service or other attacks. For example, keys selected to require
	excessive cryptographic processing, or extensive lists of CRL		excessive cryptographic processing, or extensive lists of CRL
	Distribution Point (CDP) and/or Authority Information Access (AIA)		Distribution Point (CDP) and/or Authority Information Access (AIA)
	addresses in the certificate, could be used to mount denial-of-		addresses in the certificate, could be used to mount denial-of-
	service attacks. Similarly, attacker-specified CDP and/or AIA		service attacks. Similarly, attacker-specified CDP and/or AIA
	addresses could be included in fake certificates to allow the		addresses could be included in fake certificates to allow the
	originator to detect receipt of the message even if signature		originator to detect receipt of the message even if signature
	verification fails.		verification fails.
	RSA keys of less than 2048 bits are now considered by many experts to		RSA keys of less than 2048 bits are now considered by many experts to
	be cryptographically insecure (due to advances in computing power),		be cryptographically insecure (due to advances in computing power),
	and should no longer be used to sign certificates or CRLs. Such keys		and SHOULD no longer be used to sign certificates or CRLs. Such keys
	were previously considered secure, so processing previously received		were previously considered secure, so processing previously received
	signed and encrypted mail may require processing certificates or CRLs		signed and encrypted mail may require processing certificates or CRLs
	signed with weak keys. Implementations that wish to support previous		signed with weak keys. Implementations that wish to support previous
	versions of S/MIME or process old messages need to consider the		versions of S/MIME or process old messages need to consider the
	security risks that result from accepting certificates and CRLs with		security risks that result from accepting certificates and CRLs with
	smaller key sizes (e.g., spoofed certificates) versus the costs of		smaller key sizes (e.g., spoofed certificates) versus the costs of
	denial of service. If an implementation supports verification of		denial of service. If an implementation supports verification of
	certificates or CRLs generated with RSA and DSA keys of less than		certificates or CRLs generated with RSA and DSA keys of less than
	2048 bits, it MUST warn the user. Implementers should consider		2048 bits, it MUST warn the user. Implementers should consider
	providing a stronger warning for weak signatures on certificates and		providing a stronger warning for weak signatures on certificates and
	skipping to change at page 18, line 27 ¶		skipping to change at page 18, line 40 ¶
	Publication 186-2, January 2000.		Publication 186-2, January 2000.
	[FIPS186-3]		[FIPS186-3]
	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-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-08 (work in progress), March 2017.		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-04		Message Specification", draft-ietf-lamps-rfc5751-bis-06
	(work in progress), March 2017.		(work in progress), April 2017.
	[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,
	<http://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,
	<http://www.rfc-editor.org/info/rfc2634>.		<https://www.rfc-editor.org/info/rfc2634>.
	[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object		[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
	Classes and Attribute Types Version 2.0", RFC 2985,		Classes and Attribute Types Version 2.0", RFC 2985,
	DOI 10.17487/RFC2985, November 2000,		DOI 10.17487/RFC2985, November 2000,
	<http://www.rfc-editor.org/info/rfc2985>.		<https://www.rfc-editor.org/info/rfc2985>.
	[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and		[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
	Identifiers for the Internet X.509 Public Key		Identifiers for the Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April		(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
	2002, <http://www.rfc-editor.org/info/rfc3279>.		2002, <https://www.rfc-editor.org/info/rfc3279>.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February		Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
	2003, <http://www.rfc-editor.org/info/rfc3447>.		2003, <https://www.rfc-editor.org/info/rfc3447>.
	[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional		[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
	Algorithms and Identifiers for RSA Cryptography for use in		Algorithms and Identifiers for RSA Cryptography for use in
	the Internet X.509 Public Key Infrastructure Certificate		the Internet X.509 Public Key Infrastructure Certificate
	and Certificate Revocation List (CRL) Profile", RFC 4055,		and Certificate Revocation List (CRL) Profile", RFC 4055,
	DOI 10.17487/RFC4055, June 2005,		DOI 10.17487/RFC4055, June 2005,
	<http://www.rfc-editor.org/info/rfc4055>.		<https://www.rfc-editor.org/info/rfc4055>.
	[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,
	<http://www.rfc-editor.org/info/rfc4056>.		<https://www.rfc-editor.org/info/rfc4056>.
	[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,
	<http://www.rfc-editor.org/info/rfc5035>.		<https://www.rfc-editor.org/info/rfc5035>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<http://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, DOI 10.17487/RFC5652, September 2009,		RFC 5652, DOI 10.17487/RFC5652, September 2009,
	<http://www.rfc-editor.org/info/rfc5652>.		<https://www.rfc-editor.org/info/rfc5652>.
	[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Certificate		Mail Extensions (S/MIME) Version 3.2 Certificate
	Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,		Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
	<http://www.rfc-editor.org/info/rfc5750>.		<https://www.rfc-editor.org/info/rfc5750>.
	[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, DOI 10.17487/RFC5751, January		Specification", RFC 5751, DOI 10.17487/RFC5751, January
	2010, <http://www.rfc-editor.org/info/rfc5751>.		2010, <https://www.rfc-editor.org/info/rfc5751>.
	[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet		[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
	Attribute Certificate Profile for Authorization",		Attribute Certificate Profile for Authorization",
	RFC 5755, DOI 10.17487/RFC5755, January 2010,		RFC 5755, DOI 10.17487/RFC5755, January 2010,
	<http://www.rfc-editor.org/info/rfc5755>.		<https://www.rfc-editor.org/info/rfc5755>.
	[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.		[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
	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,
	<http://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, <http://www.rfc-editor.org/info/rfc6979>.		2013, <https://www.rfc-editor.org/info/rfc6979>.
	[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 20, line 44 ¶		skipping to change at page 21, line 9 ¶
	[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) | ISO/IEC 8824-1:2002.".		Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.".
	7.2. Informational References		7.2. Informational References
	[ESS] "Enhanced Security Services for S/ MIME".		[ESS] "Enhanced Security Services for S/ MIME".
	This is the set of documents dealing with enhanged		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-04 (work in progress), March 2017.		pkix-07 (work in progress), November 2017.
	[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,
	<http://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,
	"S/MIME Version 2 Certificate Handling", RFC 2312,		"S/MIME Version 2 Certificate Handling", RFC 2312,
	DOI 10.17487/RFC2312, March 1998,		DOI 10.17487/RFC2312, March 1998,
	<http://www.rfc-editor.org/info/rfc2312>.		<https://www.rfc-editor.org/info/rfc2312>.
	[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",		[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
	RFC 2313, DOI 10.17487/RFC2313, March 1998,		RFC 2313, DOI 10.17487/RFC2313, March 1998,
	<http://www.rfc-editor.org/info/rfc2313>.		<https://www.rfc-editor.org/info/rfc2313>.
	[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax		[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax
	Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998,		Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998,
	<http://www.rfc-editor.org/info/rfc2314>.		<https://www.rfc-editor.org/info/rfc2314>.
	[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax		[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
	Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,		Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
	<http://www.rfc-editor.org/info/rfc2315>.		<https://www.rfc-editor.org/info/rfc2315>.
	[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,		[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
	DOI 10.17487/RFC2630, June 1999,		DOI 10.17487/RFC2630, June 1999,
	<http://www.rfc-editor.org/info/rfc2630>.		<https://www.rfc-editor.org/info/rfc2630>.
	[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",		[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
	RFC 2631, DOI 10.17487/RFC2631, June 1999,		RFC 2631, DOI 10.17487/RFC2631, June 1999,
	<http://www.rfc-editor.org/info/rfc2631>.		<https://www.rfc-editor.org/info/rfc2631>.
	[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate		[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
	Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999,		Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999,
	<http://www.rfc-editor.org/info/rfc2632>.		<https://www.rfc-editor.org/info/rfc2632>.
	[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message		[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message
	Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999,		Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999,
	<http://www.rfc-editor.org/info/rfc2633>.		<https://www.rfc-editor.org/info/rfc2633>.
	[RFC3114] Nicolls, W., "Implementing Company Classification Policy		[RFC3114] Nicolls, W., "Implementing Company Classification Policy
	with the S/MIME Security Label", RFC 3114,		with the S/MIME Security Label", RFC 3114,
	DOI 10.17487/RFC3114, May 2002,		DOI 10.17487/RFC3114, May 2002,
	<http://www.rfc-editor.org/info/rfc3114>.		<https://www.rfc-editor.org/info/rfc3114>.
	[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail		[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
	Extensions (S/MIME) Version 3.1 Certificate Handling",		Extensions (S/MIME) Version 3.1 Certificate Handling",
	RFC 3850, DOI 10.17487/RFC3850, July 2004,		RFC 3850, DOI 10.17487/RFC3850, July 2004,
	<http://www.rfc-editor.org/info/rfc3850>.		<https://www.rfc-editor.org/info/rfc3850>.
	[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail		[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
	Extensions (S/MIME) Version 3.1 Message Specification",		Extensions (S/MIME) Version 3.1 Message Specification",
	RFC 3851, DOI 10.17487/RFC3851, July 2004,		RFC 3851, DOI 10.17487/RFC3851, July 2004,
	<http://www.rfc-editor.org/info/rfc3851>.		<https://www.rfc-editor.org/info/rfc3851>.
	[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",		[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
	RFC 3852, DOI 10.17487/RFC3852, July 2004,		RFC 3852, DOI 10.17487/RFC3852, July 2004,
	<http://www.rfc-editor.org/info/rfc3852>.		<https://www.rfc-editor.org/info/rfc3852>.
	[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic		[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
	Curve Cryptography Algorithms", RFC 6090,		Curve Cryptography Algorithms", RFC 6090,
	DOI 10.17487/RFC6090, February 2011,		DOI 10.17487/RFC6090, February 2011,
	<http://www.rfc-editor.org/info/rfc6090>.		<https://www.rfc-editor.org/info/rfc6090>.
	[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations		[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
	for the MD5 Message-Digest and the HMAC-MD5 Algorithms",		for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
	RFC 6151, DOI 10.17487/RFC6151, March 2011,		RFC 6151, DOI 10.17487/RFC6151, March 2011,
	<http://www.rfc-editor.org/info/rfc6151>.		<https://www.rfc-editor.org/info/rfc6151>.
	[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,
	<http://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,
	<http://www.rfc-editor.org/info/rfc8032>.		<https://www.rfc-editor.org/info/rfc8032>.
	[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
	skipping to change at page 24, line 4 ¶		skipping to change at page 24, line 16 ¶
	messages) versus the costs of denial of service.		messages) versus the costs of denial of service.
	[SMIMEv3.1] set the lower limit on suggested key sizes for		[SMIMEv3.1] set the lower limit on suggested key sizes for
	creating and validation at 1024 bits. Prior to that the lower		creating and validation at 1024 bits. Prior to that the lower
	bound on key sizes was 512 bits.		bound on key sizes was 512 bits.
	- Hash functions used to validate signatures on historic messages		- Hash functions used to validate signatures on historic messages
	may longer be considered to be secure (see below). While there		may longer be considered to be secure (see below). While there
	are not currently any known practical pre-image or second pre-		are not currently any known practical pre-image or second pre-
	image attacks against MD5 or SHA-1, the fact they are no longer		image attacks against MD5 or SHA-1, the fact they are no longer
	considered to be collision resistent the security levels of the		considered to be collision resistant the security levels of the
	signatures are generally considered suspect.		signatures are generally considered suspect.
	The following algorithms have been called out for some level of		The following algorithms have been called out for some level of
	support by previous S/MIME specifications:		support by previous S/MIME specifications:
	- RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer		- RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer
	considered to be secure as it is no longer collision-resistant.		considered to be secure as it is no longer collision-resistant.
	Details can be found in [RFC6151].		Details can be found in [RFC6151].
	- RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is		- RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no
	nolonger considered to be secure as it is no longer collision-		longer considered to be secure as it is no longer collision-
	resistant. The IETF statement on SHA-1 can be found in [RFC6194]		resistant. The IETF statement on SHA-1 can be found in [RFC6194]
	but it is out-of-date relative to the most recent advances.		but it is out-of-date relative to the most recent advances.
	- DSA with SHA-256 support was dropped in [SMIMEv4.0]. DSA was		- DSA with SHA-256 support was dropped in [SMIMEv4.0]. DSA was
	dropped as part of a general movement from discrete logarithms to		dropped as part of a general movement from finite fields to
	elliptic curves. Issues have come up dealing with small group		elliptic curves. Issues have come up dealing with non-
	attacks and with non-deterministic generation of the parameter 'k'		deterministic generation of the parameter 'k' (see [RFC6979]).
	(see [RFC6979]).
	For 512-bit RSA with SHA-1 see [RFC3279] and [FIPS186-2] without		For 512-bit RSA with SHA-1 see [RFC3279] and [FIPS186-2] without
	Change Notice 1, for 512-bit RSA with SHA-256 see [RFC4055] and		Change Notice 1, for 512-bit RSA with SHA-256 see [RFC4055] and
	[FIPS186-2] without Change Notice 1.		[FIPS186-2] without Change Notice 1.
	For 512-bit DSA with SHA-1 see [RFC3279] and [FIPS186-2] without		For 512-bit DSA with SHA-1 see [RFC3279] and [FIPS186-2] without
	Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5758] and		Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5758] and
	[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see		[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
	[RFC3279] and [FIPS186-2] with Change Notice 1, for 1024-bit through		[RFC3279] and [FIPS186-2] with Change Notice 1, for 1024-bit through
	3072 DSA with SHA-256 see [RFC5758] and [FIPS186-3]. In either case,		3072 DSA with SHA-256 see [RFC5758] and [FIPS186-3]. In either case,
	the first reference provides the signature algorithm's object		the first reference provides the signature algorithm's object
	identifier and the second provides the signature algorithm's		identifier and the second provides the signature algorithm's
	definition.		definition.
	Appendix B. Moving S/MIME v2 Certificate Handling to Historic Status		Appendix B. Moving S/MIME v2 Certificate Handling to Historic Status
	The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], v3.2 [SMIMEv3.2], and v4.0		The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], v3.2 [SMIMEv3.2], and v4.0
	(this document) are backwards compatible with the S/MIME v2		(this document) are backward compatible with the S/MIME v2
	Certificate Handling Specification [SMIMEv2], with the exception of		Certificate Handling Specification [SMIMEv2], with the exception of
	the algorithms (dropped RC2/40 requirement and added DSA and RSASSA-		the algorithms (dropped RC2/40 requirement and added DSA and RSASSA-
	PSS requirements). Therefore, it is recommended that RFC 2312		PSS requirements). Therefore, it is recommended that RFC 2312
	[SMIMEv2] be moved to Historic status.		[SMIMEv2] be moved to Historic status.
	Appendix C. Acknowledgments		Appendix C. Acknowledgments
	Many thanks go out to the other authors of the S/MIME v2 RFC: Steve		Many thanks go out to the other authors of the S/MIME v2 RFC: Steve
	Dusse, Paul Hoffman, and Jeff Weinstein. Without v2, there wouldn't		Dusse, Paul Hoffman, and Jeff Weinstein. Without v2, there wouldn't
	be a v3, v3.1, v3.2 or v4.0.		be a v3, v3.1, v3.2 or v4.0.
End of changes. 68 change blocks.
	99 lines changed or deleted		110 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/