Hi, In-line... > On 27 Feb 2020, at 17:30, Sean Turner <sean@xxxxxxxxx> wrote: > > 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 Thanks. >> 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. OK, if it keeps it consistent that's fine, it just reads a little strangely to me. >> 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. Well, ops-dir reviewers might not, so maybe it’s just down to me needing to hunt down the reference to check. Wouldn’t hurt to add it? But also fine if you don’t. >> 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 OK, cheers! Tim > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
