Skip to main content

Last Call Review of draft-ietf-lamps-5480-ku-clarifications-01

Request Review of draft-ietf-lamps-5480-ku-clarifications
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2020-02-21
Requested 2020-02-07
Authors Tadahiko Ito , Sean Turner
I-D last updated 2020-02-28
Completed reviews Opsdir Last Call review of -01 by Tim Chown (diff)
Secdir Last Call review of -02 by Klaas Wierenga (diff)
Genart Last Call review of -00 by Dale R. Worley (diff)
Assignment Reviewer Tim Chown
State Completed
Review review-ietf-lamps-5480-ku-clarifications-01-opsdir-lc-chown-2020-02-27
Posted at
Reviewed revision 01 (document currently at 03)
Result Not ready
Completed 2020-02-27
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

The draft updates RFC 5480 to clarify the usage of the keyEncipherment and
dataEncipherment key usage bits in the Subject Public Key Information field for
certificates that support elliptic curve cryptography.  Specifically, it states
that neither of these bits are set for key agreement algorithms.

This is a short document with just a few lines of text that update RFC 5480. 
The rationale for the additional clarification seems clear.

The subject matter of the draft is not a strong area of interest of mine.

Overall, the document is not Ready, primarily due to some key (no pun
intended!) text being missing.


Section 1:

It would be good to state whether it is all or some specific key agreement

Section 3:

The way it is written, I would suggest saying “or” for the bits, not “and”.

A specific reference to section 2.1 of RFC 5480 would be good to add, where the
semantics id-ecDH, id-ecMQV and id-ecPublicKey are given.

The first sentence appears to be missing text - a certificate that indicates
what?  I’m guessing this should be id-ecPublicKey?