Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-pkix-shake-11: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 24 Jun 2019 02:56:52 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-lamps-pkix-shake-11: 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-pkix-shake/

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

I just have some editorial comments, all minor:

General:
Whenever you use "respectively", throughout the document, it needs a comma
before; it also needs a comma after unless it's at the end of a sentence. 
There are also some cases where you use "respectively" incorrectly, and I've
noted those below.

-- Section 2 --
A set of nits:

In "several cryptographic algorithms which use", make it "that" instead of
"which"... better anyway, but especially with the subsequent "which" (that
should have a comma before it).

You need a comma after "SHA3-512".

"d-bits-long" needs both hyphens.

"second-preimage-resistance" is a compound modifier and needs two hyphens (two
instances here).

The comma after "And" doesn't belong.

-- Section 5.1 --

   Conforming
   client implementations that process RSASSA-PSS or ECDSA with SHAKE
   signatures when processing certificates and CRLs MUST recognize the
   corresponding OIDs.

I find the double "process" a little hard to parse.  Do you mean this?:

NEW
   Conforming
   client implementations that process certificates and CRLs using RSASSA-PSS
   or ECDSA with SHAKE MUST recognize the corresponding OIDs.
END

-- Section 5.1.1 --

   The hash algorithm to hash a message being signed and the hash
   algorithm as the mask generation function used in RSASSA-PSS MUST be
   the same, SHAKE128 or SHAKE256 respectively.

There's something wrong here, and I think it's the "respectively."  I think
you're saying that the two algorithms must be the same as each other, but
"respectively" says that the first must be 128 and the second must be 256.  I
think you want this instead:

NEW
   The hash algorithm to hash a message being signed and the hash
   algorithm as the mask generation function used in RSASSA-PSS MUST be
   the same: both SHAKE128 or  both SHAKE256.
END

The "respectively" in the sentence following that is also wrong; please
rephrase that one as well (and "output length" should NOT be hyphenated).

In the final paragraph, "The RSASSA-PSS saltLength MUST be 32 or 64 bytes
respectively," is wrong (you can't really inherit the context from another
paragraph); you need to say something like, "The RSASSA-PSS saltLength MUST be
32 or 64 bytes for id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256,
respectively."  Probably better to say, "The RSASSA-PSS saltLength MUST be 32
bytes for id-RSASSA-PSS-SHAKE128 or 64 bytes for id-RSASSA-PSS-SHAKE256."

-- Section 5.1.2 --

   It is RECOMMENDED that conforming CA implementations that generate
   ECDSA with SHAKE signatures in certificates or CRLs generate such
   signatures with a deterministically generated, non-random k in
   accordance with all the requirements specified in [RFC6979].

Take or leave this one as you please, but I find the passive voice both more
confusing and unnecessary in this sentence (because you do have a clear subject
already), and I think this is easier to read:

NEW
   Conforming CA implementations that generate ECDSA with
   SHAKE signatures in certificates or CRLs SHOULD generate such
   signatures with a deterministically generated, non-random k in
   accordance with all the requirements specified in [RFC6979].
END

Later in that paragraph, two instances of "these standards" and one of "the
standards" seem to refer to [X9.62] and [SEC1], so I think it should say "those
standards" (to make it clear that you're not talking about any standards
defined in *this* document).

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 24 Jun 2019 17:01:44 +0000

Thank you Barry.

I logged the issue here https://github.com/csosto-pk/adding-shake-to-pkix/issues/46 and the fixes to your feedback are documented here https://github.com/csosto-pk/adding-shake-to-pkix/issues/46#issuecomment-505091119 The diffs are in https://github.com/csosto-pk/adding-shake-to-pkix/commit/ca1c073867c403e0ed0ed0f84e394ea9757bc37d 

I will reupload the docs at the end of the week. 

Rgs,
Panos

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Barry Leiba via Datatracker
Sent: Monday, June 24, 2019 5:57 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Russ Housley <[email-masked]>; [email-masked]; [email-masked]
Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-pkix-shake-11: (with COMMENT)

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

General:
Whenever you use "respectively", throughout the document, it needs a comma before; it also needs a comma after unless it's at the end of a sentence. 
There are also some cases where you use "respectively" incorrectly, and I've noted those below.

-- Section 2 --
A set of nits:

In "several cryptographic algorithms which use", make it "that" instead of "which"... better anyway, but especially with the subsequent "which" (that should have a comma before it).

"second-preimage-resistance" is a compound modifier and needs two hyphens (two instances here).

-- Section 5.1 --

   Conforming

NEW
   Conforming

-- Section 5.1.1 --

There's something wrong here, and I think it's the "respectively."  I think you're saying that the two algorithms must be the same as each other, but "respectively" says that the first must be 128 and the second must be 256.  I think you want this instead:

NEW

The "respectively" in the sentence following that is also wrong; please rephrase that one as well (and "output length" should NOT be hyphenated).

In the final paragraph, "The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively," is wrong (you can't really inherit the context from another paragraph); you need to say something like, "The RSASSA-PSS saltLength MUST be
32 or 64 bytes for id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256, respectively."  Probably better to say, "The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 or 64 bytes for id-RSASSA-PSS-SHAKE256."

-- Section 5.1.2 --

Take or leave this one as you please, but I find the passive voice both more confusing and unnecessary in this sentence (because you do have a clear subject already), and I think this is easier to read:

NEW

Later in that paragraph, two instances of "these standards" and one of "the standards" seem to refer to [X9.62] and [SEC1], so I think it should say "those standards" (to make it clear that you're not talking about any standards defined in *this* document).

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