< draft-ietf-curdle-cms-eddsa-signatures-00.txt		draft-ietf-curdle-cms-eddsa-signatures-01.txt >
	Internet-Draft R. Housley		Internet-Draft R. Housley
	Intended status: Standards Track Vigil Security		Intended status: Standards Track Vigil Security
	Expires: 8 March 2017 8 September 2016		Expires: 19 May 2017 19 November 2016
	Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)		Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)
			<draft-ietf-curdle-cms-eddsa-signatures-01.txt>
	<draft-ietf-curdle-cms-eddsa-signatures-00.txt>
	Abstract		Abstract
	This document describes the conventions for using Edwards-curve		This document specifies the conventions for using Edwards-curve
	Digital Signature Algorithm (EdDSA) in the Cryptographic Message		Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in
	Syntax (CMS). The conventions for Ed25519 and Ed448 are described,		the Cryptographic Message Syntax (CMS). For each curve, EdDSA
	but Ed25519ph and Ed448ph are not used with the CMS.		defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA
			mode is not used with the CMS. In addition, no context string is
			used with the CMS.
	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 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 8 March 2017.		This Internet-Draft will expire on 19 May 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Introduction		1. Introduction
	This document specifies the conventions for using the Edwards-curve		This document specifies the conventions for using the Edwards-curve
	Digital Signature Algorithm (EdDSA) [EDDSA] with the Cryptographic		Digital Signature Algorithm (EdDSA) [EDDSA] for Curve25519 and
	Message Syntax [CMS] signed-data content type. For each curve,		Curve448 with the Cryptographic Message Syntax [CMS] signed-data
	[EDDSA] defines two modes, the PureEdDSA mode without pre-hashing,		content type. For each curve, [EDDSA] defines the PureEdDSA and
	and the HashEdDSA mode with pre-hashing. The CMS conventions for two		HashEdDSA modes. However, the HashEdDSA mode is not used with the
	PureEdDSA curves (Ed25519 and Ed448) are described in this document,		CMS. In addition, no context string is used with CMS. EdDSA with
	but HashEdDSA is not used with the CMS.		Curve25519 is referred to as Ed25519, and EdDSA with Curve448 is
			referred to as Ed448. The CMS conventions for PureEdDSA with Ed25519
			and Ed448 are described in this document.
	1.1. Terminology		1.1. Terminology
	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 RFC 2119 [STDWORDS].		document are to be interpreted as described in RFC 2119 [STDWORDS].
	1.2. ASN.1		1.2. ASN.1
	CMS values are generated using ASN.1 [X680], which uses the Basic		CMS values are generated using ASN.1 [X680], which uses the Basic
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 44 ¶
	security level, and Ed448 at around the 224-bit security level.		security level, and Ed448 at around the 224-bit security level.
	One of the parameters of the EdDSA algorithm is the "prehash"		One of the parameters of the EdDSA algorithm is the "prehash"
	function. This may be the identity function, resulting in an		function. This may be the identity function, resulting in an
	algorithm called PureEdDSA, or a collision-resistant hash function,		algorithm called PureEdDSA, or a collision-resistant hash function,
	resulting in an algorithm called HashEdDSA. In most situations the		resulting in an algorithm called HashEdDSA. In most situations the
	CMS SignedData includes signed attributes, including the message		CMS SignedData includes signed attributes, including the message
	digest of the content. Since HashEdDSA offers no benefit when signed		digest of the content. Since HashEdDSA offers no benefit when signed
	attributes are present, only PureEdDSA is used with the CMS.		attributes are present, only PureEdDSA is used with the CMS.
	A message digest is computed over the data to be signed using		2.1. Algorithm Identifiers
	PureEdDSA, and then a private key operation is performed to generate
	the signature value. As described in Section 3.3 of [EDDSA], the
	signature value is the opaque value ENC(R) || ENC(S). As described
	in Section 5.3 of [CMS], the signature value is ASN.1 encoded as an
	OCTET STRING and included in the signature field of SignerInfo.
	2.1. EdDSA Algorithm Identifiers		Each algorithms are identified by an object identifier, and the
			algorithm identifier may contain parameters if needed.
			The ALGORITHM definition is repeated here for convenience:
			ALGORITHM ::= CLASS {
			&id OBJECT IDENTIFIER UNIQUE,
			&Type OPTIONAL }
			WITH SYNTAX {
			OID &id [PARMS &Type] }
			2.2. EdDSA Algorithm Identifiers
	The EdDSA signature algorithm is defined in [EDDSA], and the		The EdDSA signature algorithm is defined in [EDDSA], and the
	conventions for encoding the public key are defined in [ID.curdle-		conventions for encoding the public key are defined in
	pkix].		[ID.curdle-pkix].
	The id-Ed25519 and id-Ed448 object identifiers are used to identify		The id-Ed25519 and id-Ed448 object identifiers are used to identify
	EdDSA public keys in certificates. The object identifiers are		EdDSA public keys in certificates. The object identifiers are
	specified in [ID.curdle-pkix], and they are repeated here for		specified in [ID.curdle-pkix], and they are repeated here for
	convenience:		convenience:
	id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 }		sigAlg-Ed25519 ALGORITHM ::= { OID id-Ed25519 }
	id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 }
	2.2. EdDSA Signatures		sigAlg-Ed448 ALGORITHM ::= { OID id-Ed448 }
			id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 }
			id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 }
			2.3. Message Digest Algorithm Identifiers
			When the signer includes signed attributes, a message digest
			algorithm is used to compute the message digest on the eContent
			value. When signing with Ed25519, the message digest algorithm MUST
			be SHA-512 [RFC4634]. When signing with Ed448, the message digest
			algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value.
			Signing with Ed25519 uses SHA-512 as part of the signing operation,
			and signing with Ed448 uses SHAKE256 as part of the signing
			operation.
			For convenience, the object identifiers and parameter syntax for
			these algorithms are repeated here:
			hashAlg-SHA-512 ALGORITHM ::= { OID id-sha512 }
			hashAlg-SHAKE256 ALGORITHM ::= { OID id-shake256 }
			hashAlg-SHAKE256-LEN ALGORITHM ::= { OID id-shake256-len
			PARMS SHAKE256OutputLen }
			hashalgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
			country(16) us(840) organization(1)
			gov(101) csor(3) nistalgorithm(4) 2 }
			id-sha512 OBJECT IDENTIFIER ::= { hashAlgs 3 }
			id-shake256 OBJECT IDENTIFIER ::= { hashAlgs 12 }
			id-shake256-len OBJECT IDENTIFIER ::= { TBD }
			SHAKE256OutputLen ::= INTEGER -- Output length in bits
			{{{ NOTE: NIST will assign the missing object identifier soon. }}}
			When using the id-sha512 or id-shake256 algorithm identifier, the
			parameters MUST be absent.
			When using the id-shake256-len algorithm identifier, the parameters
			MUST be present, and the parameter MUST contain 512, encoded as a
			positive integer value.
			2.4. EdDSA Signatures
	The id-Ed25519 and id-Ed448 object identifiers are also used for		The id-Ed25519 and id-Ed448 object identifiers are also used for
	signature values. When used to identify signature algorithms, the		signature values. When used to identify signature algorithms, the
	AlgorithmIdentifier parameters field MUST be absent.		AlgorithmIdentifier parameters field MUST be absent.
	An EdDSA private key operation is produces the opaque signature		The data to be signed is processed using PureEdDSA, and then a
	value, ENC(R) || ENC(S), as described in Section 3.3 of [EDDSA]. The		private key operation generates the signature value. As described in
	resulting octet string is carried in the signature field of		Section 3.3 of [EDDSA], the signature value is the opaque value
	SignerInfo.		ENC(R) || ENC(S). As described in Section 5.3 of [CMS], the
			signature value is ASN.1 encoded as an OCTET STRING and included in
			the signature field of SignerInfo.
	3. Signed-data Conventions		3. Signed-data Conventions
	The digestAlgorithms field SHOULD contain the one-way hash function		The processing depends on whether the signer includes signed
	used to compute the message digest on the eContent value.		attributes.
	If signedAttributes are present, the same one-way hash function		The inclusion of signed attributes is preferred, but the conventions
	SHOULD be used to compute the message digest on both the eContent and		for signed-data without signed attributes are provided for
	the signedAttributes.		completeness.
	The signatureAlgorithm field MUST contain either id-Ed25519 or id-		3.1. Signed-data Conventions With Signed Attributes
	Ed448, depending on the elliptic curve that was used by the signer.
	The algorithm parameters field MUST be absent.
	The signature field contains the octet string resulting from the		The SignedData digestAlgorithms field includes the identifiers of the
	EdDSA private key signing operation.		message digest algorithms used by one or more signer. There MAY be
			any number of elements in the collection, including zero. When
			signing with Ed25519, the digestAlgorithm SHOULD include id-sha512,
			and if present, the algorithm parameters field MUST be absent. When
			signing with Ed448, the digestAlgorithm SHOULD include
			id-shake256-len, and if present, the algorithm parameters field MUST
			also be present, and the parameter MUST contain 512, encoded as a
			positive integer value.
	4. Security Considerations		The SignerInfo digestAlgorithm field includes the identifier of the
			message digest algorithms used by the signer. When signing with
			Ed25519, the digestAlgorithm MUST be id-sha512, and the algorithm
			parameters field MUST be absent. When signing with Ed448, the
			digestAlgorithm MUST be id-shake256-len, the algorithm parameters
			field MUST be present, and the parameter MUST contain 512, encoded as
			a positive integer value.
			The SignerInfo signedAttributes MUST include the message-digest
			attribute as specified in Section 11.2 of [RFC5652]. When signing
			with Ed25519, the message-digest attribute MUST contain the message
			digest computed over the eContent value using SHA-512. When signing
			with Ed448, the message-digest attribute MUST contain the message
			digest computed over the eContent value using SHAKE256 with an output
			length of 512 bits.
			The SignerInfo signatureAlgorithm field MUST contain either
			id-Ed25519 or id-Ed448, depending on the elliptic curve that was used
			by the signer. The algorithm parameters field MUST be absent.
			The SignerInfo signature field contains the octet string resulting
			from the EdDSA private key signing operation.
			3.2. Signed-data Conventions Without Signed Attributes
			The SignedData digestAlgorithms field includes the identifiers of the
			message digest algorithms used by one or more signer. There MAY be
			any number of elements in the collection, including zero. When
			signing with Ed25519, list of identifiers MAY include id-sha512, and
			if present, the algorithm parameters field MUST be absent. When
			signing with Ed448, list of identifiers MAY include id-shake256, and
			if present, the algorithm parameters field MUST be absent.
			The SignerInfo digestAlgorithm field includes the identifier of the
			message digest algorithms used by the signer. When signing with
			Ed25519, the digestAlgorithm MUST be id-sha512, and the algorithm
			parameters field MUST be absent. When signing with Ed448, the
			digestAlgorithm MUST be id-shake256, and the algorithm parameters
			field MUST be absent.
			NOTE: Either id-sha512 or id-shake256 is used as part to the
			private key signing operation. A message digest computed with one
			of these algorithms is not an input to the private key signing
			operation.
			The SignerInfo signatureAlgorithm field MUST contain either
			id-Ed25519 or id-Ed448, depending on the elliptic curve that was used
			by the signer. The algorithm parameters field MUST be absent.
			The SignerInfo signature field contains the octet string resulting
			from the EdDSA private key signing operation.
			4. Implementation Considerations
			The EdDSA specification [EDDSA] includes the following warning. It
			deserves highlighting.
			PureEdDSA requires two passes over the input. Many existing APIs,
			protocols, and environments assume digital signature algorithms
			only need one pass over the input, and may have API or bandwidth
			concerns supporting anything else.
			5. Security Considerations
	Implementations must protect the EdDSA private key. Compromise of		Implementations must protect the EdDSA private key. Compromise of
	the EdDSA private key may result in the ability to forge signatures.		the EdDSA private key may result in the ability to forge signatures.
	The generation of EdDSA private key relies on random numbers. The		The generation of EdDSA private key relies on random numbers. The
	use of inadequate pseudo-random number generators (PRNGs) to generate		use of inadequate pseudo-random number generators (PRNGs) to generate
	these values can result in little or no security. An attacker may		these values can result in little or no security. An attacker may
	find it much easier to reproduce the PRNG environment that produced		find it much easier to reproduce the PRNG environment that produced
	the keys, searching the resulting small set of possibilities, rather		the keys, searching the resulting small set of possibilities, rather
	than brute force searching the whole key space. The generation of		than brute force searching the whole key space. The generation of
	quality random numbers is difficult. RFC 4086 [RANDOM] offers		quality random numbers is difficult. RFC 4086 [RANDOM] offers
	important guidance in this area.		important guidance in this area.
			Unlike DSA and ECDSA, EdDSA does not require the generation of a
			random value for each signature operation.
	Using the same private key for different algorithms has the potential		Using the same private key for different algorithms has the potential
	of allowing an attacker to get extra information about the private		of allowing an attacker to get extra information about the private
	key. For this reason, the same private key SHOULD NOT be used with		key. For this reason, the same private key SHOULD NOT be used with
	more than one EdDSA set of parameters. For example, do not use the		more than one EdDSA set of parameters. For example, do not use the
	same private key with PureEdDSA and HashEdDSA.		same private key with PureEdDSA and HashEdDSA.
	When computing signatures, the same hash function should be used for		When computing signatures, the same hash function should be used for
	all operations. This reduces the number of failure points in the		all operations. This reduces the number of failure points in the
	signature process.		signature process.
	5. Normative References		6. Normative References
	[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC		[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
	5652, September 2009.		RFC 5652, September 2009.
	[EDDSA] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital		[EDDSA] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
	Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-00,		Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08,
	(work in progress), October 2015.		19 August 2016, Work-in-progress.
			[FIPS202] National Institute of Standards and Technology, U.S.
			Department of Commerce, "SHA-3 Standard: Permutation-Based
			Hash and Extendable-Output Functions", FIPS 202,
			August 2015.
	[ID.curdle-pkix]		[ID.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",
	15 August 2016, Work-in-progress.		draft-ietf-curdle-pkix-02, 31 October 2016,
			Work-in-progress.
			[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
			(SHA and HMAC-SHA)", RFC 4634, July 2006.
	[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[X680] ITU-T, "Information technology -- Abstract Syntax Notation		[X680] ITU-T, "Information technology -- Abstract Syntax Notation
	One (ASN.1): Specification of basic notation", ITU-T		One (ASN.1): Specification of basic notation", ITU-T
	Recommendation X.680, 2015.		Recommendation X.680, 2015.
	[X690] ITU-T, "Information technology -- ASN.1 encoding rules:		[X690] ITU-T, "Information technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, 2015.		(DER)", ITU-T Recommendation X.690, 2015.
	6. Informative References		7. Informative References
	[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Requirements for Security", RFC 4086, June 2005.		Requirements for Security", RFC 4086, June 2005.
	Author Address		Author Address
	Russ Housley		Russ Housley
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
End of changes. 22 change blocks.
	48 lines changed or deleted		186 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/