--- draft-jivsov-openpgp-ecc-10.txt	2012-03-07 12:38:40.914837576 -0800
+++ draft-jivsov-openpgp-ecc-11.txt	2012-03-21 11:55:40.426030094 -0700
@@ -4,28 +4,27 @@
 
 
 
 Network Working Group                                        A. Jivsov
 Internet Draft                                    Symantec Corporation
-Intended status: Standards                               March 7, 2012
-Expires: September 3, 2012
+Intended status: Standards                              March 21, 2012
+Expires: September 17, 2012
 
 
 
 
                                ECC in OpenPGP
-                      draft-jivsov-openpgp-ecc-10.txt
+                      draft-jivsov-openpgp-ecc-11.txt
 
 Abstract
 
-   This document proposes an Elliptic Curve Cryptography extension to
+   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 NIST
    standards.  The document aims to standardize an optimal but narrow
-   set of parameters for best interoperability and it does so within
-   the framework it defines that can be expanded in the future to
-   allow more choices.
+   set of parameters for easier interoperability between compliant
+   OpenPGP implementations.
 
 Status of this Memo
 
    This Internet-Draft is submitted to IETF in full conformance with
    the provisions of BCP 78 and BCP 79.
@@ -45,16 +44,17 @@
    http://www.ietf.org/ietf/1id-abstracts.txt.
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on September 3, 2012.
+   This Internet-Draft will expire on September 17, 2012.
 
 Copyright Notice
 
 
-A. Jivsov             Expires September 3, 2012               [Page 1]
+
+A. Jivsov             Expires September 17, 2012               [Page 1]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
    Copyright (c) 2011 IETF Trust and the persons identified as the
@@ -94,79 +94,79 @@
       15.1. Normative references..................................13
       15.2. Informative references................................14
 
 1. Introduction
 
-   The OpenPGP protocol supports RSA and DSA public key formats.  This
-   document defines the extension to incorporate support for public
-   keys that are based on Elliptic Curve Cryptography (ECC).
+   The OpenPGP protocol [RFC4880], supports RSA and DSA 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].
 
 
-
-A. Jivsov             Expires September 3, 2012               [Page 2]
+A. Jivsov             Expires September 17, 2012               [Page 2]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
-   An application MAY implement this draft; note that any [RFC2119]
-   keyword within this draft applies to an OpenPGP application only if
-   it chooses to implement this draft.
+   Any implementation MAY follow the format and methods specified in
+   this document, in which case such an implementation is called a
+   compliant application. Note that any [RFC2119] keyword within this
+   document applies to an OpenPGP application only if it chooses to be
+   a compliant application.
 
 3. Elliptic Curve Cryptography
 
-   This specification establishes the minimum set of Elliptic Curve
+   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.
+
    National Security Agency (NSA) of the United States specifies ECC
-   for use in its [Suite B] set of algorithms.  This specification
-   includes algorithms required by Suite B that are not present in
-   [RFC4880].
+   for use in its [Suite B] 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 standard references three named prime field curves, which are
-   defined in [FIPS 186-3] as "Curve P-256", "Curve P-384", and "Curve
-   P-521".
+   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
-   specification, called throughout this document as Curve OID.
-   Section 11 describes in details how this sequence of bytes is
-   formed.
+   document, called throughout this document as Curve OID. Section 11
+   describes in details how this sequence of bytes is formed.
 
 5. Supported public key algorithms
 
    Supported public key algorithms are Elliptic Curve Digital
-   Signature Algorithm (ECDSA), defined in [FIPS 186-3], and Elliptic
-   Curve Diffie-Hellman (ECDH), defined in section 8.  A compatible
-   specification of ECDSA is given in [RFC6090] as "KT-I Signatures"
-   and in [SEC1].
+   Signature Algorithm (ECDSA) [FIPS 186-3] and Elliptic Curve Diffie-
+   Hellman (ECDH), defined in section 8.  A compatible specification
+   of ECDSA is given in [RFC6090] as "KT-I Signatures" and in [SEC1].
+
+   The following public key algorithm IDs are added to expand the
+   section 9.1. Public-Key Algorithms of [RFC4880]:
+
 
-   The section 9.1. Public-Key Algorithms of [RFC4880] is expanded to
-   define the following public key algorithm IDs:
 
 
 
 
 
 
 
 
-A. Jivsov             Expires September 3, 2012               [Page 3]
+A. Jivsov             Expires September 17, 2012               [Page 3]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
           ID        Description of algorithm
@@ -177,17 +177,17 @@
 
           19        ECDSA public key algorithm
 
 
 
-   Applications MUST support ECDSA and ECDH.
+   Compliant applications MUST support ECDSA and ECDH.
 
 6. Conversion primitives
 
-   This specification only defines uncompressed point format.  The
-   point is encoded in MPI format.  The content of the MPI is the
-   following:
+   This document only defines uncompressed point format.  The point is
+   encoded in the Multiprecision Integer (MPI) format [RFC4880].  The
+   content of the MPI is the following:
 
       B = B0 || x || y
 
    where x and y are coordinates of the point P = (x, y), each encoded
    in big endian format and zero-padded to the adjusted underlying
@@ -202,34 +202,34 @@
 
       4   Uncompressed point.  x and y of EC point values follow.
 
    Note that the point O shall not appear in a public or a private
    key.  Therefore, the exact size of the MPI payload is 515 bits for
-   "Curve P-256", 771 for "Curve P-256", and 1059 for "Curve P-521".
+   "Curve P-256", 771 for "Curve P-384", and 1059 for "Curve P-521".
 
    This encoding is compatible with the definition given in [SEC1].
 
    If other conversion methods are defined in the future, the
-   application MAY use them only when it is certain that every
-   recipient can support another format.
+   compliant application MAY use them only when it is certain that
+   every recipient can support another format.
 
 7. Key Derivation Function
 
    A key derivation function (KDF) is necessary to implement EC
    encryption.  The Concatenation Key Derivation Function (Approved
 
 
 
 
-A. Jivsov             Expires September 3, 2012               [Page 4]
+A. Jivsov             Expires September 17, 2012               [Page 4]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
-   Alternative 1) defined in [NIST SP800-56A] is REQUIRED with the
-   following restriction: the KDF hash function MAY be based on any of
-   the following hash functions specified by [FIPS 180-3]: SHA2-256,
+   Alternative 1) [NIST SP800-56A] is REQUIRED with the following
+   restriction: the KDF hash function MAY be based on any of the
+   following hash functions specified by [FIPS 180-3]: SHA2-256,
    SHA2-384, SHA2-512.  See section 13 for the details regarding the
    choice of the hash function.
 
    For convenience, the synopsis of the encoding method is given below
    with significant simplifications applicable to the choice of hash
@@ -257,15 +257,15 @@
    establish a shared secret, 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.
 
-   One-Pass Diffie-Hellman method C(1, 1, ECC CDH), defined in [NIST
-   SP800-56A], MUST be implemented with the following restrictions:
-   ECC CDH primitive employed by this method is modified to always
-   assume the cofactor as 1, KDF specified in section 7 is used, and
-   KDF parameters specified below are used.
+   One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [NIST SP800-56A]
+   MUST be implemented with the following restrictions: ECC CDH
+   primitive employed by this method is modified to always assume the
+   cofactor as 1, KDF specified in section 7 is used, and KDF
+   parameters specified below are used.
 
    Key derivation function parameters MUST be encoded as concatenation
    of the following 5 variable-length and fixed-length fields:
 
    o   a variable-length field containing curve OID, formatted as
@@ -274,11 +274,11 @@
          o    a one-octet size of the following field
 
 
 
 
-A. Jivsov             Expires September 3, 2012               [Page 5]
+A. Jivsov             Expires September 17, 2012               [Page 5]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
          o   octets representing curve OID, defined in section 11
@@ -304,11 +304,11 @@
 
   o    20 octets representing recipient encryption subkey or master key
        fingerprint, identifying the key material that is needed for
        decryption
 
-  For three curves defined in this specification the size of the key
+   For three curves defined in this document the size of the key
   derivation parameters sequence, defined above, is either 54 or 51.
 
   The key wrapping method is based on [RFC3394].  KDF produces a
   symmetric key that is used as KEK as specified in [RFC3394].  Refer
   to section 13 for the details regarding the choice of the KEK
@@ -330,11 +330,11 @@
   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,
 
 
 
-A. Jivsov             Expires September 3, 2012               [Page 6]
+A. Jivsov             Expires September 17, 2012               [Page 6]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
   respectfully, to provide the same number of octets, 40 total, as an
@@ -377,20 +377,20 @@
   recipient obtains the shared secret by calculating
 
       S = rV = rvG, where (r,R) is the recipient's key pair.
 
   Consistent with section 5.13 Sym. Encrypted Integrity Protected
-  Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime
+   Data Packet (Tag 18) of [RFC4880], the MDC MUST be used anytime
   symmetric key is protected by ECDH.
 
 
 
 
 
 
 
-A. Jivsov             Expires September 3, 2012               [Page 7]
+A. Jivsov             Expires September 17, 2012               [Page 7]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
 9. Encoding of public and private keys
@@ -442,11 +442,11 @@
 
 
 
 
 
-A. Jivsov             Expires September 3, 2012               [Page 8]
+A. Jivsov             Expires September 17, 2012               [Page 8]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
    The following algorithm-specific packets are added to section
@@ -475,11 +475,11 @@
 
 11. ECC curve OID
 
    The parameter curve OID is an array of octets that define the named
    curve.  The table bellow specifies the exact sequence of bytes for
-   each named curve referenced in this specification:
+   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
 
@@ -498,11 +498,11 @@
    one octet representing the Object Identifier tag and the second
    omitted field is the length of the Object Identifier body.  For
 
 
 
-A. Jivsov             Expires September 3, 2012               [Page 9]
+A. Jivsov             Expires September 17, 2012               [Page 9]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
    example, the complete ASN.1 DER encoding for the NIST P-256 curve
@@ -511,18 +511,18 @@
 
 12. Compatibility profiles
 
 12.1. OpenPGP ECC profile
 
-   Application MUST implement NIST curve P-256, MAY implement NIST
-   curve P-384, and SHOULD implement NIST curve P-521, defined in
-   section 11.  Application MUST implement SHA2-256 and SHOULD
-   implement SHA2-512.  Application MUST implement AES-128 and SHOULD
-   implement AES-256.
+   A compliant application MUST implement NIST curve P-256, MAY
+   implement NIST curve P-384, and SHOULD implement NIST curve P-521,
+   defined in section 11.  A compliant application MUST implement
+   SHA2-256 and SHOULD implement SHA2-512.  A compliant application
+   MUST implement AES-128 and SHOULD implement AES-256.
 
-   Application SHOULD follow section 13 regarding the choice of the
-   following algorithms for each curve:
+   A compliant application SHOULD follow section 13 regarding the
+   choice of the following algorithms for each curve:
 
    o   the KDF hash algorithm
 
    o   KEK algorithm
 
@@ -534,11 +534,11 @@
    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 specification can be used to
+   A subset of algorithms allowed by this document can be used to
    achieve [Suite B] compatibility.  The references to [Suite B] in
    this document are informative.  This document is primarily
    concerned with format specification, leaving additional security
    restrictions unspecified, such as matching assigned security level
    of information to authorized recipients or interoperability
@@ -554,11 +554,11 @@
    encryption must be AES-256.  Hash algorithm restriction means that
    the hash algorithms of KDF and [RFC4880] message digest calculation
    must be SHA-384.
 
 
-A. Jivsov             Expires September 3, 2012              [Page 10]
+A. Jivsov             Expires September 17, 2012              [Page 10]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
 12.2.2. Security strength at 128 bits
@@ -571,11 +571,11 @@
    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 OpenPGP application to offer balanced
+   table below.  This allows a compliant application to offer balanced
    public key security which is compatible with symmetric key strength
    for each AES algorithms allowed by [RFC4880].
    The following table defines the hash and symmetric encryption
    algorithm that SHOULD be used with specific curve for ECDSA or
    ECDH.  Stronger hash algorithm or symmetric key algorithm MAY be
@@ -610,11 +610,11 @@
 
 
 
 
 
-A. Jivsov             Expires September 3, 2012              [Page 11]
+A. Jivsov             Expires September 17, 2012              [Page 11]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
    Curve name          Recommended KDF      Recommended KEK
@@ -626,70 +626,74 @@
 
    NIST curve P-521    SHA2-512             AES-256
 
 
 
-  This specification explicitly discourages the use of algorithms
-  other than AES as a KEK algorithm because backward compatibility of
-  the ECDH format is not a concern.  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 as the session key of the message, which
-  MAY be different from a KEK algorithm.
-
-  Applications SHOULD implement, advertise through key preferences,
-  and use in compliance with [RFC4880] strongest algorithms specified
-  in this document.
+   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.  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 as 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] strongest
+   algorithms specified in this document.
 
   Note that [RFC4880] symmetric algorithm preference list may
   restrict the use of balanced strength of symmetric key algorithms
-  for corresponding public key.  For example, the presence of
-  symmetric key algorithms and their order in key preference list
-  affects the choices available to encoding side for compliance with
-  the table above.  Therefore, applications need to be concerned with
-  this compliance throughout the life of the key, starting
-  immediately after key generation when the key preferences are first
-  added to a key.  It is generally advisable to have a symmetric
-  algorithm of strength matching the public key at the head of the
-  key preference list.
+   for the corresponding public key.  For example, the presence of
+   symmetric key algorithms and their order in the key preference list
+   affects the algorithm choices available to the encoding side, which
+   in turn may make unfeasible the adherence to the table
+   above.  Therefore, compliance with this specification is a concern
+   throughout the life of the key, starting immediately after key
+   generation when the key preferences are first added to a key.  It
+   is generally advisable to have a symmetric algorithm of strength
+   matching the public key at the head of the key preference list.
 
   Often encryption to multiple recipients results in an unordered
   intersection subset.  For example, given two recipients, if the
   first recipient's set is {A, B} and the second's is {B, A}, the
   intersection is unordered set of two algorithms A and B.  In this
-  case application SHOULD choose stronger encryption algorithm.
+   case a compliant application SHOULD choose stronger encryption
+   algorithm.
 
   Resource constraint, such as limited computational power, is the
   likely reason why an application might prefer to use weakest
   algorithms.  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.  An application in the second or strongest category
-  SHOULD prefer AES-256 to AES-192.
+   applications are expected to fall into either of two categories.  A
 
 
 
-A. Jivsov             Expires September 3, 2012              [Page 12]
+
+A. Jivsov             Expires September 17, 2012              [Page 12]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
-   While some statements in this specification refer to TripleDES
+   compliant application in the second or strongest category SHOULD
+   prefer AES-256 to AES-192.
+
+   While some statements in this document refer to TripleDES
    algorithm, this is only done to help interoperability with existing
-   application and already generated keys; AES-256 is the recommended
-   alternative to TripleDES in all circumstances when AES-256 is
-   available.
+   OpenPGP applications and already generated keys; AES-256 is the
+   recommended alternative to TripleDES in all circumstances when AES-
+   256 is available.
 
    SHA-1 MUST NOT be used for ECDSA or with KDF in ECDH method.
 
    MDC MUST be used when symmetric encryption key is protected by
    ECDH.  None of the ECC methods described in this document are
-   allowed with deprecated V3 keys.  The application MUST only use
-   Iterated and Salted S2K to protect private keys, as defined in
+   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 Iterated and Salted S2K of [RFC4880].
 
 14. IANA Considerations
+
    This document asks IANA to assign an algorithm number from OpenPGP
    Public-Key Algorithms range, or "name space" in the terminology of
    [RFC2434], that was created by [RFC4880].  Two ID numbers are
    requested, as defined in section 5.  The first one with value 19 is
    already designated for ECDSA and currently unused, while another
@@ -717,20 +721,19 @@
    "Recommendation for Pair-WiseKey Establishment Schemes Using
    Discrete Logarithm Cryptography (Revised)", March 2007
 
    [FIPS 180-3] NIST, "Secure Hash Standard (SHS)", October 2008
 
-   [RFC3394] J. Schaad, R. Housley, "Advanced Encryption Standard
-   (AES) Key Wrap Algorithm", September 2002
 
-
-
-A. Jivsov             Expires September 3, 2012              [Page 13]
+A. Jivsov             Expires September 17, 2012              [Page 13]
 
 Internet-Draft              ECC in OpenPGP                   March 2012
 
 
+   [RFC3394] J. Schaad, R. Housley, "Advanced Encryption Standard
+   (AES) Key Wrap Algorithm", September 2002
+
    [PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based
    Cryptography Standard", March 25, 1999
 
    [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing IANA
    Considerations Section in RFCs", October 1998
@@ -738,13 +741,13 @@
 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", February 2011,
+
    [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
    September 20, 2000
 
 Contributors
 
@@ -754,11 +757,11 @@
 Acknowledgment
 
    The author would like to acknowledge the help of many individuals
    who kindly voiced their opinions on IETF OpenPGP Working Group
    mailing list and, in particular the help of Jon Callas, David
-   Crick, Ian G, Werner Koch, Marco Kreen.
+   Crick, Ian G, Werner Koch, Marko Kreen.
 
 Author's Address
 
    Andrey Jivsov
    Symantec Corporation
@@ -775,10 +778,7 @@
 
 
 
 
 
-
-
-
-A. Jivsov             Expires September 3, 2012              [Page 14]
+A. Jivsov             Expires September 17, 2012              [Page 14]
 
