Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-5480-ku-clarifications-02: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 09:10:24 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-5480-ku-clarifications-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm somewhat amenable to the genart reviewer's concerns that we are
implicitly asserting restrictions in RFC 5480 usage by describing the
algorithms defined by 5480 as "key agreement algorithms"; RFC 5480 does
not seem to use that terminology to refer to id-ecPublicKey.

Section 1

   Cryptography.  As part of these semantics, it defines what
   combinations are permissible for the values of the key usage
   extensions [RFC5280].  [RFC5480] specifies 7 of the 9 values; it

nit: IMO, "key usage extensions" would mean both keyUsage and
extendedKeyUsage, but this document considers only the identified bits
in the original keyUsage extension, and thus the singular "extension"
would be more appropriate.

Section 4

What are the considerations that apply to implementations that follow
RFC 5480 but not this document, e.g., existing implementations that
allow keyEncipherment and/or dataEncipherment?  Specifically, if we are
forbidding their usage, is it because there are vulnerabilities to doing
so?  It seems like we should mention them here.

---

From: Sean Turner <[email-masked]>
Date: Tue, 10 Mar 2020 09:46:42 -0400

Ben,

Sorry - I totally missed this one.

> On Mar 2, 2020, at 12:10 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

Ah keen eye.  Yes this is just for the key usage extension and not the EKU extension.  I will fix that up.

> so?  It seems like we should mention them here.

These additions are about clarifying an omission in the standard. As far I know, there aren’t any vulnerabilities to setting them.

spt