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? > > 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. > > Dale > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
