Subject: [Gen-art] Gen-ART LC Review of draft-jivsov-openpgp-ecc-10

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Mar 2012 13:07:15 +0100

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document:                                         draft-jivsov-openpgp-ecc-10

Reviewer:                                           Christer Holmberg

Review Date:                                     2012-03-19

IETF LC End Date:                             2012-04-09

IESG Telechat date: (if known)   2012-04-09

Summary:           The draft is ready for publication, with a couple of editorial nits.

Major issues:     -

Minor issues:     -

Nits/editorial comments:

Q1:         The "MPI" abbreviation is used throughout the document, but it is not expanded anywhere, nor is there any reference.

Q2:         The Abstract says:

                "The document aims to standardize an optimal but narrow set of parameters for best interoperability"

I think it would to make it more clear what interoperability you refer to.

Q3:         The Abstract says:

                "within the framework it defines"

                However, the framework is not mentioned/clarified/defined anywhere in the document, so if you want to talk about a framework I think some clarification is needed.

Q4:         In the Introduction, please add references to OpenPGP, RSA and DSA. Also consider expansion on first occurrence.

Q5:         The document uses "This document", "This specification", "This draft" and "This standard" terminology. Please use consistent terminology.

Q6:         In section 5, I don't think you need the "defined in" parts. Simply add the reference.

                Example:             "Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS 186-3],..."

                Maybe similar changes can be done in some other parts of the document also.

Q7:         In section 5, consider modifying the following sentence:

                "The section 9.1. Public-Key Algorithms of [RFC4880] is expanded to define the following public key algorithm IDs"

                To:

                "This section extends section 9.1 (Public-Key Algorithms) or [RFC4880], by defining the following public key algorithm IDs"

Q8:         Section 5 says:

                "Applications MUST support ECDSA and ECDH."

                Please clarify what applications you refer to. I assume you mean "Applications that implement this specification", or something similar...

                The same comment also applies to section 12.1, and section 13 (the word is used many times in section 13, but it is enough to clarify it on first occurrence :)

Regards,

Christer

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 20 Mar 2012 14:52:17 -0700

Hello Christer, thank you for the feedback.

I attempted to integrate your every comment into the 
draft-jivsov-openpgp-ecc-11 revision that I attached to this e-mail (I 
didn't post it via IETF tools.) I am also attaching the diff with -10.

The summary of my changes are inlined bellow:

On 03/19/2012 05:07 AM, Christer Holmberg wrote:
>
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Q1:         The “MPI” abbreviation is used throughout the document, 
> but it is not expanded anywhere, nor is there any reference.
>
Done by referring to RFC 4880 and expanding MPI on first use to 
Multiprecision Integer.

> Q2:         The Abstract says:
>
>                 “The document aims to standardize an optimal but 
> narrow set of parameters for best interoperability”
>

Corrected this issue and  the next one ...
>
> Q3:         The Abstract says:
>
>                 “within the framework it defines”
>
>                 However, the framework is not 
> mentioned/clarified/defined anywhere in the document, so if you want 
> to talk about a framework I think some clarification is needed.
>

... with the following text:

>
>    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 easier interoperability between compliant
>    OpenPGP implementations.
>

> Q4:         In the Introduction, please add references to OpenPGP, RSA 
> and DSA. Also consider expansion on first occurrence.
>

Added the [RFC 4880] next to the OpenPGP in the Introduction, which 
happened to be the first use of OpenPGP in the body of the document. I 
left RSA and DSA undefined, as done in RFC 4880. This document is not 
concerned with these two algorithms.

> Q5:         The document uses “This document”, “This specification”, 
> “This draft” and “This standard” terminology. Please use consistent 
> terminology.
>

Corrected to "this document", which seems like the most common use 
throughout RFCs.

> Q6:         In section 5, I don’t think you need the “defined in” 
> parts. Simply add the reference.
>
>                 Example:             “Elliptic Curve Digital Signature 
> Algorithm (ECDSA) [FIPS 186-3],…”
>

I reduced a few references similar to the one you provided.

I left a few that contain additional qualifiers.

Even in this sentence that you provided, it now reads as:
> Supported public key algorithms are Elliptic Curve Digital
>    Signature Algorithm (ECDSA) [FIPS 186-3] and Elliptic Curve Diffie-
>    Hellman (ECDH), defined in section 8.

After the suggested change I felt  that earlier "defined in [FIPS 
186-3]" provided better parallelism, as I cannot use [section 8]. In any 
case, there will remain plenty of "defined" throughout the document that 
refer to inner sections.

>                 “The section 9.1. Public-Key Algorithms of [RFC4880] 
> is expanded to define the following public key algorithm IDs”
>
>                 To:
>
>                 “This section extends section 9.1 (Public-Key 
> Algorithms) or [RFC4880], by defining the following public key 
> algorithm IDs”
>

I reworded this sentence, but I kept it to maintain the original 
reference that section 9.1 is a section in RFC 4880.

> Q8:         Section 5 says:
>
>                 “Applications MUST support ECDSA and ECDH.”
>
>                 Please clarify what applications you refer to. I 
> assume you mean “Applications that implement this specification”, or 
> something similar…
>
>                 The same comment also applies to section 12.1, and 
> section 13 (the word is used many times in section 13, but it is 
> enough to clarify it on first occurrence :)
>

I changed the document by introducing the term "compliant application" 
and I replaced the relevant "applications" with "compliant applications".

> Christer
Thank you.
--- draft-jivsov-openpgp-ecc-10.txt	2012-03-07 12:38:40.914837576 -0800
+++ draft-jivsov-openpgp-ecc-11.txt	2012-03-20 14:51:03.563130407 -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 20, 2012
+Expires: September 16, 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 16, 2012.
 
 Copyright Notice

-A. Jivsov             Expires September 3, 2012               [Page 1]
+
+A. Jivsov             Expires September 16, 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 16, 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 section 9.1. Public-Key Algorithms of [RFC4880] is expanded to
-   define the following public key algorithm IDs:
+   The following public key algorithm IDs are added to expand the
+   section 9.1. Public-Key Algorithms of [RFC4880]:

 

-A. Jivsov             Expires September 3, 2012               [Page 3]
+
+
+A. Jivsov             Expires September 16, 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
@@ -207,29 +207,29 @@
    "Curve P-256", 771 for "Curve P-256", 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 16, 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,123 +274,123 @@
          o    a one-octet size of the following field

 
-A. Jivsov             Expires September 3, 2012               [Page 5]
+A. Jivsov             Expires September 16, 2012               [Page 5]
 
 Internet-Draft              ECC in OpenPGP                   March 2012

-         o   octets representing curve OID, defined in section 11
+          o   octets representing curve OID, defined in section 11
 
-  o    a one-octet public key algorithm ID defined in section 5
+   o    a one-octet public key algorithm ID defined in section 5
 
-  o    a variable-length field containing KDF parameters, identical to
-       the corresponding filed in the ECDH public key, formatted as
-       follows
+   o    a variable-length field containing KDF parameters, identical to
+        the corresponding filed in the ECDH public key, formatted as
+        follows
 
-         o   a one-octet size of the following fields; values 0 and 0xff
-             are reserved for future extensions
+          o   a one-octet size of the following fields; values 0 and 0xff
+              are reserved for future extensions
 
-         o   a one-octet value 01, reserved for future extension
+          o   a one-octet value 01, reserved for future extension
 
-         o   a one-octet hash function ID used with KDF
-         o   a one-octet algorithm ID for the symmetric algorithm used
-             to wrap the symmetric key for message encryption, see
-             section 8 for details
+          o   a one-octet hash function ID used with KDF
+          o   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    "
+   o    20 octets representing the UTF-8 encoding of the string
+        "Anonymous Sender    "
 
-  o    20 octets representing recipient encryption subkey or master key
-       fingerprint, identifying the key material that is needed for
-       decryption
+   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
-  derivation parameters sequence, defined above, is either 54 or 51.
+   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
-  algorithm, which SHOULD be one of three AES algorithms.
+   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
+   algorithm, which SHOULD be one of three AES algorithms.
 
-  The input to the key wrapping method is the value "m" derived from
-  the session key as described in section 5.1. Public-Key Encrypted
-  Session Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5
-  padding step is omitted. The result is padded using the method
-  described in [PKCS5] to the 8-byte granularity.  For example, a
-  following AES-256 session key, which 32 octets are denoted from k0
-  to k31, is composed to form the following 40 octet sequence:
+   The input to the key wrapping method is the value "m" derived from
+   the session key as described in section 5.1. Public-Key Encrypted
+   Session Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5
+   padding step is omitted. The result is padded using the method
+   described in [PKCS5] to the 8-byte granularity.  For example, a
+   following AES-256 session key, 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
+       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,
+   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,

-A. Jivsov             Expires September 3, 2012               [Page 6]
+A. Jivsov             Expires September 16, 2012               [Page 6]
 
 Internet-Draft              ECC in OpenPGP                   March 2012

-  respectfully, to provide the same number of octets, 40 total, as an
-  input to the key wrapping method.
+   respectfully, 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 with the ephemeral key used to establish shared
-  secret.  The second field is composed of the following two fields:
+   The output of the method consists of two fields.  The first field
+   is the MPI with the ephemeral key used to establish 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    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, respectfully, 32, 40, and
-  48 octets, unless size obfuscation is used.
+   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, respectfully, 32, 40, and
+   48 octets, unless 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.
+   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.
 
-        Obtain authenticated recipient public key R
-        Generate ephemeral key pair {v, V=vG}
-        Compute 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 = key size for KEK_alg_ID to be used with AESKeyWrap
-        Compute Z = KDF( S, Z_len, Param );
-        Compute C = AESKeyWrap( Z, m ) as per [RFC3394]
-        VB = convert point V to octet string
-        Output (MPI(VB) || len(C) || C).
+         Obtain authenticated recipient public key R
+         Generate ephemeral key pair {v, V=vG}
+         Compute 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 = key size for KEK_alg_ID to be used with AESKeyWrap
+         Compute Z = KDF( S, Z_len, Param );
+         Compute C = AESKeyWrap( Z, m ) as per [RFC3394]
+         VB = convert point V to 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
+   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.
+       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
-  symmetric key is protected by ECDH.
+   Consistent with section 5.13 Sym. Encrypted Integrity Protected
+   Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime
+   symmetric key is protected by ECDH.

 
 
-A. Jivsov             Expires September 3, 2012               [Page 7]
+A. Jivsov             Expires September 16, 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 16, 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 16, 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 16, 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 16, 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.
-
-  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.
-
-  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.
-
-  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.
+   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 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.
 
-A. Jivsov             Expires September 3, 2012              [Page 12]
+   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 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.  A
+
+
+
+
+A. Jivsov             Expires September 16, 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 16, 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
 
@@ -775,10 +778,7 @@

-
-
-
-A. Jivsov             Expires September 3, 2012              [Page 14]
+A. Jivsov             Expires September 16, 2012              [Page 14]

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 21 Mar 2012 12:10:40 -0700

The latest revision, attached, incorporates three additional corrections:

Section 6. P-256 -->  P-384 (typo)
Section 8. MDC "SHOULD" -->  "MUST" (unintended too relaxed spec for the new ECDH method; MDC with ECDH was set as MUST already in another section)
In Credits "Marco Kreen" -->  "Marko Kreen" (typo)

The attached revision incorporates all suggestions that I have received so far and there are no pending changes on my side.

Thank you.
--- 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
 
 Abstract

 Status of this Memo

 
-   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]
 

 1. Introduction

 

-
-A. Jivsov             Expires September 3, 2012               [Page 2]
+A. Jivsov             Expires September 17, 2012               [Page 2]
 

 

 4. Supported ECC curves

 

 

-A. Jivsov             Expires September 3, 2012               [Page 3]
+A. Jivsov             Expires September 17, 2012               [Page 3]
 

 
 
 6. Conversion primitives

       B = B0 || x || y
 
@@ -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".

 

 
 
-A. Jivsov             Expires September 3, 2012               [Page 4]
+A. Jivsov             Expires September 17, 2012               [Page 4]
 

 

@@ -274,11 +274,11 @@

 
-A. Jivsov             Expires September 3, 2012               [Page 5]
+A. Jivsov             Expires September 17, 2012               [Page 5]
 

          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]
 

   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]
 

 

-A. Jivsov             Expires September 3, 2012               [Page 8]
+A. Jivsov             Expires September 17, 2012               [Page 8]
 

 11. ECC curve OID

 
@@ -498,11 +498,11 @@

-A. Jivsov             Expires September 3, 2012               [Page 9]
+A. Jivsov             Expires September 17, 2012               [Page 9]
 

 

 
    o   the KDF hash algorithm
 
    o   KEK algorithm
 
@@ -534,11 +534,11 @@
 
 12.2. Suite-B profile

-A. Jivsov             Expires September 3, 2012              [Page 10]
+A. Jivsov             Expires September 17, 2012              [Page 10]
 

 

-A. Jivsov             Expires September 3, 2012              [Page 11]
+A. Jivsov             Expires September 17, 2012              [Page 11]
 

 
 
   Note that [RFC4880] symmetric algorithm preference list may
   restrict the use of balanced strength of symmetric key algorithms
 
   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]
 

 
 
 14. IANA Considerations
+

 
-
-
-A. Jivsov             Expires September 3, 2012              [Page 13]
+A. Jivsov             Expires September 17, 2012              [Page 13]
 

 
 
 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]