From nobody Mon Jan 23 00:34:05 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 DE290C14E511; Mon, 23 Jan 2023 00:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, 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=unavailable 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="WF5VVtVf"; dkim=pass (2048-bit key) header.d=bsi.bund.de header.b="rz5kIJ4R" 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 JHkWhvXITIvQ; Mon, 23 Jan 2023 00:34:01 -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 8AC57C14CF16; Mon, 23 Jan 2023 00:33:59 -0800 (PST) Received: from m3-bn.bund.de (localhost [127.0.0.1]) by m3-bn.bund.de (Postfix) with ESMTP id 15516671664; Mon, 23 Jan 2023 09:33:57 +0100 (CET) Received: (from localhost) by m3-bn.bund.de (MSCAN) id 4/m3-bn.bund.de/smtp-gw/mscan; Mon Jan 23 09:33:57 2023 X-NdB-Source: NdB DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=bsi.bund.de; s=211014-e768-ed25519; t=1674462823; bh=1lbESSb0ZmXsJSIsfhzzzePSyjHo8xc3HoeVeNA3q8I=; 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=WF5VVtVfWDriSOCHogr09XZPxJ8e9MB7KVVqaRtXGMJyWLveyky7XFd2NIlH97tvq U7XLMpeojdhAgGj+d2sAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsi.bund.de; s=211014-e768-rsa; t=1674462823; bh=1lbESSb0ZmXsJSIsfhzzzePSyjHo8xc3HoeVeNA3q8I=; 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=rz5kIJ4RuC1bq7hw3c3gFcwSebdUttWSob4NamPCPt/PsoA5T7Lw1SO6aXaFlG3+X oYKULoE+DCMbF1jhBe+rUz86darrhO4dG2f0mAq4Tav0+g6URqcpZe8L1B8S4g/XU0 RJtSqU8m+tD/yMTKQiKCOe8nvIL73VRsBsw5SIs7+j+5ZMQ1cPeA1ETB9Ex9v2tjDR jVrEFEU+X4C0yhTGLM99Hj6GiSwtYNMrT5YjQQU/WHkcVHicO+0tvNXIgsLdhSngkI jCJ9HCmCq4rWfpXWJ8OE5j+mj5aqnzYNW6eqKYp0BXK/P+OWrE10QE1GHFjQC9u/+z Rwu1i5YdUF47A== X-P350-Id: 1e72333a531a2b5e X-Virus-Scanned: amavisd-new at bsi.bund.de From: "Kousidis, Stavros" To: "Kampanakis, Panos" CC: LAMPS , "draft-gazdag-x509-hash-sigs.authors@ietf.org" Thread-Topic: [lamps] draft-gazdag-x509-hash-sigs-00 Thread-Index: AQHZF1Y2AY86abJjRk2uTqea+ZJ11q6FISFggCa3LJA= Date: Mon, 23 Jan 2023 08:33:26 +0000 Message-ID: <99a43b5f4620438a9cb7ca539f70dbcb@bsi.bund.de> References: <08C331ED-453C-4812-955A-F2161B960329@vigilsec.com> <3439f87bb3bb4a199f706b791cba6b6a@bsi.bund.de> <6828097d5b5b4beabb0c4243b150077f@amazon.com> In-Reply-To: <6828097d5b5b4beabb0c4243b150077f@amazon.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-esetresult: clean, is OK x-esetid: 37303A29537AD454677260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rusd: domwl, Pass through domain bsi.bund.de X-Rurd: query_ok, Pass through domain ietf.org 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: Mon, 23 Jan 2023 08:34:05 -0000 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://mailarchive.ietf.org/arch/msg/spasm/DKPDfaQZxF5_De= 9BYuoWsRKp4gM/ A summary of the counter-arguments could be that CAs have me= ssed 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://www.ietf.org/mailman/listinfo/spasm