Elliptic Curve Cryptography (ECC) in OpenPGP
RFC 6637

[Ballot comment]
Some very minor comments [UPDATE: adequately addressed in -12]:

Section 2:
  Any implementation MAY adhere to the format and methods specified
  in this document, in which case such an implementation is called a
  compliant application.

That seems a bit of a silly use of 2119 language.  I think what you really mean is this:
  Any implementation that adheres to the format and methods specified
  in this document is called a compliant application.

The sentence after that seems silly as well: the normative language here only applies to applications that want it to apply to them.  We don't lock people up if they don't comply with our specs.  It's a small point, and I completely don't mind if you ignore me here, but I suggest removing the sentence.

[Ballot comment]

Please also consider the (very recent) comments from the
secdir review. [1]

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03228.html

My previous comments are below but from a quick glance
seem to be addressed in -12.

Two substantive comments and a bunch of nits, but this is
good stuff.

#1 The write up talks about running code which is great. Did the
implementers of both take a look at this version of the document?
I don't recall any last-minute changes but no harm checking.

#2 I was left wondering about pkcs#1.5 and bleichenbacher's TLS attack
and other side-channel attacks, e.g. based on timing or power. Those
are not mentioned here, but are not things about which every coder
would know. Is there a good document covering such side-channels
against PGP, and/or ECC that could be added to section 13? (I'd bet
there is, doesn't need to be an RFC.) I think that'd be a good
addition.  If there's no good document at least some mention of side
channels as a security consideration would be good.

Nits:

- 1st para of section 5 reads as if the ECDH variant here is not
interoperable with 6090, is that the case or not? If not (as I hope)
then fixing that would be good.

- the 2119 language at the end of section 6 is odd, better to say you
MUST NOT use another format if there's any doubt that any recipient
doesn't support the new format.

- Does the 2119 lanaguage in section 7 mean that implementations MUST
support all of sha-256, sha-384 and sha-512? I've no problem with that
but making it clear would be better for interop.  Section 12 sort of
says otherwise but its a little confusing.  Maybe add a forward
reference to section 12 from 7? (Is the section 13 forward reference
there correct?)

- start of p7 s/respecfully/respectively/ nice typo:-) same typo
elsewhere as well

- the pesudocode on p7 would be better as a figure so it can be
referenced.

- "the" is missing in various places, I skipped over a bunch until it
got to me;-) that was in section 10: s/applying KDF/applying the KDF/

- section 11 could confuse a coder as to whether the truncated form or
usual encoding of the OIDs is used in the protocol. Making that
clearer would be good, e.g., by saying that the non-truncated form is
never used in this protocol (but would be found in e.g., x.509 certs
for keys concerned).

- The reference to TripleDES in section 13 can I guess be deleted and
probably refers to earlier text that's no longer present.

[Ballot comment]
[Thanks for address my other comment)

In section 8:

  o    20 octets representing the UTF-8 encoding of the string
        "Anonymous Sender    ", where the space code point has the
        hexadecimal value 20.

You would have been safer to say "the US-ASCII encoding of the string" instead of "the UTF-8 encoding". Given the goofiness of non-normalized encodings of characters in UTF-8, I still think it would probably be best to actually specify *all* of the octets to avoid some bonehead typing on a keyboard and getting it wrong:

  o    20 octets representing the UTF-8 encoding of the string
        "Anonymous Sender    ", the specific octets as follows:

        41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20

That way you're sure.

[Ballot comment]
  Thanks for addressing issues raised in the Gen-ART Review by
  Christer Holmberg on 19-Mar-2012.

  I suggest an update to the 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.

[Ballot comment]
Some very minor comments:

Section 2:
  Any implementation MAY adhere to the format and methods specified
  in this document, in which case such an implementation is called a
  compliant application.

That seems a bit of a silly use of 2119 language.  I think what you really mean is this:
  Any implementation that adheres to the format and methods specified
  in this document is called a compliant application.

The sentence after that seems silly as well: the normative language here only applies to applications that want it to apply to them.  We don't lock people up if they don't comply with our specs.  It's a small point, and I completely don't mind if you ignore me here, but I suggest removing the sentence.

[Ballot comment]

Two substantive comments and a bunch of nits, but this is
good stuff.

#1 The write up talks about running code which is great. Did the
implementers of both take a look at this version of the document?
I don't recall any last-minute changes but no harm checking.

#2 I was left wondering about pkcs#1.5 and bleichenbacher's TLS attack
and other side-channel attacks, e.g. based on timing or power. Those
are not mentioned here, but are not things about which every coder
would know. Is there a good document covering such side-channels
against PGP, and/or ECC that could be added to section 13? (I'd bet
there is, doesn't need to be an RFC.) I think that'd be a good
addition.  If there's no good document at least some mention of side
channels as a security consideration would be good.

Nits:

- 1st para of section 5 reads as if the ECDH variant here is not
interoperable with 6090, is that the case or not? If not (as I hope)
then fixing that would be good.

- the 2119 language at the end of section 6 is odd, better to say you
MUST NOT use another format if there's any doubt that any recipient
doesn't support the new format.

- Does the 2119 lanaguage in section 7 mean that implementations MUST
support all of sha-256, sha-384 and sha-512? I've no problem with that
but making it clear would be better for interop.  Section 12 sort of
says otherwise but its a little confusing.  Maybe add a forward
reference to section 12 from 7? (Is the section 13 forward reference
there correct?)

- start of p7 s/respecfully/respectively/ nice typo:-) same typo
elsewhere as well

- the pesudocode on p7 would be better as a figure so it can be
referenced.

- "the" is missing in various places, I skipped over a bunch until it
got to me;-) that was in section 10: s/applying KDF/applying the KDF/

- section 11 could confuse a coder as to whether the truncated form or
usual encoding of the OIDs is used in the protocol. Making that
clearer would be good, e.g., by saying that the non-truncated form is
never used in this protocol (but would be found in e.g., x.509 certs
for keys concerned).

- The reference to TripleDES in section 13 can I guess be deleted and
probably refers to earlier text that's no longer present.

[Ballot comment]
In section 8:

  Key derivation function parameters MUST be encoded as concatenation
  of the following 5 variable-length and fixed-length fields:

I suspect that's a bogus use of MUST. Could an implementation imagine doing it any other way? Do you really mean "Key derivation function parameters are encoded as..."?

  o    20 octets representing the UTF-8 encoding of the string
        "Anonymous Sender    "

Given the goofiness of assorted kinds of spaces and non-normalized encodings of things in UTF-8, it would probably be best to actually specify the octets to avoid some bonehead typing on a keyboard and getting it wrong:

0x41 0x6E 0x6F 0x6E 0x79 0x6D 0x6F 0x75 0x73 0x20 0x53 0x65 0x6E 0x64 0x65 0x72 0x20 0x20 0x20 0x20

IANA understands that, upon approval of this document two IANA Actions
must be completed.

First, in the Public Key Algorithms namespace located in the Pretty Good
Privacy (PGP) registry located at:

http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xml

IANA will take the entry for ID "18" and change it as follows:

ID: 18
Algorithm: ECDH public key algorithm
Reference: [ RFC-to-be ]

Second, also in the Public Key Algorithms namespace located in the
Pretty Good Privacy (PGP) registry located at:

http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xml

IANA will take the entry for ID "19" and change it as follows:

ID: 19
Algorithm: ECDSA public key algorithm
Reference: [ RFC-to-be ]

IANA understands that these two changes are the only actions required
upon approval of this document.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

Reply-To: ietf@ietf.org

Subject: Last Call:  (ECC in OpenPGP) to Proposed Standard





The IESG has received a request from an individual submitter to consider

the following document:

- 'ECC in OpenPGP'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-04-09. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This document proposes 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.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/ballot/





The following IPR Declarations may be related to this I-D:



  http://datatracker.ietf.org/ipr/1469/

======
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the document
        and, in particular, does he or she believe this version is ready
        for forwarding to the IESG for publication?

  Werner Koch .

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

  The I-D has been discussed on the mailing list of the concluded
  OpenPGP WG.  Suggested changes have been done by the author.  There
  was rough consensus in the WG that this is the way to add ECC to
  OpenPGP.

  I have no concerns about the reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective, e.g.,
        security, operational complexity, someone familiar with AAA,
        internationalization or XML?

  No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

  No.

  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

  There is a strong consensus withing the OpenPGP community that this
  the way to add ECC to OpenPGP.  Some people however questioned the
  use of ECC, regardless of the protocol.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

  No.  I am not aware of any discontent after the changes done to the
  initial version of the I-D.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
        enough; this check needs to be thorough. Has the document met all
        formal review criteria it needs to, such as the MIB Doctor, media
        type and URI type reviews?

  Yes.  One line is too long, there is a normative reference to the
  obsoleted rfc-2434.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that are
        not ready for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call procedure
        for them [RFC3967].

  There is only a normative references.  I have not yet checked it.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?

  Yes.  The IANA registry is identified by reference to RFC-4880.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?

  Formal languages are not used.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:


    Technical Summary

        This document proposes 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.

    Working Group Summary

        This document has been discussed and reviewed by members of
        the concluded OpenPGP WG.  The OpenPGP protocol has an
        reserved algorithm ID for ECC; this document suggests the use
        the participants of the of this algorithm ID.  There was a
        consensus between the participants of the discussion to use
        this document as the specification for the use of ECC in
        OpenPGP.


    Document Quality

        There are two independent implementations of this ECC extension
        to OpenPGP: The Symantec PGP software implements it, and a beta
        version of the Free Software Foundation's GnuPG software fully
        implements it.