Re: [lamps] Auditing HBS state usage

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

Actually, it's not that hard to extract the current state from either an XMSS(^MT) or LMS/HSS signature.

For XMSS and XMSS^MT, the current state is at a fixed place in the signature.

For HSS, the state is scattered in the signature; however it's not *that* hard to retrieve...

So, expressing the current state explicitly in the certificate might make things a bit easier; however it doesn't fundamentally change anything

> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Mike Ounsworth
> Sent: Tuesday, January 31, 2023 10:51 AM
> To: Kampanakis, Panos <kpanos=[e-mail]>; Vaira,
> Antonio <[e-mail]>
> Cc: LAMPS <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: [lamps] Auditing HBS state usage
> 
> [changing title, and adding PQUIP list]
> 
> > - 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?
> 
> Interesting idea!
> Basically, explicitly put the private key state in the signature for easy auditing.
> 
> 
> IMO the list of certificates issued by a CA is already well tracked and audited.
> IMO if we're gonna get ourselves into trouble with over-using a HBS key, it's
> gonna be uses of the CA key for things other than certificate signing; like a
> stuck process that re-issues the same CRL 500 times, or a CA set up for direct
> OCSP or CMP signing with the CA key, or .. who knows .. some CA software
> that uses the CA key for backend TLS connections, or that uses the CA key to
> sign audit records. All things that are completely not a problem today, so
> developers and ops personnel might not even think about them when
> moving to a HBS CA key.
> 
> I like the idea of auditing signatures and private key states, but I think for it to
> be effective you have to audit every signature performed by the HSM to
> make sure you're catching "the weird stuff" that might not otherwise get
> audited. In my mind, this is in the bucket of "quality of life features" that
> HSM vendors will need to build in to their products that support HBS.
> 
> ---
> Mike Ounsworth
> 
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Kampanakis, Panos
> Sent: Tuesday, January 31, 2023 9:28 AM
> To: Vaira, Antonio <[e-mail]>
> Cc: LAMPS <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Re: [lamps] draft-gazdag-x509-hash-sigs-00
> 
> 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 Antonio,
> 
> > - 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?
> 
> Interesting. Indeed, Stateful leaf HBS certs (which will include the tree
> verification path) could be published so auditors or verifiers could attest that
> state was not reused. For the Web there is CT so that would be relatively
> straightforward. But given these certs will not be used for the Web, it
> probably does not help much. In a code signing case, a signer vendor that
> signs its software would need to publish all HBS signatures basically for them
> to be auditable to confirm state/OTS public key was not reused. It would be
> operational overhead for vendors though to make all their signatures
> available.
> 
> There is the threat model that is important here as well. If I am the verifier of
> company X created by company X to verify company X's software signatures,
> do I need to audit company X's signing did not reuse SHBS state? Probably
> not because I trust the signer who is probably auditing internally. But still, a
> published code signing repo of all (Root signatures and ICA issued signatures
> and software signatures) could provide assurance to 3rd parties that want to
> be sure. It still is not perfect because someone could argue that some failure
> scenario while signing may have reused state but the signature did not show
> up in the published signatures, but it certainly raises trust.
> 
> 
> 
> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Vaira, Antonio
> Sent: Tuesday, January 31, 2023 7:33 AM
> To: Kousidis, Stavros <stavros.kousidis=[e-mail]>;
> Kampanakis, Panos <kpanos=[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 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.co
> m/?url=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fspasm*2FDKP
> DfaQZxF5_De9BYuoWsRKp4gM*2F&data=05*7C01*7Cantonio.vaira*40siem
> ens.com*7C42f367be82dd413a64ae08dafd1c9a04*7C38ae3bcd95794fd4add
> ab42e1495d55a*7C1*7C0*7C638100596561496300*7CUnknown*7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0*3D*7C3000*7C*7C*7C&sdata=h25km8rodm9XTku1Chgjffe*2BEm9dOR
> sXhMwrrDhcVzQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OhAlgSN8g$  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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.co
> m/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=
> 05*7C01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd
> 1c9a04*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C63810059656
> 1496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=BzfXk7I
> kssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserved=0__;JSUlJSUlJSUlJSU
> lJSUlJSUlJSUlJQ!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OirgtotNA$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.co
> m/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=
> 05*7C01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd
> 1c9a04*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C63810059656
> 1496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=BzfXk7I
> kssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserved=0__;JSUlJSUlJSUlJSU
> lJSUlJSUlJSUlJQ!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OirgtotNA$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm_
> _;!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm_
> _;!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$
> 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]
> https://www.ietf.org/mailman/listinfo/spasm