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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
