Skip to main content

Clarifications for Elliptic Curve Cryptography Subject Public Key Information
draft-ietf-lamps-5480-ku-clarifications-03

Yes

Roman Danyliw
(Alexey Melnikov)

No Objection

(Adam Roach)
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)

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

Roman Danyliw
Yes
Warren Kumari
No Objection
Comment (2020-03-03 for -02) Not sent
Thanks to Tim for the OpsDir review, and Sean for addressing it.
Éric Vyncke
No Objection
Comment (2020-02-25 for -00) Sent
Ultra short document :-)

Anyway, a minor comment: what is the location of the text updating the section 3 of RFC 5480? Should it go at the end of the existing section 3 (my guess)? Or at the beginning ? or somewhere in the middle ? Should it replace completely or partially the existing section 3? 

-éric

PS: I know that my comment is mostly larger than the update itself ;-)
Alexey Melnikov Former IESG member
Yes
Yes (for -00) Not sent

                            
Adam Roach Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2020-03-03 for -02) Sent
If further clarifications can be made based on the latest email from the Gen-ART reviewer, that would be good.
Alvaro Retana Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2020-02-25 for -00) Sent
Thanks for a nice, super-short and to-the-point document.  I hate to pick on anything here, but:

   then the following
   values also MUST NOT be present:

Do you mean "MUST NOT also be present"?  The "also" seems misplaced where it is, and it made me wonder if I misunderstood.  An alternative fix would be to simply remove "also".
Benjamin Kaduk Former IESG member
No Objection
No Objection (2020-03-02 for -02) Sent
I'm somewhat amenable to the genart reviewer's concerns that we are
implicitly asserting restrictions in RFC 5480 usage by describing the
algorithms defined by 5480 as "key agreement algorithms"; RFC 5480 does
not seem to use that terminology to refer to id-ecPublicKey.

Section 1

   Cryptography.  As part of these semantics, it defines what
   combinations are permissible for the values of the key usage
   extensions [RFC5280].  [RFC5480] specifies 7 of the 9 values; it

nit: IMO, "key usage extensions" would mean both keyUsage and
extendedKeyUsage, but this document considers only the identified bits
in the original keyUsage extension, and thus the singular "extension"
would be more appropriate.

Section 4

What are the considerations that apply to implementations that follow
RFC 5480 but not this document, e.g., existing implementations that
allow keyEncipherment and/or dataEncipherment?  Specifically, if we are
forbidding their usage, is it because there are vulnerabilities to doing
so?  It seems like we should mention them here.
Deborah Brungard Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -02) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -01) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -02) Not sent