[Gen-art] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00

[Dale Worley via Datatracker <[e-mail]>]

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]