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

[Sean Turner <[e-mail]>]

> On Feb 20, 2020, at 21:03, Dale R. Worley <[e-mail]> wrote:
> 
> Sean Turner <[e-mail]> writes:
>>>> 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
> 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:
>> 
>> 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.
> 
> 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

Yes.

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

spt