Subject: [lamps] Opsdir last call review of draft-ietf-lamps-5480-ku-clarifications-01

From: Tim Chown via Datatracker <[email-masked]>
Date: Thu, 27 Feb 2020 02:46:30 -0800

Reviewer: Tim Chown
Review result: Not Ready

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

The draft updates RFC 5480 to clarify the usage of the keyEncipherment and
dataEncipherment key usage bits in the Subject Public Key Information field for
certificates that support elliptic curve cryptography.  Specifically, it states
that neither of these bits are set for key agreement algorithms.

This is a short document with just a few lines of text that update RFC 5480. 
The rationale for the additional clarification seems clear.

The subject matter of the draft is not a strong area of interest of mine.

Overall, the document is not Ready, primarily due to some key (no pun
intended!) text being missing.

Comments:

Section 1:

It would be good to state whether it is all or some specific key agreement
algorithms.

Section 3:

The way it is written, I would suggest saying “or” for the bits, not “and”.

A specific reference to section 2.1 of RFC 5480 would be good to add, where the
semantics id-ecDH, id-ecMQV and id-ecPublicKey are given.

The first sentence appears to be missing text - a certificate that indicates
what?  I’m guessing this should be id-ecPublicKey?

Tim

---

From: Sean Turner <[email-masked]>
Date: Thu, 27 Feb 2020 12:30:16 -0500

Tim,

Thanks for the review. Responses in-line.

spt

> On Feb 27, 2020, at 05:46, Tim Chown via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Tim Chown
> Review result: Not Ready
> 

It's just the ones defined in RFC 5480 ;)  How about:

OLD:

 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.

NEW:

 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 specified
 therein.

Implemented here:
https://github.com/lamps-wg/draft-ietf-lamps-5480-ku-clarifications/pull/7

> The way it is written, I would suggest saying “or” for the bits, not “and”.

I could see “nor”, but just wanted to use words similar to those used in RFC 5480 and there it uses “and” for the MUST NOT clauses.

> semantics id-ecDH, id-ecMQV and id-ecPublicKey are given.

I will bow to the will of the IESG, but I think this is a bit overkill since I would expect that anybody reading this also read RFC 5480.

> what?  I’m guessing this should be id-ecPublicKey?

drat I was overzealous in my deletions to address an earlier comment - yep id-ecPublicKey.  It’s fixed here:
https://github.com/lamps-wg/draft-ietf-lamps-5480-ku-clarifications/blob/master/draft-ietf-lamps-5480-ku-clarifications.md

---

From: Tim Chown <[email-masked]>
Date: Thu, 27 Feb 2020 18:16:58 +0000

Hi,

In-line...

> On 27 Feb 2020, at 17:30, Sean Turner <[email-masked]> wrote:
> 
> Tim,
> 

Thanks.

> I could see “nor”, but just wanted to use words similar to those used in RFC 5480 and there it uses “and” for the MUST NOT clauses.

OK, if it keeps it consistent that's fine, it just reads a little strangely to me.

> I will bow to the will of the IESG, but I think this is a bit overkill since I would expect that anybody reading this also read RFC 5480.

Well, ops-dir reviewers might not, so maybe it’s just down to me needing to hunt down the reference to check.  Wouldn’t hurt to add it?  But also fine if you don’t.

> https://github.com/lamps-wg/draft-ietf-lamps-5480-ku-clarifications/blob/master/draft-ietf-lamps-5480-ku-clarifications.md

OK, cheers!

Tim

> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call