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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Feb 20, 2020, at 21:03, Dale R. Worley <worley@xxxxxxxxxxx> wrote:
> 
> Sean Turner <sean@xxxxxxxxx> 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
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux