> On Mar 5, 2020, at 1:35 PM, Benjamin Kaduk <kaduk@xxxxxxx> wrote: > > On Wed, Mar 04, 2020 at 12:23:43PM -0500, Sean Turner wrote: >> >> >>> On Mar 3, 2020, at 16:09, Alissa Cooper <alissa@xxxxxxxxxx> wrote: >>> >>> Dale, thanks for your reviews. Sean, thanks for your responses. I entered a No Objection ballot. If Dale’s questions can be clarified for non-expert readers, I think that would be good. >>> >>> Alissa >>> >>> >>>> On Mar 1, 2020, at 11:00 PM, Dale R. Worley <worley@xxxxxxxxxxx> wrote: >>>> >>>> Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points >>>> occur to me: >>>> >>>> 1. Introduction >>>> >>>> This document corrects this omission, by updating Section 3 of >>>> [RFC5480] to make it clear that neither keyEncipherment nor the >>>> dataEncipherment key usage bits are set for key agreement algorithms. >>>> >>>> I think it would be more accurate to say something like "neither ... are >>>> set in certificates that specify key agreement algorithms" -- usage bits >>>> are logically a component of a certificate rather than a feature of an >>>> algorithm. >>>> >>>> But it's unclear to me whether id-ecPublicKey is only used in key >>>> agreement certificates. RFC 5480 states that if the cert uses id-ecDH >>>> or id-ecMQV and provides keyUsage, then keyAgreement must be set. So >>>> it's clear that certs with id-ecDH or id-ecMQV are key agreement certs. >>>> But RFC 5480 says that if the cert lists id-ecPublicKey, then >>>> keyAgreement is optional. That suggests to me that some certs can use >>>> id-ecPublicKey without being key agreement certs. In turn, section 1 of >>>> this I-D suggests the I-D is not intended to apply to those certs, but >>>> section 3 seems to apply to them anyway. >>>> >>>> To try to distill it to one sentence: Can id-ecPublicKey appear in >>>> certs that are not for key agreement, and if so, are keyEncipherment and >>>> dataEncipherment allowed in the keyUsage of those certs? >>>> >>>> 3. Updates to Section 3 >>>> >>>> If the keyUsage extension is present in a certificate that indicates >>>> in SubjectPublicKeyInfo, then following values MUST NOT be present: >>>> ---^ >>>> >>>> Is "id-ecPublicKey" missing here? >> >> Yes - The OPSDIR review noted my took quick to submit. It’s fixed in this version: >> >> https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >> >>>> If the keyUsage extension is present in a certificate that indicates >>>> id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following >>>> values also MUST NOT be present: >>>> >>>> Is it a fact that all certificates with these three algorithms are >>>> certificates for key agreement? If so, it would be nice to state that >>>> either in section 3 or section 1, to show how section 3 is connected >>>> with "for key agreement algorithms" in section 1. Otherwise, the >>>> connection between the two requires information that is stated >>>> elsewhere. >> >> To address this, I ended up making the following tweaks in s1: >> >> This document corrects this omission, by updating Section 3 of >> [RFC5480] to make it clear that neither keyEncipherment nor the >> dataEncipherment key usage bits are set for key agreement algorithms >> defined therein. The additions are to be made to the end of >> Section 3. >> >> So, there’s a link from 5480 s3 where the three algorithms are defined to this document’s s3. > > I don't think that link fully closes the question of whether id-ecPublicKey > is defined to be a"key agreement algorithm" or not. That identifier is used for key agreement and signature. The key usage extension can restrict it to one or the other if desired. The point of this update is that it is not ever a key encipherment or data encipherment algorithm. Russ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
