From nobody Wed Feb 1 05:00:09 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 375B7C17CEA7; Wed, 1 Feb 2023 05:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 S4lu7zEEB4ge; Wed, 1 Feb 2023 05:00:06 -0800 (PST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DD6C17CEA2; Wed, 1 Feb 2023 05:00:05 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id e8-20020a17090a9a8800b0022c387f0f93so2081778pjp.3; Wed, 01 Feb 2023 05:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=autocrypt:content-transfer-encoding:mime-version:message-id :references:in-reply-to:user-agent:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Jt9avQBpN3tu/AEakirbLxaWe96YxB52OqBnb4Xb8Hw=; b=D1pJ3iAXYSqSO3Ig+3Ds6hU6qjBSd4sJLmqJNUS4Xm0SgE24pjm9kXI7L6Z3N26Gdd gcvGD+cgiR6UnmPtVFlH475a1tQS8KInpEldAys7vDo3VRD1JABXYjIhEoA7GH3LhDGq 50k3Cc9g5lTtZeWPFsFl2DG4cEr7oy9IBniOrx3v75dyzU1CbVy4qcHry7sXrjI/yYdI 9Ygav64zAYTmSoA0FtHSss4X6T0rDKW6p24PEZFo9QAd1Qxc+juLMpKL1CbD63ch9hid G4lIzphCwQ16Z0UTC46CwpWG70+r66fJMRImrqQ44/H0Qv9/zCHsXM+krtCNy8SUaW4o JX4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=autocrypt:content-transfer-encoding:mime-version:message-id :references:in-reply-to:user-agent:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Jt9avQBpN3tu/AEakirbLxaWe96YxB52OqBnb4Xb8Hw=; b=RQD5Do44rBA96IRKcVBbtZ8hZPWUQcC0+1nM09IfAsf/HrK/x75TjTJXpYho/WFECn sfzNDqoY2sDY4LMTxyEfieu/4frYBF92wssDA4lmhd1ZApHa+nPm/kzSi0LVUHCQcZ89 R/V/9QOCf8VIzGUr6gT4z+dC8mSL2hIsZZe1nPv77MyFDxZwxcbEcykAb9dqDqFU0jbI 7Qpv3481MLFLBy7YjXklKjvY8YEtNNP0G4FNHwvOTDpOLsFLQQzyNnHDp32t807ilTNi 66i7SxJM3ICsVdoL21iBlzvLlpcRUe7fCv0KMnMpaXPrH3Ov2EIHwLvdlLJ8THx3ms9e 9ffQ== X-Gm-Message-State: AO0yUKWacUGuyVqmtl07JG3SOyTt0poDWKg9vJDjrksrcCiETsjYaftc dFlB6VmXgWaWErsnWsGUvfuWbYKKzJ6TmLqY X-Google-Smtp-Source: AK7set+fVsIp7NdLdP0GxiSHB4CR0Mr82FeB6JLVTaIQeK3aWIBoJHHPxrXGPwtH2d1gfpDjflLL3w== X-Received: by 2002:a17:902:c94e:b0:198:a86c:33f with SMTP id i14-20020a170902c94e00b00198a86c033fmr2324456pla.65.1675256404807; Wed, 01 Feb 2023 05:00:04 -0800 (PST) Received: from [127.0.0.1] ([118.32.103.160]) by smtp.gmail.com with ESMTPSA id w5-20020a170902d3c500b00194bf8cef44sm11613455plb.117.2023.02.01.05.00.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Feb 2023 05:00:04 -0800 (PST) Date: Wed, 01 Feb 2023 21:59:59 +0900 From: Seo Suchan To: spasm@ietf.org, "Vaira, Antonio" , "Kousidis, Stavros" CC: LAMPS , "draft-gazdag-x509-hash-sigs.authors@ietf.org" , "pqc@ietf.org" , "Kampanakis, Panos" User-Agent: K-9 Mail for Android In-Reply-To: References: <08C331ED-453C-4812-955A-F2161B960329@vigilsec.com> <3439f87bb3bb4a199f706b791cba6b6a@bsi.bund.de> <6828097d5b5b4beabb0c4243b150077f@amazon.com> <99a43b5f4620438a9cb7ca539f70dbcb@bsi.bund.de> Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----XCG11D7BM859DEBN7AKLT1510V78MT Content-Transfer-Encoding: 7bit Autocrypt: addr=tjtncks@gmail.com; keydata= mQGNBGN7GSUBDACv4kxByGqR6X+g16a+ZGb/I4ahDx2I8ZSDLro/bdnzeF4sxc50TeQAwk7FgFx9 UYj0x5FXZTTkkhk1VysfS/ZRtr9LDJ8ZGrDX/kcyNRYdXbPYwnMd7A6eAS2NEcMpgh1zJEo8WA+r VgSoc7nNdHR8WpCgtuBZs3j08+3LzfSbuCFXNxf/mMU6+1fqBBqkUGb8z1b6Jcmi9D3PLiVIOnyj 5HcNEKKz18gKWr5HrM9MUpRHciTP0Z5/wR/KlEYbb7lI7lSiEM3F5wsPnfDVF52GX1x6d/j8swWe ch/N6h42mm2MNdU5K17Ob0j+u4X0ZVQjBSNpSYLkgOhIwZ1x2UaMrUbCouPrCEVOD7bWCyBFYpsi iJ0B/Nauu2G8sJDLpyeH9QA431+XQ5wj2TwTreqC/KpMWc+ikTytYKmGoLzY93rakDsPw7fXm3Cv e2mZ0qBj2XRTClsM/6x0p3ghj4wynA+UJ2N4vJ0V4qILEyAFA+3XGEpN0BtNCWiqO8PwtMMAEQEA AbQeU2VvIFN1Y2hhbiA8dGp0bmNrc0BnbWFpbC5jb20+iQHHBBMBCAAxFiEExSjWMeUiRmfe1PiS 7Lo6Jc7pimkFAmN7GSUCGwMECwkIBwUVCAkKCwUWAgMBAAAKCRDsujolzumKae2rC/9UPZIY36sV Dh/fuNs6z7Y4SF8nvfNIkkAdeD891sju2rUdkri3OFUlMGJDLfGjth+ZZPb94CndO+vFql94VyEI iI8q6OGwlNM7L3cntV8vSCo9i8OVsNvMS8PjDlqRqcq/tm0kX9q4ELxQtsBqSgTREVHNb8PTMHn7 mPlZIuFkx6H4zGtyQxMmz5TH4rH/jrW6vtJn+yFwnt8rux0hpOU7UNyA0BmGiJOD44oHgb/knrex J+KQY4mVf/Bgzuarfqnp3JSBR6HxMk3px+gH/oz35vVTJNqKJN2Lt4Vo/ku1YzyLAjE+wPp+8zJj TEAZyBhxTp9kVci41blwJ+PR6GY/JjlVw0mC8Ab8G3uLj5NvOTnP2rbFHmO9ecWNEP/7xN8rQy0s 7r8ojJrarj+tZwpk2AP5QLwLHNKwHwsqPk6+96/c6ANYdflQl8uOvLPAXEayBmbEYo/KownLgp3B 41iaIqYCRpVvFxux/zSK32QCbnTsfHOu/NlRpq4VfXll6Sm5AY0EY3sZJgEMAOOp2sC96VCGwDlu PA1MTtWSptbvr2s4MBBCfYIDQAqpW9Zhuaj+tH2Z8OYlgf6U5WouhlaxDrKIrVNn1uFjZFmoC89N mlnQhEDxzXa8sRzudrxsPrZTagDIOKm/DQW6OUZi9TuduoQ+xHZMpc4H56bueWOzitzNPqogf0D0 z3qu1UUqR1+w+dnoSlV5y75cW6eX9bZeXR9Zqimv2Q/WjPAFphPMG+WD4+kpsPKodQGhArmxWDkM +tu/n/U88vrUnzjCfs+qt69a5lZSGodf/YzkGaeZpXmzX1OIBjVMEe4++6euhWSkS/c7RZeHVUae bOj9vP713I6iHMiPOOTpvatlxK8gxIsY9gBerEymgtd9JjbWS7mLRt8Inn8A4mIK9/30R57f33he KZ5xgqxgBdAHmtrh/13bTw0r6Sh/3izQyN+WGjiJqbpSnvuGtqaSB93gbpLKU8Px8VcaWOuY5WKk E2t/rSU5w27Kf72a79LWnSJ+l8jv1fFnhmigkqH0+QARAQABiQG2BBgBCAAgFiEExSjWMeUiRmfe 1PiS7Lo6Jc7pimkFAmN7GSYCGwwACgkQ7Lo6Jc7pimkY8Av+OGVS59yLCXxr5UK3SPZrh8KcyQQd qqpMW7UDse8Fo6shXWL9VAh26gFhfaKo6seAHCeedSDhVvopFkoxpWM+TK8dEMZBD+Xru3gEhQW7 lBGn45E0AHPIe/trXDidGRXC4HDJ1Xk8aavfGSBMnc6Mnmwm23VjDXppKEhjk+iEUWwiDxzeahV6 3KkcWIXx/j+IBnXwMi7HkXEK5dVWP9kuM5d8soIbBbEZ2fl4IJNjy+SBWK6/fR+WgxfWLth5f/mI Bm1nsF7UUXDjOS5ZR918cKtoK6VZaWZu/N6CaAVD4gZtOZCParum5cMx79ggrfQxOqVCcfmxM43a roOB6bElAe34t+F/cD9bxCVspJ37RsAWdS7rT7WyCfQPlP4Szf4XAQoVdfiszKPUdTCrnvMKHqnP P0JD6SmK67e1uF4gKZKs3X5qOiF6CQZ+JBWAq4BxoUfqpkuPsD5m82P7eWO66SzztUJp5BJ47wRB dmGyizGb9Hc9ro+61/QeLCtDYyjs 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 13:00:08 -0000 ------XCG11D7BM859DEBN7AKLT1510V78MT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable isn't this in effect make them 5 year roots that are cross signed by older = roots? like eg: ISRG X1 signed by DST X3 On 2023=EB=85=84 2=EC=9B=94 1=EC=9D=BC =EC=98=A4=ED=9B=84 9=EC=8B=9C 31=EB= =B6=84 5=EC=B4=88 GMT+09:00, "Vaira, Antonio" =EC=9E=91=EC=84=B1=ED=95=A8: >Hi Stavros, > >My interpretation is that the SEED should be indeed considered as "privat= e keying material" therefore I am also concerned with the point b) you rais= ed=2E > >I would also add, even if we theoretically do not concern ourselves with = the 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 thes= e HSMs they will all boot? The timeline I have in mind is 20+ years (realis= tic RootCA lifetime) and I am not sure if an HSM, even if stored in "perfec= t conditions", will still boot after 20 years=2E > >For the reason above, I was thinking about an alternative approach that c= an be summarized with the following steps: >1=2E the tree #1 is generated, with a height that is proportional to the = required number of signatures and its leaves can be used to perform digital= signatures, >2=2E 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=2E repeat step 2 after every X years, initializing each time new OTS pr= ivate keys in a new HSM=2E > >After 3 iterations the HBS state would look like the following: > > root > - > / \ > / \ > / \ > / \ > / \ > / \ > / \ > ----------------- > | | | > | | | > sig1 sig2 =2E=2E=2E - > / \ > / \ > / \ > / \ > / \ > / \ > / \ > ----------------- > | | | > | | | > sig1 sig2 =2E=2E=2E - > / \ > / \ > / \ > / \ > / \ > / \ > / \ > ----------------- > | | | | > | | | | > sig1 sig2 =2E=2E=2E =2E=2E=2E > >The first 2 trees can be considered as no longer usable, even if there ar= e still unused leaves, because their corresponding OTS private keys are in = HSMs which may no longer be available=2E The OTS keys associated to the tre= e corresponds are generated and stored on a "fresh" HSM=2E > >Without considering redundancy requirements (also not considered in the s= teps above for sake of simplicity), with this approach it would be possible= to use one HSM at the time and replace it after X years with a new one (av= oiding to initialize HSMs and securely store them) and it would not be need= ed to redistribute the root to all the relying parties=2E But the signature= would increase of a fixed number of bytes (i=2Ee=2E, the signature perform= ed over the root of the new subtree using the last OTS private key of the p= arent tree) every X years=2E > >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-sigs=2Eauthors@ietf= =2Eorg; pqc@ietf=2Eorg; 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= CAs face when using stateful HBS in our draft=2E This already came up in c= omments that Panos sent, see here: https://eur01=2Esafelinks=2Eprotection= =2Eoutlook=2Ecom/?url=3Dhttps%3A%2F%2Fmailarchive=2Eietf=2Eorg%2Farch%2Fmsg= %2Fspasm%2FhUe6bBqGoJhyu5vObbYJMbtCEDw%2F&data=3D05%7C01%7Cantonio=2Evaira%= 40siemens=2Ecom%7Cd988d9a6eb5d4ac79f4808db042989a7%7C38ae3bcd95794fd4addab4= 2e1495d55a%7C1%7C0%7C638108348674728031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4= wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda= ta=3D%2BjO3%2Bi0NfdqHmSaEJ9BCbpE3Hv8xwsaoVfnkuWfwfVg%3D&reserved=3D0 > >The =C2=A77 of NIST SP 800-208 elaborates on distributed multi-trees inst= antiated via cryptographic modules=2E It is stated there that > >"due to the risks associated with copying OTS keys, this recommendation p= rohibits exporting private keying material (Section 8)=2E" > >I do ask myself if the "private keying material" 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 =C2=A73=2E1= =2E7 in RFC8391)=2E > >On the one hand I would say yes, but: > >a) As I read NIST SP 800-208 the requirements described in =C2=A77 and = =C2=A78 are primarily concerned with the OTS private keys (that is when the= counter comes into play along with the SEED)=2E >b) I cannot imagine how one can practically address the "do not export pr= ivate keying material" requirement if the SEED is included here=2E This wou= ld imply your interpretation that at key generation time one would have to = put a lot of sleeping HSMs on the shelf=2E As a concrete example, imagine a= iming for 2^20 signatures and instantiating HSS with two levels, height 10 = on the top level and height 20 on the bottom level=2E The top level coverin= g the distribution/redundancy aspect=2E That would mean that your shelf is = packed with 2^10 HSMs holding the bottom level LMS instances=2E You could a= im for height 5 on the top level tree, but still 2^5 HSMs are not practical= in my personal opinion=2E > >@All: May I ask, how the above mentioned requirement about exporting priv= ate keying material has to be interpreted? > >However, I (personally) still think that stateful HBS should be available= as an option in our ecosystems=2E > >Best >Stavros > >-----Urspr=C3=BCngliche Nachricht----- >Von: Vaira, Antonio > >Gesendet: Dienstag, 31=2E Januar 2023 13:33 >An: Kousidis, Stavros >; Kampanakis, Panos > >Cc: LAMPS >; draft-gazdag-x509-= hash-sigs=2Eauthors@ietf=2Eorg >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= of personal considerations: > >- I believe that we will also need to have "stateful HBS ICAs", to at lea= st sign "stateful HBS code-signing certificates"=2E This would allow a rely= ing party to validate the code-signing certificates, and its associated cer= tificate chain, by verifying only one type of digital signatures, which in = this case would be a stateful HBS scheme=2E This type of ICAs may be handle= d as RootCA, so probably there is not much to add to the security considera= tions=2E >- my understanding of stateful HBS schemes is that the state of the priva= te key can be uniquely identified by the authentication path that is part o= f the signature=2E Could we think to derive a unique value, out of this aut= hentication path and embed it into a certificate field? Maybe such certific= ate can be further published, for example on CT, to allow public scrutiny o= f the CA operations? >- on a more generic note, the recent publication of CNSA 2=2E0, despite a= pplying only to NSS, may trigger other regulatory bodies, which may be tran= sversal to the scope of NSS, to adopt similar guidelines=2E Therefore I thi= nk we might have to deal with stateful HBS sooner than later=2E > >- @Stavros: it would be very interesting to know more about how you plan = to handle the requirements from =C2=A77 of NIST SP 800-208=2E > > in my understanding, to fulfil the requirements set forth in this s= ection one would that initializing several hypertrees on different HSMs=2E = One or more HSMs may be used immediately and the remaining should be secure= ly stored for later use (as disaster recovery mechanism for example)=2E I t= hink this approach might prove to be quite cumbersome, at least over a long= period of time (which is intended use of stateful HBS)=2E > > do you see additional approaches that would allow to comply with th= e requirements from =C2=A77 of NIST SP 800-208? > > >Many thanks >Antonio Vaira > >-----Original Message----- >From: Spasm > O= n Behalf Of Kousidis, Stavros >Sent: Monday, 23 January 2023 09:33 >To: Kampanakis, Panos > >Cc: LAMPS >; draft-gazdag-x509-= hash-sigs=2Eauthors@ietf=2Eorg >Subject: Re: [lamps] draft-gazdag-x509-hash-sigs-00 > >Dear Pano, > >thank you for your comments and suggestions, and sorry for the late reply= =2E > >The typical use case we have in mind are root and (potentially also subor= dinate) CAs which are using an HSM for cert signing that ensures the secure= handling of the state=2E When discussing this in the security consideratio= ns we would also stress on NISTs proposal to use "Distributed Multi-Tree Ha= sh-Based Signatures" (see NIST SP 800-208 =C2=A77) as a design to further e= nsure that states are handled appropriately=2E > >We have tracked the other use cases you mentioned as an issue in in our r= epository=2E I think Stefan Gazdag has some experience here and we will dis= cuss how to incorporate your suggestions in the security considerations=2E > >Best >Stavros > >-----Urspr=C3=BCngliche Nachricht----- >Von: Kampanakis, Panos > >Gesendet: Donnerstag, 29=2E Dezember 2022 18:23 >An: Kousidis, Stavros > >Cc: LAMPS >; draft-gazdag-x509-= hash-sigs=2Eauthors@ietf=2Eorg >Betreff: RE: [lamps] draft-gazdag-x509-hash-sigs-00 > >One more comment regarding draft-gazdag-x509-hash-sigs=2E > >Stateful HBS had come up previously for X=2E509 and some participants voi= ced serious concerns https://eur01=2Esafelinks=2Eprotection=2Eoutlook=2Ecom= /?url=3Dhttps%3A%2F%2Fmailarchive=2Eietf=2Eorg%2Farch%2Fmsg%2Fspasm%2FDKPDf= aQZxF5_De9BYuoWsRKp4gM%2F&data=3D05%7C01%7Cantonio=2Evaira%40siemens=2Ecom%= 7Cd988d9a6eb5d4ac79f4808db042989a7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7= C0%7C638108348674728031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3DWedj6fJ8p56= 4lYwaDHXQAjbEYjT8oX5jl1A8eNop9So%3D&reserved=3D0 A summary of the counter-a= rguments could be that CAs have messed up before, how can we rest assured t= hey will not reuse state=2E > >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=2E Maybe ano= ther use is for code-signing EKU certs where the signer controls its signin= g process and the verifiers trust it=2E The draft also mentions subordinat= e CA certificates=2E I don't think these are good use-cases for stateful HB= S=2E I would suggest for the draft to clearly stress the potentially use-ca= ses for Stateful HBS=2E Also I suggest for the security considerations sect= ion to stress the importance and how you envision these use-cases will be a= ble to address the state concern=2E For example a Root CA uses an HSM and s= igns very few ICA certs and then goes offline=2E Another example is a code-= signer keeps track of all its signatures and can go back and attest the sta= te was not reused periodically and its verifiers usually trust the signer= =2E Another one could be the state look ahead where you retrieve x states a= nd change your pointer before you even start signing anything=2E > > > >-----Original Message----- >From: Spasm > O= n Behalf Of Kousidis, Stavros >Sent: Saturday, December 24, 2022 12:11 AM >To: Russ Housley > >Cc: LAMPS >; draft-gazdag-x509-= hash-sigs=2Eauthors@ietf=2Eorg >Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00 > >CAUTION: This email originated from outside of the organization=2E Do not= click links or open attachments unless you can confirm the sender and know= the content is safe=2E > > > >Dear Russ, > >thank you for the information=2E > >In the next version we will adopt the "OCTET STRING" definition of RFC 87= 08 for HSS and apply this also to XMSS/XMSS^MT=2E The same applies to SPHIN= CS+ where we will adopt the definition of "draft-ietf-lamps-cms-sphincs-plu= s-01"=2E > >Best >Stavros > >-----Urspr=C3=BCngliche Nachricht----- >Von: Russ Housley > >Gesendet: Freitag, 23=2E Dezember 2022 18:12 >An: draft-gazdag-x509-hash-sigs=2Eauthors@ietf=2Eorg >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=2E > >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=2E I think this = is a problem=2E There should only be one way to encode the HSS/LMS public = key=2E > >Russ > >_______________________________________________ >Spasm mailing list >Spasm@ietf=2Eorg >https://eur01=2Esafelinks=2Eprotection=2Eoutlook=2Ecom/?url=3Dhttps%3A%2F= %2Fwww=2Eietf=2Eorg%2Fmailman%2Flistinfo%2Fspasm&data=3D05%7C01%7Cantonio= =2Evaira%40siemens=2Ecom%7Cd988d9a6eb5d4ac79f4808db042989a7%7C38ae3bcd95794= fd4addab42e1495d55a%7C1%7C0%7C638108348674728031%7CUnknown%7CTWFpbGZsb3d8ey= JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%= 7C%7C&sdata=3DwFkKzzwn5JFkvymGcyOrOix99O8otkKQ5pdOmuGwh5M%3D&reserved=3D0 > >_______________________________________________ >Spasm mailing list >Spasm@ietf=2Eorg >https://eur01=2Esafelinks=2Eprotection=2Eoutlook=2Ecom/?url=3Dhttps%3A%2F= %2Fwww=2Eietf=2Eorg%2Fmailman%2Flistinfo%2Fspasm&data=3D05%7C01%7Cantonio= =2Evaira%40siemens=2Ecom%7Cd988d9a6eb5d4ac79f4808db042989a7%7C38ae3bcd95794= fd4addab42e1495d55a%7C1%7C0%7C638108348674728031%7CUnknown%7CTWFpbGZsb3d8ey= JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%= 7C%7C&sdata=3DwFkKzzwn5JFkvymGcyOrOix99O8otkKQ5pdOmuGwh5M%3D&reserved=3D0 > ------XCG11D7BM859DEBN7AKLT1510V78MT Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable isn't this in effect make them 5 year roots that are cross signed by= older roots? like eg: ISRG X1 signed by DST X3

On 2023=EB=85=84 2=EC=9B=94 1=EC=9D=BC =EC=98=A4=ED=9B=84 9=EC=8B=9C= 31=EB=B6=84 5=EC=B4=88 GMT+09:00, "Vaira, Antonio" <antonio=2Evaira@sie= mens=2Ecom> =EC=9E=91=EC=84=B1=ED=95=A8:
=
Hi = Stavros,
&nb= sp;
My = interpretation is that the SEED should be indeed considered as "private key= ing material" therefore I am also concerned with the point b) you raised=2E=
&nb= sp;
I w= ould also add, even if we theoretically do not concern ourselves with the o= perational/cost overheads of having a lot of HSMs initialized and put in st= orage, can we realistically be sure that by the time we will need these HSMs they will all boot? The timeline I hav= e in mind is 20+ years (realistic RootCA lifetime) and I am not sure if an = HSM, even if stored in =E2=80=9Cperfect conditions=E2=80=9D, will still boo= t after 20 years=2E
&nb= sp;
For= the reason above, I was thinking about an alternative approach that can be= summarized with the following steps:
1= =2E the tree #1 is generated, with a height that is proportional to the req= uired number of signatures and its leaves can be used to perform digital si= gnatures,
2= =2E 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= =2E repeat step 2 after every X years, initializing each time new OTS priva= te keys in a new HSM=2E
 =
Aft= er 3 iterations the HBS state would look like the following:<= /div>
&nb= sp;
   &n= bsp;       root
          -   =             &nb= sp;         
         / \   &nbs= p;            &= nbsp;       
        /   \  &nbs= p;            &= nbsp;       
       /     \ &nbs= p;            &= nbsp;       
      /       \&nbs= p;            &= nbsp;       
     /        = \            &= nbsp;       
    /         =   \           &= nbsp;       
   /          =    \          &= nbsp;       
  -----------------        &n= bsp;        
  |    |       &nbs= p;  |           = ;      
  |    |       &nbs= p;  |           = ;      
sig1 sig2  =2E=2E=2E   -     &nbs= p;           
            &n= bsp;    / \        &= nbsp;       
            &n= bsp;   /   \       &= nbsp;       
            &n= bsp;  /     \      &= nbsp;       
            &n= bsp; /       \     &= nbsp;       
             /=          \    &= nbsp;       
            / =           \   &= nbsp;       
           /  =            \  &= nbsp;       
          -----------------&n= bsp;        
          |   = |          |   = ;      
          |   = |          |   = ;      
         sig1 sig2  =2E=2E=2E=    -         
            &n= bsp;            / \&= nbsp;       
            &n= bsp;           / &nb= sp; \       
            &n= bsp;          /  &nb= sp;  \      
            &n= bsp;         /   &nb= sp;   \     
            &n= bsp;        /    &nb= sp;    \    
            &n= bsp;       /     &nb= sp;     \   
            &n= bsp;      /      &nb= sp;      \  
            &n= bsp;     ----------------- 
            &n= bsp;     |    |    | &nb= sp;  |          &nbs= p;
            &n= bsp;     |    |   | &nb= sp;  |          &nbs= p;
            &n= bsp;    sig1 sig2  =2E=2E=2E  =2E=2E=2E
 =
The= first 2 trees can be considered as no longer usable, even if there are sti= ll unused leaves, because their corresponding OTS private keys are in HSMs = which may no longer be available=2E The OTS keys associated to the tree corresponds are generated and stored on a =E2= =80=9Cfresh=E2=80=9D HSM=2E
 =
Wit= hout considering redundancy requirements (also not considered in the steps = above for sake of simplicity), with this approach it would be possible to u= se one HSM at the time and replace it after X years with a new one (avoiding to initialize HSMs and securely store the= m) and it would not be needed to redistribute the root to all the relying p= arties=2E But the signature would increase of a fixed number of bytes (i=2E= e=2E, the signature performed over the root of the new subtree using the last OTS private key of the parent tree)= every X years=2E
 =
Wha= t do you think?
&nb= sp;
Tha= nks
Ant= onio
 =
---= --Original Message-----
From: Kousidis, Stavros <stavros=2Ekousidis@bsi=2Ebund=2Ede>
Sent: Wednesday, 1 February 2023 08:54
To: Vaira, Antonio (T CST SEA-DE) <antonio=2Evaira@siemens=2Ecom> Cc: LAMPS <spasm@ietf=2Eorg>; draft-gazdag-x509-hash-sigs=2Eauthors@= ietf=2Eorg; pqc@ietf=2Eorg; Kampanakis, Panos <kpanos@amazon=2Ecom> Subject: AW: [lamps] draft-gazdag-x509-hash-sigs-00
 =
Dea= r Antonio,
&nb= sp;
I f= eel that we will have to take up a discussion on practical issues that CAs = face when using stateful HBS in our draft=2E This already came up in commen= ts that Panos sent, see here: https://eur01=2Esafelinks=2Eprotection=2Eoutlook=2Ecom/?url=3Dh= ttps%3A%2F%2Fmailarchive=2Eietf=2Eorg%2Farch%2Fmsg%2Fspasm%2FhUe6bBqGoJhyu5= vObbYJMbtCEDw%2F&data=3D05%7C01%7Cantonio=2Evaira%40siemens=2Ecom%7Cd98= 8d9a6eb5d4ac79f4808db042989a7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C= 638108348674728031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu= MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3D%2BjO3%2Bi0N= fdqHmSaEJ9BCbpE3Hv8xwsaoVfnkuWfwfVg%3D&reserved=3D0
 =
The= =C2=A77 of NIST SP 800-208 elaborates on distributed multi-trees instantia= ted via cryptographic modules=2E It is stated there that
&nb= sp;
"du= e to the risks associated with copying OTS keys, this recommendation prohib= its exporting private keying material (Section 8)=2E"
&nb= sp;
I d= o ask myself if the "private keying material" described here includes the s= ecret value "SEED" that can be used to pseudorandomly generate an LMS or XM= SS private key (see Appendix A in RFC8554 or analoguously =C2=A73=2E1=2E7 in RFC8391)=2E
&nb= sp;
On = the one hand I would say yes, but:
&nb= sp;
a) = As I read NIST SP 800-208 the requirements described in =C2=A77 and =C2=A78= are primarily concerned with the OTS private keys (that is when the counte= r comes into play along with the SEED)=2E
b) = I cannot imagine how one can practically address the "do not export private= keying material" requirement if the SEED is included here=2E This would im= ply your interpretation that at key generation time one would have to put a lot of sleeping HSMs on the shelf=2E As a con= crete example, imagine aiming for 2^20 signatures and instantiating HSS wit= h two levels, height 10 on the top level and height 20 on the bottom level= =2E The top level covering the distribution/redundancy aspect=2E That would mean that your shelf is packed with 2^10 HSMs holding= the bottom level LMS instances=2E You could aim for height 5 on the top le= vel tree, but still 2^5 HSMs are not practical in my personal opinion=2E
&nb= sp;
@Al= l: May I ask, how the above mentioned requirement about exporting private k= eying material has to be interpreted?
&nb= sp;
How= ever, I (personally) still think that stateful HBS should be available as a= n option in our ecosystems=2E
&nb= sp;
Bes= t
Sta= vros
&nb= sp;
---= --Urspr=C3=BCngliche Nachricht-----
Von= : Vaira, Antonio <anton= io=2Evaira@siemens=2Ecom>
Ges= endet: Dienstag, 31=2E Januar 2023 13:33
An:= Kousidis, Stavros <stavros=2Ekousidis@bsi=2Ebund=2Ede>; Kampanakis, Panos <kpanos@amazon=2Ecom>
Cc:= LAMPS <spasm@ietf=2Eorg>; draft-gaz= dag-x509-hash-sigs=2Eauthors@ietf=2Eorg
Bet= reff: RE: [lamps] draft-gazdag-x509-hash-sigs-00
&nb= sp;
Dea= r Stavros, Dear Panos,
&nb= sp;
I h= ope I am not intruding this conversation, I would like to add a couple of p= ersonal considerations:
&nb= sp;
- I= believe that we will also need to have "stateful HBS ICAs", to at least si= gn "stateful HBS code-signing certificates"=2E This would allow a relying p= arty to validate the code-signing certificates, and its associated certificate chain, by verifying only one type of digita= l signatures, which in this case would be a stateful HBS scheme=2E This typ= e of ICAs may be handled as RootCA, so probably there is not much to add to= the security considerations=2E
- m= y understanding of stateful HBS schemes is that the state of the private ke= y can be uniquely identified by the authentication path that is part of the= signature=2E Could we think to derive a unique value, out of this authentication path and embed it into a certific= ate field? Maybe such certificate can be further published, for example on = CT, to allow public scrutiny of the CA operations?
- o= n a more generic note, the recent publication of CNSA 2=2E0, despite applyi= ng only to NSS, may trigger other regulatory bodies, which may be transvers= al to the scope of NSS, to adopt similar guidelines=2E Therefore I think we might have to deal with stateful HBS so= oner than later=2E
&nb= sp;
- @= Stavros: it would be very interesting to know more about how you plan to ha= ndle the requirements from =C2=A77 of NIST SP 800-208=2E
&nb= sp;   > in my understanding, to fulfil the requirements set fo= rth in this section one would that initializing several hypertrees on diffe= rent HSMs=2E One or more HSMs may be used immediately and the remaining should be securely stored for later use (as disaster recovery me= chanism for example)=2E I think this approach might prove to be quite cumbe= rsome, at least over a long period of time (which is intended use of statef= ul HBS)=2E
&nb= sp;   > do you see additional approaches that would allow to c= omply with the requirements from =C2=A77 of NIST SP 800-208?<= /div>
&nb= sp;
&nb= sp;
Man= y thanks
Ant= onio Vaira
&nb= sp;
---= --Original Message-----
Fro= m: Spasm <spasm-bounces@ietf= =2Eorg> On Behalf Of Kousidis, Stavros
Sen= t: Monday, 23 January 2023 09:33
To:= Kampanakis, Panos <kpanos=3D40amazon=2Ecom@dmarc=2Eietf=2Eorg><= /div>
Cc:= LAMPS <spasm@ietf=2Eorg>; draft-gaz= dag-x509-hash-sigs=2Eauthors@ietf=2Eorg
Sub= ject: Re: [lamps] draft-gazdag-x509-hash-sigs-00
&nb= sp;
Dea= r Pano,
&nb= sp;
tha= nk you for your comments and suggestions, and sorry for the late reply=2E
&nb= sp;
The= typical use case we have in mind are root and (potentially also subordinat= e) CAs which are using an HSM for cert signing that ensures the secure hand= ling of the state=2E When discussing this in the security considerations we would also stress on NISTs proposal to u= se "Distributed Multi-Tree Hash-Based Signatures" (see NIST SP 800-208 =C2= =A77) as a design to further ensure that states are handled appropriately= =2E
&nb= sp;
We = have tracked the other use cases you mentioned as an issue in in our reposi= tory=2E I think Stefan Gazdag has some experience here and we will discuss = how to incorporate your suggestions in the security considerations=2E
&nb= sp;
Bes= t
Sta= vros
&nb= sp;
---= --Urspr=C3=BCngliche Nachricht-----
Von= : Kampanakis, Panos <kpanos=3D40amazon=2Ecom@dmarc=2Eietf=2Eorg>
Ges= endet: Donnerstag, 29=2E Dezember 2022 18:23
An:= Kousidis, Stavros <stavros=2Ekousidis@bsi=2Ebund=2Ede>
Cc:= LAMPS <spasm@ietf=2Eorg>; draft-gaz= dag-x509-hash-sigs=2Eauthors@ietf=2Eorg
Bet= reff: RE: [lamps] draft-gazdag-x509-hash-sigs-00
&nb= sp;
One= more comment regarding draft-gazdag-x509-hash-sigs=2E
&nb= sp;
&nb= sp;
I t= hink your argument for Stateful HBS in this draft is only for root CAs whic= h sign a few ICAs and then go to sleep and rarely wake up=2E Maybe another = use is for code-signing EKU certs where the signer controls its signing process and the verifiers trust it=2E  Th= e draft also mentions subordinate CA certificates=2E I don't think these ar= e good use-cases for stateful HBS=2E I would suggest for the draft to clear= ly stress the potentially use-cases for Stateful HBS=2E Also I suggest for the security considerations section to stress th= e importance and how you envision these use-cases will be able to address t= he state concern=2E For example a Root CA uses an HSM and signs very few IC= A certs and then goes offline=2E 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=2E Another one could be the state look ahead where you re= trieve x states and change your pointer before you even start signing anything=2E
&nb= sp;
&nb= sp;
&nb= sp;
---= --Original Message-----
Fro= m: Spasm <spasm-bounces@ietf= =2Eorg> On Behalf Of Kousidis, Stavros
Sen= t: Saturday, December 24, 2022 12:11 AM
To:= Russ Housley <housley@vigilse= c=2Ecom>
Cc:= LAMPS <spasm@ietf=2Eorg>; draft-gaz= dag-x509-hash-sigs=2Eauthors@ietf=2Eorg
Sub= ject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00
&nb= sp;
CAU= TION: This email originated from outside of the organization=2E Do not clic= k links or open attachments unless you can confirm the sender and know the = content is safe=2E
&nb= sp;
&nb= sp;
&nb= sp;
Dea= r Russ,
&nb= sp;
tha= nk you for the information=2E
&nb= sp;
In = the next version we will adopt the "OCTET STRING" definition of RFC 8708 fo= r HSS and apply this also to XMSS/XMSS^MT=2E The same applies to SPHINCS+ w= here we will adopt the definition of "draft-ietf-lamps-cms-sphincs-plus-01"= =2E
&nb= sp;
Bes= t
Sta= vros
&nb= sp;
---= --Urspr=C3=BCngliche Nachricht-----
Von= : Russ Housley <housley@vigils= ec=2Ecom>
Ges= endet: Freitag, 23=2E Dezember 2022 18:12
Cc:= LAMPS <spasm@ietf=2Eorg>
Bet= reff: [lamps] draft-gazdag-x509-hash-sigs-00
&nb= sp;
Dea= r I-D Authors:
&nb= sp;
RFC= 8708 has this definition:
&nb= sp;
&nb= sp;    HSS-LMS-HashSig-PublicKey ::=3D OCTET STRING
&nb= sp;
Thi= s will carry the bytes as defined in RFC 8554=2E
&nb= sp;
dra= ft-gazdag-x509-hash-sigs-00 says:
&nb= sp;
&nb= sp;   HSS-HashSig-PublicKey ::=3D SEQUENCE {
&nb= sp;      levels     OCTET STRI= NG, -- number of levels L
&nb= sp;      tree       = OCTET STRING, -- typecode of top-level LMS tree
&nb= sp;      ots      &n= bsp; OCTET STRING, -- typecode of top-level LM-OTS
&nb= sp;      identifier OCTET STRING, -- identifier I = of top-level LMS key pair
&nb= sp;      root       = OCTET STRING  -- root T[1] of top-level tree
&nb= sp;   }
&nb= sp;
Thi= s will produce a different byte string than RFC 8554=2E  I think this = is a problem=2E  There should only be one way to encode the HSS/LMS pu= blic key=2E
&nb= sp;
Rus= s
&nb= sp;
___= ____________________________________________
Spa= sm mailing list
 =
___= ____________________________________________
Spa= sm mailing list
 =
------XCG11D7BM859DEBN7AKLT1510V78MT--