< draft-ietf-lamps-rfc5750-bis-01.txt		draft-ietf-lamps-rfc5750-bis-02.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: May 2, 2017 Brute Squad Labs, Inc.		Expires: August 27, 2017 Brute Squad Labs, Inc.
	S. Turner		S. Turner
	sn3rd		sn3rd
	October 29, 2016		February 23, 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-01		draft-ietf-lamps-rfc5750-bis-02
	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 May 2, 2017.		This Internet-Draft will expire on August 27, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	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
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	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 . . . . . . . . . . . . . . . . . . . 15
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.1. Normative References . . . . . . . . . . . . . . . . . . 18		6.1. Normative References . . . . . . . . . . . . . . . . . . 17
	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 6, line 44 ¶		skipping to change at page 6, line 44 ¶
	Section 7: Moved references from Appendix B to Section 6. Updated		Section 7: Moved references from Appendix B to Section 6. Updated
	the references.		the references.
	Appendix A: Moved Appendix A to Appendix B. Added Appendix A to move		Appendix A: Moved Appendix A to Appendix B. Added Appendix A to move
	S/MIME v2 Certificate Handling to Historic Status.		S/MIME v2 Certificate Handling to Historic Status.
	1.6. Changes since S/MIME 3.2		1.6. Changes since S/MIME 3.2
	Section 3: Require support for internationalized email addresses.		Section 3: Require support for internationalized email addresses.
	Section 4.3: Mandated support for ECDSA for P-256 and Ed25519.		Section 4.3: Mandated support for ECDSA with P-256 and Ed25519.
	Moved algorithms with SHA-1 and MD5 to historical status.		Moved algorithms with SHA-1 and MD5 to historical status.
	Moved DSA support to historical status. Increased lower		Moved DSA support to historical status. Increased lower
	bounds on RSA key sizes.		bounds on RSA key sizes.
	Appendix A: Add a new appendix for algorithms that are now considered		Appendix A: Add a new appendix for algorithms that are now considered
	to be historical.		to be historical.
	2. CMS Options		2. CMS Options
	The CMS message format allows for a wide variety of options in		The CMS message format allows for a wide variety of options in
	skipping to change at page 9, line 11 ¶		skipping to change at page 9, line 11 ¶
	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 US-ASCII characters are encoded as described		addresses retricted to 7-bit ASCII characters are encoded as
	in Section 4.2.1.6 of [RFC5280]. Internationalized Email address		described in Section 4.2.1.6 of [RFC5280]. Internationalized Email
	names are encoded as described in [I-D.ietf-lamps-eai-addresses].		address names are encoded as described in
	The email address SHOULD be in the subjectAltName extension, and		[I-D.ietf-lamps-eai-addresses]. The email address SHOULD be in the
	SHOULD NOT be in the subject distinguished name.		subjectAltName extension, and SHOULD NOT be in the subject
			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 US-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
	addresses in the Distinguished Name field in the PKCS #9 [RFC2985]		addresses in the Distinguished Name field in the PKCS #9 [RFC2985]
	emailAddress attribute:		emailAddress attribute:
	pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=		pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }
	Note that this attribute MUST be encoded as IA5String and has an		Note that this attribute MUST be encoded as IA5String and has an
	upper bound of 255 characters. The right side of the email address		upper bound of 255 characters. The right side of the email address
	SHOULD be treated as ASCII-case-insensitive.		SHOULD be treated as ASCII-case-insensitive.
	Comparing of email addresses is fraught with peril.		Comparing of email addresses is fraught with peril.
	[I-D.ietf-lamps-eai-addresses] defines the procedure for doing		[I-D.ietf-lamps-eai-addresses] defines the procedure for doing
	comparison of Internationalized email addresses. For US-ASCII email		comparison of Internationalized email addresses. For ASCII email
	addresses the domain component (right-hand side of the '@') MUST be		addresses the domain component (right-hand side of the '@') MUST be
	compared using a case-insensitive function. The local name component		compared using a case-insensitive function. The local name component
	(left-hand side of the '@') SHOULD be compared using a case-		(left-hand side of the '@') SHOULD be compared using a case-
	insensitive function. Some localities may perform other		insensitive function. Some localities may perform other
	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
	skipping to change at page 13, line 23 ¶		skipping to change at page 13, line 23 ¶
	For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and		For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and
	[FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256		[FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256
	see [RFC4055] and [RFC3447]. In either case, the first reference		see [RFC4055] and [RFC3447]. In either case, 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.		provides the signature algorithm's definition.
	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. Other curves than durve 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
	and the second provides the signature algorithm's definition. Other		and the second provides the signature algorithm's definition. Other
	curves than curve 25519 MAY be used as well.		curves than curve 25519 MAY be used as well.
	4.4. PKIX Certificate Extensions		4.4. PKIX Certificate Extensions
	PKIX describes an extensible framework in which the basic certificate		PKIX describes an extensible framework in which the basic certificate
	skipping to change at page 15, line 14 ¶		skipping to change at page 15, line 14 ¶
	concerning the digitalSignature or nonRepudiation bits within this		concerning the digitalSignature or nonRepudiation bits within this
	extension.		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 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 US-ASCII email addresses		the entity for this certificate. Any ASCII email addresses present
	present MUST be encoded using the rfc822Name CHOICE of the		MUST be encoded using the rfc822Name CHOICE of the GeneralName type
	GeneralName type as described in [RFC5280], Section 4.2.1.6. Any		as described in [RFC5280], Section 4.2.1.6. Any internationalized
	internationalized email addresses present MUST be encoded using the		email addresses present MUST be encoded using the otherName CHOICE of
	otherName CHOICE of the GeneralName type as described in		the GeneralName type as described in [I-D.ietf-lamps-eai-addresses],
	[I-D.ietf-lamps-eai-addresses], Section 3. Since the SubjectAltName		Section 3. Since the SubjectAltName type is a SEQUENCE OF
	type is a SEQUENCE OF GeneralName, multiple email addresses MAY be		GeneralName, multiple email addresses MAY be present.
	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 18, line 4 ¶		skipping to change at page 17, line 46 ¶
	for certificates and CRLs associated with previously stored messages.		for certificates and CRLs associated with previously stored messages.
	Server implementations (e.g., secure mail list servers) where user		Server implementations (e.g., secure mail list servers) where user
	warnings are not appropriate SHOULD reject messages with weak		warnings are not appropriate SHOULD reject messages with weak
	cryptography.		cryptography.
	If an implementation is concerned about compliance with National		If an implementation is concerned about compliance with National
	Institute of Standards and Technology (NIST) key size		Institute of Standards and Technology (NIST) key size
	recommendations, then see [SP800-57].		recommendations, then see [SP800-57].
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[FIPS186-2]		[FIPS186-2]
	National Institute of Standards and Technology (NIST),		National Institute of Standards and Technology (NIST),
	"Digital Signature Standard (DSS) [With Change Notice 1]",		"Digital Signature Standard (DSS) [With Change Notice 1]",
	Federal Information Processing Standards		Federal Information Processing Standards
	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-00 (work in progress), July 2016.		addresses-06 (work in progress), February 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 3.5		Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", draft-ietf-lamps-rfc5751-bis-01		Message Specification", draft-ietf-lamps-rfc5751-bis-02
	(work in progress), August 2016.		(work in progress), October 2016.
	[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 20, line 40 ¶		skipping to change at page 20, line 40 ¶
	[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 enhanged
	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, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for		Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for
	use in the Internet X.509 Public Key Infrastructure",		use in the Internet X.509 Public Key Infrastructure",
	draft-ietf-curdle-pkix-01 (work in progress), August 2016.		draft-ietf-curdle-pkix-03 (work in progress), November
			2016.
	[I-D.irtf-cfrg-eddsa]		[I-D.irtf-cfrg-eddsa]
	Josefsson, S. and I. Liusvaara, "Edwards-curve Digital		Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
	Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08		Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08
	(work in progress), August 2016.		(work in progress), August 2016.
	[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
End of changes. 16 change blocks.
	28 lines changed or deleted		30 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/