From nobody Tue Jan 31 04:33:11 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 BF689C14F74A; Tue, 31 Jan 2023 04:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=pass (2048-bit key) header.d=siemens.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 Zw6imPj4hdyg; Tue, 31 Jan 2023 04:33:06 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2082.outbound.protection.outlook.com [40.107.6.82]) (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 0719AC14F740; Tue, 31 Jan 2023 04:33:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SdME+NZ2VEXxqnusvApab/ujrm+k5d4szj+gR21hxYErNRdOwi7xjoxhQ7eQAYJHLMSg0vHLzG4Hcf1L67SV8fBr1ucIz5xoTSIJ4Mb+x5NXeIY1lJH86qH4PSHsXBODEsOn8xl9gLa8Bfe4WUfWFnfhV+5i/qeyLkRHQ2NR3er15ezYgd14xnYWQb5SUiY1FQKBCMN3Lq3T4mtFBk9pLEg5C0As3g5ScMep6ang3MZZS95Q6rHOKUlIr1qek40G8mIjlA406k2sa2AMAlXxtdRG8cZpUj7troTdgEYxmPqepBFxJAhOy5wAgF03zkseezMwQUPBmHMkeMBayHtuvA== 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=eR1aU/kHGicqEhzS/f5TLuKXT4b0qwXWOfWrCRhvucs=; b=iW+uAsydgfC3TpYJkQg76L4rcVANj8HhW335xLgzaNNwkiVcFjhTZ29As9G0Yc0pDHCb2QdmLXekHBmHtRrWb+iKtjI9ouf5l4jNohtKGMNvsXfSWPP4x1Yg7Ay7a4cvBaHiTKV7VwBY3Xg88deciopvSPah4kBrLXGnnFM4y5ya8DenxrflhScpRTkA4fMNcSuepEg4oc0G4TAkGZL+cRPhInhBtKv7bdM+PhO/dGDNtSRn2dVyFTfnbLcEA3Xy/FzjynqE553awvpu5BKGpncAvIq6JE8B/uz0gWco15CDIkSUs0R5qLr5RenHpGT7UgyQB4gTgIN6vEOm8CPN9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eR1aU/kHGicqEhzS/f5TLuKXT4b0qwXWOfWrCRhvucs=; b=W65GEm3487p3OGCNJPxPZllsnBzaVCILCaU5AvV+EZr0fiR4o4x4//ZA4DpUYkL9j3ZQ9u0nl2aa4K633jhLC7I91Vap2enSDczKLfvuWX9ltWaudT3FzxKm+K4ZkE0Y1IEyJP2Me5k8ppdh5sj7bBDs7/9nGchSb8hOeMT4SMw7stS4A3aqfBLTDz50JsqTKRIBHykh4aPbG5+wNEnGldiVQOd1QZvhh+3P/9Bd/vjKDMcWyZe4NdwT8UePSnVoehumeodph21DdE9idHmmsz+FiGPqPjsJlgS2QbjXQp9zPheAejblvNlXATTafAz/ElskFY/PpiYvp/f0PoWEeA== Received: from DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:34c::22) by DB5PR10MB7918.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:4a9::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.36; Tue, 31 Jan 2023 12:33:02 +0000 Received: from DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM ([fe80::804c:aa94:7e98:ccae]) by DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM ([fe80::804c:aa94:7e98:ccae%8]) with mapi id 15.20.6043.023; Tue, 31 Jan 2023 12:33:02 +0000 From: "Vaira, Antonio" To: "Kousidis, Stavros" , "Kampanakis, Panos" CC: LAMPS , "draft-gazdag-x509-hash-sigs.authors@ietf.org" Thread-Topic: [lamps] draft-gazdag-x509-hash-sigs-00 Thread-Index: AQHZFvGjd7zEuqdS50KQZEBiw8H3Hq58fj4AgAioM4CAJrZlAIAMzD3g Date: Tue, 31 Jan 2023 12:33:02 +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: <99a43b5f4620438a9cb7ca539f70dbcb@bsi.bund.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ActionId=a0c1b8ba-bf24-49eb-b097-b0a5b9eb095b; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=0; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=true; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Name=restricted; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2023-01-31T11:59:33Z; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU0PR10MB5244:EE_|DB5PR10MB7918:EE_ x-ms-office365-filtering-correlation-id: 1e8513aa-0626-4749-4f19-08db03874b67 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aJwje8KhN069W8yh2OIZPXbAtJh7UbOzpIOVlIRKhIDTO7pfXcX3yXJ7iYVafnMBI9Sebm+pH6C1ev5MpLoxXlXOuojZtY9DvpBF9+S0im06mTw1tl4p5USRT6jcMb7yLmSC73fZ/8ISonKqCkdrss/6MpYvBAMLhsqqNMb4d6MX/TYc87XMB5odpAKhe1Y2WXoRMldbq9QEaaDjjsF/49PgMwmwWCjVg+qtaolprKWJaGszdEDXTI8gitjwUNznRlzQIoIqLr7k0PgVhAZBkJuRQL+HEZ60jH6LYazHhtnRpcdJXDYGsnB5oVT2zn78p/GJHGWodCKKJ8A530Cc34CxNoU4B3opiuG//vWG8QaSCzeJMTsWm8hel544Y2lvi+xHtGoDhFDLr0Mu8jO4FpWxLhmr6e0hLAhWV3sVrurpoBQFKweB4QMzv6TxEspUaVTdxm+UIttJtCAfPIAhH3m2jEAL3RCoOMCkMVyJGnKd86iaLZR8uMMbDasr+qfn6qd+eg9eT9osMPSEdXW1LpUsP5l4MYb5Z2kFEUte0q9hVCnajhUS8+Kl+qPP3lXRNeoY/z6E4OCJqNnEdmrh+mlD7US0lvFeRdGnVcGK/UEE3GDLcglKFghGowucb8fyvKqKZe6rmqg6QJOGuBoaYoony2h+GkDRtyawJxXlvCi3Rwqml86k7NxoEEQ2O53SkFfmTCo6fMu/kO9pqi+V6JA/yBe8dBn/GTybFEBnEar6+hADWvqBpUETU9/VD7qs9uYA/sxbh/lBPN1AFTljRA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(396003)(376002)(366004)(39860400002)(346002)(451199018)(5660300002)(55016003)(2906002)(33656002)(122000001)(38100700002)(66899018)(966005)(66574015)(7696005)(45080400002)(53546011)(478600001)(6506007)(186003)(26005)(9686003)(71200400001)(82960400001)(38070700005)(86362001)(4326008)(76116006)(83380400001)(110136005)(8676002)(54906003)(64756008)(66946007)(66446008)(66556008)(66476007)(316002)(8936002)(41300700001)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?6DTNW6xQea8G4Kxu+JdJeKTepRdE3rhjyOUSJe2EeGXoodbSvV98LD/+Gq?= =?iso-8859-1?Q?Dl7WPBHZJjbvH2tagbKP8JEfW04GwEi3XPRU8xFhE/V9zTVyDJHz8qjoHJ?= =?iso-8859-1?Q?HjewRp6pXeXAlZCyxXJsltVo3BS2S+bm01VNqRs2CkXMnqo0UPX4VBXG26?= =?iso-8859-1?Q?3EtRU+krAO2bXf6qLNPpP2xZEioqCIPB3GQtKJnFXq9JlnICBm/SdiTHvV?= =?iso-8859-1?Q?hi4yzjsXsXl4y76EjZ1ih8UES7MtoVuHYTgd0nhsIoUDKvMJfK4V6ZlrsA?= =?iso-8859-1?Q?4kqLBNUV/l2npr6b1Vu/Gebuy+WyD1IhrouOW/FyhLbTOKfoojg0pudNWc?= =?iso-8859-1?Q?7HABcdYSckMvHXLVg+6EXgnYN+J7JccL/yVHPjg1Ud9A/BQg5SArbE+RQk?= =?iso-8859-1?Q?ozCaPw3xoM98SylEqk1YBitSupp1zhAxK6PB8WYsZprC1D+g0iCdvbbUhz?= =?iso-8859-1?Q?8BzyBS4yhxsLi/PsY2olAhK0Mu/v3u5NMiEd/zIBasWXlV/wN92Kd4fKiB?= =?iso-8859-1?Q?zYEFppjyiwxSmf0jKLMqI7pc6KZBuM0OxajIGcYwE6+MBg1mcKRXKXbYog?= =?iso-8859-1?Q?9pB5r925EtK9+T5kvLv26/0lzpey1S3coeIU3r12wsqBkaoMTQi/swUz5y?= =?iso-8859-1?Q?dpqiRAI0MHLku3qYVZq4C/lkw5NTYlCN2AwtgEfltqubQZPvhhBjoGpsal?= =?iso-8859-1?Q?SvP2WH/oun7r3+6NKV8iruH1xaA7ZC4azqp/inY2PpZyOm1y+ARacwFWak?= =?iso-8859-1?Q?a4dOtACFMI0wLZykKkx1rTad6MHfxBVV9pGIc3R29x9290qpdb9AK9B3iZ?= =?iso-8859-1?Q?/0Z3Ay3wsBQoigT1Jq65bdvNwUyTOO+R+1ps7X8aUxr3itC5S4xlnd5Xeu?= =?iso-8859-1?Q?+89tc8Vb84pdebY+1SLgruczXRo9k2t3425WYtBfCpMFEVKfxCorkkx9ps?= =?iso-8859-1?Q?5nGXnBtttZCHxQz+D5BTiovmfq3DShuAtWvREN2H/ZQTe1xwv2xmnsopet?= =?iso-8859-1?Q?Ust8aVqm9k4qdPrRnOrztVlJdTG2TE9FZ4vpFIXZOmFIQCxISbDULm4oR1?= =?iso-8859-1?Q?1OLZAMLoY2LV2RV4FMeyf/vQoz76PbAWy9yR7hnqkqG9u4RlQPPaoowMiW?= =?iso-8859-1?Q?J6DKH9REVf6a2rzH33LrBTwNtDOiKnay6Rn4wS8SXQiQfy/2AL2ncg/Tgm?= =?iso-8859-1?Q?Q41FHhkZ2owpny4S+IS/uQHThXl7QAuQoX3xNim0PYyq3WjScDL83Sj6Kb?= =?iso-8859-1?Q?4zpsTpVZe9ayuCvrua094rb2xtNaWluLXLg9TwLyCcArQGRuI2g3olJFgE?= =?iso-8859-1?Q?2Kmlp/xSv1pDEDHb1mlrwgehgiENCWBN/rw4ZOicCtuswnC62xITp4FXzP?= =?iso-8859-1?Q?BmV+0WEqFUGIeOnnPLRAHNE81hWOCvSuBnUA417gQFWGKaSogC8wLe3Qzx?= =?iso-8859-1?Q?ZB1zGg96RzAWPAiQUjfPrOp+PubE3WRb5WR5Z0BTdAjg4O25gtKUOcEmlv?= =?iso-8859-1?Q?b6VM5zkXja4HzVszLlu+4McH9AVtQfDs3O1SKZlPyMxXigAUQATrDlHihi?= =?iso-8859-1?Q?F67b45x2ZXVfYJXNtfzqig4iMeYFW8UO2T/ZaBWa2ki1YFRM9ygWPNjRO4?= =?iso-8859-1?Q?rwDJJI1hSmfYNyNI9pY2mjiv8xSZ6A3+h1MtX4Bha2ZJMP/PP3JEw3HQ?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 1e8513aa-0626-4749-4f19-08db03874b67 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2023 12:33:02.3274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PlZscN6r/YCOfJNdowaCUmlKjnHBulZKOXN/eDhXi4HLfVhQhuloTG+we/O4Qg2Dm6xcVNM3Lpr5nQkMTKNvh1enULpQh+sE6NhpsaC/b84= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR10MB7918 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: Tue, 31 Jan 2023 12:33:10 -0000 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