Re: [lamps] draft-gazdag-x509-hash-sigs-00

["Vaira, Antonio" <[e-mail]>]

Dear Stavros, Dear Panos,

I hope I am not intruding this conversation, I would like to add a couple of personal considerations:

- I believe that we will also need to have "stateful HBS ICAs", to at least sign "stateful HBS code-signing certificates". This would allow a relying party to validate the code-signing certificates, and its associated certificate chain, by verifying only one type of digital signatures, which in this case would be a stateful HBS scheme. This type of ICAs may be handled as RootCA, so probably there is not much to add to the security considerations.
- my understanding of stateful HBS schemes is that the state of the private key can be uniquely identified by the authentication path that is part of the signature. Could we think to derive a unique value, out of this authentication path and embed it into a certificate field? Maybe such certificate can be further published, for example on CT, to allow public scrutiny of the CA operations?
- on a more generic note, the recent publication of CNSA 2.0, despite applying only to NSS, may trigger other regulatory bodies, which may be transversal to the scope of NSS, to adopt similar guidelines. Therefore I think we might have to deal with stateful HBS sooner than later.

- @Stavros: it would be very interesting to know more about how you plan to handle the requirements from §7 of NIST SP 800-208.
    > in my understanding, to fulfil the requirements set forth in this section one would that initializing several hypertrees on different HSMs. One or more HSMs may be used immediately and the remaining should be securely stored for later use (as disaster recovery mechanism for example). I think this approach might prove to be quite cumbersome, at least over a long period of time (which is intended use of stateful HBS).
    > do you see additional approaches that would allow to comply with the requirements from §7 of NIST SP 800-208?


Many thanks
Antonio Vaira

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Kousidis, Stavros
Sent: Monday, 23 January 2023 09:33
To: Kampanakis, Panos <kpanos=[e-mail]>
Cc: LAMPS <[e-mail]>; [e-mail]
Subject: Re: [lamps] draft-gazdag-x509-hash-sigs-00

Dear Pano,

thank you for your comments and suggestions, and sorry for the late reply.

The typical use case we have in mind are root and (potentially also subordinate) CAs which are using an HSM for cert signing that ensures the secure handling of the state. When discussing this in the security considerations we would also stress on NISTs proposal to use "Distributed Multi-Tree Hash-Based Signatures" (see NIST SP 800-208 §7) as a design to further ensure that states are handled appropriately.

We have tracked the other use cases you mentioned as an issue in in our repository. I think Stefan Gazdag has some experience here and we will discuss how to incorporate your suggestions in the security considerations.

Best
Stavros

-----Ursprüngliche Nachricht-----
Von: Kampanakis, Panos <kpanos=[e-mail]> 
Gesendet: Donnerstag, 29. Dezember 2022 18:23
An: Kousidis, Stavros <[e-mail]>
Cc: LAMPS <[e-mail]>; [e-mail]
Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00

One more comment regarding draft-gazdag-x509-hash-sigs. 

Stateful HBS had come up previously for X.509 and some participants voiced serious concerns https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspasm%2FDKPDfaQZxF5_De9BYuoWsRKp4gM%2F&data=05%7C01%7Cantonio.vaira%40siemens.com%7C42f367be82dd413a64ae08dafd1c9a04%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638100596561496300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h25km8rodm9XTku1Chgjffe%2BEm9dORsXhMwrrDhcVzQ%3D&reserved=0 A summary of the counter-arguments could be that CAs have messed up before, how can we rest assured they will not reuse state. 

I think your argument for Stateful HBS in this draft is only for root CAs which sign a few ICAs and then go to sleep and rarely wake up. Maybe another use is for code-signing EKU certs where the signer controls its signing process and the verifiers trust it.  The draft also mentions subordinate CA certificates. I don't think these are good use-cases for stateful HBS. I would suggest for the draft to clearly stress the potentially use-cases for Stateful HBS. Also I suggest for the security considerations section to stress the importance and how you envision these use-cases will be able to address the state concern. For example a Root CA uses an HSM and signs very few ICA certs and then goes offline. Another example is a code-signer keeps track of all its signatures and can go back and attest the state was not reused periodically and its verifiers usually trust the signer. Another one could be the state look ahead where you retrieve x states and change your pointer before you even start signing anything.

 

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Kousidis, Stavros
Sent: Saturday, December 24, 2022 12:11 AM
To: Russ Housley <[e-mail]>
Cc: LAMPS <[e-mail]>; [e-mail]
Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Dear Russ,

thank you for the information.

In the next version we will adopt the "OCTET STRING" definition of RFC 8708 for HSS and apply this also to XMSS/XMSS^MT. The same applies to SPHINCS+ where we will adopt the definition of "draft-ietf-lamps-cms-sphincs-plus-01".

Best
Stavros

-----Ursprüngliche Nachricht-----
Von: Russ Housley <[e-mail]>
Gesendet: Freitag, 23. Dezember 2022 18:12
An: [e-mail]
Cc: LAMPS <[e-mail]>
Betreff: [lamps] draft-gazdag-x509-hash-sigs-00

Dear I-D Authors:

RFC 8708 has this definition:

     HSS-LMS-HashSig-PublicKey ::= OCTET STRING

This will carry the bytes as defined in RFC 8554.

draft-gazdag-x509-hash-sigs-00 says:

    HSS-HashSig-PublicKey ::= SEQUENCE {
       levels     OCTET STRING, -- number of levels L
       tree       OCTET STRING, -- typecode of top-level LMS tree
       ots        OCTET STRING, -- typecode of top-level LM-OTS
       identifier OCTET STRING, -- identifier I of top-level LMS key pair
       root       OCTET STRING  -- root T[1] of top-level tree
    }

This will produce a different byte string than RFC 8554.  I think this is a problem.  There should only be one way to encode the HSS/LMS public key.

Russ

_______________________________________________
Spasm mailing list
[e-mail]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Cantonio.vaira%40siemens.com%7C42f367be82dd413a64ae08dafd1c9a04%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638100596561496300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BzfXk7IkssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8%3D&reserved=0

_______________________________________________
Spasm mailing list
[e-mail]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Cantonio.vaira%40siemens.com%7C42f367be82dd413a64ae08dafd1c9a04%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638100596561496300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BzfXk7IkssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8%3D&reserved=0