< draft-ietf-curdle-cms-eddsa-signatures-04.txt		draft-ietf-curdle-cms-eddsa-signatures-05.txt >
	Internet-Draft R. Housley		Internet-Draft R. Housley
	Intended status: Standards Track Vigil Security		Intended status: Standards Track Vigil Security
	Expires: 10 October 2017 10 April 2017		Expires: 11 October 2017 11 April 2017
	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-04.txt>		<draft-ietf-curdle-cms-eddsa-signatures-05.txt>
	Abstract		Abstract
	This document specifies the conventions for using Edwards-curve		This document specifies the conventions for using Edwards-curve
	Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in		Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in
	the Cryptographic Message Syntax (CMS). For each curve, EdDSA		the Cryptographic Message Syntax (CMS). For each curve, EdDSA
	defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA		defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA
	mode is not used with the CMS. In addition, no context string is		mode is not used with the CMS. In addition, no context string is
	used with the CMS.		used with the CMS.
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 10 October 2017.		This Internet-Draft will expire on 11 October 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 37 ¶		skipping to change at page 3, line 37 ¶
	id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 }		id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 }
	id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 }		id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 }
	2.3. Message Digest Algorithm Identifiers		2.3. Message Digest Algorithm Identifiers
	When the signer includes signed attributes, a message digest		When the signer includes signed attributes, a message digest
	algorithm is used to compute the message digest on the eContent		algorithm is used to compute the message digest on the eContent
	value. When signing with Ed25519, the message digest algorithm MUST		value. When signing with Ed25519, the message digest algorithm MUST
	be SHA-512 [RFC4634]. When signing with Ed448, the message digest		be SHA-512 [FIPS180]. Additional information on SHA-512 is available
			in RFC 6234 [RFC6234]. When signing with Ed448, the message digest
	algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value.		algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value.
	Signing with Ed25519 uses SHA-512 as part of the signing operation,		Signing with Ed25519 uses SHA-512 as part of the signing operation,
	and signing with Ed448 uses SHAKE256 as part of the signing		and signing with Ed448 uses SHAKE256 as part of the signing
	operation.		operation.
	For convenience, the object identifiers and parameter syntax for		For convenience, the object identifiers and parameter syntax for
	these algorithms are repeated here:		these algorithms are repeated here:
	hashAlg-SHA-512 ALGORITHM ::= { OID id-sha512 }		hashAlg-SHA-512 ALGORITHM ::= { OID id-sha512 }
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	The SignerInfo signatureAlgorithm field MUST contain either		The SignerInfo signatureAlgorithm field MUST contain either
	id-Ed25519 or id-Ed448, depending on the elliptic curve that was used		id-Ed25519 or id-Ed448, depending on the elliptic curve that was used
	by the signer. The algorithm parameters field MUST be absent.		by the signer. The algorithm parameters field MUST be absent.
	The SignerInfo signature field contains the octet string resulting		The SignerInfo signature field contains the octet string resulting
	from the EdDSA private key signing operation.		from the EdDSA private key signing operation.
	4. Implementation Considerations		4. Implementation Considerations
	The EdDSA specification [EDDSA] includes the following warning. It		The EdDSA specification [EDDSA] includes the following warning. It
	deserves highlighting.		deserves highlighting, especially when signed-data is used without
			signed attributes and the content to be signed might be quite large:
	PureEdDSA requires two passes over the input. Many existing APIs,		PureEdDSA requires two passes over the input. Many existing APIs,
	protocols, and environments assume digital signature algorithms		protocols, and environments assume digital signature algorithms
	only need one pass over the input, and may have API or bandwidth		only need one pass over the input, and may have API or bandwidth
	concerns supporting anything else.		concerns supporting anything else.
	5. Security Considerations		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.
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 29 ¶
	RFC 5652, September 2009.		RFC 5652, September 2009.
	[CURDLE-PKIX]		[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-02, 31 October 2016,		draft-ietf-curdle-pkix-02, 31 October 2016,
	Work-in-progress.		Work-in-progress.
	[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-08,		Signature Algorithm (EdDSA)", RFC 8032, January 2017.
	19 August 2016, Work-in-progress.
			[FIPS180] National Institute of Standards and Technology, U.S.
			Department of Commerce, "Secure Hash Standard", Federal
			Information Processing Standard (FIPS) 180-3, October
			2008.
	[FIPS202] National Institute of Standards and Technology, U.S.		[FIPS202] National Institute of Standards and Technology, U.S.
	Department of Commerce, "SHA-3 Standard: Permutation-Based		Department of Commerce, "SHA-3 Standard: Permutation-Based
	Hash and Extendable-Output Functions", FIPS 202,		Hash and Extendable-Output Functions", Federal Information
	August 2015.		Processing Standard (FIPS) 202, August 2015.
	[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.
	9. Informative References		9. 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.
			[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
			(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
	Author's Address		Author's Address
	Russ Housley		Russ Housley
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	housley@vigilsec.com		housley@vigilsec.com
End of changes. 8 change blocks.
	12 lines changed or deleted		18 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/