Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure
draft-ietf-curdle-pkix-10

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

Ben Campbell Yes

Benjamin Kaduk Yes

Comment (2018-04-13 for -07)
It's good to see this being done.  I found several nits (and second the genart reviewer's request for the RFC 8174 boilerplate).

Section 1

   [...] This RFC defines the ASN.1 Object Identifiers
   (OIDs) for the operations X25519 and X448 along with the parameters.

"the parameters" is not scoped properly; "their parameters", maybe?

   [...] The convention used for identifying
   the algorithm/curve combinations are to use the Ed25519 and Ed448 for
   the PureEdDSA mode. [...]

"the Ed25519" is an overzealous "the"; also singular/plural mismatch
for convention/are.

      [...], or the OID should
      merely not that a context string needs to be provided.

s/not/note/


Section 3

   o  algorithm identifies the cryptographic algorithm with an object
      identifier.  This is one of the OIDs defined below.

"is" may be too restrictive, since there are other possible uses of
AlgorithmIdentifier.

   In this document we defined four new OIDs for identifying the
   different curve/algorithm pairs.  The curves being curve25519 and
   curve448.  The algorithms being ECDH and EdDSA in pure mode.

s/defined/define/, and join the latter sentence fragments into the
former sentence with commas/"and".


Section 4

The public key example immediately follows text about how the
key-exchange and EdDSA usages will produce different public key
encodings for a given private key, but does not say which encoding
it uses.  It would be nice to have that clearly indicated in the
text.


Section 7

   Asymmetric Key Packages [RFC5958] describes how encode a private key

"how to encode"

Alexey Melnikov Yes

Comment (2018-04-15 for -07)
Benjamin already spotted s/not/note.

Eric Rescorla Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2018-04-18 for -07)
Please update Section 2 to reference BCP 14 rather than RFC 2119.

Spencer Dawkins No Objection

Comment (2018-04-12 for -07)
Nit:

  o  The EdDSA algorithms are the only IETF algorithms that currently
      support the use of contexts, however there is a possibility that
      there will be confusion between which algorithms need have
                                 "need" or "need to have"? ^
      separate keys and which do not.  This may result in a decrease of
      security for those other algorithms.

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-04-16 for -07)
I'd ballot Yes, but I'm not sufficiently schooled in the art to be able to back that up...

Instead, I offer a nit :-) :
1: "There are still on going discussions" -> ongoing.

Mirja Kühlewind No Objection

Terry Manderson No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-04-16 for -07)
Thanks to everyone who contributed to this document.

This is not as much a document comment as a flag for IANA -- the OIDs
1.3.101.114 and 1.3.101.115 show as reserved by this document at
https://www.ietf.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.101
but those codepoints no longer appear in this document. We should make sure
they get released by IANA rather than finalized to point to the RFC this will
become.

---------------------------------------------------------------------------

§3:

>     For this reason, a small
>     number of implementations may still require the field to be
>     present.

I'm surprised that there's no implementation guidance here. Presumably (based
on the text about curve25519 and curve448), the parameter is present but NULL?
Is it recommended to set this for maximum compatiblity? Or is this simply
something that users should be allowed to configure when generating these?

===========================================================================
Nits
===========================================================================

§1:

>  o  The EdDSA algorithms are the only IETF algorithms that currently
>     support the use of contexts, however there is a possibility that
>     there will be confusion between which algorithms need have
>     separate keys and which do not.  This may result in a decrease of

Nit: "...need to have..."

---------------------------------------------------------------------------
§1:

>  o  There are still on going discussions among the cryptographic

Nit: "ongoing"

---------------------------------------------------------------------------

§1:

>  o  There needs to be discussions about the correct way to identify
>     when context strings are to be used.  It is not clear if different
>     OIDs should be used for different contexts, or the OID should
>     merely not that a context string needs to be provided.

Nit: "...merely note..."

---------------------------------------------------------------------------

§2:

Consider use of RFC 8174 boiler plate - the document uses non-normative,
lowercase "should" in some locations.

Martin Vigoureux No Objection