< draft-ietf-lamps-rfc5750-bis-02.txt		draft-ietf-lamps-rfc5750-bis-03.txt >
	LAMPS J. Schaad		LAMPS J. Schaad
	Internet-Draft August Cellars		Internet-Draft August Cellars
	Intended status: Standards Track B. Ramsdell		Intended status: Standards Track B. Ramsdell
	Expires: August 27, 2017 Brute Squad Labs, Inc.		Expires: September 14, 2017 Brute Squad Labs, Inc.
	S. Turner		S. Turner
	sn3rd		sn3rd
	February 23, 2017		March 13, 2017
	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-02		draft-ietf-lamps-rfc5750-bis-03
	Abstract		Abstract
	This document specifies conventions for X.509 certificate usage by		This document specifies conventions for X.509 certificate usage by
	Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.		Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.
	S/MIME provides a method to send and receive secure MIME messages,		S/MIME provides a method to send and receive secure MIME messages,
	and certificates are an integral part of S/MIME agent processing.		and certificates are an integral part of S/MIME agent processing.
	S/MIME agents validate certificates as described in RFC 5280, the		S/MIME agents validate certificates as described in RFC 5280, the
	Internet X.509 Public Key Infrastructure Certificate and CRL Profile.		Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
	S/MIME agents must meet the certificate processing requirements in		S/MIME agents must meet the certificate processing requirements in
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 August 27, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(http://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 3, line 9 ¶		skipping to change at page 3, line 9 ¶
	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 . . . . . . . . . . . . . . . 11
	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. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.1. Normative References . . . . . . . . . . . . . . . . . . 17		6.1. Normative References . . . . . . . . . . . . . . . . . . 18
	6.2. Informational References . . . . . . . . . . . . . . . . 20		6.2. Informational References . . . . . . . . . . . . . . . . 20
	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 . . . . . . . . . . . . . . . . . . . . . . . 24
	Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 24		Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	S/MIME agent: User software that is a receiving agent, a sending		S/MIME agent: User software that is a receiving agent, a sending
	agent, or both.		agent, or both.
	1.2. Conventions Used in This Document		1.2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	We define some additional terms here:		We define the additional requirement levels:
	SHOULD+ This term means the same as SHOULD. However, the authors		SHOULD+ This term means the same as SHOULD. However, the authors
	expect that a requirement marked as SHOULD+ will be promoted		expect that a requirement marked as SHOULD+ will be promoted
	at some future time to be a MUST.		at some future time to be a MUST.
	SHOULD- This term means the same as SHOULD. However, the authors		SHOULD- This term means the same as SHOULD. However, the authors
	expect that a requirement marked as SHOULD- will be demoted		expect that a requirement marked as SHOULD- will be demoted
	to a MAY in a future version of this document.		to a MAY in a future version of this document.
	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 a		future document. Although its status will be determined at a
	later time, it is reasonable to expect that if a future		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
			RSA signature algorithm even when not qualified as such. There are a
			couple of places where it refers to the general RSA cryptographic
			operation, these can be determined from the context where it is used.
	1.3. Compatibility with Prior Practice S/MIME		1.3. Compatibility with Prior Practice 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], 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
	skipping to change at page 13, line 13 ¶		skipping to change at page 13, line 13 ¶
	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)
	4096 < key size : MAY (see Security Considerations)		4096 < key size : MAY (see Security Considerations)
	For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and		The signature algorithm object identifiers for RSA PKCS#1 v1.5 and
	[FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256		RSASSA-PSS with SHA-256 using 1024-bit through 3072-bit public keys
	see [RFC4055] and [RFC3447]. In either case, the first reference		are specified in [RFC4055] and the signature algorithm definition is
	provides the signature algorithm's object identifier and the second		found in [FIPS186-2] with Change Notice 1.
	provides the signature algorithm's definition.
			The signature algorithm object identifiers for RSA PKCS#1 v1.5 and
			RSASSA-PSS with SHA-256 using 4096-bit public keys are specified in
			[RFC4055] and the signature algorithm definition is found in
			[RFC3447].
	For RSASSA-PSS with SHA-256 see [RFC4056].		For RSASSA-PSS with SHA-256 see [RFC4056].
	For ECDSA see [RFC5758] and [RFC6090]. The first reference provides		For ECDSA see [RFC5758] and [RFC6090]. The first reference provides
	the signature algorithm's object identifier and the second provides		the signature algorithm's object identifier and the second provides
	the signature algorithm's definition. Curves other than curve P-256		the signature algorithm's definition. Curves other than curve P-256
	MAY be used as well.		MAY be used as well.
	For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. The		For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. The
	first reference provides the signature algorithm's object identifier		first reference provides the signature algorithm's object identifier
	skipping to change at page 18, line 19 ¶		skipping to change at page 18, line 23 ¶
	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-06 (work in progress), February 2017.		addresses-08 (work in progress), March 2017.
	[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-02		Message Specification", draft-ietf-lamps-rfc5751-bis-03
	(work in progress), October 2016.		(work in progress), February 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>.		<http://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>.		<http://www.rfc-editor.org/info/rfc2634>.
	skipping to change at page 24, line 42 ¶		skipping to change at page 24, line 46 ¶
	(this document) are backwards compatible with the S/MIME v2		(this document) are backwards 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, or v3.2.		be a v3, v3.1, v3.2 or v4.0.
	A number of the members of the S/MIME Working Group have also worked		A number of the members of the S/MIME Working Group have also worked
	very hard and contributed to this document. Any list of people is		very hard and contributed to this document. Any list of people is
	doomed to omission, and for that I apologize. In alphabetical order,		doomed to omission, and for that I apologize. In alphabetical order,
	the following people stand out in my mind because they made direct		the following people stand out in my mind because they made direct
	contributions to this document.		contributions to this document.
	Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul		Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul
	Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling,		Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling,
	and Denis Pinkas.		and Denis Pinkas.
			The version 4 update to the S/MIME documents was done under the
			auspices of the LAMPS Working Group.
	Authors' Addresses		Authors' Addresses
	Jim Schaad		Jim Schaad
	August Cellars		August Cellars
	Email: ietf@augustcellars.com		Email: ietf@augustcellars.com
	Blake Ramsdell		Blake Ramsdell
	Brute Squad Labs, Inc.		Brute Squad Labs, Inc.
End of changes. 12 change blocks.
	17 lines changed or deleted		29 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/