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

From: Dale Worley via Datatracker <[email-masked]>
Date: Tue, 18 Feb 2020 19:07:50 -0800

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]

---

From: Sean Turner <[email-masked]>
Date: Thu, 20 Feb 2020 09:49:23 -0500

Dale,

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

spt

> On Feb 18, 2020, at 22:07, Dale Worley via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Dale Worley

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

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

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

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

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

> 2nd paragraph should be omitted.)

See above.

Cheers,

spt

---

From: Tadahiko Ito <[email-masked]>
Date: Thu, 20 Feb 2020 16:09:43 +0100

Hi

let me fix a little.

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

we are not sure, but believe when specified they will not use
id-ecPublicKey as a algorithm,

but they may use id-ecPublicKey in the metadata field,  along with ECIES
algorithm identifier in the algorithm field.

Regards Tadahiko Ito

2020年2月20日(木) 15:49 Sean Turner <[email-masked]>:

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 20 Feb 2020 21:03:13 -0500

Sean Turner <[email-masked]> writes:
> "unrestricted". In other words, when key agreement certificates can
I assume that "when" in the above line should be omitted.
> 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:
>

I'm still finding this an uphill climb.  If I understand you correctly,
"key agreement" is not an attribute of an algorithm per se, but rather
an attribute of a certificate.  And thus id-ecPublicKey may be specified
in a key agreement certificate (that is, one with keyAgreement), but can
also be specified in non-key agreement certificates (that is, ones
without keyAgrement).  But id-ecDH and id-ecMQV may only be used in key
agreement certificates, and in that sense they can be considered "key
agreement algorithms".  Is that correct?

Dale

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Feb 2020 21:01:12 -0500

> On Feb 20, 2020, at 21:03, Dale R. Worley <[email-masked]> wrote:
> 

Yes.

BTW - I spun a new version to make the changes I noted early (at the request of Roman)

spt