Elliptic Curve Cryptography (ECC) in OpenPGP
RFC 6637

Note: This ballot was opened for revision 10 and is now closed.

(Stephen Farrell) Yes

Comment (2012-04-11 for -12)
No email
send info
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.


- 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

- "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.

Barry Leiba Yes

Comment (2012-04-11 for -12)
No email
send info
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.

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-04-09 for -11)
No email
send info
  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.

(Pete Resnick) No Objection

Comment (2012-04-12)
No email
send info
[Thanks for address my comments]

(Robert Sparks) No Objection