From nobody Tue Jan 31 07:51:04 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 03EEBC14CF05; Tue, 31 Jan 2023 07:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=pass (2048-bit key) header.d=entrust.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 9224JkUsKWcd; Tue, 31 Jan 2023 07:50:58 -0800 (PST) Received: from mx07-0015a003.pphosted.com (mx07-0015a003.pphosted.com [185.132.183.227]) (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 C2056C14CE55; Tue, 31 Jan 2023 07:50:57 -0800 (PST) Received: from pps.filterd (m0242864.ppops.net [127.0.0.1]) by mx08-0015a003.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30VB5fIr030091; Tue, 31 Jan 2023 09:50:55 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=mail1; bh=Qxl4b9cal/TZXDjKW1MFWlCcHoJGGHy7FpCKqoyWAUs=; b=Pf0/LGaWK6+C7vMo5mx1UpY5wmIDa6EsbXkgOARrNCMZhv1kypeMSBjLqkbC5J/lg41k zV+GWj7B7dr9iSfVBMm4yP32vQU4VmWL5+SWgFDXPBTuCmSRqd9geoE8mS8c2xc2a8gq DUbGfiJAtfPigzwM1NuV9WSmpFYygYUNIJKUMBGGPoO1TRTZJFmysQlqZSGzYZxPJ5F5 QIPfzA8JXOMZNJh4LRCU2IAAxpXjQ9BvqqXObXoYsNlFtiymII6HbELAzH7SHOcRc/6z rKR4eF/+a5OLm3YRopznhCTPCmH8rbUpS/w6yIObGJ9GZFSJGtIjVc8u/BiPFLjrPN0y Jw== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2177.outbound.protection.outlook.com [104.47.55.177]) by mx08-0015a003.pphosted.com (PPS) with ESMTPS id 3nd196up25-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Jan 2023 09:50:55 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hC3W0FCBWQpN++C+ZMVhNYibzJS69BC2BPfQAnUAdJLDjmFCYlz0Eq//BmaHlwUYTxNuY+wqP7eRbKIbN12eOZO4Ns3g03kiRVeNBN8ef0AKJyYDqAEXQEbXSeiPAhQqqBdMvzvm/IIJqt2w6avuY/DXDpfFpqCJKgL1sYzSUp5XYWX3ItsDXLNHiyRp1DFmvh9d9qwPiWfYSnilV1v1AS0mgbylNzNScEvx0KYLj244yVXUkN88Jf845S2f9u2eXsaPVUwVxiJD7s24XMp+x+MoIm/KiwwyOjLK4ByH0YzflQdriyNY8F4D9pElHVDxDzCtdNN5twyDyBl1P9cIFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Qxl4b9cal/TZXDjKW1MFWlCcHoJGGHy7FpCKqoyWAUs=; b=VuUHZ29qtvZhI3Zd3pnMYB7PlZHlHs7MCLXOYFoXu2ypk3KCEQT2xlqUaxZlSMbAMk57CwbSpqlDQrEVD823pfsVbmHwRoaaqykJRShlMe5KIecISUgPXT/8c03xYguSagY8wgo076UAdzi4XkqJDvAQEgLYVcV0wKRCdWQa5jhpfNVnqHmc0axd2Jp9vT/ogXvAwOdCYJbVcQhEYzdd0ZQql/0GZrnXi+/LZ+pzfUPwAk0C/HKolOTelHHtku2VwJZ81/eZLxBIl78W8c54JQXF+W+kiagjbT+TtGSYuuxmvAALGst6on1XUZMoz/2WUz6WqqnFOXDW13jFddBbNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none Received: from CH0PR11MB5739.namprd11.prod.outlook.com (2603:10b6:610:100::20) by PH7PR11MB6403.namprd11.prod.outlook.com (2603:10b6:510:1f9::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.38; Tue, 31 Jan 2023 15:50:52 +0000 Received: from CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::3000:a478:192a:3860]) by CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::3000:a478:192a:3860%4]) with mapi id 15.20.6043.038; Tue, 31 Jan 2023 15:50:52 +0000 From: Mike Ounsworth To: "Kampanakis, Panos" , "Vaira, Antonio" CC: LAMPS , "draft-gazdag-x509-hash-sigs.authors@ietf.org" , "pqc@ietf.org" Thread-Topic: [lamps] Auditing HBS state usage Thread-Index: AQHZNYvLJFhNQHS890WcGYc42bP4AQ== Date: Tue, 31 Jan 2023 15:50:52 +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: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH0PR11MB5739:EE_|PH7PR11MB6403:EE_ x-ms-office365-filtering-correlation-id: 634e660a-7131-4449-bd20-08db03a2ee76 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mQR3fplt7tI8frMtckncHfdy3YbkNg3dYllfLtAYGDg1LlB7AVIPyEZr/Wuvd9o+jEOvwQuCO/0lCgg3UbBIl8HR86HZffI+iy2DmEJm0UXgXb87vhJciCxrL0suTan5Cru8iFIdtD7bMGKPcTLR1PPDlWJt7pMthYrrB1Wt9+9MNk/vF4hw822cWTp0NuN2knX1zu9Jy71gg5yDZr/6YAodqxuw51Z8buTQG2mgYAeSk8c6OVxECTFDoQggDs3ZtQmGW/ih7aHdzFbIjcsI4LJk+xl6SNHe5DFFhtkycv1Li3UbUvG6WgodvFkQRj9d1mzINfzwXicQ5eiAg0su8Dl5Wu+0OabgvQaEqW0OSsnYbGm7V2LqBd1VYmDQ0tKO6LbHhnLTe/t0etJur5C5romaIOlquvQv50Cc1VYUCTQleuZhUJJkQH3aqGxCe48VlDL+Y4YGyZTo+WnXX6NLZtVygwwLTWgsYD1VNfom7duX39EmgHJ5a4a8Em9CX6nqRpGWVaNhxeeOV5oKUhEkfEXfV4f2TLe6QIYmRqqK8FUUS1H2Q5VACIeOMdyXP/VXlX0kWO8F+GFwJnP6aHl9QhQ8INfYO3naVyXbljGJom4buILF+5Pkla8dnOTmo6zjQ3BZnBpxwzLbqnz4p14+vPFkIrnXHkoKfkfQ2ZWmmbMTgCFFESYKMKGa7C3qa7jO8AxMNQtoqyw6eFSe3pPZsd9lxKC5R0fhGSdnZcfwukY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR11MB5739.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(39860400002)(366004)(376002)(396003)(136003)(346002)(451199018)(41300700001)(66446008)(64756008)(66946007)(66476007)(66556008)(316002)(110136005)(54906003)(8676002)(4326008)(76116006)(8936002)(5660300002)(52536014)(122000001)(38100700002)(86362001)(38070700005)(33656002)(66899018)(6506007)(53546011)(186003)(966005)(26005)(9686003)(71200400001)(83380400001)(30864003)(66574015)(2906002)(55016003)(7696005)(45080400002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?10arDqa6e4g5jjVUffO1ByGz7YrMunGi8t4lbS+v0DqjILSBoONxJQ4lkT?= =?iso-8859-1?Q?qie5kHQDonx9+c79dDfRFqy5/B1gLq7ztMPlF6vFyRNQrD7qK8Wg02drtW?= =?iso-8859-1?Q?rMbwi0h9aZTgfOVMgV/MblH65gbxuspSL5chCScPPsA2s1ojiIcE2XWqEV?= =?iso-8859-1?Q?eTkbnkoMIS9qPeZw0f7yhuv0JjPzJBudy/xJjQtGJC36YizXTwc7ghEcZ8?= =?iso-8859-1?Q?nOc0JSPKeFXqxNciCBvhZ3gPiZIzHh9q3A33QIXsxeWHoC9MyOJ6oC0ItO?= =?iso-8859-1?Q?A2FRidGkG764NFHD0Kn0Pe2kmjNfFNbixjuBkK53TTB3dYyw9Zgr36Li7S?= =?iso-8859-1?Q?Ooggr8MHbqhPvvzmzATrZa1hmTcsCbXgwDA6tuw84JXSm4XT0WUST5hBTk?= =?iso-8859-1?Q?GGxLh9SsOZWkn2xWnGiCo088lgq5qRu2onJDBTU4jUfYTMGr5HpGxCqOGc?= =?iso-8859-1?Q?L0MoXKoBZ7v3B4OHZmwU1gaGNvg8eFQx53BfQpr2lt7At3aAyksh97Z++S?= =?iso-8859-1?Q?FQ3KO0gzpPVoK6reagIKXQr3W+BpsQZkRSHshX+CZsn9dZC1VaBfLFCxuV?= =?iso-8859-1?Q?1CfgWglBOC0sgW3IE6OsN9sPehxdO9/RubqGnHrBrOI8DDUq5qRpHxDZZi?= =?iso-8859-1?Q?AR/XoTF7CC41SKvbH2VOqpGHkQUg58PlxeDclym0spDYz7/ZxOmMer+BmI?= =?iso-8859-1?Q?O9TrIyCpAlBh1GAfXrIwMkXHzDYeNeZ16J+ADbb4hzO+35grMxIpxiw9gc?= =?iso-8859-1?Q?rSXQ9pUkX73X9C436rnqo2z8vHAzW+kEANQRO7TUCS8Tc9Rnf51b6rURgy?= =?iso-8859-1?Q?erhm8Uuef5oeTt6S/3R3qIfF3+XYGMF7YLkYe/HlsuP6INX7CL6FUQdHub?= =?iso-8859-1?Q?P3z9fCggrXwapBfVucd7Wx0/9plzwBEQSE0l4u5AF4oQ39VukO/QvcEBNW?= =?iso-8859-1?Q?4H7nA0Fld1DjUFrBLNjn2UiuAHaSs4iRwgGl+0OWiaw0DX5TW4di0DQq3n?= =?iso-8859-1?Q?l/8yFjc/a4bMrWkmqK7ASE64Zc8eODcuX0is51SQVUmTlOgQ24bO4665xP?= =?iso-8859-1?Q?PpvyLhK8JRZeaZ8ZUuLqHWEOlIzRMmZtaEiW7X+xfTrPQL/aDIEeRWo+qD?= =?iso-8859-1?Q?hhYj65CXq3XXrmKZyi1j3jYqiAKRWXKhzxGfysNaAjBfrr5LmlU+WY87ss?= =?iso-8859-1?Q?2hsEOhYWN0xr1k4Z61Z8YH2Mm654jkRjqkhcIoDPV00MbmvkmkYpjiB1q2?= =?iso-8859-1?Q?ryvAvbNAoD6gj40H5UnAbJm4xY66Dv1lJ316Or8p05qx9cH34IZY6a32gV?= =?iso-8859-1?Q?R3Pnd0xZmXL10kENBsVjT3sOxCqJKpgJpZpDjYOdhOHX+tlC6Ug14rnuiz?= =?iso-8859-1?Q?EZNKh+VcIGd7ROpfiBYGCO1uxxGzE0XcmqNIeU1PisEKF8DLJ9F3rMcRfH?= =?iso-8859-1?Q?dBOGmw+9KJWqHSWN1diI9lOB5hiPRzMJiETGmh4ChRZ4MfNk2l/jEu/W5F?= =?iso-8859-1?Q?8giFZR66xTU1lNyMh2Oi4YyCDux8ub4jOvFypiquwOUzdWFmTuc/0wjWV6?= =?iso-8859-1?Q?HgIOFqsrb0be/M8y56i+hwF1duoq5aLEouCHIgG7SA3RyTbYfW1aKQGXv1?= =?iso-8859-1?Q?0KmrY2Sujr4X+vcLng3yV8UpM+xA8ldVrF?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: entrust.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH0PR11MB5739.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 634e660a-7131-4449-bd20-08db03a2ee76 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2023 15:50:52.2932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: W6uYY2dgWUwBQoGpc71ZFtL8BLQ+uF/bb+DUK5qag187ys1W7KR0+TIzI27wu7XU7xYl9HIoRjESdEfRoxyMmfvqRZg3hZilN6+T2wNAcZE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6403 X-Proofpoint-ORIG-GUID: 8KGS0gGL7x0Hi3XYvapxUDzQIIu2rh_5 X-Proofpoint-GUID: 8KGS0gGL7x0Hi3XYvapxUDzQIIu2rh_5 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-31_08,2023-01-31_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 impostorscore=0 malwarescore=0 mlxscore=0 clxscore=1011 adultscore=0 suspectscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 phishscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301310140 Archived-At: Subject: Re: [lamps] Auditing HBS state usage 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: Tue, 31 Jan 2023 15:51:02 -0000 [changing title, and adding PQUIP list] > - 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. Could we think to derive a unique value, out of this authe= ntication path and embed it into a certificate field? Maybe such certificat= e 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 a= uditing. IMO the list of certificates issued by a CA is already well tracked and aud= ited. IMO if we're gonna get ourselves into trouble with over-using a HBS k= ey, it's gonna be uses of the CA key for things other than certificate sign= ing; like a stuck process that re-issues the same CRL 500 times, or a CA se= t up for direct OCSP or CMP signing with the CA key, or .. who knows .. som= e CA software that uses the CA key for backend TLS connections, or that use= s the CA key to sign audit records. All things that are completely not a pr= oblem today, so developers and ops personnel might not even think about the= m 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 H= SM 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 On Behalf Of Kampanakis, Panos Sent: Tuesday, January 31, 2023 9:28 AM To: Vaira, Antonio Cc: LAMPS ; draft-gazdag-x509-hash-sigs.authors@ietf.org 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 priva= te key can be uniquely identified by the authentication path that is part o= f the signature. Could we think to derive a unique value, out of this authe= ntication path and embed it into a certificate field? Maybe such certificat= e 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 v= erification 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 relativ= ely 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 t= hem to be auditable to confirm state/OTS public key was not reused. It woul= d be operational overhead for vendors though to make all their signatures a= vailable. There is the threat model that is important here as well. If I am the verif= ier of company X created by company X to verify company X's software signat= ures, do I need to audit company X's signing did not reuse SHBS state? Prob= ably not because I trust the signer who is probably auditing internally. Bu= t still, a published code signing repo of all (Root signatures and ICA issu= ed signatures and software signatures) could provide assurance to 3rd parti= es that want to be sure. It still is not perfect because someone could argu= e that some failure scenario while signing may have reused state but the si= gnature did not show up in the published signatures, but it certainly raise= s trust. -----Original Message----- From: Spasm On Behalf Of Vaira, Antonio Sent: Tuesday, January 31, 2023 7:33 AM To: Kousidis, Stavros ; Ka= mpanakis, Panos 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 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 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. Stateful HBS had come up previously for X.509 and some participants voiced = serious concerns https://urldefense.com/v3/__https://eur01.safelinks.protec= tion.outlook.com/?url=3Dhttps*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fs= pasm*2FDKPDfaQZxF5_De9BYuoWsRKp4gM*2F&data=3D05*7C01*7Cantonio.vaira*40siem= ens.com*7C42f367be82dd413a64ae08dafd1c9a04*7C38ae3bcd95794fd4addab42e1495d5= 5a*7C1*7C0*7C638100596561496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA= iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=3Dh25= km8rodm9XTku1Chgjffe*2BEm9dORsXhMwrrDhcVzQ*3D&reserved=3D0__;JSUlJSUlJSUlJS= UlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBo= hCOjROZnG7WeOcu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OhAlgSN8g$ A summ= ary of the counter-arguments could be that CAs have messed up before, how c= an we rest assured they will not reuse state. 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 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://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/= ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=3D05*7C= 01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd1c9a04*7C38ae3= bcd95794fd4addab42e1495d55a*7C1*7C0*7C638100596561496300*7CUnknown*7CTWFpbG= Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C= 3000*7C*7C*7C&sdata=3DBzfXk7IkssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserv= ed=3D0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_= cAnMTdMiIqi4_tPkbBohCOjROZnG7WeOcu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H= 6OirgtotNA$ _______________________________________________ Spasm mailing list Spasm@ietf.org https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/= ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=3D05*7C= 01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd1c9a04*7C38ae3= bcd95794fd4addab42e1495d55a*7C1*7C0*7C638100596561496300*7CUnknown*7CTWFpbG= Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C= 3000*7C*7C*7C&sdata=3DBzfXk7IkssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserv= ed=3D0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_= cAnMTdMiIqi4_tPkbBohCOjROZnG7WeOcu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H= 6OirgtotNA$ _______________________________________________ Spasm mailing list Spasm@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!= !FJ-Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7WeOcu5HmlSV= FHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$ _______________________________________________ Spasm mailing list Spasm@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!= !FJ-Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7WeOcu5HmlSV= FHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$ Any email and files/attachments transmitted with it are confidential and ar= e 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 Entr= ust immediately and delete the message from your system.