idnits 2.17.1 draft-jivsov-openpgp-ecc-14.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 498 has weird spacing: '...trength stre...' == Unrecognized Status in 'Intended status: Standards', 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 (April 11, 2012) is 4369 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-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST SP800-56A' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180-3' ** 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: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: Standards April 11, 2012 5 Expires: October 8, 2012 7 ECC in OpenPGP 8 draft-jivsov-openpgp-ecc-14.txt 10 Abstract 12 This document defines an Elliptic Curve Cryptography extension to 13 the OpenPGP public key format and specifies three Elliptic Curves 14 that enjoy broad support by other standards, including standards 15 published by the US National Institute of Standards and 16 Technology. The document specifies the conventions for 17 interoperability between compliant OpenPGP implementations that 18 make use of this extension. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with 23 the provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on October 8, 2012. 44 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 59 1. Introduction.................................................2 60 2. Conventions used in this document............................2 61 3. Elliptic Curve Cryptography..................................3 62 4. Supported ECC curves.........................................3 63 5. Supported public key algorithms..............................3 64 6. Conversion primitives........................................4 65 7. Key Derivation Function......................................4 66 8. EC DH Algorithm (ECDH).......................................5 67 9. Encoding of public and private keys..........................8 68 10. Message encoding with public keys...........................9 69 11. ECC curve OID...............................................9 70 12. Compatibility profiles.....................................10 71 12.1. OpenPGP ECC profile...................................10 72 12.2. Suite-B profile.......................................10 73 12.2.1. Security strength at 192 bits....................10 74 12.2.2. Security strength at 128 bits....................11 75 13. Security Considerations....................................11 76 14. IANA Considerations........................................13 77 15. References.................................................13 78 15.1. Normative references..................................13 79 15.2. Informative references................................14 81 1. Introduction 83 The OpenPGP protocol [RFC4880] supports RSA and DSA public key 84 formats. This document defines the extension to incorporate 85 support for public keys that are based on Elliptic Curve 86 Cryptography (ECC). 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 92 this document are to be interpreted as described in [RFC2119]. 94 Any implementation that adheres to the format and methods specified 95 in this document is called a compliant application. Compliant 96 applications is a subset of the the broader set of [RFC4880] 97 OpenPGP applications. Any [RFC2119] keyword within this document 98 applies to compliant applications only. 100 3. Elliptic Curve Cryptography 102 This document establishes the minimum set of Elliptic Curve 103 Cryptography (ECC) public key parameters and cryptographic methods 104 that will likely satisfy the widest range of platforms and 105 applications and facilitate interoperability. It adds a more 106 efficient method for applications to balance the overall level of 107 security with any AES algorithm specified in [RFC4880] than by 108 simply increasing the size of RSA keys. 109 This document defines a path to expand ECC support in the future. 111 National Security Agency (NSA) of the United States specifies ECC 112 for use in its [Suite B] set of algorithms. This document includes 113 algorithms required by Suite B that are not present in [RFC4880]. 115 [KOBLITZ] provides a thorough introduction to ECC. 117 4. Supported ECC curves 119 This document references three named prime field curves, defined in 120 [FIPS 186-3] as "Curve P-256", "Curve P-384", and "Curve P-521". 122 The named curves are referenced as a sequence of bytes in this 123 document, called throughout this document as curve OID. Section 11 124 describes in details how this sequence of bytes is formed. 126 5. Supported public key algorithms 128 The supported public key algorithms are Elliptic Curve Digital 129 Signature Algorithm (ECDSA) [FIPS 186-3] and Elliptic Curve Diffie- 130 Hellman (ECDH). A compatible specification of ECDSA is given in 131 [RFC6090] as "KT-I Signatures" and in [SEC1]; ECDH is defined in 132 section 8. 134 The following public key algorithm IDs are added to expand the 135 section 9.1. Public-Key Algorithms of [RFC4880]: 137 ID Description of algorithm 139 [to be ECDH public key algorithm 140 ASSIGNED] 141 presumably 18 143 19 ECDSA public key algorithm 145 Compliant applications MUST support ECDSA and ECDH. 147 6. Conversion primitives 149 This document only defines the uncompressed point format. The 150 point is encoded in the Multiprecision Integer (MPI) format 151 [RFC4880]. The content of the MPI is the following: 153 B = 04 || x || y 155 where x and y are coordinates of the point P = (x, y), each encoded 156 in the big endian format and zero-padded to the adjusted underlying 157 field size. The adjusted underlying field size is the underlying 158 field size that is rounded up to the nearest 8-bit boundary. 160 Therefore, the exact size of the MPI payload is 515 bits for "Curve 161 P-256", 771 for "Curve P-384", and 1059 for "Curve P-521". 163 Even though the zero point, also called the point at infinity, may 164 occur as a result of arithmetic operations on points of an elliptic 165 curve, it SHALL NOT appear in data structures defined in this 166 document. 168 This encoding is compatible with the definition given in [SEC1]. 170 If other conversion methods are defined in the future, a compliant 171 application MUST NOT use a new format when in doubt that any 172 recipient can support it. Consider, for example, that while both 173 the public key and the per-recipient ECDH data structure, 174 respectively defined in sections 9 and 10, contain an encoded point 175 field, the format changes to the field in section 10 only affect a 176 given recipient of a given message. 178 7. Key Derivation Function 180 A key derivation function (KDF) is necessary to implement the EC 181 encryption. The Concatenation Key Derivation Function (Approved 182 Alternative 1) [NIST SP800-56A] with the KDF hash function that is 183 SHA2-256 [FIPS 180-3] or stronger is REQUIRED. See section 12 for 184 the details regarding the choice of the hash function. 186 For convenience, the synopsis of the encoding method is given below 187 with significant simplifications attributable to the restricted 188 choice of hash functions in this document. However, [NIST SP800- 189 56A] is the normative source of the definition. 191 // Implements KDF( X, oBits, Param ); 192 // Input: point X = (x,y) 193 // oBits - the desired size of output 194 // hBits - the size of output of hash function Hash 195 // Param - octets representing the parameters 196 // Assumes that oBits <= hBits 197 // Convert the point X to the octet string, see section 6: 198 // ZB' = 04 || x || y 199 // and extract the x portion from ZB' 200 ZB = x; 201 MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param ); 202 return oBits leftmost bits of MB. 203 Note that ZB in the KDF description above is is the compact 204 representation of X, defined in section 4.2 of [RFC6090] 206 8. EC DH Algorithm (ECDH) 208 The method is a combination of a ECC Diffie-Hellman method to 209 establish a shared secret, a key derivation method to process the 210 shared secret into a derived key, and a key wrapping method that 211 uses the derived key to protect a session key used to encrypt a 212 message. 214 The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [NIST SP800-56A] 215 MUST be implemented with the following restrictions: the ECC CDH 216 primitive employed by this method is modified to always assume the 217 cofactor as 1, the KDF specified in section 7 is used, and the KDF 218 parameters specified below are used. 220 The KDF parameters are encoded as concatenation of the following 5 221 variable-length and fixed-length fields, compatible with the 222 definition of the OtherInfo bitstring [NIST SP800-56A]: 224 o a variable-length field containing a curve OID, formatted as 225 follows 227 o a one-octet size of the following field 229 o the octets representing a curve OID, defined in section 11 231 o a one-octet public key algorithm ID defined in section 5 233 o a variable-length field containing KDF parameters, identical to 234 the corresponding field in the ECDH public key, formatted as 235 follows 237 o a one-octet size of the following fields; values 0 and 0xff 238 are reserved for future extensions 240 o a one-octet value 01, reserved for future extensions 242 o a one-octet hash function ID used with the KDF 244 o a one-octet algorithm ID for the symmetric algorithm used 245 to wrap the symmetric key for message encryption, see 246 section 8 for details 248 o 20 octets representing the UTF-8 encoding of the string 249 "Anonymous Sender ", which is the octet sequence 250 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20 252 o 20 octets representing a recipient encryption subkey or a master 253 key fingerprint, identifying the key material that is needed for 254 the decryption 256 The size of the KDF pameters sequence, defined above, is either 54 257 or 51 for the three curves defined in this document. 259 The key wrapping method is described in [RFC3394]. KDF produces a 260 symmetric key that is used as a KEK as specified in 261 [RFC3394]. Refer to section 13 for the details regarding the 262 choice of the KEK algorithm, which SHOULD be one of three AES 263 algorithms. Key wrapping and unwrapping is performed with the 264 Default Initial Value of [RFC3394]. 266 The input to the key wrapping method is the value "m" derived from 267 the session key, as described in section 5.1. Public-Key Encrypted 268 Session Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5 269 padding step is omitted. The result is padded using the method 270 described in [PKCS5] to the 8-byte granularity. For example, a 271 following AES-256 session key, which 32 octets are denoted from k0 272 to k31, is composed to form the following 40 octet sequence: 274 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 276 The octets c0 and c1 above denote the checksum. This encoding 277 allows the sender to obfuscate the size of the symmetric encryption 278 key used to encrypt the data. For example, assuming that an AES 279 algorithm is used for the session key, the sender MAY use 21, 13, 280 and 5 bytes of padding for AES-128, AES-192, and AES-256, 281 respectively, to provide the same number of octets, 40 total, as an 282 input to the key wrapping method. 284 The output of the method consists of two fields. The first field 285 is the MPI containing the ephemeral key used to establish the 286 shared secret. The second field is composed of the following two 287 fields: 289 o a one octet, encoding the size in octets of the result of the 290 key wrapping method; the value 255 is reserved for future 291 extensions 293 o up to 254 octets representing the result of the key wrapping 294 method, applied to the 8-byte padded session key, as described 295 above 297 Note that for session key sizes 128, 192, and 256 bits the size of 298 the result of the key wrapping method is, respectively, 32, 40, and 299 48 octets, unless the size obfuscation is used. 301 For convenience, the synopsis of the encoding method is given 302 below, however, this section, [NIST SP800-56A], and [RFC3394] are 303 the normative sources of the definition. 305 Obtain the authenticated recipient public key R 306 Generate an ephemeral key pair {v, V=vG} 307 Compute the shared point S = vR; 308 m = symm_alg_ID || session key || checksum || pkcs5_padding; 309 curve_OID_len = (byte)len(curve_OID); 310 Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 311 || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous 312 Sender " || recipient_fingerprint; 313 Z_len = the key size for the KEK_alg_ID used with AESKeyWrap 314 Compute Z = KDF( S, Z_len, Param ); 315 Compute C = AESKeyWrap( Z, m ) as per [RFC3394] 316 VB = convert point V to the octet string 317 Output (MPI(VB) || len(C) || C). 319 The decryption is the inverse of the method given. Note that the 320 recipient obtains the shared secret by calculating 322 S = rV = rvG, where (r,R) is the recipient's key pair. 324 Consistent with section 5.13 Sym. Encrypted Integrity Protected 325 Data Packet (Tag 18) of [RFC4880], MDC MUST be used anytime 326 symmetric key is protected by ECDH. 328 9. Encoding of public and private keys 330 The following algorithm-specific packets are added to Section 5.5.2 331 Public-Key Packet Formats of [RFC4880] to support ECDH and ECDSA. 333 This algorithm-specific portion is: 335 Algorithm-Specific Fields for ECDSA keys: 336 o a variable-length field containing a curve OID, formatted 337 as follows 339 o a one-octet size of the following field; values 0 and 340 0xFF are reserved for future extensions 342 o octets representing a curve OID, defined in section 11 344 o MPI of an EC point representing a public key 346 Algorithm-Specific Fields for ECDH keys: 348 o a variable-length field containing a curve OID, formatted 349 as follows 351 o a one-octet size of the following field; values 0 and 352 0xFF are reserved for future extensions 354 o the octets representing a curve OID, defined in 355 section 11 357 o MPI of EC point representing public key 359 o a variable-length field containing KDF parameters, 360 formatted as follows 362 o a one-octet size of the following fields; values 0 and 363 0xff are reserved for future extensions 365 o a one-octet value 01, reserved for future extensions 367 o a one-octet hash function ID used with a KDF 369 o a one-octet algorithm ID for the symmetric algorithm 370 used to wrap the symmetric key used for the message 371 encryption; see section 8 for details 373 Observe that an ECDH public key is composed of the same sequence of 374 fields that define an ECDSA key, plus the KDF parameters field. 376 The following algorithm-specific packets are added to section 377 5.5.3. Secret-Key Packet Formats of [RFC4880] to support ECDH and 378 ECDSA. 380 Algorithm-Specific Fields for ECDH or ECDSA secret keys: 382 o an MPI of an integer representing the secret key, which is 383 a scalar of the public EC point 385 10. Message encoding with public keys 387 Section 5.2.2. Version 3 Signature Packet Format defines signature 388 formats. No changes in the format are needed for ECDSA. 390 Section 5.1. Public-Key Encrypted Session Key Packets (Tag 1) is 391 extended to support ECDH. The following two fields are the result 392 of applying the KDF, as described in section 8. 394 Algorithm Specific Fields for ECDH: 395 o an MPI of EC point representing an ephemeral public key 397 o a one octet size, followed by a symmetric key encoded using 398 the method described in section 8. 400 11. ECC curve OID 402 The parameter curve OID is an array of octets that define a named 403 curve. The table bellow specifies the exact sequence of bytes for 404 each named curve referenced in this document: 406 ASN.1 Object OID Curve OID bytes in Curve name in 407 Identifier len hexadecimal [FIPS 186-3] 408 representation 410 1.2.840.10045.3.1.7 8 2A 86 48 CE 3D 03 01 07 NIST curve P-256 412 1.3.132.0.34 5 2B 81 04 00 22 NIST curve P-384 414 1.3.132.0.35 5 2B 81 04 00 23 NIST curve P-521 416 The sequence of octets in the third column is the result of 417 applying the Distinguished Encoding Rules (DER) to the ASN.1 Object 418 Identifier with subsequent truncation. The truncation removes the 419 two fields of encoded Object Identifier. The first omitted field 420 is one octet representing the Object Identifier tag and the second 421 omitted field is the length of the Object Identifier body. For 422 example, the complete ASN.1 DER encoding for the NIST P-256 curve 423 OID is "06 08 2A 86 48 CE 3D 03 01 07", from which the first entry 424 in the table above is constructed by omitting the first two 425 octets. Only the truncated sequence of octets is the valid 426 representation of a curve OID. 428 12. Compatibility profiles 430 12.1. OpenPGP ECC profile 432 A compliant application MUST implement NIST curve P-256, MAY 433 implement NIST curve P-384, and SHOULD implement NIST curve P-521, 434 defined in section 11. A compliant application MUST implement 435 SHA2-256, and SHOULD implement SHA2-384 and SHA2-512. A compliant 436 application MUST implement AES-128 and SHOULD implement AES-256. 438 A compliant application SHOULD follow section 13 regarding the 439 choice of the following algorithms for each curve: 441 o the KDF hash algorithm 443 o the KEK algorithm 445 o the message digest algorithm and the hash algorithm used in the 446 key certifications 448 o the symmetric algorithm used for message encryption. 450 It is recommended that the chosen symmetric algorithm for message 451 encryption be no less secure than the KEK algorithm. 453 12.2. Suite-B profile 455 A subset of algorithms allowed by this document can be used to 456 achieve [Suite B] compatibility. The references to [Suite B] in 457 this document are informative. This document is primarily 458 concerned with format specification, leaving additional security 459 restrictions unspecified, such as matching assigned security level 460 of information to authorized recipients or interoperability 461 concerns arising from fewer allowed algorithms in [Suite B] than 462 allowed by [RFC4880]. 464 12.2.1. Security strength at 192 bits 466 To achieve the security strength of 192 bits [Suite B] requires 467 NIST curve P-384, AES-256, and SHA2-384. The symmetric algorithm 468 restriction means that the algorithm of KEK used for key wrapping 469 in section 8 and a [RFC4880] session key used for message 470 encryption must be AES-256. The hash algorithm restriction means 471 that the hash algorithms of KDF and the [RFC4880] message digest 472 calculation must be SHA-384. 474 12.2.2. Security strength at 128 bits 476 The set of algorithms in section 12.2.1 is extended to allow NIST 477 curve P-256, AES-128, and SHA2-256. 479 13. Security Considerations 481 Refer to [FIPS 186-3] B.4.1 for the method to generate a uniformly 482 distributed ECC private key. 484 The curves proposed in this document correspond to the symmetric 485 key sizes 128 bits, 192 bits, and 256 bits, as described in the 486 table below. This allows a compliant application to offer balanced 487 public key security which is compatible with the symmetric key 488 strength for each AES algorithm allowed by [RFC4880]. 490 The following table defines the hash and the symmetric encryption 491 algorithm that SHOULD be used with a given curve for ECDSA or 492 ECDH. A stronger hash algorithm or a symmetric key algorithm MAY 493 be used for a given ECC curve. However, note that the increase in 494 the strength of the hash algorithm or the symmetric key algorithm 495 may not increase the overall security offered by the given ECC key. 497 Curve name ECC RSA Hash size Symmetric 498 strength strength, key size 499 informative 501 NIST curve P-256 256 3072 256 128 503 NIST curve P-384 384 7680 384 192 505 NIST curve P-521 521 15360 512 256 507 Requirement levels indicated elsewhere in this document lead to the 508 following combinations of algorithms in OpenPGP profile: MUST 509 implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD implement 510 NIST curve P-521 / SHA2-512 / AES-256, MAY implement NIST curve P- 511 384 / SHA2-384 / AES-256, among other allowed combinations. 513 Consistent with the table above, the following table defines the 514 KDF hash algorithm and the AES KEK encryption algorithm that SHOULD 515 be used with a given curve for ECDH. Stronger KDF hash algorithm 516 or AES KEK algorithm MAY be used for a given ECC curve. 518 Curve name Recommended KDF Recommended KEK 519 hash algorithm encryption algorithm 521 NIST curve P-256 SHA2-256 AES-128 523 NIST curve P-384 SHA2-384 AES-192 525 NIST curve P-521 SHA2-512 AES-256 527 This document explicitly discourages the use of algorithms other 528 than AES as a KEK algorithm because backward compatibility of the 529 ECDH format is not a concern. The KEK algorithm is only used 530 within the scope of a Public-Key Encrypted Session Key Packet, 531 which represents an ECDH key recipient of a message. Compare this 532 with the algorithm used for the session key of the message, which 533 MAY be different from a KEK algorithm. 535 Compliant applications SHOULD implement, advertise through key 536 preferences, and use in compliance with [RFC4880] the strongest 537 algorithms specified in this document. 539 Note that the [RFC4880] symmetric algorithm preference list may 540 make it impossible to use the balanced strength of symmetric key 541 algorithms for a corresponding public key. For example, the 542 presence of the symmetric key algorithm IDs and their order in the 543 key preference list affects the algorithm choices available to the 544 encoding side, which in turn may make the adherence to the table 545 above unfeasible. Therefore, compliance with this specification is 546 a concern throughout the life of the key, starting immediately 547 after the key generation when the key preferences are first added 548 to a key. It is generally advisable to position a symmetric 549 algorithm ID of strength matching the public key at the head of the 550 key preference list. 552 Encryption to multiple recipients often results in an unordered 553 intersection subset. For example, if the first recipient's set is 554 {A, B} and the second's is {B, A}, the intersection is an unordered 555 set of two algorithms A and B. In this case a compliant 556 application SHOULD choose the stronger encryption algorithm. 558 Resource constraints, such as limited computational power, is a 559 likely reason why an application might prefer to use the weakest 560 algorithm. On the other side of the spectrum are applications that 561 can implement every algorithm defined in this document. Most 562 applications are expected to fall into either of two categories. A 563 compliant application in the second, or strongest, category SHOULD 564 prefer AES-256 to AES-192. 566 SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH 567 method. 569 MDC MUST be used when symmetric encryption key is protected by 570 ECDH. None of the ECC methods described in this document are 571 allowed with deprecated V3 keys. A compliant application MUST only 572 use Iterated and Salted S2K to protect private keys, as defined in 573 section 3.7.1.3 Iterated and Salted S2K of [RFC4880]. 575 Side channel attacks are a concern when a compliant application's 576 use of OpenPGP format can be modeled by a decryption or signing 577 oracle model, for example, when an application is a network service 578 performing decryption to unauthenticated remote users. ECC scalar 579 multiplication operations used in ECDSA and ECDH are vulnerable to 580 side channel attacks. Countermeasures can often be taken at the 581 higher protocol level, such as limiting the number of allowed 582 failures or time-blinding of the operations associated with each 583 network interface. Mitigations at the scalar multiplication level 584 seek to eliminate any measurable distinction between ECC point 585 addition and doubling operations. 587 14. IANA Considerations 589 This document asks IANA to assign an algorithm number from the 590 OpenPGP Public-Key Algorithms range, or the "name space" in the 591 terminology of [RFC2434], that was created by [RFC4880]. Two ID 592 numbers are requested, as defined in section 5. The first one with 593 value 19 is already designated for ECDSA and is currently unused, 594 while another one is new (and suggested to be 18; there is an 595 implementation advantage in having consecutive ID values for the 596 two complementary algorithms). 598 15. References 600 15.1. Normative references 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", March 1997 605 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 606 Thayer, "OpenPGP Message Format", November 2007 608 [Suite B] NSA, US Government, NSA Suite B Cryptography, March 11, 609 2010, http://www.nsa.gov/ia/programs/suiteb_cryptography/ 611 [FIPS 186-3] US Dept. of Commerce / NIST, "Digital Signature 612 Standard (DSS)", June 2009 614 [NIST SP800-56A] Elaine Barker, Don Johnson, and Miles Smid, 615 "Recommendation for Pair-WiseKey Establishment Schemes Using 616 Discrete Logarithm Cryptography (Revised)", March 2007 618 [FIPS 180-3] NIST, "Secure Hash Standard (SHS)", October 2008 620 [RFC3394] J. Schaad, R. Housley, "Advanced Encryption Standard 621 (AES) Key Wrap Algorithm", September 2002 623 [PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based 624 Cryptography Standard", March 25, 1999 626 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing IANA 627 Considerations Section in RFCs", October 1998 629 15.2. Informative references 631 [KOBLITZ] N. Koblitz, "A course in number theory and cryptography", 632 Chapter VI. Elliptic Curves, ISBN: 0-387-96576-9, Springer-Verlag, 633 1987 635 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental 636 Elliptic Curve Cryptography Algorithms", February 2011, 638 [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 639 September 20, 2000 641 Contributors 643 Hal Finney provided important criticism on compliance with [NIST 644 SP800-56A] and [Suite B], and pointed out a few other mistakes. 646 Acknowledgment 648 The author would like to acknowledge the help of many individuals 649 who kindly voiced their opinions on IETF OpenPGP Working Group 650 mailing list and, in particular the help of Jon Callas, David 651 Crick, Ian G, Werner Koch, Marko Kreen. 653 Author's Address 655 Andrey Jivsov 656 Symantec Corporation 657 Email: Andrey_Jivsov@symantec.com