Re: [Suit] Information model updates

[Brendan Moran <[e-mail]>]

Hi Dick,

> On 3 Jun 2021, at 12:44, Dick Brooks <[e-mail]> wrote:
>
> Hi Brendan,
>
> Thank you for that very insightful description of the process – very helpful.
>
> The process you describe is clearly the result of methodical thought, analysis and design.
>
> However, the small community of SCRM software vendors, including REA, are implementing controls to identify SW risks proactively, prior to any change to the baseline state of a device.

Lets try to be clear about exactly which objectives are achieved by each part of the SUIT Specification and the surrounding entities and protocols.

The SUIT manifest specification is designed, primarily, to be a contract between the Firmware Author and the Recipient. The exact meaning of Firmware Author can be somewhat variable, but ultimately, it means the holder of a private key that is associated with a Trust Anchor known by the Recipient. It’s very much intended that this key be air-gapped, or held in an HSM, not an online signing system, since such platforms instantly become high-value targets for adversaries.

This is explicitly not the same as the relationship between the Firmware Author and the Firmware Distributor, nor the relationship between the Firmware Distributor and the Recipient. There are certain provisions in the manifest to enable those relationships as well.

> Yesterday, Microsoft announced the acquisition of ReFirm Labs, which is one of the SCRM vendors  that performs this type of interrogation of a binary object before any attempt to install or run the software or make any change to the  baseline state of a device.
> FYI: IMO, Refirm Labs is a trophy catch by Microsoft – Binwalk is the gold standard for pulling apart a binary to assess its components. Microsoft even produced a cute little video showing how this works – note everything happens before the SW goes to an IoT device: http://aka.ms/refirmadiotvideo
>
> Complete announcement from Microsoft is here: https://www.microsoft.com/security/blog/2021/06/02/microsoft-acquires-refirm-labs-to-enhance-iot-security/
>
> IMO, sending the software to a device to make these SCRM risk assessments appears to be in violation of the NERC CIP-010-3 software verification regulation as sending the SW to the device appears to be a change to the device baseline. Others may see this differently.

The manifest is not the software. The manifest is software metadata, security material, and instructions required to install the software. As such, sending a manifest to a device does NOT change the device baseline.

I assume you’re referring to Requirement 1.6 (please clarify if not):
> Prior to a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5, and when the method to do so is available to the Responsible Entity from the software source:
> - 1.6.1. Verify the identity of the software source; and
> - 1.6.2. Verify the integrity of the software obtained from the software source.

This is explicitly how SUIT works. It’s just that the devices are responsible for themselves. Notwithstanding that, SUIT has explicit provisions for enabling an intermediary  to perform pre-deployment checks:

4.3.19.  REQ.SEC.MFST.CHECK: Validate manifests prior to deployment
   Manifests SHOULD be verified prior to deployment.  This reduces
   problems that may arise with devices installing firmware images that
   damage devices unintentionally.

   Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)

https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#section-4.3.19


In order for an intermediary to evaluate a manifest prior to deployment, they will require certain vital information provided by the Recipient Device, for example Trust Anchors, Vendor ID(s) and Class ID(s). Vendor ID(s) and Class ID(s) are intended to be reported via Attestation as defined in the RATS working group (see here: https://datatracker.ietf.org/doc/draft-birkholz-rats-suit-claims/). Perhaps we should add Trust Anchors to that claim set. There may be some security considerations to reporting those details upwards. This will require careful consideration.


Here is the relevant section of the workflow (amended from previous email). Please bear in mind that this likely belongs in the iotops-wg, not suit-wg.



Logically, every way that we approach this is a de-facto delegation scheme:

        • The Trust Provisioning Authority (TPA) delegates some authority to Trust Anchors (TA) by installing those TAs in the device with some mechanism to specify what permissions they have. Permissions may be, for example:
                • Authorship rights to individual software components
                • Authorship rights to groups of components
                • Qualification Rights (verification that SW works for intended purpose)
                • Malware Attestation Rights
                • Distribution Rights (authorisation to override certain parts of a manifest, enabling the Trust Anchor or its delegate to redirect fetches from public to private infrastructure, for example)
        • Each TA may delegate some or all of its permissions to a subordinate authority (SA)
        • Each SA may delegate some or all of its permissions to a further SA.
        • Each SA may sign a manifest.

We have not been prescriptive about the exact mechanism for 1. because there are many, equally valid ways for it to be done. For example, this may be done by:
        • Installing a TA in a specific location with predefined permissions
        • Referencing a TA Subject Key Identifier in an Access Control List, signed by the TPA
        • Signing a TA “certificate” including key usage fields with the TPA’s private key.

Each of these approaches is equally valid and allows a verifier to work backwards from the manifest directly to the TPA, as the ultimate authority.

A Firmware Distributor registers devices:
Each device registers with the Firmware Distributor
The device boots into a secure operating mode
The bootloader measures important system parameters (e.g. TAs, Vendor ID(s), Class ID(s), firmware versions, firmware digests)
The bootloader signs the system parameters (the Attestation Evidence), then disables the signing key
The bootloader hands over to the application/OS
The management application connects to the Firmware Distributor and uploads the signed system parameters
The Firmware Distributor evaluates each Attestation Evidence:
It sends the Attestation Evidence to a Verifier.
The Verifier evaluates the trustworthiness of the Attestation Evidence.
The Verifier signs the Attestation Evidence, creating an Attestation Report.
The Verifier returns the Attestation Report to the Firmware Distributor (Relying Party in RATS terminology)
Firmware Distributor evaluates the Attestation Report for discrepancies with previous data or out-of-date firmware.
The Firmware Distributor saves each Attestation Evidence for use in evaluating manifests.

Firmware Creation:
One SA (a Firmware Author) creates a manifest that describes the installation of a firmware
Optionally:
The SA creates a random Content Encryption Key, Initialization Vector
The SA encrypts the firmware
The SA places the encryption information in the manifest/manifest envelope (TBD).
The SA places recipient information in the manifest envelope
This may include third parties for Third Party Evaluation
The SA signs the manifest
The SA sends the manifest to a distributor

Optional: Third Party Evaluation. Third Parties may need to evaluate and authorise a manifest independently, for example: Firmware Author’s QA department, Network Operator, Device Operator, Building Manager, Malware Scanning Service. The Third Parties:
Optional:
Decrypt the firmware using the encryption info in the manifest/envelope
Evaluate the Firmware. For example:
Test interaction with network
Test interaction with deployed devices
Test for functionality
Perform static analysis
Scan for known malware
Endorse the Firmware:
The Third Party adds its signature to the manifest.
NOTE: the Third Party Endorsements are NOT required to work exactly like this. This specification provides one option for third party endorsements. These do not carry documentation about endorsement process with them. That falls outside the scope of the SUIT manifest. An additional specification would be required to define how third party endorsements bearing documents would work, but SUIT could add a container for them.


Pre-deployment check. The Firmware Distributor:
Receives a manifest from the Firmware Author
Uses saved attestation information to determine a target set of recipient devices.
Verifies the authority of the signers: To accomplish this, the verifier is required to:
        • Verify each delegation chain:
                • Extract the first delegation CWT, containing the first SA
                • Verify the CWT against the specified TA
                • Compute the permissions of the first SA using the TA permissions and the delegation CWT
                • Extract the next delegation CWT
                • Verify the CWT against the previous SA
                • Compute the permissions of the next SA using the previous SA permissions and the delegation CWT
                • If there are more CWTs to process, go to 4, otherwise:
                • Compute the final SA permissions
        • Verify the manifest authenticity & authority
                • Verify each manifest signature against the specified SA (typically the final SA of a chain)
                • Compute the aggregate manifest permissions:
                        • This is the union of the permissions of every signer of the manifest.
Evaluates any endorsements from Third Party Evaluations
Validates signatures against authorised third parties
Provisioning of trusted third parties into Firmware Distributor infrastructure is out of scope
Optionally prunes third-party endorsements prior to distribution (this lowers overhead for the recipients and the network)
Validates that manifest applies to target devices (Vendor ID/Class ID matching)


The Recipient Device then needs to:
        • Verify each delegation chain:
                • Extract the first delegation CWT, containing the first SA
                • Verify the CWT against the specified TA
                • Compute the permissions of the first SA using the TA permissions and the delegation CWT
                • Extract the next delegation CWT
                • Verify the CWT against the previous SA
                • Compute the permissions of the next SA using the previous SA permissions and the delegation CWT
                • If there are more CWTs to process, go to 4, otherwise:
                • Compute the final SA permissions
        • Verify the manifest authenticity & authority
                • Verify each manifest signature against the specified SA (typically the final SA of a chain)
                • Compute the aggregate manifest permissions:
                        • This is the union of the permissions of every signer of the manifest.
        • Process the manifest
                • For each command in the manifest:
                        • Verify that the manifest has adequate permissions to perform the specified operation on the specified component identifier
                        • Perform the command
                • Where a dependency manifest is encountered:
                        • Dependency permissions are the union of the dependency manifest’s aggregate permissions and all dependent manifests’ aggregate permissions

Hopefully this clarifies the process. I hope that this process is adequate to meet or exceed NERC requirements.

Best Regards,
Brendan


> I believe the SUIT approach for IoT SW updates will work in some circumstances, e.g. home thermostats, etc. However, I’m not sure it will fly in cases where devices are operating critical infrastructure functions, like safety protection systems and Electric Grid controls. I suspect those SW updates will come under “proactive scrutiny” using SCRM risk assessments before any change to a devices baseline. Just my .02
>
> Thanks,
>
> Dick Brooks
> <image001.jpg>
> Never trust software, always verify and report! ™
> http://www.reliableenergyanalytics.com
> Email: [e-mail]
> Tel: [phone]
>
> From: Brendan Moran <[e-mail]>
> Sent: Thursday, June 3, 2021 7:16 AM
> To: [e-mail]
> Cc: Russ Housley <[e-mail]>; suit <[e-mail]>
> Subject: Re: [Suit] Information model updates
>
> Hi Dick,
>
> I’m not sure if I’ve answered this in the parallel discussion we were having on malware scan attestation, but I’ll address it here too.
>
> Logically, every way that we approach this is a de-facto delegation scheme:
>
>       • The Trust Provisioning Authority (TPA) delegates some authority to Trust Anchors (TA) by installing those TAs in the device with some mechanism to specify what permissions they have. Permissions may be, for example:
>               • Authorship rights to individual software components
>               • Authorship rights to groups of components
>               • Qualification Rights (verification that SW works for intended purpose)
>               • Malware Attestation Rights
>               • Distribution Rights (authorisation to override certain parts of a manifest, enabling the Trust Anchor or its delegate to redirect fetches from public to private infrastructure, for example)
>       • Each TA may delegate some or all of its permissions to a subordinate authority (SA)
>       • Each SA may delegate some or all of its permissions to a further SA.
>       • Each SA may sign a manifest.
>
> We have not been prescriptive about the exact mechanism for 1. because there are many, equally valid ways for it to be done. For example, this may be done by:
>       • Installing a TA in a specific location with predefined permissions
>       • Referencing a TA Subject Key Identifier in an Access Control List, signed by the TPA
>       • Signing a TA “certificate” including key usage fields with the TPA’s private key.
>
>
> Each of these approaches is equally valid and allows a verifier to work backwards from the manifest directly to the TPA, as the ultimate authority.
>
> To accomplish this, the verifier is required to:
>       • Verify each delegation chain:
>               • Extract the first delegation CWT, containing the first SA
>               • Verify the CWT against the specified TA
>               • Compute the permissions of the first SA using the TA permissions and the delegation CWT
>               • Extract the next delegation CWT
>               • Verify the CWT against the previous SA
>               • Compute the permissions of the next SA using the previous SA permissions and the delegation CWT
>               • If there are more CWTs to process, go to 4, otherwise:
>               • Compute the final SA permissions
>       • Verify the manifest authenticity & authority
>               • Verify each manifest signature against the specified SA (typically the final SA of a chain)
>               • Compute the aggregate manifest permissions:
>                       • This is the union of the permissions of every signer of the manifest.
>       • Process the manifest
>               • For each command in the manifest:
>                       • Verify that the manifest has adequate permissions to perform the specified operation on the specified component identifier
>                       • Perform the command
>               • Where a dependency manifest is encountered:
>                       • Dependency permissions are the union of the dependency manifest’s aggregate permissions and all dependent manifests’ aggregate permissions
> This enables a full chain of trust with explicit permissions all the way back to the TPA. Hopefully this explains the process. Is there a place that this needs to be more fully explained?
>
> Best Regards,
> Brendan
>
>
>
>
>
>> On 28 May 2021, at 15:59, Dick Brooks <[e-mail]> wrote:
>>
>> As I was tracing back the verification process in the Manifest https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13
>> https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-5.2
>>
>> This eventually led me to COSE’s Signing and Verification process, which contains the following guidance:
>>
>> In addition to performing the signature verification, the application
>>    may also perform the appropriate checks to ensure that the key is
>>    correctly paired with the signing identity and that the signing
>>    identity is authorized before performing actions.
>>
>> This is where I hit the dead end – I could not find guidance on the  appropriate checks to ensure that the key is
>>    correctly paired with the signing identity and that the signing
>>    identity is authorized before performing actions
>>
>> Any insights on what are the appropriate checks would be greatly appreciated. Thanks in advance.
>>
>> Thanks,
>>
>> Dick Brooks
>> <image001.jpg>
>> Never trust software, always verify and report! ™
>> http://www.reliableenergyanalytics.com
>> Email: [e-mail]
>> Tel: [phone]
>>
>> From: Dick Brooks <[e-mail]>
>> Sent: Friday, May 28, 2021 7:39 AM
>> To: [e-mail]; 'Russ Housley' <[e-mail]>
>> Cc: 'suit' <[e-mail]>; 'Brendan Moran' <[e-mail]>
>> Subject: RE: [Suit] Information model updates
>>
>> Russ and SUIT WG members,
>>
>> I’m continuing to research how trust in a digital signature -> software supplier is being established and verified. And I have a question regarding the SUIT architecture.
>>
>> The need for validation is made clear in the Architecture:
>>
>> Authentication ensures that the device can cryptographically identify the author(s) creating firmware images and manifests. Authenticated identities may be used as input to the authorization process. Not all entities creating and signing manifests have the same permissions. A device needs to determine whether the requested action is indeed covered by the permission of the party that signed the manifest. Informing the device about the permissions of the different parties also happens in an out-of-band fashion and is a duty of the Trust Provisioning Authority.
>>
>> I looked further for some guidance on how a Trust Provisioning Authority is expected to ensure that a signing party has received permission to sign a firmware update from the original software supplier. I didn’t find anything in this regard.
>>
>> Can you point me to some information regarding the verification steps a TPA is required to implement to ensure that a signing party has been authorized to sign a software object on behalf of the original developer/licensor of a software object?
>>
>> It appears the device relies on the TPA’s assertion that a signature on software is indeed authorized and trustworthy without performing any checks on it’s own that this is indeed the case. Is my understanding correct?
>>
>> Lastly, what party is expected to perform TPA roles/responsibilities – Certificate Authorities?
>>
>> Thanks,
>>
>> Dick Brooks
>> <image001.jpg>
>> Never trust software, always verify and report! ™
>> http://www.reliableenergyanalytics.com
>> Email: [e-mail]
>> Tel: [phone]
>>
>> From: Dick Brooks <[e-mail]>
>> Sent: Wednesday, May 26, 2021 7:40 AM
>> To: [e-mail]; 'Russ Housley' <[e-mail]>
>> Cc: 'suit' <[e-mail]>; 'Brendan Moran' <[e-mail]>
>> Subject: RE: [Suit] Information model updates
>>
>> Russ,
>>
>> I looked through draft 13 and I didn’t see anything explicit. It looks like the information model (https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-11#section-4)  touches this subject, but I don’t see any materials that explicitly provides guidance regarding: “how to verify that a signing party is authorized to sign software licensed/produced by party X and is considered a trusted party. “
>>
>> This verification step would need to occur during digital signature verification to confirm that the signing party has been authorized to sign software on behalf of party X.
>>
>> If you think this is not an appropriate topic for this WG then I can take it off list. Any insights you or the WG can offer is appreciated.
>>
>> Please accept my apologies if this is not a proper topic for the suit WG.
>>
>> Thanks,
>>
>> Dick Brooks
>> <image001.jpg>
>> Never trust software, always verify and report! ™
>> http://www.reliableenergyanalytics.com
>> Email: [e-mail]
>> Tel: [phone]
>>
>> From: Suit <[e-mail]> On Behalf Of Dick Brooks
>> Sent: Tuesday, May 25, 2021 6:13 PM
>> To: 'Russ Housley' <[e-mail]>
>> Cc: 'suit' <[e-mail]>; 'Brendan Moran' <[e-mail]>
>> Subject: Re: [Suit] Information model updates
>>
>> Will do, Russ.
>>
>> Just an FYI:
>>
>> Here is a snippet from a discussion within NAESB today regarding supplier identification, signing key verification and the issuance of code signing keys. NAESB is in the process of updating it’s PKI standard as a first step to address this matter:
>>
>> There is some support to use a dns:identifier within certain SBOM fields, here’s an SBOM example:
>>
>> SPDXVersion: SPDX-2.2
>> DataLicense: CC0-1.0
>> SPDXID: SPDXRef-DOCUMENT
>> DocumentName: SAG-PM generated SBOM
>> DocumentNamespace: dns:softwareassuranceguardian.com
>> Creator: Organization: dns:reliableenergyanalytics.com
>>
>> Using this example I could envision the DNS Zone file for reliableenergyanalytics.com
>>
>> Having a DSA record identifying dns:ssl.com as an authorized signer for reliableenergyanalytics.com. This would enable a CA. i.e. GlobalSign, that receives a code signing CSR  to check reliableenergyanalytics.com DNS Zone file for a DSA record listing ssl.com as a authorized signer.
>>
>> This won’t solve the entire software supply chain issue with regard to identity and authorized signer verification, but it’s a good first step, that is missing today.
>>
>> I’ll let you and the SUIT WG know if the concern I raised is already covered in draft-ietf-suit-manifest-13.
>>
>> Thanks for looking into this.
>>
>> Thanks,
>>
>> Dick Brooks
>> <image001.jpg>
>> Never trust software, always verify and report! ™
>> http://www.reliableenergyanalytics.com
>> Email: [e-mail]
>> Tel: [phone]
>>
>> From: Russ Housley <[e-mail]>
>> Sent: Tuesday, May 25, 2021 5:22 PM
>> To: Dick Brooks <[e-mail]>
>> Cc: suit <[e-mail]>; Brendan Moran <[e-mail]>
>> Subject: Re: [Suit] Information model updates
>>
>> Dick:
>>
>> Please take a look at the current WG document (draft-ietf-suit-manifest-13).  I think that the discussion of dependencies and their processing is what you are asking about.
>>
>> Russ
>>
>>
>>
>>> On May 24, 2021, at 10:19 AM, Dick Brooks <[e-mail]> wrote:
>>>
>>> Thanks, Russ. Sorry about that – here is the article contents – thanks for your insights and recommendation. Very interested in knowing your thoughts, especially regarding the DNS DSA concept.
>>>
>>> We cannot secure the software supply chain without SBOM
>>>
>>> A Software Bill of Materials (SBOM) has received considerable attention since the Cybersecurity Executive order was released on May 12, 2021 calling on government agencies to require SBOM’s from software vendors, “(vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website”
>>> The Executive Order goes on to describe an SBOM, with an emphasis on it’s component inventory capabilities, “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software”, “It is analogous to a list of ingredients on food packaging.”
>>> All of these claims are indeed accurate, however there is another essential and critically important element that SBOM’s provide, which is essential to secure the software supply chain; The identity of the software source supplier that produced and licensed the software, which can be verified using digital signing keys issued by trustworthy Certificate Authorities.
>>> Current practices used in the software supply chain do not require identification of the actual software supplier and licensor of a software package. Some practices require that software packages be digitally signed, however there is no verification or validation that the signer of a software package and the supplier/licensor are related, or that the supplier/licensor has authorized a given party to sign a software object on their behalf. This creates a false sense of security when parties rely on tools such as Microsoft’s signtool to validate a digital signature. Signtool does not validate that a digital signature is indeed authorized to sign a software product on behalf of the original source supplier/licensor – it has no way of verifying that a given signing key is authorized to sign a software package. Signtool will report a valid signature if the cryptographic verifications and trust chain reports produce successful results, which do not verify the authorization of a signing party and supplier arrangement. This issue is similar to a past scenario where Certificate Authorities were issuing SSL certificates to domains without authorization to do so, which resulted in the implementation of DNS CAA (IETF RFC 6844) records to identify authorized parties to issue SSL certificates. A similar authorization scheme may be appropriate to authorize the issuance of digital certificates and signing keys to parties that have been authorized by a software supplier/licensor to sign software objects on their behalf.
>>> The ability to determine trustworthiness is the key to securing the software supply chain. SBOM is the foundation for establishing this trust by specifying the identification of the actual source supplier/licensor of a software product. This supplier information can then be used to validate a digital signature applied to a software object by verifying the relationship of the software supplier and software signer using a trusted method to verify this relationship. A solution similar to DNS CAA, ref: “DNS Certification Authority Authorization (CAA) Resource Record”, IETF RFC 6844 may be worth exploring to address this need.
>>>
>>> There is no doubt that securing the software supply chain requires a software consumer to verify the identity of a software source supplier and licensor of a software object. SBOM is a critical requirement in this process due to its standard method for identifying a software supplier/licensor of a software object. Having this SBOM supplier identifier will enable a software consumer to verify this party using digital signatures based on digital certificates issued by trusted Certificate Authorities.  What is missing today is a means to verify the authorization of a signing party by the software source supplier/licensor using trusted mechanisms, similar to RFC 6844. Perhaps, one day, we may see a DNS Digital Signature Authorization (DSA) record to meet this need.
>>>
>>> Thanks,
>>>
>>> Dick Brooks
>>> <image001.jpg>
>>> Never trust software, always verify and report! ™
>>> http://www.reliableenergyanalytics.com
>>> Email: [e-mail]
>>> Tel: [phone]
>>>
>>> From: Russ Housley <[e-mail]>
>>> Sent: Monday, May 24, 2021 10:14 AM
>>> To: [e-mail]
>>> Cc: Brendan Moran <[e-mail]>; suit <[e-mail]>
>>> Subject: Re: [Suit] Information model updates
>>>
>>> Dick:
>>>
>>> To read the article that you reference, I must join "The Energy Collective Group".  If you want us to consider your thoughts, you need to make them freely and openly available. Posting them here also has the desirable property that they get included in the mail archive of the WG discussion.
>>>
>>> Russ
>>>
>>>
>>>> On May 24, 2021, at 10:01 AM, Dick Brooks <[e-mail]> wrote:
>>>>
>>>> Russ, et al,
>>>>
>>>>                I’ve raised an issue with regard to software supplier identification and verification as part of a software supply chain verification. I haven’t been paying much attention to the SUIT and MUD work, so I would be curious to know if this issue also effects your work in this area.
>>>>
>>>> https://energycentral.com/c/ec/we-cannot-secure-software-supply-chain-without-sbom
>>>>
>>>> Thanks,
>>>>
>>>> Dick Brooks
>>>> <image001.jpg>
>>>> Never trust software, always verify and report! ™
>>>> http://www.reliableenergyanalytics.com
>>>> Email: [e-mail]
>>>> Tel: [phone]
>>>>
>>>> From: Suit <[e-mail]> On Behalf Of Russ Housley
>>>> Sent: Monday, May 24, 2021 9:55 AM
>>>> To: Brendan Moran <[e-mail]>
>>>> Cc: suit <[e-mail]>
>>>> Subject: Re: [Suit] Information model updates
>>>>
>>>> The IESG is waiting for a revised Internet-Draft to be posted.
>>>>
>>>> Russ
>>>>
>>>>
>>>>> On May 13, 2021, at 6:06 AM, Brendan Moran <[e-mail]> wrote:
>>>>>
>>>>> I’ve made a number of pull requests to the information model. These should address the issues raised by IESG review.
>>>>>
>>>>> See here for more information: https://github.com/suit-wg/information-model/pulls
>>>>>
>>>>> Brendan
>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>>>> _______________________________________________
>>>>> Suit mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/suit
>>>>
>>>> _______________________________________________
>>>> Suit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/suit
>>>
>>> _______________________________________________
>>> Suit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/suit
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.