idnits 2.17.1 draft-housley-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. -- The document date (18 April 2016) is 2928 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') ** Downref: Normative reference to an Informational draft: draft-ietf-curdle-pkix-eddsa (ref. 'PKIXEDDSA') -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: 20 October 2016 18 April 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, Ed25519ph, Ed448, and 15 Ed448ph are described. 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 20 October 2016. 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. The conventions for 54 two recommended elliptic curves are specified, Ed25519 and Ed448. 55 For each curve, two modes are defined, the PureEdDSA mode without 56 pre-hashing (Ed25519 and Ed448), and the HashEdDSA mode with pre- 57 hashing (Ed25519ph and Ed448ph). 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 A message digest is computed over the data to be signed using EdDSA, 79 and then a private key operation is performed to generate the 80 signature value. As described in Section 3.3 of [EDDSA], the 81 signature value is the opaque value ENC(R) || ENC(S). As described 82 in Section 5.3 of [CMS], the signature value is ASN.1 encoded as an 83 OCTET STRING and included in the signature field of SignerInfo. 85 2.1. Certificate Identifiers 87 The EdDSA signature algorithm is defined in [EDDSA], and the 88 conventions for encoding the public key are defined in [PKIXEDDSA]. 90 The id-EdDSAPublicKey OID is used for identifying EdDSA public keys: 92 id-EdDSAPublicKey OBJECT IDENTIFIER ::= { 1 3 101 100 } 94 When the id-EdDSAPublicKey onject identifier is used, the 95 AlgorithmIdentifier parameters field MUST contain EdDSAParameters to 96 specify a particular set of EdDSA parameters: 98 EdDSAParameters ::= ENUMERATED { 99 ed25519 (1), -- PureEdDSA 100 ed25519ph (2), -- HashEdDSA 101 ed448 (3), -- PureEdDSA 102 ed448ph (4) } -- HashEdDSA 104 2.2. Signature Identifiers 106 The algorithm identifier for EdDSA signatures is: 108 id-EdDSASignature OBJECT IDENTIFIER ::= { 1 3 101 101 } 110 When the id-EdDSASignature object identifier is used for a signature, 111 the AlgorithmIdentifier parameters field MUST be absent. 113 3. Signed-data Conventions 115 digestAlgorithms SHOULD contain the one-way hash function used to 116 compute the message digest on the eContent value. 118 The same one-way hash function SHOULD be used for computing the 119 message digest on both the eContent and the signedAttributes value if 120 signedAttributes are present. 122 signatureAlgorithm MUST contain id-EdDSASignature. The algorithm 123 parameters field MUST be absent. 125 signature contains the single value resulting from the EdDSA signing 126 operation. 128 4. Security Considerations 130 Implementations must protect the EdDSA private key. Compromise of 131 the EdDSA private key may result in the ability to forge signatures. 133 The generation of EdDSA private key relies on random numbers. The 134 use of inadequate pseudo-random number generators (PRNGs) to generate 135 these values can result in little or no security. An attacker may 136 find it much easier to reproduce the PRNG environment that produced 137 the keys, searching the resulting small set of possibilities, rather 138 than brute force searching the whole key space. The generation of 139 quality random numbers is difficult. RFC 4086 [RANDOM] offers 140 important guidance in this area. 142 Using the same private key for different algorithms has the potential 143 of allowing an attacker to get extra information about the key. It 144 is strongly suggested that the same key not be used with more than 145 one EdDSA set of parameters. 147 When computing signatures, the same hash function should be used for 148 all operations. This reduces the number of failure points in the 149 signature process. 151 5. Normative References 153 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 154 5652, September 2009. 156 [EDDSA] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 157 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-00, 158 (work in progress), October 2015. 160 [PKIXEDDSA] 161 Josefsson, S., "Using Curve25519 and Curve448 in PKIX", 162 draft-ietf-curdle-pkix-eddsa-00, (work in progress), 163 October 2015. 165 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, March 1997. 168 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 169 One (ASN.1): Specification of basic notation", ITU-T 170 Recommendation X.680, 2002. 172 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 173 Specification of Basic Encoding Rules (BER), Canonical 174 Encoding Rules (CER) and Distinguished Encoding Rules 175 (DER)", ITU-T Recommendation X.690, 2002. 177 6. Informative References 179 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 180 Requirements for Security", RFC 4086, June 2005. 182 Author Address 184 Russ Housley 185 918 Spring Knoll Drive 186 Herndon, VA 20170 187 USA 188 housley@vigilsec.com