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

From: Roman Danyliw <[email-masked]>
Date: Mon, 3 Jun 2019 18:33:22 +0000

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 6 Jun 2019 18:10:41 +0000

Thank you Roman. They are all addressed in the latest version https://github.com/csosto-pk/adding-shake-to-pkix/blob/master/draft-ietf-lamps-pkix-shake-current.txt The log of the actions take in regards to every individual comment is here https://github.com/csosto-pk/adding-shake-to-pkix/issues/44 

I am planning to upload the next iteration next Monday unless there is more feedback.

Panos

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Roman Danyliw
Sent: Monday, June 03, 2019 2:33 PM
To: [email-masked]
Subject: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10

Hi!

(2.a) Section 2
   And, the

(2.b) Section 2

(3) Editorial
(3.a) Section 5.1
   In an

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/

(5) Section 5.1.
   They

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./

Regards,
Roman

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 7 Jun 2019 15:52:59 +0000

Hi Panos!

The working revision below addresses all of my comments.  Thank you for these changes (and for making them proactively in the CMS draft as applicable too).

Roman

> From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
> Sent: Thursday, June 06, 2019 2:11 PM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: RE: Second AD Review: draft-ietf-lamps-pkix-shake-10
> 
> Thank you Roman. They are all addressed in the latest version
> https://github.com/csosto-pk/adding-shake-to-pkix/blob/master/draft-ietf-
> lamps-pkix-shake-current.txt The log of the actions take in regards to every
> individual comment is here https://github.com/csosto-pk/adding-shake-to-
> pkix/issues/44
> 
> 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/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/
> 
> (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
> 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
>