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

[[e-mail] (Dale R. Worley)]

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