[lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10

[Roman Danyliw <[e-mail]>]

Hi!

As a document I inherited in the "IESG:: Waiting for Writeup Internet-Drafts", I conducted a second AD review on draft-ietf-lamps-pkix-shake-10.  I have the following feedback:

(1) Header. Per idnits:    == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list.

s/Updates: RFC3279/Updates: 3279/

(2) Additional References Needed

(2.a) Section 2
   And, the
   corresponding collision and second preimage resistance strengths for
   SHAKE256 are min(d/2,256) and min(d,256) bits respectively.

Recommend you cite Section A.1 of [SHA3] as the source of these security strength metrics.

(2.b) Section 2
   A SHAKE can be used as the message digest function (to hash the
   message to be signed) in RSASSA-PSS and ECDSA  and as the hash in the
   mask generating function in RSASSA-PSS.

Provide a reference on first use for RSASSA-PSS [RFC8017] and ECDSA [X9.62]

(3) Editorial
(3.a) Section 5.1
   In an
   X.509 certificate a signature is encoded  with an algorithm identifier
   in the signatureAlgorithm attribute and a signatureValue  that
   contains the actual signature.

s/signatureValue/signatureValue attribute/

(3.b) Section 5.1.1.  Add commas between terms.  

s/hash and mask generating algorithm and trailer and salt are embedded in the OID definition/
hash, mask generating algorithm, trailer and salt are embedded in the OID definition/

(3.c) Section 5.1.1.  Define the acronym MGF on first use

s/mask generation function/mask generation function (MGF)/

(3.d) Section 5.1.  Duplicate word.  s/section Section 4/Section 4/

(4) Section 5.1.  The ASN.1 blob of Certificate is inserted in the text without citation or explanation.  It seems like the paragraph prior to it should make explicit reference to it (as it cites the elements).

(5) Section 5.1.
   They
   MAY also generate such signatures in accordance with all other
   recommendations in [X9.62] or [SEC1] if they have a stated policy
   that requires conformance to these standards.  These standards may
   have not specified SHAKE128 and SHAKE256 as hash algorithm options.
   However, SHAKE128 and SHAKE256 with output length being 32 and 64
   octets respectively are substitutions for 256 and 512-bit output hash
   algorithms such as SHA256 and SHA512 used in the standards.

I recommend being more precise in this text.

s/These standards may have not specified SHAKE128 and SHAKE256 as hash algorithm options./
These standards have not specified SHAKE128 and SHAKE256 as hash algorithm options./

Per "SHAKE128 and SHAKE256 with output length being 32 and 64 octets respectively are substitutions for ... SHA256 and SHA 512", what does substitutions mean in this case?  Similar output size or cryptographic strength?

Regards,
Roman