idnits 2.17.1 draft-ietf-curdle-cms-eddsa-signatures-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 131 has weird spacing: '... string resul...' -- The document date (8 September 2016) is 2786 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-eddsa-00 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-eddsa (ref. 'EDDSA') -- Possible downref: Non-RFC (?) normative reference: ref. 'ID.curdle-pkix' -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 Intended status: Standards Track Vigil Security 4 Expires: 8 March 2017 8 September 2016 6 Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) 8 10 Abstract 12 This document describes the conventions for using Edwards-curve 13 Digital Signature Algorithm (EdDSA) in the Cryptographic Message 14 Syntax (CMS). The conventions for Ed25519 and Ed448 are described, 15 but Ed25519ph and Ed448ph are not used with the CMS. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 8 March 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 This document specifies the conventions for using the Edwards-curve 52 Digital Signature Algorithm (EdDSA) [EDDSA] with the Cryptographic 53 Message Syntax [CMS] signed-data content type. For each curve, 54 [EDDSA] defines two modes, the PureEdDSA mode without pre-hashing, 55 and the HashEdDSA mode with pre-hashing. The CMS conventions for two 56 PureEdDSA curves (Ed25519 and Ed448) are described in this document, 57 but HashEdDSA is not used with the CMS. 59 1.1. Terminology 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [STDWORDS]. 65 1.2. ASN.1 67 CMS values are generated using ASN.1 [X680], which uses the Basic 68 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 69 [X690]. 71 2. EdDSA Signature Algorithm 73 The Edwards-curve Digital Signature Algorithm (EdDSA) [EDDSA] is a 74 variant of Schnorr's signature system with (possibly twisted) Edwards 75 curves. Ed25519 is intended to operate at around the 128-bit 76 security level, and Ed448 at around the 224-bit security level. 78 One of the parameters of the EdDSA algorithm is the "prehash" 79 function. This may be the identity function, resulting in an 80 algorithm called PureEdDSA, or a collision-resistant hash function, 81 resulting in an algorithm called HashEdDSA. In most situations the 82 CMS SignedData includes signed attributes, including the message 83 digest of the content. Since HashEdDSA offers no benefit when signed 84 attributes are present, only PureEdDSA is used with the CMS. 86 A message digest is computed over the data to be signed using 87 PureEdDSA, and then a private key operation is performed to generate 88 the signature value. As described in Section 3.3 of [EDDSA], the 89 signature value is the opaque value ENC(R) || ENC(S). As described 90 in Section 5.3 of [CMS], the signature value is ASN.1 encoded as an 91 OCTET STRING and included in the signature field of SignerInfo. 93 2.1. EdDSA Algorithm Identifiers 95 The EdDSA signature algorithm is defined in [EDDSA], and the 96 conventions for encoding the public key are defined in [ID.curdle- 97 pkix]. 99 The id-Ed25519 and id-Ed448 object identifiers are used to identify 100 EdDSA public keys in certificates. The object identifiers are 101 specified in [ID.curdle-pkix], and they are repeated here for 102 convenience: 104 id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 } 105 id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 } 107 2.2. EdDSA Signatures 109 The id-Ed25519 and id-Ed448 object identifiers are also used for 110 signature values. When used to identify signature algorithms, the 111 AlgorithmIdentifier parameters field MUST be absent. 113 An EdDSA private key operation is produces the opaque signature 114 value, ENC(R) || ENC(S), as described in Section 3.3 of [EDDSA]. The 115 resulting octet string is carried in the signature field of 116 SignerInfo. 118 3. Signed-data Conventions 120 The digestAlgorithms field SHOULD contain the one-way hash function 121 used to compute the message digest on the eContent value. 123 If signedAttributes are present, the same one-way hash function 124 SHOULD be used to compute the message digest on both the eContent and 125 the signedAttributes. 127 The signatureAlgorithm field MUST contain either id-Ed25519 or id- 128 Ed448, depending on the elliptic curve that was used by the signer. 129 The algorithm parameters field MUST be absent. 131 The signature field contains the octet string resulting from the 132 EdDSA private key signing operation. 134 4. Security Considerations 136 Implementations must protect the EdDSA private key. Compromise of 137 the EdDSA private key may result in the ability to forge signatures. 139 The generation of EdDSA private key relies on random numbers. The 140 use of inadequate pseudo-random number generators (PRNGs) to generate 141 these values can result in little or no security. An attacker may 142 find it much easier to reproduce the PRNG environment that produced 143 the keys, searching the resulting small set of possibilities, rather 144 than brute force searching the whole key space. The generation of 145 quality random numbers is difficult. RFC 4086 [RANDOM] offers 146 important guidance in this area. 148 Using the same private key for different algorithms has the potential 149 of allowing an attacker to get extra information about the private 150 key. For this reason, the same private key SHOULD NOT be used with 151 more than one EdDSA set of parameters. For example, do not use the 152 same private key with PureEdDSA and HashEdDSA. 154 When computing signatures, the same hash function should be used for 155 all operations. This reduces the number of failure points in the 156 signature process. 158 5. Normative References 160 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 161 5652, September 2009. 163 [EDDSA] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 164 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-00, 165 (work in progress), October 2015. 167 [ID.curdle-pkix] 168 Josefsson, S., and J. Schaad, "Algorithm Identifiers for 169 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 170 use in the Internet X.509 Public Key Infrastructure", 171 15 August 2016, Work-in-progress. 173 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, March 1997. 176 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 177 One (ASN.1): Specification of basic notation", ITU-T 178 Recommendation X.680, 2015. 180 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 181 Specification of Basic Encoding Rules (BER), Canonical 182 Encoding Rules (CER) and Distinguished Encoding Rules 183 (DER)", ITU-T Recommendation X.690, 2015. 185 6. Informative References 187 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 188 Requirements for Security", RFC 4086, June 2005. 190 Author Address 192 Russ Housley 193 918 Spring Knoll Drive 194 Herndon, VA 20170 195 USA 196 housley@vigilsec.com