From nobody Tue Jan 31 23:54:36 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 66A43C14CE51; Tue, 31 Jan 2023 23:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.295 X-Spam-Level: X-Spam-Status: No, score=-4.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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="34wTYtO5"; dkim=pass (2048-bit key) header.d=bsi.bund.de header.b="shgZHe7t" 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 YUcCE6iBWXcF; Tue, 31 Jan 2023 23:54:29 -0800 (PST) Received: from m1-bn.bund.de (m1-bn.bund.de [77.87.228.73]) (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 5B9CCC14CE4F; Tue, 31 Jan 2023 23:54:27 -0800 (PST) Received: from m1-bn.bund.de (localhost [127.0.0.1]) by m1-bn.bund.de (Postfix) with ESMTP id AF2E528DBBA; Wed, 1 Feb 2023 08:54:24 +0100 (CET) Received: (from localhost) by m1-bn.bund.de (MSCAN) id 4/m1-bn.bund.de/smtp-gw/mscan; Wed Feb 1 08:54:24 2023 X-NdB-Source: NdB DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=bsi.bund.de; s=211014-e768-ed25519; t=1675238058; bh=jjBHjzhJBq6h7gkY+bVkXUB9PQI1uU/zQJi8w6l0eyE=; h=From:To:CC:Subject:Date:References:In-Reply-To:Content-Type: Content-Transfer-Encoding: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=34wTYtO50CwvwDSjS9ZYbxJlzFjnQLBtiuKTzE8KVcI0r/AWLmGem9y4UaDygyrRD sp0uoMpgKox9vhHsdXPCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsi.bund.de; s=211014-e768-rsa; t=1675238058; bh=jjBHjzhJBq6h7gkY+bVkXUB9PQI1uU/zQJi8w6l0eyE=; h=From:To:CC:Subject:Date:References:In-Reply-To:Content-Type: Content-Transfer-Encoding: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=shgZHe7tUU3LMZ4NvTdR/RRZpboYKzhEOr6CCEFwlG8HetOCGZ9BD2TNwfHjdFBZr UM/wuOd7CxU0lzZNwvr4Ghob8dhU5NY4qNmmuiiN+e0ji9MEf5pYCQlm8+hczJD1Yl 8e7ky0ePK7RsIiRn89icE5EJrUE9Q17rz4gijiXhyyJQ/U2hmI2+ZyMwl4FxlABnuq 5Xszt2g5Nw0bPWR52q3tfXWKr4H6yTD8CGSVId5pGHaZjeT2eLFP7Y7UxVrzJU/ry8 5HTKgEqv7evNpR6UE79RGS7/FVVYQbmeifxWSqhhjYB0yWNZEX2oz/0n98sFuCCyQM IvIxZzCeNkQ8A== X-P350-Id: 1ed0d55225848c8e 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+ZJ11q58fj4AgAioM4CAJrZlAIAMzD3ggABMBqA= Date: Wed, 1 Feb 2023 07:54:13 +0000 Message-ID: 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: 37303A29E519D454667266 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EsetResult: clean, is OK X-EsetId: 37303A295382EA54667266 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: Wed, 01 Feb 2023 07:54:34 -0000 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://mailarchive.ietf.org/arch/msg/spasm/= hUe6bBqGoJhyu5vObbYJMbtCEDw/ 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 =20 Gesendet: Dienstag, 31. Januar 2023 13:33 An: Kousidis, Stavros ; Kampanakis, Panos Cc: LAMPS ; draft-gazdag-x509-hash-sigs.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 Behalf Of Kousidis, Stavros Sent: Monday, 23 January 2023 09:33 To: Kampanakis, Panos Cc: LAMPS ; draft-gazdag-x509-hash-sigs.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 =20 Gesendet: Donnerstag, 29. Dezember 2022 18:23 An: Kousidis, Stavros Cc: LAMPS ; draft-gazdag-x509-hash-sigs.authors@ietf.org Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00 One more comment regarding draft-gazdag-x509-hash-sigs.=20 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%7C42f367be82dd413a64= ae08dafd1c9a04%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638100596561496= 300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1= haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3Dh25km8rodm9XTku1Chgjffe%2BEm9dO= RsXhMwrrDhcVzQ%3D&reserved=3D0 A summary of the counter-arguments could be = that CAs have messed up before, how can we rest assured they will not reuse= state.=20 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. =20 -----Original Message----- From: Spasm On Behalf Of Kousidis, Stavros Sent: Saturday, December 24, 2022 12:11 AM To: Russ Housley Cc: LAMPS ; draft-gazdag-x509-hash-sigs.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%7C42f367be82dd413a64ae08dafd1c9a04%7C38ae3bcd95794fd4addab42e1495d55a%= 7C1%7C0%7C638100596561496300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC= JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3DBzfXk7= IkssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8%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%7C42f367be82dd413a64ae08dafd1c9a04%7C38ae3bcd95794fd4addab42e1495d55a%= 7C1%7C0%7C638100596561496300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC= JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3DBzfXk7= IkssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8%3D&reserved=3D0