> On Feb 20, 2020, at 21:03, Dale R. Worley <wor...@ariadne.com> wrote:
>
> Sean Turner <s...@sn3rd.com> 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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
