< draft-ietf-curdle-cms-eddsa-signatures-05.txt		draft-ietf-curdle-cms-eddsa-signatures-06.txt >
	Internet-Draft R. Housley		Internet-Draft R. Housley
	Intended status: Standards Track Vigil Security		Intended status: Standards Track Vigil Security
	Expires: 11 October 2017 11 April 2017		Expires: 2 December 2017 2 June 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-05.txt>		<draft-ietf-curdle-cms-eddsa-signatures-06.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.
	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 11 October 2017.		This Internet-Draft will expire on 2 December 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
	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] for Curve25519 and		Digital Signature Algorithm (EdDSA) [EDDSA] for curve25519 and
	Curve448 with the Cryptographic Message Syntax [CMS] signed-data		curve448 with the Cryptographic Message Syntax [CMS] signed-data
	content type. For each curve, [EDDSA] defines the PureEdDSA and		content type. For each curve, [EDDSA] defines the PureEdDSA and
	HashEdDSA modes. However, the HashEdDSA mode is not used with the		HashEdDSA modes. However, the HashEdDSA mode is not used with the
	CMS. In addition, no context string is used with CMS. EdDSA with		CMS. In addition, no context string is used with CMS. EdDSA with
	Curve25519 is referred to as Ed25519, and EdDSA with Curve448 is		curve25519 is referred to as Ed25519, and EdDSA with curve448 is
	referred to as Ed448. The CMS conventions for PureEdDSA with Ed25519		referred to as Ed448. The CMS conventions for PureEdDSA with Ed25519
	and Ed448 are described in this document.		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
	skipping to change at page 2, line 46 ¶		skipping to change at page 2, line 46 ¶
	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.
	2.1. Algorithm Identifiers		2.1. Algorithm Identifiers
	Each algorithms are identified by an object identifier, and the		Each algorithm is identified by an object identifier, and the
	algorithm identifier may contain parameters if needed.		algorithm identifier may contain parameters if needed.
	The ALGORITHM definition is repeated here for convenience:		The ALGORITHM definition is repeated here for convenience:
	ALGORITHM ::= CLASS {		ALGORITHM ::= CLASS {
	&id OBJECT IDENTIFIER UNIQUE,		&id OBJECT IDENTIFIER UNIQUE,
	&Type OPTIONAL }		&Type OPTIONAL }
	WITH SYNTAX {		WITH SYNTAX {
	OID &id [PARMS &Type] }		OID &id [PARMS &Type] }
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	2.4. EdDSA Signatures		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.
	The data to be signed is processed using PureEdDSA, and then a		The data to be signed is processed using PureEdDSA, and then a
	private key operation generates the signature value. As described in		private key operation generates the signature value. As described in
	Section 3.3 of [EDDSA], the signature value is the opaque value		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		ENC(R) || ENC(S), where || represents concatenation. As described in
	signature value is ASN.1 encoded as an OCTET STRING and included in		Section 5.3 of [CMS], the signature value is ASN.1 encoded as an
	the signature field of SignerInfo.		OCTET STRING and included in the signature field of SignerInfo.
	3. Signed-data Conventions		3. Signed-data Conventions
	The processing depends on whether the signer includes signed		The processing depends on whether the signer includes signed
	attributes.		attributes.
	The inclusion of signed attributes is preferred, but the conventions		The inclusion of signed attributes is preferred, but the conventions
	for signed-data without signed attributes are provided for		for signed-data without signed attributes are provided for
	completeness.		completeness.
End of changes. 8 change blocks.
	11 lines changed or deleted		11 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/