Ballot for draft-ietf-curdle-pkix
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
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.
Benjamin already spotted s/not/note.
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"
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.
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.