doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc6637.txt b/doc/rfc/rfc6637.txt
new file mode 100644
index 0000000..d253b02
--- /dev/null
+++ b/doc/rfc/rfc6637.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Jivsov
+Request for Comments: 6637                          Symantec Corporation
+Category: Standards Track                                      June 2012
+ISSN: 2070-1721
+
+
+              Elliptic Curve Cryptography (ECC) in OpenPGP
+
+Abstract
+
+   This document defines an Elliptic Curve Cryptography extension to the
+   OpenPGP public key format and specifies three Elliptic Curves that
+   enjoy broad support by other standards, including standards published
+   by the US National Institute of Standards and Technology.  The
+   document specifies the conventions for interoperability between
+   compliant OpenPGP implementations that make use of this extension and
+   these Elliptic Curves.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6637.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Jivsov                       Standards Track                    [Page 1]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Conventions used in This Document ...............................3
+   3. Elliptic Curve Cryptography .....................................3
+   4. Supported ECC Curves ............................................3
+   5. Supported Public Key Algorithms .................................4
+   6. Conversion Primitives ...........................................4
+   7. Key Derivation Function .........................................5
+   8. EC DH Algorithm (ECDH) ..........................................5
+   9. Encoding of Public and Private Keys .............................8
+   10. Message Encoding with Public Keys ..............................9
+   11. ECC Curve OID .................................................10
+   12. Compatibility Profiles ........................................10
+      12.1. OpenPGP ECC Profile ......................................10
+      12.2. Suite-B Profile ..........................................11
+           12.2.1. Security Strength at 192 Bits .....................11
+           12.2.2. Security Strength at 128 Bits .....................11
+   13. Security Considerations .......................................12
+   14. IANA Considerations ...........................................14
+   15. References ....................................................14
+      15.1. Normative References .....................................14
+      15.2. Informative References ...................................15
+   16. Contributors ..................................................15
+   17. Acknowledgment ................................................15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jivsov                       Standards Track                    [Page 2]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+1.  Introduction
+
+   The OpenPGP protocol [RFC4880] supports RSA and DSA (Digital
+   Signature Algorithm) public key formats.  This document defines the
+   extension to incorporate support for public keys that are based on
+   Elliptic Curve Cryptography (ECC).
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].  Any
+   implementation that adheres to the format and methods specified in
+   this document is called a compliant application.  Compliant
+   applications are a subset of the broader set of OpenPGP applications
+   described in [RFC4880].  Any [RFC2119] keyword within this document
+   applies to compliant applications only.
+
+3.  Elliptic Curve Cryptography
+
+   This document establishes the minimum set of Elliptic Curve
+   Cryptography (ECC) public key parameters and cryptographic methods
+   that will likely satisfy the widest range of platforms and
+   applications and facilitate interoperability.  It adds a more
+   efficient method for applications to balance the overall level of
+   security with any AES algorithm specified in [RFC4880] than by simply
+   increasing the size of RSA keys.  This document defines a path to
+   expand ECC support in the future.
+
+   The National Security Agency (NSA) of the United States specifies ECC
+   for use in its [SuiteB] set of algorithms.  This document includes
+   algorithms required by Suite B that are not present in [RFC4880].
+
+   [KOBLITZ] provides a thorough introduction to ECC.
+
+4.  Supported ECC Curves
+
+   This document references three named prime field curves, defined in
+   [FIPS-186-3] as "Curve P-256", "Curve P-384", and "Curve P-521".
+
+   The named curves are referenced as a sequence of bytes in this
+   document, called throughout, curve OID.  Section 11 describes in
+   detail how this sequence of bytes is formed.
+
+
+
+
+
+
+
+
+Jivsov                       Standards Track                    [Page 3]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+5.  Supported Public Key Algorithms
+
+   The supported public key algorithms are the Elliptic Curve Digital
+   Signature Algorithm (ECDSA) [FIPS-186-3] and the Elliptic Curve
+   Diffie-Hellman (ECDH).  A compatible specification of ECDSA is given
+   in [RFC6090] as "KT-I Signatures" and in [SEC1]; ECDH is defined in
+   Section 8 of this document.
+
+   The following public key algorithm IDs are added to expand Section
+   9.1 of [RFC4880], "Public-Key Algorithms":
+
+          ID        Description of Algorithm
+          --        --------------------------
+          18        ECDH public key algorithm
+          19        ECDSA public key algorithm
+
+   Compliant applications MUST support ECDSA and ECDH.
+
+6.  Conversion Primitives
+
+   This document only defines the uncompressed point format.  The point
+   is encoded in the Multiprecision Integer (MPI) format [RFC4880].  The
+   content of the MPI is the following:
+
+      B = 04 || x || y
+
+   where x and y are coordinates of the point P = (x, y), each encoded
+   in the big-endian format and zero-padded to the adjusted underlying
+   field size.  The adjusted underlying field size is the underlying
+   field size that is rounded up to the nearest 8-bit boundary.
+
+   Therefore, the exact size of the MPI payload is 515 bits for "Curve
+   P-256", 771 for "Curve P-384", and 1059 for "Curve P-521".
+
+   Even though the zero point, also called the point at infinity, may
+   occur as a result of arithmetic operations on points of an elliptic
+   curve, it SHALL NOT appear in data structures defined in this
+   document.
+
+   This encoding is compatible with the definition given in [SEC1].
+
+   If other conversion methods are defined in the future, a compliant
+   application MUST NOT use a new format when in doubt that any
+   recipient can support it.  Consider, for example, that while both the
+   public key and the per-recipient ECDH data structure, respectively
+   defined in Sections 9 and 10, contain an encoded point field, the
+   format changes to the field in Section 10 only affect a given
+   recipient of a given message.
+
+
+
+Jivsov                       Standards Track                    [Page 4]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+7.  Key Derivation Function
+
+   A key derivation function (KDF) is necessary to implement the EC
+   encryption.  The Concatenation Key Derivation Function (Approved
+   Alternative 1) [NIST-SP800-56A] with the KDF hash function that is
+   SHA2-256 [FIPS-180-3] or stronger is REQUIRED.  See Section 12 for
+   the details regarding the choice of the hash function.
+
+   For convenience, the synopsis of the encoding method is given below
+   with significant simplifications attributable to the restricted
+   choice of hash functions in this document.  However, [NIST-SP800-56A]
+   is the normative source of the definition.
+
+          //   Implements KDF( X, oBits, Param );
+          //   Input: point X = (x,y)
+          //   oBits - the desired size of output
+          //   hBits - the size of output of hash function Hash
+          //   Param - octets representing the parameters
+          //   Assumes that oBits <= hBits
+         // Convert the point X to the octet string, see section 6:
+         //   ZB' = 04 || x || y
+         // and extract the x portion from ZB'
+         ZB = x;
+         MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param );
+         return oBits leftmost bits of MB.
+
+   Note that ZB in the KDF description above is the compact
+   representation of X, defined in Section 4.2 of [RFC6090].
+
+8.  EC DH Algorithm (ECDH)
+
+   The method is a combination of an ECC Diffie-Hellman method to
+   establish a shared secret, a key derivation method to process the
+   shared secret into a derived key, and a key wrapping method that uses
+   the derived key to protect a session key used to encrypt a message.
+
+   The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [NIST-SP800-56A]
+   MUST be implemented with the following restrictions: the ECC CDH
+   primitive employed by this method is modified to always assume the
+   cofactor as 1, the KDF specified in Section 7 is used, and the KDF
+   parameters specified below are used.
+
+
+
+
+
+
+
+
+
+
+Jivsov                       Standards Track                    [Page 5]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+   The KDF parameters are encoded as a concatenation of the following 5
+   variable-length and fixed-length fields, compatible with the
+   definition of the OtherInfo bitstring [NIST-SP800-56A]:
+
+   o  a variable-length field containing a curve OID, formatted as
+      follows:
+
+         -  a one-octet size of the following field
+
+         - the octets representing a curve OID, defined in Section 11
+
+   o  a one-octet public key algorithm ID defined in Section 5
+
+   o  a variable-length field containing KDF parameters, identical to
+      the corresponding field in the ECDH public key, formatted as
+      follows:
+
+         -  a one-octet size of the following fields; values 0 and 0xff
+            are reserved for future extensions
+
+         -  a one-octet value 01, reserved for future extensions
+
+         -  a one-octet hash function ID used with the KDF
+
+         -  a one-octet algorithm ID for the symmetric algorithm used to
+            wrap the symmetric key for message encryption; see Section 8
+            for details
+
+   o  20 octets representing the UTF-8 encoding of the string
+      "Anonymous Sender    ", which is the octet sequence
+      41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20
+
+   o  20 octets representing a recipient encryption subkey or a master
+      key fingerprint, identifying the key material that is needed for
+      the decryption
+
+   The size of the KDF parameters sequence, defined above, is either 54
+   or 51 for the three curves defined in this document.
+
+   The key wrapping method is described in [RFC3394].  KDF produces a
+   symmetric key that is used as a key-encryption key (KEK) as specified
+   in [RFC3394].  Refer to Section 13 for the details regarding the
+   choice of the KEK algorithm, which SHOULD be one of three AES
+   algorithms.  Key wrapping and unwrapping is performed with the
+   default initial value of [RFC3394].
+
+
+
+
+
+
+Jivsov                       Standards Track                    [Page 6]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+   The input to the key wrapping method is the value "m" derived from
+   the session key, as described in Section 5.1 of [RFC4880], "Public-
+   Key Encrypted Session Key Packets (Tag 1)", except that the PKCS #1.5
+   (Public-Key Cryptography Standards version 1.5) padding step is
+   omitted.  The result is padded using the method described in [PKCS5]
+   to the 8-byte granularity.  For example, the following AES-256
+   session key, in which 32 octets are denoted from k0 to k31, is
+   composed to form the following 40 octet sequence:
+
+       09 k0 k1 ... k31 c0 c1 05 05 05 05 05
+
+   The octets c0 and c1 above denote the checksum.  This encoding allows
+   the sender to obfuscate the size of the symmetric encryption key used
+   to encrypt the data.  For example, assuming that an AES algorithm is
+   used for the session key, the sender MAY use 21, 13, and 5 bytes of
+   padding for AES-128, AES-192, and AES-256, respectively, to provide
+   the same number of octets, 40 total, as an input to the key wrapping
+   method.
+
+   The output of the method consists of two fields.  The first field is
+   the MPI containing the ephemeral key used to establish the shared
+   secret.  The second field is composed of the following two fields:
+
+   o  a one-octet encoding the size in octets of the result of the key
+      wrapping method; the value 255 is reserved for future extensions
+
+   o  up to 254 octets representing the result of the key wrapping
+      method, applied to the 8-byte padded session key, as described
+      above
+
+   Note that for session key sizes 128, 192, and 256 bits, the size of
+   the result of the key wrapping method is, respectively, 32, 40, and
+   48 octets, unless the size obfuscation is used.
+
+   For convenience, the synopsis of the encoding method is given below;
+   however, this section, [NIST-SP800-56A], and [RFC3394] are the
+   normative sources of the definition.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jivsov                       Standards Track                    [Page 7]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+         Obtain the authenticated recipient public key R
+         Generate an ephemeral key pair {v, V=vG}
+         Compute the shared point S = vR;
+         m = symm_alg_ID || session key || checksum || pkcs5_padding;
+         curve_OID_len = (byte)len(curve_OID);
+         Param = curve_OID_len || curve_OID || public_key_alg_ID || 03
+         || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous
+         Sender    " || recipient_fingerprint;
+         Z_len = the key size for the KEK_alg_ID used with AESKeyWrap
+         Compute Z = KDF( S, Z_len, Param );
+         Compute C = AESKeyWrap( Z, m ) as per [RFC3394]
+         VB = convert point V to the octet string
+         Output (MPI(VB) || len(C) || C).
+
+   The decryption is the inverse of the method given.  Note that the
+   recipient obtains the shared secret by calculating
+
+       S = rV = rvG, where (r,R) is the recipient's key pair.
+
+   Consistent with Section 5.13 of [RFC4880], "Sym. Encrypted Integrity
+   Protected Data Packet (Tag 18)", a Modification Detection Code (MDC)
+   MUST be used anytime the symmetric key is protected by ECDH.
+
+9. Encoding of Public and Private Keys
+
+   The following algorithm-specific packets are added to Section 5.5.2
+   of [RFC4880], "Public-Key Packet Formats", to support ECDH and ECDSA.
+
+   This algorithm-specific portion is:
+
+   Algorithm-Specific Fields for ECDSA keys:
+
+      o  a variable-length field containing a curve OID, formatted
+         as follows:
+
+         -  a one-octet size of the following field; values 0 and
+            0xFF are reserved for future extensions
+
+         -  octets representing a curve OID, defined in Section 11
+
+      o  MPI of an EC point representing a public key
+
+
+
+
+
+
+
+
+
+
+Jivsov                       Standards Track                    [Page 8]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+     Algorithm-Specific Fields for ECDH keys:
+
+      o  a variable-length field containing a curve OID, formatted
+         as follows:
+
+         -  a one-octet size of the following field; values 0 and
+            0xFF are reserved for future extensions
+
+         -  the octets representing a curve OID, defined in
+            Section 11
+
+         -  MPI of an EC point representing a public key
+
+      o  a variable-length field containing KDF parameters,
+         formatted as follows:
+
+         -  a one-octet size of the following fields; values 0 and
+            0xff are reserved for future extensions
+
+         -  a one-octet value 01, reserved for future extensions
+
+         -  a one-octet hash function ID used with a KDF
+
+         -  a one-octet algorithm ID for the symmetric algorithm
+            used to wrap the symmetric key used for the message
+            encryption; see Section 8 for details
+
+   Observe that an ECDH public key is composed of the same sequence of
+   fields that define an ECDSA key, plus the KDF parameters field.
+
+   The following algorithm-specific packets are added to Section 5.5.3.
+   of [RFC4880], "Secret-Key Packet Formats", to support ECDH and ECDSA.
+
+     Algorithm-Specific Fields for ECDH or ECDSA secret keys:
+
+      o  an MPI of an integer representing the secret key, which is a
+         scalar of the public EC point
+
+10.  Message Encoding with Public Keys
+
+   Section 5.2.2 of [RFC4880], "Version 3 Signature Packet Format"
+   defines signature formats.  No changes in the format are needed for
+   ECDSA.
+
+   Section 5.1 of [RFC4880], "Public-Key Encrypted Session Key Packets
+   (Tag 1)" is extended to support ECDH.  The following two fields are
+   the result of applying the KDF, as described in Section 8.
+
+
+
+
+Jivsov                       Standards Track                    [Page 9]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+   Algorithm-Specific Fields for ECDH:
+
+      o an MPI of an EC point representing an ephemeral public key
+
+      o a one-octet size, followed by a symmetric key encoded using the
+         method described in Section 8
+
+11.  ECC Curve OID
+
+   The parameter curve OID is an array of octets that define a named
+   curve.  The table below specifies the exact sequence of bytes for
+   each named curve referenced in this document:
+
+   ASN.1 Object          OID Curve OID bytes in         Curve name in
+   Identifier            len hexadecimal                [FIPS-186-3]
+                             representation
+
+   1.2.840.10045.3.1.7    8   2A 86 48 CE 3D 03 01 07   NIST curve P-256
+
+   1.3.132.0.34           5   2B 81 04 00 22            NIST curve P-384
+
+   1.3.132.0.35           5   2B 81 04 00 23            NIST curve P-521
+
+   The sequence of octets in the third column is the result of applying
+   the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier
+   with subsequent truncation.  The truncation removes the two fields of
+   encoded Object Identifier.  The first omitted field is one octet
+   representing the Object Identifier tag, and the second omitted field
+   is the length of the Object Identifier body.  For example, the
+   complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A
+   86 48 CE 3D 03 01 07", from which the first entry in the table above
+   is constructed by omitting the first two octets.  Only the truncated
+   sequence of octets is the valid representation of a curve OID.
+
+12.  Compatibility Profiles
+
+12.1.  OpenPGP ECC Profile
+
+   A compliant application MUST implement NIST curve P-256, MAY
+   implement NIST curve P-384, and SHOULD implement NIST curve P-521, as
+   defined in Section 11.  A compliant application MUST implement
+   SHA2-256 and SHOULD implement SHA2-384 and SHA2-512.  A compliant
+   application MUST implement AES-128 and SHOULD implement AES-256.
+
+
+
+
+
+
+
+
+Jivsov                       Standards Track                   [Page 10]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+   A compliant application SHOULD follow Section 13 regarding the choice
+   of the following algorithms for each curve:
+
+   o  the KDF hash algorithm
+
+   o  the KEK algorithm
+
+   o  the message digest algorithm and the hash algorithm used in the
+      key certifications
+
+   o  the symmetric algorithm used for message encryption.
+
+   It is recommended that the chosen symmetric algorithm for message
+   encryption be no less secure than the KEK algorithm.
+
+12.2.  Suite-B Profile
+
+   A subset of algorithms allowed by this document can be used to
+   achieve [SuiteB] compatibility.  The references to [SuiteB] in this
+   document are informative.  This document is primarily concerned with
+   format specification, leaving additional security restrictions
+   unspecified, such as matching the assigned security level of
+   information to authorized recipients or interoperability concerns
+   arising from fewer allowed algorithms in [SuiteB] than allowed by
+   [RFC4880].
+
+12.2.1.  Security Strength at 192 Bits
+
+   To achieve the security strength of 192 bits, [SuiteB] requires NIST
+   curve P-384, AES-256, and SHA2-384.  The symmetric algorithm
+   restriction means that the algorithm of KEK used for key wrapping in
+   Section 8 and an [RFC4880] session key used for message encryption
+   must be AES-256.  The hash algorithm restriction means that the hash
+   algorithms of KDF and the [RFC4880] message digest calculation must
+   be SHA-384.
+
+12.2.2.  Security Strength at 128 Bits
+
+   The set of algorithms in Section 12.2.1 is extended to allow NIST
+   curve P-256, AES-128, and SHA2-256.
+
+
+
+
+
+
+
+
+
+
+
+Jivsov                       Standards Track                   [Page 11]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+13.  Security Considerations
+
+   Refer to [FIPS-186-3], B.4.1, for the method to generate a uniformly
+   distributed ECC private key.
+
+   The curves proposed in this document correspond to the symmetric key
+   sizes 128 bits, 192 bits, and 256 bits, as described in the table
+   below.  This allows a compliant application to offer balanced public
+   key security, which is compatible with the symmetric key strength for
+   each AES algorithm allowed by [RFC4880].
+
+   The following table defines the hash and the symmetric encryption
+   algorithm that SHOULD be used with a given curve for ECDSA or ECDH.
+   A stronger hash algorithm or a symmetric key algorithm MAY be used
+   for a given ECC curve.  However, note that the increase in the
+   strength of the hash algorithm or the symmetric key algorithm may not
+   increase the overall security offered by the given ECC key.
+
+   Curve name         ECC        RSA         Hash size   Symmetric
+                      strength   strength,               key size
+                                 informative
+
+   NIST curve P-256   256        3072        256         128
+
+   NIST curve P-384   384        7680        384         192
+
+   NIST curve P-521   521        15360       512         256
+
+   Requirement levels indicated elsewhere in this document lead to the
+   following combinations of algorithms in the OpenPGP profile: MUST
+   implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD implement
+   NIST curve P-521 / SHA2-512 / AES-256, MAY implement NIST curve P-384
+   / SHA2-384 / AES-256, among other allowed combinations.
+
+   Consistent with the table above, the following table defines the KDF
+   hash algorithm and the AES KEK encryption algorithm that SHOULD be
+   used with a given curve for ECDH.  A stronger KDF hash algorithm or
+   AES KEK algorithm MAY be used for a given ECC curve.
+
+   Curve name          Recommended KDF      Recommended KEK
+                       hash algorithm       encryption algorithm
+
+   NIST curve P-256    SHA2-256             AES-128
+
+   NIST curve P-384    SHA2-384             AES-192
+
+   NIST curve P-521    SHA2-512             AES-256
+
+
+
+
+Jivsov                       Standards Track                   [Page 12]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+   This document explicitly discourages the use of algorithms other than
+   AES as a KEK algorithm because backward compatibility of the ECDH
+   format is not a concern.  The KEK algorithm is only used within the
+   scope of a Public-Key Encrypted Session Key Packet, which represents
+   an ECDH key recipient of a message.  Compare this with the algorithm
+   used for the session key of the message, which MAY be different from
+   a KEK algorithm.
+
+   Compliant applications SHOULD implement, advertise through key
+   preferences, and use in compliance with [RFC4880], the strongest
+   algorithms specified in this document.
+
+   Note that the [RFC4880] symmetric algorithm preference list may make
+   it impossible to use the balanced strength of symmetric key
+   algorithms for a corresponding public key.  For example, the presence
+   of the symmetric key algorithm IDs and their order in the key
+   preference list affects the algorithm choices available to the
+   encoding side, which in turn may make the adherence to the table
+   above infeasible.  Therefore, compliance with this specification is a
+   concern throughout the life of the key, starting immediately after
+   the key generation when the key preferences are first added to a key.
+   It is generally advisable to position a symmetric algorithm ID of
+   strength matching the public key at the head of the key preference
+   list.
+
+   Encryption to multiple recipients often results in an unordered
+   intersection subset.  For example, if the first recipient's set is
+   {A, B} and the second's is {B, A}, the intersection is an unordered
+   set of two algorithms, A and B.  In this case, a compliant
+   application SHOULD choose the stronger encryption algorithm.
+
+   Resource constraints, such as limited computational power, is a
+   likely reason why an application might prefer to use the weakest
+   algorithm.  On the other side of the spectrum are applications that
+   can implement every algorithm defined in this document.  Most
+   applications are expected to fall into either of two categories.  A
+   compliant application in the second, or strongest, category SHOULD
+   prefer AES-256 to AES-192.
+
+   SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method.
+
+   MDC MUST be used when a symmetric encryption key is protected by
+   ECDH.  None of the ECC methods described in this document are allowed
+   with deprecated V3 keys.  A compliant application MUST only use
+   iterated and salted S2K to protect private keys, as defined in
+   Section 3.7.1.3 of [RFC4880], "Iterated and Salted S2K".
+
+
+
+
+
+Jivsov                       Standards Track                   [Page 13]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+   Side channel attacks are a concern when a compliant application's use
+   of the OpenPGP format can be modeled by a decryption or signing
+   oracle model, for example, when an application is a network service
+   performing decryption to unauthenticated remote users.  ECC scalar
+   multiplication operations used in ECDSA and ECDH are vulnerable to
+   side channel attacks.  Countermeasures can often be taken at the
+   higher protocol level, such as limiting the number of allowed
+   failures or time-blinding of the operations associated with each
+   network interface.  Mitigations at the scalar multiplication level
+   seek to eliminate any measurable distinction between the ECC point
+   addition and doubling operations.
+
+14.  IANA Considerations
+
+   Per this document, IANA has assigned an algorithm number from the
+   "Public Key Algorithms" range (or the "name space" in the terminology
+   of [RFC5226]) of the "Pretty Good Privacy (PGP)" registry, created by
+   [RFC4880].  Two ID numbers have been assigned, as defined in Section
+   5.  The first one, value 19, is already designated for ECDSA and is
+   currently unused, while the other one, value 18, is new.
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
+                    Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4880]        Callas, J., Donnerhacke, L., Finney, H., Shaw, D.,
+                    and R. Thayer, "OpenPGP Message Format", RFC 4880,
+                    November 2007.
+
+   [SuiteB]         National Security Agency, "NSA Suite B
+                    Cryptography", March 11, 2010,
+                    http://www.nsa.gov/ia/programs/suiteb_cryptography/.
+
+   [FIPS-186-3]     National Institute of Standards and Technology, U.S.
+                    Department of Commerce, "Digital Signature
+                    Standard", FIPS 186-3, June 2009.
+
+   [NIST-SP800-56A] Barker, E., Johnson, D., and M. Smid,
+                    "Recommendation for Pair-Wise Key Establishment
+                    Schemes Using Discrete Logarithm Cryptography", NIST
+                    Special Publication 800-56A Revision 1, March 2007.
+
+   [FIPS-180-3]     National Institute of Standards and Technology, U.S.
+                    Department of Commerce, "Secure Hash Standard
+                    (SHS)", FIPS 180-3, October 2008.
+
+
+
+Jivsov                       Standards Track                   [Page 14]
+
+RFC 6637                     ECC in OpenPGP                    June 2012
+
+
+   [RFC3394]        Schaad, J. and R. Housley, "Advanced Encryption
+                    Standard (AES) Key Wrap Algorithm", RFC 3394,
+                    September 2002.
+
+   [PKCS5]          RSA Laboratories, "PKCS #5 v2.0: Password-Based
+                    Cryptography Standard", March 25, 1999.
+
+   [RFC5226]        Narten, T. and H. Alvestrand, "Guidelines for
+                    Writing an IANA Considerations Section in RFCs", BCP
+                    26, RFC 5226, May 2008.
+
+15.2.  Informative References
+
+   [KOBLITZ]        N. Koblitz, "A course in number theory and
+                    cryptography", Chapter VI. Elliptic Curves, ISBN:
+                    0-387-96576-9, Springer-Verlag, 1987
+
+   [RFC6090]        McGrew, D., Igoe, K., and M. Salter, "Fundamental
+                    Elliptic Curve Cryptography Algorithms", RFC 6090,
+                    February 2011.
+
+   [SEC1]           Standards for Efficient Cryptography Group, "SEC 1:
+                    Elliptic Curve Cryptography", September 2000.
+
+16.  Contributors
+
+   Hal Finney provided important criticism on compliance with
+   [NIST-SP800-56A] and [SuiteB], and pointed out a few other mistakes.
+
+17.  Acknowledgment
+
+   The author would like to acknowledge the help of many individuals who
+   kindly voiced their opinions on the IETF OpenPGP Working Group
+   mailing list, in particular, the help of Jon Callas, David Crick, Ian
+   G, Werner Koch, and Marko Kreen.
+
+Author's Address
+
+   Andrey Jivsov
+   Symantec Corporation
+   EMail: Andrey_Jivsov@symantec.com
+
+
+
+
+
+
+
+
+
+
+Jivsov                       Standards Track                   [Page 15]
+