From nobody Thu Mar 2 23:22:38 2023 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635D8C14F731; Thu, 2 Mar 2023 23:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.995 X-Spam-Level: X-Spam-Status: No, score=-6.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=bsi.bund.de header.b="TTiXeQV4"; dkim=pass (2048-bit key) header.d=bsi.bund.de header.b="FgEc9KsO" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9O8e1VXxtw8; Thu, 2 Mar 2023 23:22:31 -0800 (PST) Received: from m3-bn.bund.de (m3-bn.bund.de [77.87.228.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8613C14CEE3; Thu, 2 Mar 2023 23:22:29 -0800 (PST) Received: from m3-bn.bund.de (localhost [127.0.0.1]) by m3-bn.bund.de (Postfix) with ESMTP id EEC756716E2; Fri, 3 Mar 2023 08:22:26 +0100 (CET) Received: (from localhost) by m3-bn.bund.de (MSCAN) id 4/m3-bn.bund.de/smtp-gw/mscan; Fri Mar 3 08:22:26 2023 X-NdB-Source: NdB DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=bsi.bund.de; s=211014-e768-ed25519; t=1677828133; bh=HzA70km57cZ/9xEibPCNo4Z47FHyfDiI+QhcnOFUy0Q=; h=From:To:CC:Subject:Date:References:In-Reply-To:Content-Type: MIME-Version:Autocrypt:Cc:Content-Transfer-Encoding:Content-Type: Date:From:In-Reply-To:Mime-Version:Openpgp:References:Reply-To: Resent-To:Sender:Subject:To; b=TTiXeQV4iwsr5loxpmsA8YfauuYW2tAi1tbKjDu2HjC3fJyunCRcKsdpyOJ4J+X/+ yJWwjK6HMbjt9lwr7LkAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsi.bund.de; s=211014-e768-rsa; t=1677828133; bh=HzA70km57cZ/9xEibPCNo4Z47FHyfDiI+QhcnOFUy0Q=; h=From:To:CC:Subject:Date:References:In-Reply-To:Content-Type: MIME-Version:Autocrypt:Cc:Content-Transfer-Encoding:Content-Type: Date:From:In-Reply-To:Mime-Version:Openpgp:References:Reply-To: Resent-To:Sender:Subject:To; b=FgEc9KsORyThtJ8FDMhBF8k/ZwxFwY8IZ+x6gfDAUfBsWCQcJd8EXQBdFVhaq2h1h ENzcKGsVhKBjsEGjvJHmHX0/3qD3iK/9gzEk4CP00NAdgVNZ1JVqELYSay5EitHyGh f1s+TPaJiDHFpMdggaUO2jhz4PA+eTkjJrcuuUGz6gchq4wCwhGqzipmbl11nMJeHk xDd7tuKALzgjtuglys/1XkqKwTzfUaJEIFrOthGsrdmijEcMAFXTtKHFym+w3iZ0vY QNqGebuoALzKoJ7v74MEZiJxXhqBL0U75S+r7x906uLyHem4OEU24vmk1WswIqLrZZ 0WpjPhI8H1DAA== X-P350-Id: 200d012a58b9f8ca X-Virus-Scanned: amavisd-new at bsi.bund.de From: "Kousidis, Stavros" To: "Vaira, Antonio" CC: LAMPS , "draft-gazdag-x509-hash-sigs.authors@ietf.org" , "pqc@ietf.org" , "Kampanakis, Panos" Thread-Topic: [lamps] draft-gazdag-x509-hash-sigs-00 Thread-Index: AQHZF1Y2AY86abJjRk2uTqea+ZJ11q58fj4AgAioM4CAJrZlAIAMzD3ggABMBqCAAT2RgIAu3LhA Date: Fri, 3 Mar 2023 07:21:56 +0000 Message-ID: <402e8a7be79549cc9e1965a7a0dd6316@bsi.bund.de> References: <08C331ED-453C-4812-955A-F2161B960329@vigilsec.com> <3439f87bb3bb4a199f706b791cba6b6a@bsi.bund.de> <6828097d5b5b4beabb0c4243b150077f@amazon.com> <99a43b5f4620438a9cb7ca539f70dbcb@bsi.bund.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Old-x-esetresult: clean, is OK Old-x-esetid: 37303A29F7A5EA54627564 Content-Type: multipart/alternative; boundary="_000_402e8a7be79549cc9e1965a7a0dd6316bsibundde_" MIME-Version: 1.0 X-EsetResult: clean, is OK X-EsetId: 37303A29537AD454627564 X-Rusd: domwl, Pass through domain bsi.bund.de X-Rurd: query_ok, Pass through domain siemens.com Archived-At: Subject: Re: [lamps] draft-gazdag-x509-hash-sigs-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2023 07:22:36 -0000 --_000_402e8a7be79549cc9e1965a7a0dd6316bsibundde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Antonio, it has been a while but let me add my thoughts to your proposal. The problems are: 1) You don't solve the distribution/backup problem while you are signi= ng with a specific tree during your first X years. 2) Your signature sizes grow over time with every subtree you add beca= use of the additional OTS in the newly established multi-tree. 3) You change the public key once you add a subtree. Let me elaborate on point 3) as this is something you certainly don't want: HSS encodes the number of levels in the public key (see =A76.1 in RFC8554) = so that you know how to verify a signature when you receive it (see =A76.3 = in RFC8554). Likewise XMSS/XMSS^MT encodes an identifier specifying the (mu= lti-)tree (see =A74.1.7 and =A74.2.2 in RFC8391). This means that your trus= t anchor changes (e.g. X.509 certificate) and you have to distribute it aga= in. Best Stavros Von: Vaira, Antonio Gesendet: Mittwoch, 1. Februar 2023 13:31 An: Kousidis, Stavros Cc: LAMPS ; draft-gazdag-x509-hash-sigs.authors@ietf.org; p= qc@ietf.org; Kampanakis, Panos Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00 Hi Stavros, My interpretation is that the SEED should be indeed considered as "private = keying material" therefore I am also concerned with the point b) you raised= . I would also add, even if we theoretically do not concern ourselves with th= e operational/cost overheads of having a lot of HSMs initialized and put in= storage, can we realistically be sure that by the time we will need these = HSMs they will all boot? The timeline I have in mind is 20+ years (realisti= c RootCA lifetime) and I am not sure if an HSM, even if stored in "perfect = conditions", will still boot after 20 years. For the reason above, I was thinking about an alternative approach that can= be summarized with the following steps: 1. the tree #1 is generated, with a height that is proportional to the requ= ired number of signatures and its leaves can be used to perform digital sig= natures, 2. after X years, for example 5 years, the last leaf of tree #1 is used to = sign a new subtree, tree #2, that corresponds to OTS private keys that are = initialized in a new HSM, 3. repeat step 2 after every X years, initializing each time new OTS privat= e keys in a new HSM. After 3 iterations the HBS state would look like the following: root - / \ / \ / \ / \ / \ / \ / \ ----------------- | | | | | | sig1 sig2 ... - / \ / \ / \ / \ / \ / \ / \ ----------------- | | | | | | sig1 sig2 ... - / \ / \ / \ / \ / \ / \ / \ ----------------- | | | | | | | | sig1 sig2 ... ... The first 2 trees can be considered as no longer usable, even if there are = still unused leaves, because their corresponding OTS private keys are in HS= Ms which may no longer be available. The OTS keys associated to the tree co= rresponds are generated and stored on a "fresh" HSM. Without considering redundancy requirements (also not considered in the ste= ps above for sake of simplicity), with this approach it would be possible t= o use one HSM at the time and replace it after X years with a new one (avoi= ding to initialize HSMs and securely store them) and it would not be needed= to redistribute the root to all the relying parties. But the signature wou= ld increase of a fixed number of bytes (i.e., the signature performed over = the root of the new subtree using the last OTS private key of the parent tr= ee) every X years. What do you think? Thanks Antonio -----Original Message----- From: Kousidis, Stavros > Sent: Wednesday, 1 February 2023 08:54 To: Vaira, Antonio (T CST SEA-DE) > Cc: LAMPS >; draft-gazdag-x509-hash-s= igs.authors@ietf.org; = pqc@ietf.org; Kampanakis, Panos > Subject: AW: [lamps] draft-gazdag-x509-hash-sigs-00 Dear Antonio, I feel that we will have to take up a discussion on practical issues that C= As face when using stateful HBS in our draft. This already came up in comme= nts that Panos sent, see here: https://eur01.safelinks.protection.outlook.c= om/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspasm%2FhUe6bBq= GoJhyu5vObbYJMbtCEDw%2F&data=3D05%7C01%7Cantonio.vaira%40siemens.com%7Cd988= d9a6eb5d4ac79f4808db042989a7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6= 38108348674728031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM= zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3D%2BjO3%2Bi0NfdqHm= SaEJ9BCbpE3Hv8xwsaoVfnkuWfwfVg%3D&reserved=3D0 The =A77 of NIST SP 800-208 elaborates on distributed multi-trees instantia= ted via cryptographic modules. It is stated there that "due to the risks associated with copying OTS keys, this recommendation pro= hibits exporting private keying material (Section 8)." I do ask myself if the "private keying material" described here includes th= e secret value "SEED" that can be used to pseudorandomly generate an LMS or= XMSS private key (see Appendix A in RFC8554 or analoguously =A73.1.7 in RF= C8391). On the one hand I would say yes, but: a) As I read NIST SP 800-208 the requirements described in =A77 and =A78 ar= e primarily concerned with the OTS private keys (that is when the counter c= omes into play along with the SEED). b) I cannot imagine how one can practically address the "do not export priv= ate keying material" requirement if the SEED is included here. This would i= mply your interpretation that at key generation time one would have to put = a lot of sleeping HSMs on the shelf. As a concrete example, imagine aiming = for 2^20 signatures and instantiating HSS with two levels, height 10 on the= top level and height 20 on the bottom level. The top level covering the di= stribution/redundancy aspect. That would mean that your shelf is packed wit= h 2^10 HSMs holding the bottom level LMS instances. You could aim for heigh= t 5 on the top level tree, but still 2^5 HSMs are not practical in my perso= nal opinion. @All: May I ask, how the above mentioned requirement about exporting privat= e keying material has to be interpreted? However, I (personally) still think that stateful HBS should be available a= s an option in our ecosystems. Best Stavros -----Urspr=FCngliche Nachricht----- Von: Vaira, Antonio > Gesendet: Dienstag, 31. Januar 2023 13:33 An: Kousidis, Stavros >; Kampanakis, Panos > Cc: LAMPS >; draft-gazdag-x509-hash-s= igs.authors@ietf.org Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00 Dear Stavros, Dear Panos, I hope I am not intruding this conversation, I would like to add a couple o= f 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 certifi= cate 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 R= ootCA, 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 authent= ication path and embed it into a certificate field? Maybe such certificate = can be further published, for example on CT, to allow public scrutiny of th= e CA operations? - on a more generic note, the recent publication of CNSA 2.0, despite apply= ing only to NSS, may trigger other regulatory bodies, which may be transver= sal 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 =A77 of NIST SP 800-208. > in my understanding, to fulfil the requirements set forth in this sec= tion one would that initializing several hypertrees on different HSMs. One = or more HSMs may be used immediately and the remaining should be securely s= tored for later use (as disaster recovery mechanism for example). I think t= his approach might prove to be quite cumbersome, at least over a long perio= d of time (which is intended use of stateful HBS). > do you see additional approaches that would allow to comply with the = requirements from =A77 of NIST SP 800-208? Many thanks Antonio Vaira -----Original Message----- From: Spasm > On Beha= lf Of Kousidis, Stavros Sent: Monday, 23 January 2023 09:33 To: Kampanakis, Panos > Cc: LAMPS >; draft-gazdag-x509-hash-s= igs.authors@ietf.org 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 subordi= nate) CAs which are using an HSM for cert signing that ensures the secure h= andling of the state. When discussing this in the security considerations w= e would also stress on NISTs proposal to use "Distributed Multi-Tree Hash-B= ased Signatures" (see NIST SP 800-208 =A77) as a design to further ensure t= hat states are handled appropriately. We have tracked the other use cases you mentioned as an issue in in our rep= ository. I think Stefan Gazdag has some experience here and we will discuss= how to incorporate your suggestions in the security considerations. Best Stavros -----Urspr=FCngliche Nachricht----- Von: Kampanakis, Panos > Gesendet: Donnerstag, 29. Dezember 2022 18:23 An: Kousidis, Stavros > Cc: LAMPS >; draft-gazdag-x509-hash-s= igs.authors@ietf.org 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=3Dhttp= s%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspasm%2FDKPDfaQZxF5_De9BYuoWs= RKp4gM%2F&data=3D05%7C01%7Cantonio.vaira%40siemens.com%7Cd988d9a6eb5d4ac79f= 4808db042989a7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638108348674728= 031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1= haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3DWedj6fJ8p564lYwaDHXQAjbEYjT8oX5= jl1A8eNop9So%3D&reserved=3D0 A summary of the counter-arguments could be th= at CAs have messed up before, how can we rest assured they will not reuse s= tate. I think your argument for Stateful HBS in this draft is only for root CAs w= hich 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 pr= ocess and the verifiers trust it. The draft also mentions subordinate CA c= ertificates. I don't think these are good use-cases for stateful HBS. I wou= ld suggest for the draft to clearly stress the potentially use-cases for St= ateful HBS. Also I suggest for the security considerations section to stres= s the importance and how you envision these use-cases will be able to addre= ss 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 tra= ck of all its signatures and can go back and attest the state was not reuse= d periodically and its verifiers usually trust the signer. Another one coul= d be the state look ahead where you retrieve x states and change your point= er before you even start signing anything. -----Original Message----- From: Spasm > On Beha= lf Of Kousidis, Stavros Sent: Saturday, December 24, 2022 12:11 AM To: Russ Housley > Cc: LAMPS >; draft-gazdag-x509-hash-s= igs.authors@ietf.org Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00 CAUTION: This email originated from outside of the organization. Do not cli= ck 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=FCngliche Nachricht----- Von: Russ Housley > Gesendet: Freitag, 23. Dezember 2022 18:12 An: draft-gazdag-x509-hash-sigs.authors@ietf.org Cc: LAMPS > Betreff: [lamps] draft-gazdag-x509-hash-sigs-00 Dear I-D Authors: RFC 8708 has this definition: HSS-LMS-HashSig-PublicKey ::=3D OCTET STRING This will carry the bytes as defined in RFC 8554. draft-gazdag-x509-hash-sigs-00 says: HSS-HashSig-PublicKey ::=3D 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 Spasm@ietf.org https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fspasm&data=3D05%7C01%7Cantonio.vaira%40siemens= .com%7Cd988d9a6eb5d4ac79f4808db042989a7%7C38ae3bcd95794fd4addab42e1495d55a%= 7C1%7C0%7C638108348674728031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC= JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3DwFkKzz= wn5JFkvymGcyOrOix99O8otkKQ5pdOmuGwh5M%3D&reserved=3D0 _______________________________________________ Spasm mailing list Spasm@ietf.org https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fspasm&data=3D05%7C01%7Cantonio.vaira%40siemens= .com%7Cd988d9a6eb5d4ac79f4808db042989a7%7C38ae3bcd95794fd4addab42e1495d55a%= 7C1%7C0%7C638108348674728031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC= JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3DwFkKzz= wn5JFkvymGcyOrOix99O8otkKQ5pdOmuGwh5M%3D&reserved=3D0 --_000_402e8a7be79549cc9e1965a7a0dd6316bsibundde_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Antonio= ,

 = ;

it has bee= n a while but let me add my thoughts to your proposal.

 = ;

The proble= ms are:

 = ;

1= )   &= nbsp;  You don̵= 7;t solve the distribution/backup problem while you are signing with a spec= ific tree during your first X years.

2= )   &= nbsp;  Your signatu= re sizes grow over time with every subtree you add because of the additiona= l OTS in the newly established multi-tree.

3= )   &= nbsp;  You change t= he public key once you add a subtree.

 = ;

Let me ela= borate on point 3) as this is something you certainly don’t want:

 = ;

HSS encode= s the number of levels in the public key (see =A76.1 in RFC8554) so that yo= u know how to verify a signature when you receive it (see =A76.3 in RFC8554). Likewise XMSS/XMSS^MT encodes an identifier sp= ecifying the (multi-)tree (see =A74.1.7 and =A74.2.2 in RFC8391). This mean= s that your trust anchor changes (e.g. X.509 certificate) and you have to d= istribute it again.

 = ;

Best<= /o:p>

Stavros

&nbs= p;

Von: Vaira, Antonio <antonio.vair= a@siemens.com>
Gesendet: Mittwoch, 1. Februar 2023 13:31
An: Kousidis, Stavros <stavros.kousidis@bsi.bund.de>
Cc: LAMPS <spasm@ietf.org>; draft-gazdag-x509-hash-sigs.author= s@ietf.org; pqc@ietf.org; Kampanakis, Panos <kpanos@amazon.com>
Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00

 

Hi Stavros,

 

My interpretation is that the SEED should be indeed= considered as "private keying material" therefore I am also conc= erned with the point b) you raised.

 

I would also add, even if we theoretically do not c= oncern ourselves with the operational/cost overheads of having a lot of HSM= s initialized and put in storage, can we realistically be sure that by the time we will need these HSMs they will all boot? The t= imeline I have in mind is 20+ years (realistic RootCA lifetime) and I a= m not sure if an HSM, even if stored in “perfect conditions”, w= ill still boot after 20 years.

 

For the reason above, I was thinking about an alter= native approach that can be summarized with the following steps:

1. the tree #1 is generated, with a height that is = proportional to the required number of signatures and its leaves can be use= d to perform digital signatures,

2. after X years, for example 5 years, the last lea= f of tree #1 is used to sign a new subtree, tree #2, that corresponds to OT= S private keys that are initialized in a new HSM,

3. repeat step 2 after every X years, initializing = each time new OTS private keys in a new HSM.

 <= /o:p>

After 3 iterations the HBS state would look like th= e following:

 

   &= nbsp;       root

          -&n= bsp;            = ;            

         / \ =             &nb= sp;          

        /   \=             &nb= sp;          

       /   &n= bsp; \           &nb= sp;          

      /    &n= bsp;  \          &nb= sp;          

     /     &n= bsp;   \         &nb= sp;          

    /      &n= bsp;    \        &nb= sp;          

   /       &n= bsp;     \       &nb= sp;          

  -----------------     &nbs= p;           

  |    |     =      |        &= nbsp;        

  |    |     =      |        &= nbsp;        

sig1 sig2  ...   -    &= nbsp;           &nbs= p;

         &nbs= p;       / \     &nb= sp;          

         &nbs= p;      /   \    &nb= sp;          

         &nbs= p;     /     \   &nb= sp;          

         &nbs= p;    /       \  &nb= sp;          

         &nbs= p;   /         \ &nb= sp;          

         &nbs= p;  /           \&nb= sp;          

         &nbs= p; /            = ; \          

          ---= --------------         

          |&n= bsp;   |          |&= nbsp;        

          |&n= bsp;   |          |&= nbsp;        

         sig1 sig2=   ...   -        &nb= sp;

         &nbs= p;            &= nbsp;  / \        

         &nbs= p;            &= nbsp; /   \       

         &nbs= p;             = /     \      

         &nbs= p;            / = ;      \     

         &nbs= p;           /  = ;       \    

         &nbs= p;          /   = ;        \   

         &nbs= p;         /    = ;         \  

         &nbs= p;        ----------------- 

         &nbs= p;        |    |  &n= bsp; |    |        &= nbsp;  

         &nbs= p;        |    | &nb= sp; |    |        &n= bsp;  

         &nbs= p;       sig1 sig2  ...  ...=

 <= /o:p>

The first 2 trees can be considered as no longer us= able, even if there are still unused leaves, because their corresponding OT= S private keys are in HSMs which may no longer be available. The OTS keys associated to the tree corresponds are generate= d and stored on a “fresh” HSM.

 <= /o:p>

Without considering redundancy requirements (also n= ot considered in the steps above for sake of simplicity), with this approac= h it would be possible to use one HSM at the time and replace it after X years with a new one (avoiding to initialize HSMs a= nd securely store them) and it would not be needed to redistribute the root= to all the relying parties. But the signature would increase of a fixed nu= mber of bytes (i.e., the signature performed over the root of the new subtree using the last OTS private key = of the parent tree) every X years.

 <= /o:p>

What do you think?

 

Thanks

Antonio

 <= /o:p>

-----Original Message-----
From: Kousidis, Stavros <stavros.kousidis@bsi.bund.de>
Sent: Wednesday, 1 February 2023 08:54
To: Vaira, Antonio (T CST SEA-DE) <antonio.vaira@siemens.com>
Cc: LAMPS <spasm@ietf.org>; draft-gazdag-x509-hash-sigs.authors@ietf.org; pqc@ietf.org; Kampanakis, Panos <kpanos@amazon.com>
Subject: AW: [lamps] draft-gazdag-x509-hash-sigs-00

 <= /o:p>

Dear Antonio,

 

 <= /o:p>

The =A77 of NIST SP 800-208 elaborates on distribut= ed multi-trees instantiated via cryptographic modules. It is stated there t= hat

 

"due to the risks associated with copying OTS = keys, this recommendation prohibits exporting private keying material (Sect= ion 8)."

 

I do ask myself if the "private keying materia= l" described here includes the secret value "SEED" that can = be used to pseudorandomly generate an LMS or XMSS private key (see Appendix A in RFC8554 or analoguously =A73.1.7 in RFC8391).

 

On the one hand I would say yes, but:

 

a) As I read NIST SP 800-208 the requirements descr= ibed in =A77 and =A78 are primarily concerned with the OTS private keys (th= at is when the counter comes into play along with the SEED).

b) I cannot imagine how one can practically address= the "do not export private keying material" requirement if the S= EED is included here. This would imply your interpretation that at key generation time one would have to put a lot of sleeping HSMs o= n the shelf. As a concrete example, imagine aiming for 2^20 signatures and = instantiating HSS with two levels, height 10 on the top level and height 20= on the bottom level. The top level covering the distribution/redundancy aspect. That would mean that your she= lf is packed with 2^10 HSMs holding the bottom level LMS instances. You cou= ld aim for height 5 on the top level tree, but still 2^5 HSMs are not pract= ical in my personal opinion.

 

@All: May I ask, how the above mentioned requiremen= t about exporting private keying material has to be interpreted?

 

However, I (personally) still think that stateful H= BS should be available as an option in our ecosystems.

 

Best

Stavros

 

-----Urspr=FCngliche Nachricht-----

Von: Vaira, Antonio <antonio.vaira@siemens.com>

Gesendet: Dienstag, 31. Januar 2023 13:33

An: Kousidis, Stavros <stavros.kousidis@bsi.bund.de>; Kampanakis, Pa= nos <kpanos@amazon.com>

Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00=

 

Dear Stavros, Dear Panos,

 

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

 

- I believe that we will also need to have "st= ateful HBS ICAs", to at least sign "stateful HBS code-signing cer= tificates". This would allow a relying party to validate the code-signing certificates, and its associated certificate chain, by verify= ing only one type of digital signatures, which in this case would be a stat= eful HBS scheme. This type of ICAs may be handled as RootCA, so probably th= ere 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 authenticati= on 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 publishe= d, 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 bodie= s, 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 mo= re about how you plan to handle the requirements from =A77 of NIST SP 800-2= 08.

    > in my understanding, to ful= fil 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 inte= nded use of stateful HBS).

    > do you see additional appro= aches that would allow to comply with the requirements from =A77 of NIST SP= 800-208?

 

 

Many thanks

Antonio Vaira

 

-----Original Message-----

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Kousidis, Stavros=

Sent: Monday, 23 January 2023 09:33

To: Kampanakis, Panos <kpanos=3D40amazon.com@dmarc.ietf.org>= ;

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

 

Dear Pano,

 

thank you for your comments and suggestions, and so= rry 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 t= hat ensures the secure handling of the state. When discussing this in the security considerations we would also stress o= n NISTs proposal to use "Distributed Multi-Tree Hash-Based Signatures&= quot; (see NIST SP 800-208 =A77) as a design to further ensure that states = are handled appropriately.

 

We have tracked the other use cases you mentioned a= s 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=FCngliche Nachricht-----

Von: Kampanakis, Panos <kpanos=3D40amazon.com@dmarc.ietf.org>

Gesendet: Donnerstag, 29. Dezember 2022 18:23

An: Kousidis, Stavros <stavros.kousidis@bsi.bund.de>

Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00=

 

One more comment regarding draft-gazdag-x509-hash-s= igs.

 

 

I think your argument for Stateful HBS in this draf= t is only for root CAs which sign a few ICAs and then go to sleep and rarel= y 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 an= d signs very few ICA certs and then goes offline. Another example is a code-signer keeps track of all its sign= atures 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 loo= k ahead where you retrieve x states and change your pointer before you even start signing anything.

 

 

 

-----Original Message-----

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Kousidis, Stavros=

Sent: Saturday, December 24, 2022 12:11 AM

To: Russ Housley <housley@vigilsec.com>

Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-ha= sh-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 S= TRING" 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=FCngliche Nachricht-----

Von: Russ Housley <housley@vigilsec.com>

Gesendet: Freitag, 23. Dezember 2022 18:12

Cc: LAMPS <spa= sm@ietf.org>

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

 

Dear I-D Authors:

 

RFC 8708 has this definition:

 

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

 

This will carry the bytes as defined in RFC 8554.

 

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

 

    HSS-HashSig-PublicKey ::=3D SEQU= ENCE {

       levels &n= bsp;   OCTET STRING, -- number of levels L

       tree &nbs= p;     OCTET STRING, -- typecode of top-level LMS tree<= /span>

       ots  = ;      OCTET STRING, -- typecode of top-level LM-O= TS

       identifier OCT= ET STRING, -- identifier I of top-level LMS key pair

       root &nbs= p;     OCTET STRING  -- root T[1] of top-level tre= e

    }

 

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

 

Russ

 

_______________________________________________

Spasm mailing list

 <= /o:p>

_______________________________________________

Spasm mailing list

 <= /o:p>

=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Java, JavaScript sowie aktive Inhalte wurden aus dieser E-Mail herausgefilt= ert. --_000_402e8a7be79549cc9e1965a7a0dd6316bsibundde_--