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 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 | |
Request | Last Call review on draft-ietf-lamps-5480-ku-clarifications by Ops Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/ops-dir/sK59AotfcugFJ9wICUx-KuknmpQ | |
Reviewed revision | 01 (document currently at 03) | |
Result | Not ready | |
Completed | 2020-02-27 |
review-ietf-lamps-5480-ku-clarifications-01-opsdir-lc-chown-2020-02-27-00
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