Re: [lamps] [Pqc] Auditing HBS state usage

["Vaira, Antonio" <[e-mail]>]

Dear all,

Many thanks for the interesting discussions and inputs.

My main take away for these exchanges is that most likely there will not be a trustworthy technical/mathematical method to prove that stateful signature operations are carried out in a compliant manner and it will indeed boil down to "trust and risk perception" linked to a specific use case.
I am inclined to think that for the majority of use cases, where a moderate level of assurance on the signing operations is required, it might be enough to trust the HSM and the operational team to follow the right procedures and pass periodical external audits.

Thanks
Antonio

-----Original Message-----
From: Fregly, Andrew <[e-mail]> 
Sent: Tuesday, 31 January 2023 22:35
To: Scott Fluhrer (sfluhrer) <[e-mail]>; Mike Ounsworth <Mike.Ounsworth=[e-mail]>; Kampanakis, Panos <kpanos=[e-mail]>; Vaira, Antonio (T CST SEA-DE) <[e-mail]>
Cc: LAMPS <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Pqc] [lamps] Auditing HBS state usage

State auditing based on embedded state in signatures may be quite challenging when distributed signing processes are used for hash-based signatures. Consider the scenario where HSMs are allocated to separate lower levels of a hierarchical tree structure. This is the scenario currently required for distributed signing with HSS or XMSS^MT to be in compliance with NIST SP 800-208. It is described in section 7 of that document.

Andy Fregly

On 1/31/23, 1:10 PM, "Scott Fluhrer (sfluhrer)" <[e-mail] <mailto:[e-mail]>> wrote:


Actually, it's not that hard to extract the current state from either an XMSS(^MT) or LMS/HSS signature.


For XMSS and XMSS^MT, the current state is at a fixed place in the signature.


For HSS, the state is scattered in the signature; however it's not *that* hard to retrieve...


So, expressing the current state explicitly in the certificate might make things a bit easier; however it doesn't fundamentally change anything


> -----Original Message-----
> From: Spasm <[e-mail] <mailto:[e-mail]>> 
> On Behalf Of Mike Ounsworth
> Sent: Tuesday, January 31, 2023 10:51 AM
> To: Kampanakis, Panos <kpanos=[e-mail] 
> <mailto:[e-mail]>>; Vaira, Antonio 
> <[e-mail] <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>;
> [e-mail] <mailto:[e-mail]>
> Subject: Re: [lamps] Auditing HBS state usage
> 
> [changing title, and adding PQUIP list]
> 
> > - 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 
> authentication path and embed it into a certificate field? Maybe such 
> certificate 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 auditing.
> 
> 
> IMO the list of certificates issued by a CA is already well tracked and audited.
> IMO if we're gonna get ourselves into trouble with over-using a HBS 
> key, it's gonna be uses of the CA key for things other than 
> certificate signing; like a stuck process that re-issues the same CRL 
> 500 times, or a CA set up for direct OCSP or CMP signing with the CA 
> key, or .. who knows .. some CA software that uses the CA key for 
> backend TLS connections, or that uses the CA key to sign audit 
> records. All things that are completely not a problem today, so 
> developers and ops personnel might not even think about them 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 HSM 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 <[e-mail] <mailto:[e-mail]>> 
> On Behalf Of Kampanakis, Panos
> Sent: Tuesday, January 31, 2023 9:28 AM
> To: Vaira, Antonio <[e-mail] 
> <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>
> 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 
> > 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 
> authentication path and embed it into a certificate field? Maybe such 
> certificate 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 verification 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 relatively 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 them to be auditable to 
> confirm state/OTS public key was not reused. It would be operational 
> overhead for vendors though to make all their signatures available.
> 
> There is the threat model that is important here as well. If I am the 
> verifier of company X created by company X to verify company X's 
> software signatures, do I need to audit company X's signing did not 
> reuse SHBS state? Probably not because I trust the signer who is 
> probably auditing internally. But still, a published code signing repo 
> of all (Root signatures and ICA issued signatures and software 
> signatures) could provide assurance to 3rd parties that want to be 
> sure. It still is not perfect because someone could argue that some 
> failure scenario while signing may have reused state but the signature did not show up in the published signatures, but it certainly raises trust.
> 
> 
> 
> -----Original Message-----
> From: Spasm <[e-mail] <mailto:[e-mail]>> 
> On Behalf Of Vaira, Antonio
> Sent: Tuesday, January 31, 2023 7:33 AM
> To: Kousidis, Stavros <stavros.kousidis=[e-mail] 
> <mailto:[e-mail]>>;
> Kampanakis, Panos <kpanos=[e-mail] 
> <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>
> Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00
> 
> CAUTION: This email originated from outside of the organization. Do 
> not click 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 of 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 certificate 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 RootCA, 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 authentication path and embed it into a certificate field? 
> Maybe such certificate can be further published, for example on CT, to 
> allow public scrutiny of the CA operations?
> - on a more generic note, the recent publication of CNSA 2.0, despite 
> applying only to NSS, may trigger other regulatory bodies, which may 
> be transversal 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 §7 of NIST SP 800-208.
> > in my understanding, to fulfil the requirements set forth in this 
> > section
> one would that initializing several hypertrees on different HSMs. One 
> or more HSMs may be used immediately and the remaining should be 
> securely stored for later use (as disaster recovery mechanism for 
> example). I think this approach might prove to be quite cumbersome, at 
> least over a long period of time (which is intended use of stateful HBS).
> > do you see additional approaches that would allow to comply with the
> requirements from §7 of NIST SP 800-208?
> 
> 
> Many thanks
> Antonio Vaira
> 
> -----Original Message-----
> From: Spasm <[e-mail] <mailto:[e-mail]>> 
> On Behalf Of Kousidis, Stavros
> Sent: Monday, 23 January 2023 09:33
> To: Kampanakis, Panos <kpanos=[e-mail] 
> <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>
> 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
> subordinate) CAs which are using an HSM for cert signing that ensures 
> the secure handling of the state. When discussing this in the security 
> considerations we would also stress on NISTs proposal to use 
> "Distributed Multi-Tree Hash-Based Signatures" (see NIST SP 800-208 
> §7) as a design to further ensure that states are handled appropriately.
> 
> We have tracked the other use cases you mentioned as an issue in in 
> our repository. I think Stefan Gazdag has some experience here and we 
> will discuss how to incorporate your suggestions in the security considerations.
> 
> Best
> Stavros
> 
> -----Ursprüngliche Nachricht-----
> Von: Kampanakis, Panos <kpanos=[e-mail] 
> <mailto:[e-mail]>>
> Gesendet: Donnerstag, 29. Dezember 2022 18:23
> An: Kousidis, Stavros <[e-mail] 
> <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.c
> o&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df03c808d
> b03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638107977225684
> 573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmakNR805nAoNcBlHUpc43L
> LgxlYvwH870W6Gcu8uww%3D&reserved=0 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
> defense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.
> co&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df03c808
> db03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63810797722568
> 4573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmakNR805nAoNcBlHUpc43
> LLgxlYvwH870W6Gcu8uww%3D&reserved=0>
> m/?url=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fspasm*2FDKP
> DfaQZxF5_De9BYuoWsRKp4gM*2F&data=05*7C01*7Cantonio.vaira*40siem
> ens.com*7C42f367be82dd413a64ae08dafd1c9a04*7C38ae3bcd95794fd4add
> ab42e1495d55a*7C1*7C0*7C638100596561496300*7CUnknown*7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0*3D*7C3000*7C*7C*7C&sdata=h25km8rodm9XTku1Chgjffe*2BEm9dOR
> sXhMwrrDhcVzQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OhAlgSN8g$ A summary of 
> the counter-arguments could be that CAs have messed up before, how can 
> we rest assured they will not reuse state.
> 
> 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. 
> Maybe another use is for code-signing EKU certs where the signer 
> controls its signing process and the verifiers trust it. The draft 
> also mentions subordinate CA certificates. I don't think these are 
> good use-cases for stateful HBS. I would suggest for the draft to 
> clearly stress the potentially use-cases for Stateful HBS. Also I 
> suggest for the security considerations section to stress the 
> importance and how you envision these use-cases will be able to 
> address 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 track of all its signatures and can go back and 
> attest the state was not reused periodically and its verifiers usually 
> trust the signer. Another one could be the state look ahead where you retrieve x states and change your pointer before you even start signing anything.
> 
> 
> 
> -----Original Message-----
> From: Spasm <[e-mail] <mailto:[e-mail]>> 
> On Behalf Of Kousidis, Stavros
> Sent: Saturday, December 24, 2022 12:11 AM
> To: Russ Housley <[e-mail] <mailto:[e-mail]>>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>
> Subject: RE: [EXTERNAL][lamps] draft-gazdag-x509-hash-sigs-00
> 
> CAUTION: This email originated from outside of the organization. Do 
> not click 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üngliche Nachricht-----
> Von: Russ Housley <[e-mail] <mailto:[e-mail]>>
> Gesendet: Freitag, 23. Dezember 2022 18:12
> An: [e-mail] 
> <mailto:[e-mail]>
> Cc: LAMPS <[e-mail] <mailto:[e-mail]>>
> Betreff: [lamps] draft-gazdag-x509-hash-sigs-00
> 
> Dear I-D Authors:
> 
> RFC 8708 has this definition:
> 
> HSS-LMS-HashSig-PublicKey ::= OCTET STRING
> 
> This will carry the bytes as defined in RFC 8554.
> 
> draft-gazdag-x509-hash-sigs-00 says:
> 
> HSS-HashSig-PublicKey ::= 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
> [e-mail] <mailto:[e-mail]>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.c
> o&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df03c808d
> b03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638107977225684
> 573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmakNR805nAoNcBlHUpc43L
> LgxlYvwH870W6Gcu8uww%3D&reserved=0 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
> defense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.
> co&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df03c808
> db03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63810797722568
> 4573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmakNR805nAoNcBlHUpc43
> LLgxlYvwH870W6Gcu8uww%3D&reserved=0>
> m/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=
> 05*7C01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd
> 1c9a04*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C63810059656
> 1496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=BzfXk7I
> kssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserved=0__;JSUlJSUlJSUlJSU
> lJSUlJSUlJSUlJQ!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OirgtotNA$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.c
> o&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df03c808d
> b03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638107977225684
> 573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmakNR805nAoNcBlHUpc43L
> LgxlYvwH870W6Gcu8uww%3D&reserved=0 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
> defense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outlook.
> co&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df03c808
> db03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63810797722568
> 4573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmakNR805nAoNcBlHUpc43
> LLgxlYvwH870W6Gcu8uww%3D&reserved=0>
> m/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=
> 05*7C01*7Cantonio.vaira*40siemens.com*7C42f367be82dd413a64ae08dafd
> 1c9a04*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C63810059656
> 1496300*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=BzfXk7I
> kssXiXjWumPeivk5qXUsPP2tXjqRJZXx3QB8*3D&reserved=0__;JSUlJSUlJSUlJSU
> lJSUlJSUlJSUlJQ!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OirgtotNA$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F
> spasm_&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df03
> c808db03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6381079772
> 25684573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ppnQS0FS5qvKtaO7aI
> E0Rw4nO%2BUAWN2GH6hDg9OvY94%3D&reserved=0 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
> defense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2
> Fspasm_&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df0
> 3c808db03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638107977
> 225684573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ppnQS0FS5qvKtaO7a
> IE0Rw4nO%2BUAWN2GH6hDg9OvY94%3D&reserved=0>
> _;!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F
> spasm_&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df03
> c808db03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6381079772
> 25684573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ppnQS0FS5qvKtaO7aI
> E0Rw4nO%2BUAWN2GH6hDg9OvY94%3D&reserved=0 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
> defense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2
> Fspasm_&data=05%7C01%7Cantonio.vaira%40siemens.com%7Cdce17b85daf248df0
> 3c808db03d30d86%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638107977
> 225684573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ppnQS0FS5qvKtaO7a
> IE0Rw4nO%2BUAWN2GH6hDg9OvY94%3D&reserved=0>
> _;!!FJ-
> Y8qCqXTj2!esBnp7Nl7B1z9kQbd2Cr_cAnMTdMiIqi4_tPkbBohCOjROZnG7We
> Ocu5HmlSVFHnbif3t0MFYttHiFf4DUHO8hDBsvLpjr-H6OgQtC7kZg$
> Any email and files/attachments transmitted with it are confidential 
> and are 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 Entrust immediately and delete the message from your system.
> 
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Cantonio.vaira%40s
> iemens.com%7Cdce17b85daf248df03c808db03d30d86%7C38ae3bcd95794fd4addab4
> 2e1495d55a%7C1%7C0%7C638107977225840808%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=lEUwNjLS%2BO5uBs9CJNCOIIUVVROtSftXWRdgIlL0nzE%3D&reserved
> =0 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Cantonio.vaira%40
> siemens.com%7Cdce17b85daf248df03c808db03d30d86%7C38ae3bcd95794fd4addab
> 42e1495d55a%7C1%7C0%7C638107977225840808%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> C%7C%7C&sdata=lEUwNjLS%2BO5uBs9CJNCOIIUVVROtSftXWRdgIlL0nzE%3D&reserve
> d=0>