Subject: [lamps] AD Review: draft-ietf-lamps-cms-shakes-10

From: Roman Danyliw <[email-masked]>
Date: Wed, 12 Jun 2019 20:33:46 +0000

Hi!

The following is my AD review of draft-lamps-cms-shakes-10:

(1) Section 5.  Isn't the request to IANA for OID assignment for id-RSASSA-PSS-SHAKE128, id-RSASSA-PSS-SHAKE256, id-ecdsa-with-shake128, id-ecdsa-with-shake256 a duplicate of what is in draft-ietf-lamps-pkix-shake?

==[ Editorial 

(2) Editorial feedback on draft-ietf-lamps-pkix-shake applies here too:

** Header.  Drop "RFC" from the updates line in the header - s/RFC3370/3370/
** Section 1.  Adding the reference of "(Appendix A.1 [SHA3])" for the sentence about "second preimage resistance strengths"
** Section 4.2.1.  s/hash and mask generating algorithm and trailer and salt are/hash, mask generating algorithm,  trailer, and salt are/
** Section 4.2.1.  Expand MGF on first use (which is at the end of Section 2 but not as an acronym)

(3) Section 3.  Per the EDNOTE, I agree.  It seems confusing to say that id-RSASSA-PSS-SHAKE128, id-RSASSA-PSS-SHAKE256, id-ecdsa-with-shake128, id-ecdsa-with-shake256 are being defined in this draft.  Why not include a reference to draft-ietf-lamps-pkix-shake (the same way there is one to shake-nist-oids)?
(3) Section 3.  Per id-KmacWithSHAKE128/256, provide a reference on where these were defined and reuse the language used above that "we include them here for convenience."

(4) Section 4.2.  Recommend precision in naming the fields:

s/Signature values are located in the SignerInfo signature field of SignedData and countersignature/
 Signature values are located in the SignerInfo signature field of SignedData content type and countersignature attribute./

(5) Section 4.2.1.  There appears to be an extra use of the word hash in this sentence:

s/The hash algorithm to hash a message being signed and the hash and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 respectively./
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.   

Thanks,
Roman

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Jun 2019 17:01:58 -0400

> (1) Section 5.  Isn't the request to IANA for OID assignment for id-RSASSA-PSS-SHAKE128, id-RSASSA-PSS-SHAKE256, id-ecdsa-with-shake128, id-ecdsa-with-shake256 a duplicate of what is in draft-ietf-…

Yes, this is the same request.  The OIDs, once assigned, need to appear in both documents.

Russ

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 14 Jun 2019 19:11:12 +0000

Hi Roman,

Thank you again. All addressed. The diffs are here https://github.com/csosto-pk/adding-shake-to-pkix/commit/0efc652142d355944585b4c6d8e7d512a68d69b9 

The specific details of the fixes are in the github issue https://github.com/csosto-pk/adding-shake-to-pkix/issues/45#issuecomment-501801167 

One basic comment is that the OIDs defined in the PKIX draft are reused in this one, but I don't request them in the IANA considerations sections any more since they will be defined in the other RFC already. So let's try to publish the PKIX one first and the CMS after that. 

I am planning upload this new iteration early next week unless there are more comments. 

Rgs,
Panos

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Roman Danyliw
Sent: Wednesday, June 12, 2019 4:34 PM
To: [email-masked]
Cc: Roman Danyliw <[email-masked]>
Subject: [lamps] AD Review: draft-ietf-lamps-cms-shakes-10

Hi!

==[ Editorial 

s/Signature values are located in the SignerInfo signature field of SignedData and countersignature/  Signature values are located in the SignerInfo signature field of SignedData content type and countersignature attribute./

Thanks,
Roman

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