Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
draft-ietf-curdle-pkix-10
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.
Warren Kumari
No Objection
Comment
(2018-04-16 for -07)
Unknown
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)
Unknown
Benjamin already spotted s/not/note.
Ben Campbell Former IESG member
Yes
Yes
(for -07)
Unknown
Benjamin Kaduk Former IESG member
Yes
Yes
(2018-04-13 for -07)
Unknown
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)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2018-04-16 for -07)
Unknown
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)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -07)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -07)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2018-04-12 for -07)
Unknown
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)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -07)
Unknown