Re: [Gen-art] draft-ietf-lamps-5480-ku-clarifications-01

[Benjamin Kaduk <[e-mail]>]

On Wed, Mar 04, 2020 at 12:23:43PM -0500, Sean Turner wrote:
> 
> 
> > On Mar 3, 2020, at 16:09, Alissa Cooper <[e-mail]> wrote:
> > 
> > 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 <[e-mail]> wrote:
> >> 
> >> 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?
> 
> 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/
> 
> >>  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.
> 
> 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.

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