> 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
