Skip to main content

Elliptic Curve Cryptography (ECC) in OpenPGP
draft-jivsov-openpgp-ecc-14

Revision differences

Document history

Date Rev. By Action
2015-10-14
14 (System) Notify list changed from Andrey_Jivsov@symantec.com, wk@gnupg.org, draft-jivsov-openpgp-ecc@ietf.org to wk@gnupg.org
2012-06-12
14 (System) RFC published
2012-04-19
14 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-04-19
14 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2012-04-19
14 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-04-19
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-04-17
14 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2012-04-16
14 (System) IANA Action state changed to In Progress
2012-04-16
14 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-04-16
14 Amy Vezza IESG has approved the document
2012-04-16
14 Amy Vezza Closed "Approve" ballot
2012-04-16
14 Amy Vezza Ballot approval text was generated
2012-04-16
14 Amy Vezza Ballot writeup was changed
2012-04-12
14 Cindy Morgan State changed to Approved-announcement to be sent from IESG Evaluation
2012-04-12
14 Sean Turner Ballot writeup was changed
2012-04-12
14 Pete Resnick [Ballot comment]
[Thanks for address my comments]
2012-04-12
14 Pete Resnick Ballot comment text updated for Pete Resnick
2012-04-12
14 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-04-12
14 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2012-04-11
14 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Brian Weis.
2012-04-11
14 Andrey Jivsov New version available: draft-jivsov-openpgp-ecc-14.txt
2012-04-11
13 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2012-04-11
13 Andrey Jivsov New version available: draft-jivsov-openpgp-ecc-13.txt
2012-04-11
12 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-04-11
12 Barry Leiba
[Ballot comment]
Some very minor comments [UPDATE: adequately addressed in -12]:

Section 2:
  Any implementation MAY adhere to the format and methods specified
  …
[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.
2012-04-11
12 Barry Leiba Ballot comment text updated for Barry Leiba
2012-04-11
12 Sean Turner State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-04-11
12 Stephen Farrell
[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 …
[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.
2012-04-11
12 Stephen Farrell Ballot comment text updated for Stephen Farrell
2012-04-10
12 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-04-10
12 Pete Resnick
[Ballot comment]
[Thanks for address my other comment)

In section 8:

  o    20 octets representing the UTF-8 encoding of the string
    …
[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.
2012-04-10
12 Pete Resnick Ballot comment text updated for Pete Resnick
2012-04-10
12 Andrey Jivsov New version available: draft-jivsov-openpgp-ecc-12.txt
2012-04-09
11 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2012-04-09
11 Russ Housley
[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 …
[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.
2012-04-09
11 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-04-09
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-04-09
11 Barry Leiba
[Ballot comment]
Some very minor comments:

Section 2:
  Any implementation MAY adhere to the format and methods specified
  in this document, in which …
[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.
2012-04-09
11 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2012-04-09
11 Stephen Farrell
[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 …
[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.
2012-04-09
11 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2012-04-09
11 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-04-07
11 Pete Resnick
[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 …
[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
2012-04-07
11 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-04-06
11 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-04-03
11 Amanda Baber
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 …
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.
2012-03-30
11 Christer Holmberg Request for Last Call review by GENART Completed. Reviewer: Christer Holmberg.
2012-03-26
11 Andrey Jivsov New version available: draft-jivsov-openpgp-ecc-11.txt
2012-03-25
10 Sean Turner Ballot has been issued
2012-03-25
10 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2012-03-25
10 Sean Turner Ballot writeup was changed
2012-03-25
10 Sean Turner Created "Approve" ballot
2012-03-16
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Brian Weis
2012-03-16
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Brian Weis
2012-03-15
10 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2012-03-15
10 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2012-03-12
10 Amy Vezza Last call sent
2012-03-12
10 Amy Vezza
State changed to In Last Call from Last Call Requested<br><br>The following Last Call Announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org><br><br>To: IETF-Announce …
State changed to In Last Call from Last Call Requested<br><br>The following Last Call Announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org><br><br>To: IETF-Announce <ietf-announce@ietf.org><br><br>Reply-To: ietf@ietf.org<br><br>Subject: Last Call: <draft-jivsov-openpgp-ecc-10.txt> (ECC in OpenPGP) to Proposed Standard<br><br><br><br><br><br>The IESG has received a request from an individual submitter to consider<br><br>the following document:<br><br>- 'ECC in OpenPGP'<br><br>  <draft-jivsov-openpgp-ecc-10.txt> as a Proposed Standard<br><br><br><br>The IESG plans to make a decision in the next few weeks, and solicits<br><br>final comments on this action. Please send substantive comments to the<br><br>ietf@ietf.org mailing lists by 2012-04-09. Exceptionally, comments may be<br><br>sent to iesg@ietf.org instead. In either case, please retain the<br><br>beginning of the Subject line to allow automated sorting.<br><br><br><br>Abstract<br><br><br><br><br><br>  This document proposes an Elliptic Curve Cryptography extension to<br><br>  the OpenPGP public key format and specifies three Elliptic Curves<br><br>  that enjoy broad support by other standards, including NIST<br><br>  standards.  The document aims to standardize an optimal but narrow<br><br>  set of parameters for best interoperability and it does so within<br><br>  the framework it defines that can be expanded in the future to<br><br>  allow more choices.<br><br><br><br><br><br><br><br><br><br>The file can be obtained via<br><br>http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/<br><br><br><br>IESG discussion can be tracked via<br><br>http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/ballot/<br><br><br><br><br><br>The following IPR Declarations may be related to this I-D:<br><br><br><br>  http://datatracker.ietf.org/ipr/1469/<br><br><br><br><br><br><br><br>
2012-03-12
10 Amy Vezza Last call announcement was generated
2012-03-11
10 Sean Turner Placed on agenda for telechat - 2012-04-12
2012-03-11
10 Sean Turner Last call was requested
2012-03-11
10 Sean Turner Ballot approval text was generated
2012-03-11
10 Sean Turner Ballot writeup was generated
2012-03-11
10 Sean Turner State changed to Last Call Requested from Publication Requested
2012-03-11
10 Sean Turner Last call announcement was changed
2012-03-11
10 Sean Turner Last call announcement was generated
2012-03-09
10 Amy Vezza
======
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the …
======
  (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 <wk@gnupg.org>.

  (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.
2012-03-09
10 Amy Vezza State changed to Publication Requested from AD is watching::AD Followup
2012-03-07
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-03-07
10 Andrey Jivsov New version available: draft-jivsov-openpgp-ecc-10.txt
2012-03-06
09 Sean Turner State changed to AD is watching::Revised ID Needed from AD is watching
2012-03-06
09 Sean Turner Note added 'Wener Koch (wk@gnupg.org) is the Document Shepherd.'
2012-03-06
09 Sean Turner State Change Notice email list changed to Andrey_Jivsov@symantec.com, wk@gnupg.org, draft-jivsov-openpgp-ecc@tools.ietf.org
2012-03-06
09 Sean Turner Stream changed to IETF
2012-03-06
09 Sean Turner Intended Status changed to Proposed Standard
2012-03-06
09 Sean Turner IESG process started in state AD is watching
2012-02-17
09 (System) New version available: draft-jivsov-openpgp-ecc-09.txt
2011-09-27
08 (System) New version available: draft-jivsov-openpgp-ecc-08.txt
2011-03-28
07 (System) New version available: draft-jivsov-openpgp-ecc-07.txt
2011-03-28
09 (System) Document has expired
2011-01-06
(System) Posted related IPR disclosure: Certicom Corp's Statement about IPR related to draft-jivsov-openpgp-ecc
2010-09-19
06 (System) New version available: draft-jivsov-openpgp-ecc-06.txt
2010-06-25
05 (System) New version available: draft-jivsov-openpgp-ecc-05.txt
2009-12-26
04 (System) New version available: draft-jivsov-openpgp-ecc-04.txt
2009-06-29
03 (System) New version available: draft-jivsov-openpgp-ecc-03.txt
2009-01-01
02 (System) New version available: draft-jivsov-openpgp-ecc-02.txt
2008-07-07
01 (System) New version available: draft-jivsov-openpgp-ecc-01.txt
2008-04-29
00 (System) New version available: draft-jivsov-openpgp-ecc-00.txt