Subject: [Gen-art] Genart last call review of draft-ietf-lamps-pkix-shake-08

From: Joel Halpern via Datatracker <[email-masked]>
Date: Sat, 30 Mar 2019 02:55:23 -0700

Reviewer: Joel Halpern
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-pkix-shake-08
Reviewer: Joel Halpern
Review Date: 2019-03-30
IETF LC End Date: 2019-04-10
IESG Telechat date: Not scheduled for a telechat

Summary: This document is almost ready for publication as a Proposed Standard

Major issues:
    One of the key points of this RFC seems to be to assign the identifiers for
    the use of the two SHAKE variants.  It is thus confusing that the
    identifiers end with "TBD", and thus are not defined in this document.

Minor issues:
    The algorithm identifiers are label as TVD.  There are at least two values
    (one for SHAKE128 and one for SHAKE256) with each used in two context
    (RSASSA-PSS and ECDSA).  It would be helpful if the two (or four)
    identifiers were labeled clearly TBD1 and TBD2 (and possibly TBD3 and TBD4).

Nits/editorial comments:
    There is one use of "SHAKES" as the plural of SHAKE in section 5.1.1.  All
    other uses are "SHAKEs", which seems to be correct.

---

From: Russ Housley <[email-masked]>
Date: Sat, 30 Mar 2019 20:21:20 -0400

> On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Joel Halpern

They will be assigned by NIST once they are sure that these are the identifiers that we want.  This is much the same as we do when IANA is ti assign the identifier.

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 31 Mar 2019 07:28:36 +0200

Maybe a note that the assignment will take place once the drafts are 
approved, and that the RFC should coordiante with the authors and NIST 
on this?  (I presume we have done this before, and we do not have the 
problem we have in some other cases of "no number until RFC" / "no RFC 
until number".)

Yours,
Joel