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