Skip to main content

Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
RFC 8410

Yes

(Ben Campbell)
(Eric Rescorla)

No Objection

Alvaro Retana
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)

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

Alvaro Retana
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.
Alexey Melnikov Former IESG member
Yes
Yes (2018-04-15 for -07)
Benjamin already spotted s/not/note.
Ben Campbell Former IESG member
Yes
Yes (for -07)

                            
Benjamin Kaduk Former IESG member
Yes
Yes (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"
Eric Rescorla Former IESG member
Yes
Yes (for -07)

                            
Adam Roach Former IESG member
No Objection
No Objection (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.
Alissa Cooper Former IESG member
No Objection
No Objection (2018-04-18 for -07)
Please update Section 2 to reference BCP 14 rather than RFC 2119.
Deborah Brungard Former IESG member
No Objection
No Objection (for -07)

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -07)

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -07)

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -07)

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (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 Former IESG member
No Objection
No Objection (for -07)

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -07)