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

[Russ Housley <[e-mail]>]

Mike:

We just tried to put out a placeholder.  As you know, we do not want to get too far ahead of NIST, but we do want to create a home for the specifications that build upon the yet-to-be-published NIST standards.  We made some guesses that will need to be adjusted.

We expect to use the NIST assigned OIDs.  Regarding you comment 5, the LAMPS charter does not allow us to assign temporary OISs (because they never really go away.

Together, these points are the reason for the first paragraph of the I-D:

   NOTICE: This document will be adjusted to match the SPHINCS+
   specification that is published by NIST.  Until that happens, just
   about everything in this document is likely to change.

That said, the authors will look at each of the comments to see which ones are reasonable to address now.

Regarding comment number 7, we have seen many people get confused about this part of signed-data.  That is the reason for the reminder in a algorithm-specific document.  It came up in the review of Section 5 of RFC 8708, and the same text is used again here.

Regarding comment 8: Oops, the review by me and my co-authors missed that one...  

Regarding comment 9: There are many ways to handle that situation, and this specification needs to warn about it, but it should not pick among the potential ways to handle it.  That said, it might be good to say something about the consequences of exceeding that limit.

Russ


> On Aug 19, 2022, at 5:35 PM, Mike Ounsworth <[e-mail]> wrote:
> 
> 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://github.com/open-quantum-safe/oqs-provider/blob/b159e4fe659e2d9e57a30435f9d8f5ab11533597/test/oqs_test_signatures.c#L41
> ---
> Mike Ounsworth
> 
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Russ Housley
> Sent: August 19, 2022 2:35 PM
> To: LAMPS <[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$
> Status:         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$
> Htmlized:       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]
> 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.