Re: [lamps] [EXTERNAL] Re: FYI: New Version Notification for draft-housley-lamps-cms-sphincs-plus-00.txt

[Russ Housley <[e-mail]>]

Mike:

It will be much easier to generate an example once the object identifiers are assigned.  I could use placeholder values, but I would rather avoid anyone using them.

Russ


> On Sep 6, 2022, at 10:43 AM, Mike Ounsworth <Mike.Ounsworth=[e-mail]> wrote:
> 
> Awesome.
>  
> My remaining question is whether you are planning to include samples as an appendix?
>  
> ---
> Mike Ounsworth
>  
> From: Russ Housley <[e-mail] <mailto:[e-mail]>> 
> Sent: September 3, 2022 3:39 PM
> To: Mike Ounsworth <[e-mail] <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] Re: [lamps] FYI: New Version Notification for draft-housley-lamps-cms-sphincs-plus-00.txt
>  
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
> Hi Mike.
>  
> I just posted -01 to address your comments.  Thanks for the careful review.
>  
> Russ
>  
>  
> From: Spasm <[e-mail] <mailto:[e-mail]>> on behalf of Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]>>
> Sent: Friday, August 19, 2022 4:35:23 PM
> To: Russ Housley <[e-mail] <mailto:[e-mail]>>; LAMPS <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [lamps] [EXTERNAL] FYI: New Version Notification for draft-housley-lamps-cms-sphincs-plus-00.txt
>  
> I support this document. Here is my review:
> 
> 
> 1.
> Section 2: " The corresponding FIPS public keys are the leaves in k binary trees." Is that a typo? What does the Federal Information Processing Standards have to do with these leaf nodes?
> 
> 2.
> The "WOTS+" acronym should probably be expanded.
> 
> 3.
> The paragraph starting "A SPHINCS+ signature consists of..." is likely rather confusing to someone not already an expert in this. Perhaps some ascii art depicting both the subtree relationships, as well as showing which nodes are involved in a given signature would be illustrative?
> 
> 
> 4.
> The intro paragraph of section 3 says "The AlgorithmIdentifier for an SPHINCS+ public key uses *the* id-alg-sphincs-plus object identifier" ... emphasis on "*THE* id-alg-sphincs-plus OID", implying there's a single one, but in the ASN.1 definitions you have:
> 
>    IDENTIFIER id-alg-sphincs-plus-128
>    IDENTIFIER id-alg-sphincs-plus-192
>    IDENTIFIER id-alg-sphincs-plus-256
> 
> I assume the opening paragraph should read "... uses one of the id-alg-sphincs-plus-* object identifiers"?
> 
> 
> 5.
> I see the asn.1 module has the above OIDs as TBDs; I assume they will eventually cross-reference NIST-assigned OIDs?
> 
> Can I request you stick in temporary OIDs for now for interoperable prototyping?
> 
> 
> 6.
> 
>   "The SPHINCS+ public key value is an OCTET STRING.  (Should we say something more here about the size?)"
> 
> I vote "No", but you should include an appendix with a PEM-encoded pub key, priv key, and signature over the string "The quick brown fox jumps over... you know what" (nod to OQS [footnote1]) for each security level; size can be inferred from the sample data.
> 
> 7.
> Section 4:
> 
>   "   IF (signed attributes are absent)
>       THEN SPHINCS+_Sign(content)
>       ELSE message-digest attribute = Hash(content);
>            SPHINCS+_Sign(DER(SignedAttributes)) "
> 
> Naïve question: is this business of what string you're actually signing not already covered by the CMS spec? Seems a bit odd to have protocol logic in an algorithm spec.
> 
> 
> 8.
> Section 5:
> 
>   " Along with the private key, the implementation MUST keep track of which leaf nodes in the tree have been used.  Loss of integrity of this tracking data can cause a one-time key to be used more than once.  As a result, when a private key and the tracking data are stored on non-volatile media ..."
> 
> 
> Uhh, that seems copy/pasted from a stateful HBS draft, isn't the whole point of SPHICS+ that that not be the case?
> 
> 
> 9.
> Section 5:
> 
>    "A SPHINCS+ tree MUST NOT be used for more than 2^64 signing operations."
> 
> This sentence probably needs expanding; horizontally-scaled instances using copies of the same keys, or backup-and-restore scenarios are gonna make it super annoying to track how many signatures a given key has performed. Needing a centralized usage counter pretty much kills scalability; and requires disaster recovery sites to have unique keys from the primary site.
> 
> Granted, 2^64 is _a lot_, and if you're building a system that's gonna have anywhere near that amount of throughput, then you probably have bigger scalability issues to solve first. Most people will never be anywhere close to 2^64 signatures and are safe to completely ignore this security consideration.
> 
> 
> 
> [Footnote1]: https://urldefense.com/v3/__https://github.com/open-quantum-safe/oqs-provider/blob/b159e4fe659e2d9e57a30435f9d8f5ab11533597/test/oqs_test_signatures.c*L41__;Iw!!FJ-Y8qCqXTj2!fNFjxVSsqGkSgYlxqE25xP6M8hjJgUwUyz3f1c3lFmbxt-CsTRZu5keK-Oqpek1dsyh4hW_sqyYZfCo3eVFmYM3ICkCoTdHLn1Q1ookb1w$ <https://urldefense.com/v3/__https:/github.com/open-quantum-safe/oqs-provider/blob/b159e4fe659e2d9e57a30435f9d8f5ab11533597/test/oqs_test_signatures.c*L41__;Iw!!FJ-Y8qCqXTj2!fNFjxVSsqGkSgYlxqE25xP6M8hjJgUwUyz3f1c3lFmbxt-CsTRZu5keK-Oqpek1dsyh4hW_sqyYZfCo3eVFmYM3ICkCoTdHLn1Q1ookb1w$>  
> ---
> Mike Ounsworth
> 
> -----Original Message-----
> From: Spasm <[e-mail] <mailto:[e-mail]>> On Behalf Of Russ Housley
> Sent: August 19, 2022 2:35 PM
> To: LAMPS <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] [lamps] FYI: New Version Notification for draft-housley-lamps-cms-sphincs-plus-00.txt
> 
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
> 
> ______________________________________________________________________
> 
> A new version of I-D, draft-housley-lamps-cms-sphincs-plus-00.txt
> has been successfully submitted by Russ Housley and posted to the IETF repository.
> 
> Name:           draft-housley-lamps-cms-sphincs-plus
> Revision:       00
> Title:          Use of the SPHINCS+ Signature Algorithm in the Cryptographic Message Syntax (CMS)
> Document date:  2022-08-19
> Group:          Individual Submission
> Pages:          11
> URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-housley-lamps-cms-sphincs-plus-00.txt__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAJ84GYsN$ <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-housley-lamps-cms-sphincs-plus-00.txt__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAJ84GYsN$>
> Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-housley-lamps-cms-sphincs-plus/__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAAqcmAJ0$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-housley-lamps-cms-sphincs-plus/__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAAqcmAJ0$>
> Html:           https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-housley-lamps-cms-sphincs-plus-00.html__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAGRbuc3g$ <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-housley-lamps-cms-sphincs-plus-00.html__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAGRbuc3g$>
> Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sphincs-plus__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAHRh0nHN$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sphincs-plus__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haAHRh0nHN$>
> 
> 
> Abstract:
>   SPHINCS+ is a stateless hash-based signature scheme.  This document
>   specifies the conventions for using the SPHINCS+ stateless hash-based
>   signature algorithm with the Cryptographic Message Syntax (CMS).  In
>   addition, the algorithm identifier and public key syntax are
>   provided.
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haACt-2oqH$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!aqZazqUu1skhae2xlUOrC2SFN3zLh0XQHO3U7OGsZsUEV1iZg0cyf4KxvEn2lIeKq3F6Lf_4BrQg-pRPz3haACt-2oqH$>
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!fNFjxVSsqGkSgYlxqE25xP6M8hjJgUwUyz3f1c3lFmbxt-CsTRZu5keK-Oqpek1dsyh4hW_sqyYZfCo3eVFmYM3ICkCoTdHLn1SnKI0s3g$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!fNFjxVSsqGkSgYlxqE25xP6M8hjJgUwUyz3f1c3lFmbxt-CsTRZu5keK-Oqpek1dsyh4hW_sqyYZfCo3eVFmYM3ICkCoTdHLn1SnKI0s3g$> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!cc7YJMfMb2I4zYvR9FdhJBMhhzE-58A48nGP-mKW-T3gePOhHsyi2wpymzssZP_84b_gDiltt6EnNJGF3GD0QA$>_______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>