Re: [Gen-art] draft-ietf-lamps-5480-ku-clarifications-01

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@ariadne.com> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art