Last Call Review of draft-ietf-lamps-5480-ku-clarifications-01
review-ietf-lamps-5480-ku-clarifications-01-opsdir-lc-chown-2020-02-27-00

Request Review of draft-ietf-lamps-5480-ku-clarifications
Requested rev. 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
Draft 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 Worley (diff)
Assignment Reviewer Tim Chown
State Completed
Review review-ietf-lamps-5480-ku-clarifications-01-opsdir-lc-chown-2020-02-27
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/sK59AotfcugFJ9wICUx-KuknmpQ
Reviewed rev. 01 (document currently at 03)
Review result Not Ready
Review completed: 2020-02-27

Review
review-ietf-lamps-5480-ku-clarifications-01-opsdir-lc-chown-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.

Comments:

Section 1:

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

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?

Tim