Tim, Thanks for the review. Responses in-line. spt > On Feb 27, 2020, at 05:46, Tim Chown via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Tim Chown > Review result: Not Ready > > 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. It's just the ones defined in RFC 5480 ;) How about: OLD: This document corrects this omission, by updating Section 3 of [RFC5480] to make it clear that neither keyEncipherment nor the dataEncipherment key usage bits are set for key agreement algorithms. NEW: This document corrects this omission, by updating Section 3 of [RFC5480] to make it clear that neither keyEncipherment nor the dataEncipherment key usage bits are set for key agreement algorithms specified therein. Implemented here: https://github.com/lamps-wg/draft-ietf-lamps-5480-ku-clarifications/pull/7 > Section 3: > > The way it is written, I would suggest saying “or” for the bits, not “and”. I could see “nor”, but just wanted to use words similar to those used in RFC 5480 and there it uses “and” for the MUST NOT clauses. > 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. I will bow to the will of the IESG, but I think this is a bit overkill since I would expect that anybody reading this also read RFC 5480. > The first sentence appears to be missing text - a certificate that indicates > what? I’m guessing this should be id-ecPublicKey? drat I was overzealous in my deletions to address an earlier comment - yep id-ecPublicKey. It’s fixed here: https://github.com/lamps-wg/draft-ietf-lamps-5480-ku-clarifications/blob/master/draft-ietf-lamps-5480-ku-clarifications.md -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
