Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lamps-5480-ku-clarifications-00 Reviewer: Dale R. Worley Review Date: 2020-02-18 IETF LC End Date: 2020-02-07 IESG Telechat date: [unknown] Summary: This draft is on the right track but has open issues, described in the review. The text is difficult to follow in places. I believe that the WG has a clear understanding of what is intended, but a few small editorial errors have unfortunately rendered the text incorrect and contradictory to RFC 5480. Note that I am unfamiliar with the details of PKI certificates; this review is based largely on what I have learned from RFC 5480 and this I-D. >From the discussion it appears that id-ecDH and id-ecMQV are "key agreement algorithms" and that, as such, they should not be used with keyEncipherment or dataEncipherment. [this draft, section 3] Conversely, id-ecPublicKey is not a "key agreement algorithm". [RFC 5480, section 2.1.2, para. 1, sentence 1] 1. Introduction 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. This could be clearer by replacing or augmenting "key agreement algorithms" with a description of which of these algorithms are key agreement algorithms, viz., id-ecDH and id-ecMQV. Otherwise, one must first have read RFC 5480 to understand this introduction correctly. 3. Updates to Section 3 If the keyUsage extension is present in a certificate that indicates id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in SubjectPublicKeyInfo, then following values MUST NOT be present: keyEncipherment; and dataEncipherment. If the keyUsage extension is present in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following values also MUST NOT be present: keyEncipherment; and dataEncipherment. The structure of this section is peculiar, since it presents almost the same text about "id-ecPublicKey" and about "id-ecDH or id-ecMQV". If the intention is to say the same thing about all three, these should be folded together. It is also not clear why the first paragraph refers to AlgorithmIdentifier but the second paragraph uses SubjectPublicKeyInfo to refer to essentially the same thing. But this text appears to contradict the statement in [RFC 5480] that the usage of id-ecPublicKey is "unrestricted" and is not a key agreement algorithm, in which case the first paragraph should say "the following values MAY be present". (In which case, the "also" in the 2nd paragraph should be omitted.) [END] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
