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

From: [email-masked] (Dale R. Worley)
Date: Sun, 01 Mar 2020 22:39:10 -0500

Sean Turner <[email-masked]> writes:
> BTW - I spun a new version to make the changes I noted early (at the
> request of Roman)

I will read the new version and go from there.

I realize that this I-D is just a modification of a previous RFC and as
such there isn't a requirement that it be fully comprehensible on its
own.  However, I'm sensitive to terminology, and I want to ensure that
even if reading the document alone does not fully inform the reader, it
should not cause them to believe incorrect things because the
terminology does not properly reflect the reality.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 01 Mar 2020 23:00:26 -0500

Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points
occur to me:

   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.

I think it would be more accurate to say something like "neither ... are
set in certificates that specify key agreement algorithms" -- usage bits
are logically a component of a certificate rather than a feature of an
algorithm.

But it's unclear to me whether id-ecPublicKey is only used in key
agreement certificates.  RFC 5480 states that if the cert uses id-ecDH
or id-ecMQV and provides keyUsage, then keyAgreement must be set.  So
it's clear that certs with id-ecDH or id-ecMQV are key agreement certs.
But RFC 5480 says that if the cert lists id-ecPublicKey, then
keyAgreement is optional.  That suggests to me that some certs can use
id-ecPublicKey without being key agreement certs.  In turn, section 1 of
this I-D suggests the I-D is not intended to apply to those certs, but
section 3 seems to apply to them anyway.

To try to distill it to one sentence:  Can id-ecPublicKey appear in
certs that are not for key agreement, and if so, are keyEncipherment and
dataEncipherment allowed in the keyUsage of those certs?

   3.  Updates to Section 3

   If the keyUsage extension is present in a certificate that indicates
   in SubjectPublicKeyInfo, then following values MUST NOT be present:
---^

Is "id-ecPublicKey" missing here?

   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:

Is it a fact that all certificates with these three algorithms are
certificates for key agreement?  If so, it would be nice to state that
either in section 3 or section 1, to show how section 3 is connected
with "for key agreement algorithms" in section 1.  Otherwise, the
connection between the two requires information that is stated
elsewhere.

Dale

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 3 Mar 2020 16:09:40 -0500

Dale, thanks for your reviews. Sean, thanks for your responses. I entered a No Objection ballot. If Dale’s questions can be clarified for non-expert readers, I think that would be good.

Alissa

> On Mar 1, 2020, at 11:00 PM, Dale R. Worley <[email-masked]> wrote:
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Mar 2020 12:23:43 -0500

> On Mar 3, 2020, at 16:09, Alissa Cooper <[email-masked]> wrote:
> 

Yes - The OPSDIR review noted my took quick to submit.  It’s fixed in this version:

https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/

>> connection between the two requires information that is stated

To address this, I ended up making the following tweaks in s1:

 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
 defined therein.  The additions are to be made to the end of
 Section 3.

So, there’s a link from 5480 s3 where the three algorithms are defined to this document’s s3.

spt

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Mar 2020 10:35:32 -0800

> So, there’s a link from 5480 s3 where the three algorithms are defined to this document’s s3.

I don't think that link fully closes the question of whether id-ecPublicKey
is defined to be a"key agreement algorithm" or not.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Thu, 5 Mar 2020 15:29:47 -0500

> On Mar 5, 2020, at 1:35 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

That identifier is used for key agreement and signature.  The key usage extension can restrict it to one or the other if desired.  The point of this update is that it is not ever a key encipherment or data encipherment algorithm.

Russ