idnits 2.17.1 draft-jivsov-openpgp-ecc-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 468 has weird spacing: '...trength stre...' == Unrecognized Status in 'Intended status: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (June 24, 2010) is 5056 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Suite B' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST SP800-56A' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-2' ** Downref: Normative reference to an Informational RFC: RFC 3394 -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS5' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Jivsov 3 Internet Draft Symantec Corporation 4 Intended status: Internet Draft June 24, 2010 5 Expires: December 21, 2010 7 ECC in OpenPGP 8 draft-jivsov-openpgp-ecc-05.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 21, 2010. 34 Copyright Notice 36 Copyright (c) 2009 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 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This document proposes an Elliptic Curve Cryptography extension to 52 the OpenPGP public key format and specifies three Elliptic Curves 53 that enjoy broad support by other standards, including NIST 54 standards. The document aims to standardize an optimal but narrow 55 set of parameters for best interoperability and it does so within 56 the framework it defines that can be expanded in the future to 57 allow more choices. 59 Table of Contents 60 1. Introduction.................................................2 61 2. Conventions used in this document............................2 62 3. Elliptic Curve Cryptography..................................3 63 4. Supported ECC curves.........................................3 64 5. Supported public key algorithms..............................3 65 6. Conversion primitives........................................4 66 7. Key Derivation Function......................................4 67 8. EC DH Algorithm (ECDH).......................................5 68 9. Encoding of public and private keys..........................7 69 10. Data encoding with public keys..............................8 70 11. ECC curve OID...............................................9 71 12. Compatibility profiles......................................9 72 12.1. OpenPGP ECC profile....................................9 73 12.2. Suite-B profile.......................................10 74 12.2.1. Secret information...............................10 75 12.2.2. Top Secret information...........................10 76 13. Security Considerations....................................10 77 14. IANA Considerations........................................12 78 15. Normative references.......................................12 80 1. Introduction 82 The OpenPGP protocol supports RSA and DSA public key formats. This 83 document defines the extension to incorporate support for public 84 keys that are based on Elliptic Curve Cryptography (ECC). 86 2. Conventions used in this document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 90 this document are to be interpreted as described in [RFC2119]. 92 An application MAY implement this draft; note that any [RFC2119] 93 keyword within this draft applies to an OpenPGP application only if 94 it chooses to implement this draft. 96 3. Elliptic Curve Cryptography 98 This specification establishes the minimum set of Elliptic Curve 99 Cryptography public key parameters and cryptographic methods that 100 will likely satisfy the widest range of platforms and applications 101 and facilitate interoperability. This specification offers 102 efficient cryptographic method for applications to match the level 103 of security of every type of AES algorithm specified in [RFC4880]. 105 This document defines a path to expand ECC support in the future. 106 National Security Agency (NSA) of the United States specifies ECC 107 for use in its Suite B set of algorithms [Suite B]. This 108 specification includes algorithms permitted by Suite B, so it would 109 be possible to build a Suite B compatible implementation based on a 110 subset of [RFC4880] and this specification. 112 4. Supported ECC curves 114 This standard references three named prime field curves, which are 115 defined in [FIPS 186-2] as "Curve P-256", "Curve P-384", and "Curve 116 P-521". 118 In data structures that this specification defines the named curves 119 are referenced as a sequence of bytes, called throughout this 120 specification as Curve OID. Section 11 describes in details how 121 this sequence of bytes is formed. 123 5. Supported public key algorithms 125 Supported public key algorithms are Elliptic Curve Digital 126 Signature Algorithm (ECDSA), defined in [FIPS 186-2], and Elliptic 127 Curve Diffie-Hellman (ECDH), defined in section 8. 129 Other compatible definition of ECDSA can be found in [SEC1]. 131 The section 9.1. Public-Key Algorithms of [RFC4880] is expanded to 132 define the following public key algorithm IDs: 134 ID Description of algorithm 136 19 ECDSA public key algorithm 138 [to be ECDH public key algorithm 139 ASSIGNED] 140 presumably 22 142 Applications MUST support ECDSA and ECDH. 144 6. Conversion primitives 146 The method to convert an EC point to the octet string is defined in 147 [SEC1]. This specification only defines uncompressed point 148 format. For convenience, the synopsis of the encoding method is 149 given below, however, the [SEC1] is the normative source of the 150 definition. 152 The point is encoded in MPI format. The content of the MPI is the 153 following: 155 B = B0 || x || y 156 where x and y are coordinates of the point P = (x, y), each encoded 157 in big endian format and zero-padded to the underlying field size. 159 B0 is a byte with following values: 161 value description 163 0 Point O. In this case there is no x or y octets present. 165 4 Uncompressed point. x and y of EC point values follow. 167 Note that point O shall not appear in a public or a private 168 key. Therefore, the size of the MPI payload is always curve_size*2 169 + 3 bits. For example, for "Curve P-256" the point is represented 170 as a bit string of length 515 bits. 172 If other conversion methods are defined in the future, the 173 application MAY use them only when it is certain that every 174 recipient of the data supports the other format. 176 7. Key Derivation Function 178 A key derivation function (KDF) is necessary to implement EC 179 encryption. The Concatenation Key Derivation Function (Approved 180 Alternative 1) defined in [NIST SP800-56A] is REQUIRED with the 181 following restriction: the KDF hash function MAY be any of the 182 following hash functions specified by [FIPS 180-2]: SHA2-256, 183 SHA2-384, SHA2-512. See section 13 for the details regarding the 184 choice of the hash function. 186 For convenience, the synopsis of the encoding method is given 187 below, however, [NIST SP800-56A] is the normative source of the 188 definition. 190 // Implements KDF( X, oBits, P ); 191 // Input: point X = (x,y) 192 // oBits - the desired size of output 193 // hBits - the size of output of hash function Hash 194 // P - octets representing the parameters 196 counter=1; 197 threshold = (oBits + hBits - 1) / hBits; 198 // Convert the point P to octet string as defined in section 6: 199 // ZB' = 04 || x || y 200 // and extract the x portion from ZB': 201 ZB = x; 202 do { 203 C32 = (uint32)big_endian(counter); 204 HB = Hash ( C32 || ZB || P ); 205 MB = MB || HB; 206 counter = counter + 1; 207 } while( counter <= threshold ); 208 return oBits leftmost bits of MB 210 8. EC DH Algorithm (ECDH) 212 The method is a combination of ECC Diffie-Hellman method to 213 establish a shared secret and a key wrapping method that uses the 214 shared secret to protect symmetric encryption key. 216 One-Pass Diffie-Hellman method C(1, 1, ECC CDH), defined in [NIST 217 SP800-56A], SHOULD be implemented with the following restrictions: 218 ECC CDH primitive employed by this method is modified to always 219 assume the cofactor as 1, KDF specified in section 7 is used, and 220 KDF parameters specified below are used. 222 Key derivation parameters MUST be encoded as concatenation of the 223 following 7 fields, each of them, except the first one, is 224 considered a fixed-length field of corresponding size: 226 o a variable-length field containing curve OID, formatted as 227 follows 229 o a one-octet size of the following field 231 o octets representing curve OID, defined in section 11 233 o a one-octet public key algorithm ID defined in section 5 235 o a one-octet value 01, reserved for future extensions 236 o a one-octet hash function ID used in KDF; according to section 237 7, this octet is 08 for SHA2-256, 09 for SHA2-384, or 10 for 238 SHA2-512 240 o a one-octet algorithm ID for the symmetric algorithm used to 241 wrap the symmetric key for message encryption; the method is 242 defined later in this section 244 o 15 octets representing the UTF-8 encoding of the string 245 "AnonymousSender" 247 o 20 octets representing recipient encryption subkey or master key 248 fingerprint, identifying the key material that is needed for 249 decryption 251 For three curves defined in this specification the size of the key 252 derivation parameters sequence, defined above, is either 48 or 45. 254 The key wrapping method is based on [RFC3394]. KDF produces the 255 AES key that is used as KEK according to [RFC3394]. Refer to 256 section 13 for the details regarding the choice of the KEK 257 algorithm, which MUST be one of three AES algorithms. 259 The input to key wrapping method is the value "m" derived from the 260 session key as described in section 5.1. Public-Key Encrypted 261 Session Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5 262 padding step is omitted. The result is padded using the method 263 described in [PKCS5] to the 8-byte granularity. For example, a 264 following AES-256 session key which 32 octets are denoted from k0 265 to k31 is composed as described bellow to form a 40 octet sequence: 267 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 269 The octets c0 and c1 above denote the checksum. This encoding 270 allows the sender to obfuscate size of the symmetric encryption key 271 used to encrypt the data. To do this the sender MAY use 21, 13, 272 and 5 bytes of padding for AES-128, AES-192, and AES-256, 273 respectfully, to provide the same number of octets, 40 total, as an 274 input to the key wrapping method. 276 The output of the method consists of two fields. The first field 277 is the MPI with the ephemeral key used to establish shared 278 secret. The second field is composed of the following two fields: 280 o a one octet, encoding the size in octets of the result of the 281 key wrapping method; the value 255 is reserved for future 282 extensions 283 o up to 254 octets representing the result of the key wrapping 284 method applied to session key encoded as described above 286 Note that for session key sizes 128, 192, and 256 bits the size of 287 the result of the key wrapping method is, respectfully, 32, 40, and 288 48 octets. 290 For convenience, the synopsis of the encoding method is given 291 below, however, this section, [NIST SP800-56A], and [RFC3394] are 292 the normative sources of the definition. 294 Obtain authenticated recipient public key R 295 Generate ephemeral key pair {v, V=vG} 296 Compute shared point S = vR; 297 m = symm_alg_ID || session key || checksum || pkcs5_padding; 298 curve_OID_len = (byte)len(curve_OID); 299 Param = curve_OID_len || curve_OID || public_key_alg_ID || 300 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || 301 "AnonymousSender" || recipient_fingerprint; 302 Z_len = key size for AES_alg_ID to be used with AESKeyWrap 303 Compute Z = KDF( S, Z_len, Param ); 304 Compute C = AESKeyWrap( Z, m ) as per [RFC3394] 305 VB = convert point V to octet string 306 Output (MPI(VB) || len(C) || C). 308 The decryption is the inverse of the method given. Note that the 309 recipient obtains the shared secret by calculating 311 S = rV = rvG, where (r,R) is the recipient's key pair. 313 Consistent with section 5.13 Sym. Encrypted Integrity Protected 314 Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime 315 symmetric key is protected by ECDH. 317 9. Encoding of public and private keys 319 The following algorithm-specific packets are added to Section 5.5.2 320 Public-Key Packet Formats of [RFC4880] to support ECDH and ECDSA. 322 This algorithm-specific portion is: 324 Algorithm-Specific Fields for ECDH keys: 326 o a variable-length field containing curve OID, formatted as 327 follows 329 o a one-octet size of the following field; values 0 and 330 0xFF are reserved for future extensions 331 o octets representing curve OID, defined in section 11 333 o a one-octet value 01, reserved for future extension 335 o a one-octet hash function ID used with KDF 337 o a one-octet algorithm ID for the symmetric algorithm used 338 to wrap the symmetric key for message encryption, see 339 section 8 for details 341 o MPI of EC point representing public key 343 Algorithm-Specific Fields for ECDSA keys: 344 o a variable-length field containing curve OID, formatted as 345 follows 347 o a one-octet size of the following field; values 0 and 348 0xFF are reserved for future extensions 350 o octets representing curve OID, defined in section 11 352 o MPI of EC point representing public key 354 The following algorithm-specific packets are added to section 355 5.5.3. Secret-Key Packet Formats of [RFC4880] to support ECDH and 356 ECDSA. 358 Algorithm-Specific Fields for ECDH or ECDSA secret keys: 360 o MPI of an integer representing the secret key, which is a 361 scalar of the EC point 363 10. Data encoding with public keys 365 Section 5.2.2. Version 3 Signature Packet Format defines signature 366 formats. No changes in format are needed for ECDSA. 368 Section 5.1. Public-Key Encrypted Session Key Packets (Tag 1) is 369 extended to support ECDH. The following two fields are result of 370 applying KDF, as described in section 8. 372 Algorithm Specific Fields for ECDH: 373 o an MPI of EC point representing ephemeral public key 375 o a one octet size, followed by a symmetric key encoded 376 using the method described in section 8. 377 11. ECC curve OID 379 The parameter curve OID is an array of octets that define the named 380 curve. The table bellow specifies the exact sequence of bytes for 381 each named curve referenced in this specification: 383 ASN.1 Object OID Curve OID bytes in Curve name in 384 Identifier len hexadecimal [FIPS 186-2] 385 representation 387 1.2.840.10045.3.1.7 8 2A 86 48 CE 3D 03 01 07 NIST curve P-256 389 1.3.132.0.34 5 2B 81 04 00 22 NIST curve P-384 391 1.3.132.0.35 5 2B 81 04 00 23 NIST curve P-521 393 The sequence of octets in the third column is the result of 394 applying Distinguished Encoding Rules (DER) to the ASN.1 Object 395 Identifier with subsequent truncation. The truncation removes two 396 fields of encoded Object Identifier. The first omitted field is 397 one octet representing the Object Identifier tag and the second 398 omitted field is the length of the Object Identifier body. For 399 example, the complete ASN.1 DER encoding for the NIST P-256 curve 400 is "06 08 2A 86 48 CE 3D 03 01 07", from which the entry in the 401 table above is constructed by omitting two first octets. 403 12. Compatibility profiles 405 12.1. OpenPGP ECC profile 407 Application MUST implement NIST curve P-256, MAY implement NIST 408 curve P-384, and SHOULD implement NIST curve P-521, defined in 409 section 11. Application MUST implement SHA2-256 and SHOULD 410 implement SHA2-512. Application MUST implement AES-128 and SHOULD 411 implement AES-256. 413 Application SHOULD follow section 13 regarding the choice of the 414 following algorithms for each curve 416 o the KDF hash algorithm 417 o KEK algorithm 419 o message digest algorithm and hash algorithm used in key 420 certifications 422 o message encryption symmetric algorithm. 424 It is recommended that the chosen symmetric algorithm for message 425 encryption be no less secure than the KEK algorithm. 427 12.2. Suite-B profile 429 A subset of algorithms allowed by this specification can be used to 430 achieve [Suite B] compatibility. The references to [Suite B] in 431 this document are informative. This document is primarily 432 concerned with format specification, leaving unspecified additional 433 security restrictions, such as matching security level of 434 information with authorized recipients or interoperability concerns 435 arising from fewer allowed algorithms in [Suite B] than in 436 [RFC4880]. 438 12.2.1. Secret information 440 Applications MUST use NIST curves P-256 or P-384. KEK MUST be used 441 with AES-128 or AES-256. KDF MUST be used with SHA2-256 or 442 SHA2-384. 444 Note that the most secure algorithm in of each of 3 categories 445 above is also listed in the section 12.2.2. 447 12.2.2. Top Secret information 449 Application MUST use NIST curve P-384. KEK MUST be used with 450 AES-256. SHA2-384 MUST be used for KDF. 452 13. Security Considerations 454 The curves proposed in this document correspond to the symmetric 455 key sizes 128 bits, 192 bits, and 256 bits as described in the 456 table below. This allows OpenPGP application to offer security 457 comparable with the strength of each AES algorithms allowed by 458 [RFC4880]. 460 The following table defines the hash and symmetric encryption 461 algorithm that SHOULD be used with specific curve for ECDSA or 462 ECDH. Stronger hash algorithm or symmetric key algorithm MAY be 463 used for a given ECC curve. However, note that the increase in the 464 strength of the hash algorithm or symmetric key algorithm may not 465 increase the overall security offered by the given ECC key. 467 Curve name ECC RSA Hash size Symmetric 468 strength strength, key size 469 informative 471 NIST curve P-256 256 3072 256 128 473 NIST curve P-384 384 7680 384 192 475 NIST curve P-521 521 15360 512 256 477 Requirement levels indicated elsewhere in this document result in 478 the effective support for the following combinations of algorithms 479 in OpenPGP profile: MUST implement NIST curve P-256 / SHA2-256 / 480 AES-128, SHOULD implement NIST curve P-521 / SHA2-512 / AES-256, 481 MAY implement NIST curve P-384 / SHA2-384 / AES-256, among other 482 allowed combinations. 484 Consistent with the table above, the following table defines the 485 KDF hash algorithm and AES KEK encryption algorithm that SHOULD be 486 used with specific curve for ECDH. Stronger KDF hash algorithm or 487 KEK algorithm MAY be used for a given ECC curve. 489 Curve name Recommended KDF Recommended KEK 490 hash algorithm encryption algorithm 492 NIST curve P-256 SHA2-256 AES-128 494 NIST curve P-384 SHA2-384 AES-192 496 NIST curve P-521 SHA2-512 AES-256 498 Applications SHOULD implement, advertise through key preferences, 499 and use in compliance with [RFC4880] strongest algorithms specified 500 in this document. 502 Note that [RFC4880] symmetric algorithm preference list may 503 restrict the use of balanced strength of symmetric key algorithms 504 for corresponding public key. For example, the presence of 505 symmetric key algorithms and their order in key preference list 506 affects the choices available to encoding side for compliance with 507 the table above. Therefore, applications need to be concerned with 508 this compliance throughout the life of the key, starting 509 immediately after key generation when the key preferences are first 510 added to a key. It is generally advisable to have at the head of 511 the key preference list a symmetric algorithm of strength 512 corresponding to the public key. 514 Often encryption to multiple recipients results in an unordered 515 intersection subset. For example, given two recipients, if first 516 recipient's set is {A, B} and second's is {B, A}, the intersection 517 is unordered set of two algorithms A and B. In this case 518 application SHOULD choose stronger encryption algorithm. 520 Resource constraint, such as limited computational power, is the 521 likely reason why an application might prefer to use weakest 522 algorithms. On the other side of the spectrum are applications 523 that can implement every algorithm defined in this document. Most 524 of applications are expected to fall into either of two 525 categories. An application in the second or strongest category 526 SHOULD prefer AES-256 to AES-192. 528 While some statements in this specification refer to TripleDES 529 algorithm, this is only done to help interoperability with existing 530 application and already generated keys; AES-256 is the recommended 531 alternative to TripleDES in all circumstances when AES-256 is 532 available. 534 SHA-1 MUST NOT be used for ECDSA or as part of ECDH method. 536 MDC MUST be used when symmetric encryption key is protected by 537 ECDH. None of the ECC methods described in this document are 538 allowed with deprecated V3 keys. The application MUST only use 539 Iterated and Salted S2K to protect private keys, as defined in 540 section 3.7.1.3 Iterated and Salted S2K of [RFC4880]. 542 14. IANA Considerations 544 This document asks IANA to assign an algorithm number from OpenPGP 545 Public-Key Algorithms range, or "name space" in the terminology of 546 [RFC2434], that was created by [RFC4880]. Two ID numbers are 547 requested, as defined in section 5. The first one with value 19 is 548 already designated for ECDSA and currently unused, while another 549 one is new (and expected to be 22). 551 15. Normative references 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", March 1997 556 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 557 Thayer, "OpenPGP Message Format", November 2007 559 [Suite B] NSA, US Government, NSA Suite B Cryptography, March 11, 560 2010, 561 http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml 563 [FIPS 186-2] US Dept. of Commerce / NIST, "DIGITAL SIGNATURE 564 STANDARD (DSS)", October 5, 2001 566 [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 567 September 20, 2000 569 [NIST SP800-56A] Elaine Barker, Don Johnson, and Miles Smid, 570 "Recommendation for Pair-WiseKey Establishment Schemes Using 571 Discrete Logarithm Cryptography (Revised)", March 2007 573 [FIPS 180-2] NIST, "SECURE HASH STANDARD", August 1, 2002 575 [RFC3394] J. Schaad, R. Housley, "Advanced Encryption Standard 576 (AES) Key Wrap Algorithm", September 2002 578 [PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based 579 Cryptography Standard", March 25, 1999 581 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing IANA 582 Considerations Section in RFCs", October 1998 584 Contributors 586 Hal Finney provided important criticism on compliance with [NIST 587 SP800-56A] and [Suite B], and pointed out a few other mistakes. 589 Acknowledgment 591 The author would like to acknowledge the help of many individuals 592 who kindly voiced their opinions on IETF OpenPGP Working Group 593 mailing list and, in particular the help of Jon Callas, David 594 Crick, Ian G, Werner Koch. [to be continued] 596 Author's Address 598 Andrey Jivsov 599 Symantec Corporation 600 Email: ajivsov@pgp.com