idnits 2.17.1 draft-koch-eddsa-for-openpgp-03.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 draft header indicates that this document updates RFC4880, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4880, updated by this document, for RFC5378 checks: 1999-12-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 28, 2015) is 3161 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Koch 3 Internet-Draft g10 Code 4 Updates: 4880 (if approved) August 28, 2015 5 Intended status: Informational 6 Expires: February 29, 2016 8 EdDSA for OpenPGP 9 draft-koch-eddsa-for-openpgp-03 11 Abstract 13 This specification extends OpenPGP with the EdDSA public key 14 algorithm and describes the use of curve Ed25519. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on February 29, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Supported Curves . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Point Format . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Encoding of Public and Private Keys . . . . . . . . . . . . . 3 54 5. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Curve OID . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 10.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 6 63 A.1. Sample key . . . . . . . . . . . . . . . . . . . . . . . 6 64 A.2. Sample signature . . . . . . . . . . . . . . . . . . . . 7 65 Appendix B. Point compression flag bytes . . . . . . . . . . . . 7 66 Appendix C. Changes since -02 . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 The OpenPGP specification in [RFC4880] defines the RSA, Elgamal, and 72 DSA public key algorithms. [RFC6637] adds support for Elliptic Curve 73 Cryptography and specifies the ECDSA and ECDH algorithms. Due to 74 patent reasons no point compression was defined. 76 This document specifies how to use the EdDSA public key signature 77 algorithm [I-D.josefsson-eddsa-ed25519] with the OpenPGP standard. 78 It defines a new signature algorithm named EdDSA and specifies how to 79 use the Ed25519 curve with EdDSA. This algorithm uses a custom point 80 compression method. There are three main advantages of the EdDSA 81 algorithm: It does not require the use of a unique random number for 82 each signature, there are no padding or truncation issues as with 83 ECDSA, and it is more resilient to side-channel attacks. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Supported Curves 91 This document references the Curve "Ed25519" which is the Edwards 92 form of "Curve25519" and specified in the same paper as the "EdDSA" 93 algorithm ([ED25519]). For the full specification see 94 [I-D.josefsson-eddsa-ed25519]. 96 Other curves may be used by using a specific OID for the curve and 97 its EdDSA parameters. 99 The following public key algorithm IDs are added to expand section 100 9.1 of [RFC4880], "Public-Key Algorithms": 102 +-------+-----------------------------+ 103 | ID | Description of Algorithm | 104 +-------+-----------------------------+ 105 | TBD1 | EdDSA public key algorithm | 106 +-------+-----------------------------+ 108 Compliant applications MUST support EdDSA with the curve Ed25519. 109 Applications MAY support other curves as long as a dedicated OID for 110 using that curve with EdDSA is used. 112 3. Point Format 114 The EdDSA algorithm defines a specific point compression format. To 115 indicate the use of this compression format and to make sure that the 116 key can be represented in the Multiprecision Integer (MPI) format of 117 [RFC4880] the octet string specifying the point is prefixed with the 118 octet 0x40. This encoding is an extension of the encoding given in 119 [RFC6637] which uses 0x04 to indicate an uncompressed point. 121 For example, the length of a public key for the curve Ed25519 is 263 122 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the 123 native value of the public key. 125 4. Encoding of Public and Private Keys 127 The following algorithm specific packets are added to Section 5.5.2 128 of [RFC4880], "Public-Key Packet Formats", to support EdDSA. 130 Algorithm-Specific Fields for EdDSA keys: 132 o a variable length field containing a curve OID, formatted as 133 follows: 135 * a one-octet size of the following field; values 0 and 0xFF are 136 reserved for future extensions, 138 * octets representing a curve OID, defined in Section 6. 140 o MPI of an EC point representing a public key Q as described under 141 Point Format above. 143 The following algorithm specific packets are added to Section 5.5.3 144 of [RFC4880], "Secret-Key Packet Formats", to support EdDSA. 146 Algorithm-Specific Fields for EdDSA keys: 148 o an MPI of an integer representing the secret key, which is a 149 scalar of the public EC point. 151 The version 4 packet format MUST be used. 153 5. Message Encoding 155 Section 5.2.3 of [RFC4880], "Version 4 Signature Packet Format" 156 specifies formats. To support EdDSA no change is required, the MPIs 157 representing the R and S value are encoded as MPIs in the same way as 158 done for the DSA and ECDSA algorithms; in particular the Algorithm- 159 Specific Fields for an EdDSA signature are: 161 - MPI of EdDSA value r. 163 - MPI of EdDSA value s. 165 Note that the compressed version of R and S as specified for EdDSA 166 ([I-D.josefsson-eddsa-ed25519]) is used. 168 The version 3 signature format MUST NOT be used with EdDSA. 170 Although that algorithm allows arbitrary data as input, its use with 171 OpenPGP requires that a digest of the message is used as input. See 172 section 5.2.4 of [RFC4880], "Computing Signatures" for details. 173 Truncation of the resulting digest is never applied; the resulting 174 digest value is used verbatim as input to the EdDSA algorithm. 176 6. Curve OID 178 The EdDSA key parameter curve OID is an array of octets that defines 179 a named curve. The table below specifies the exact sequence of bytes 180 for each named curve referenced in this document: 182 +------------------------+------+------------------------+----------+ 183 | OID | Len | Encoding in hex format | Name | 184 +------------------------+------+------------------------+----------+ 185 | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 | 186 | | | 0F 01 | | 187 +------------------------+------+------------------------+----------+ 189 See [RFC6637] for a description of the OID encoding given in the 190 second and third columns. 192 7. Security Considerations 194 The security considerations of [RFC4880] apply accordingly. 196 Although technically possible the use of EdDSA with digest algorithms 197 weaker than SHA-256 (e.g. SHA-1) is not suggested. 199 8. IANA Considerations 201 IANA is requested to assign an algorithm number from the OpenPGP 202 Public-Key Algorithms range, or the "namespace" in the terminology of 203 [RFC5226], that was created by [RFC4880]. See section 2. 205 +-------+-----------------------------+------------+ 206 | ID | Algorithm | Reference | 207 +-------+-----------------------------+------------+ 208 | TBD1 | EdDSA public key algorithm | This doc | 209 +-------+-----------------------------+------------+ 211 [Notes to RFC-Editor: Please remove the table above on publication. 212 It is desirable not to reuse old or reserved algorithms because some 213 existing tools might print a wrong description. A higher number is 214 also an indication for a newer algorithm. As of now 22 is the next 215 free number.] 217 9. Acknowledgments 219 The author would like to acknowledge the help of the individuals who 220 kindly voiced their opinions on the IETF OpenPGP and GnuPG mailing 221 lists, in particular, the help of Andrey Jivsov, Jon Callas, and 222 NIIBE Yutaka. 224 10. References 226 10.1. Normative References 228 [I-D.josefsson-eddsa-ed25519] 229 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 230 josefsson-eddsa-ed25519-03 (work in progress), May 2015. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 236 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 238 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 239 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 240 May 2008. 242 [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in 243 OpenPGP", RFC 6637, June 2012. 245 10.2. Informative References 247 [ED25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. 248 Yang, "High-speed high-security signatures", Journal of 249 Cryptographic Engineering Volume 2, Issue 2, pp. 77-89, 250 September 2011, 251 . 253 Appendix A. Test vectors 255 For help implementing this specification a non-normative example is 256 given. This example assumes that the algorithm id for EdDSA (TBD1) 257 will be 22. 259 A.1. Sample key 261 The secret key used for this example is: 263 D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2 265 Note that this is the raw secret key used as input to the EdDSA 266 signing operation. The key was created on 2014-08-19 14:28:27 and 267 thus the fingerprint of the OpenPGP key is: 269 C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A 271 The algorithm specific input parameters without the MPI length 272 headers are: 274 oid: 2b06010401da470f01 276 q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406 278 The entire public key packet is thus: 280 98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47 281 0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19 282 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e 283 43 ee 3b 24 06 285 A.2. Sample signature 287 The signature is created using the sample key over the input data 288 "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash 289 function is: 291 m: 4f70656e504750040016080006050255f95f9504ff0000000c 293 Using the SHA-256 hash algorithm yields the digest: 295 d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280 297 Which is fed into the EdDSA signature function and yields this 298 signature: 300 r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366 302 s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404 304 The entire signature packet is thus: 306 88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a 307 09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9 308 0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2 309 7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00 310 d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e 311 a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04 313 Appendix B. Point compression flag bytes 315 This specification introduces the new flag byte 0x40 to indicate the 316 point compression format. The value has been chosen so that the high 317 bit is not cleared and thus to avoid accidental sign extension. Two 318 other values might also be interesting for other ECC specifications: 320 Flag Description 321 ---- ----------- 322 0x04 Standard flag for uncompression format 323 0x40 Native point format of the curve follows 324 0x41 Only X coordinate follows. 325 0x42 Only Y coordinate follows. 327 Appendix C. Changes since -02 329 o Fixed decription in the test vectors regarding an extra 0x00 byte. 331 o Small gramar fixes. 333 o Reference Josefsson's EdDSA I-D instead of the original paper. 335 Author's Address 337 Werner Koch 338 g10 Code 340 Email: wk@gnupg.org 341 URI: https://g10code.com