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

[Sean Turner <[e-mail]>]

Dale,

Hi! And, thanks for your review comments in-line.

spt

> On Feb 18, 2020, at 22:07, Dale Worley via Datatracker <[e-mail]> wrote:
> 
> 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.

Sometimes when you are too familiar with the context you assume too much so a fresh set of eye can help!

> 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]

Ah ... this might be where some of misunderstanding comes from because id-ecPublicKey MAY be a key agreement algorithm that is why it is “unrestricted”. In other words, when key agreement certificates can include the following OIDs: id-ecDH (for an EC DH algorithm), id-ecMQV (for EC MQV), or id-ecPublicKey (for any algorithm). Here’s the text from 5480 about id-ecPublicKey being used as key agreement algrithm:

If the keyUsage extension is present in an End Entity (EE)
certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo,
then any combination of the following values MAY be present:

 digitalSignature;
 nonRepudiation; and
 keyAgreement.

> 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.

See above.

I also pondered how much to put in the intro to accommodate those readers that are not as familiar with RFC 5480. I went the minimal route since this is supposed to be just adding two sentences to RFC 5480. I sure hope people that are not intimately familiar with RFC 5480 do immediately go read RFC 5480 because this draft isn’t all that much use without doing so :)

> 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.

There are two reasons I’d like to not merge these two bits of text:

1. Agreed it is a bit odd, but it does mirror RFC 5480, which talks about id-ecPublicKey for CA certificates and then EE certificates and then id-ecDH/id-ecMQV. I guess we could collapse it, but for me then it’s a style thing and I’d rather mimic the RFC it’s updating.

2. With separate sentences we leave open the door for ECC encryption algorithms like ECIES
<https://itectec.com/spec/c-3-elliptic-curve-integrated-encryption-scheme-ecies/>

These algorithm need a lot of metadata (including EC point, KDF algorithm, hash algorithms, metadata of hash or KDF, etc…), and we are not sure, but believe, when specified they will not use id-ecPublicKey.
However, they may use SubjectPublicKeyInfo for their metadata.

If we integrate two sentence together, a possible future ECIES draft will conflict with our draft.

> 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.

I am pretty sure we did that to provide some context for where the OIDs go, but you are right the first paragraph could just of easily been:

 If the keyUsage extension is present in a certificate that indicates
 id-ecPublicKey in SubjectPublicKeyInfo,

I will make that change.

> 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.)

See above.

Cheers,

spt