Subject: [sacm] CoSWID and EAT and CWT

From: Laurence Lundblade <[email-masked]>
Date: Thu, 21 Nov 2019 08:34:50 +0800

Hi,

I’m not on the SACM list, but did look at the archive. Hopefully I’m not out of sync.

My thought is to register one claim for CWT that is an entire CoSWID (in CDDL the concise-swid-tag).

That way CoSWID can grow and develop on its own without lots of adds and subtracts to the CWT registry. It has its own IANA registry with its own experts and such. Seems like the coupling / factoring is about right.

This would also be the way I’d like to have it in EAT attestation. We’ve done a mini version of this with the location claim <https://tools.ietf.org/html/draft-ietf-rats-eat-01#section-3.8>.

Then if you just want to sign a CoSWID CWT style, this works pretty well too. It has a slight overhead compared to having all the CoSWID data items as direct CWT claims in that it will have an additional map layer, but that is only about three bytes.

LL

---

From: Ira McDonald <[email-masked]>
Date: Wed, 20 Nov 2019 20:00:28 -0500

Hi Laurence,

That seems like a good suggestion for a simple way to integrate CoSWID
content
into EAT.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Nov 20, 2019 at 7:35 PM Laurence Lundblade <[email-masked]>
wrote:

> That way CoSWID can grow and develop on its own without lots of adds and
> subtracts to the CWT registry. It has its own IANA registry with its own
> experts and such. Seems like the coupling / factoring is about right.
>
> This would also be the way I’d like to have it in EAT attestation. We’ve
> done a mini version of this with the location claim
> <https://tools.ietf.org/html/draft-ietf-rats-eat-01#section-3.8>.
>
> Then if you just want to sign a CoSWID CWT style, this works pretty well
> too. It has a slight overhead compared to having all the CoSWID data items
> as direct CWT claims in that it will have an additional map layer, but that
> is only about three bytes.
>
> LL
>
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 20 Nov 2019 21:10:49 -0500

Great, thanks Laurence.  If that's easier I think having the CoSWID in one
claim should be ok and would have the same result as the suggestion I
made.  Changing the CoSWID format is a big enough process that it shouldn't
happen very often.

Best regards,
Kathleen

On Wed, Nov 20, 2019 at 8:00 PM Ira McDonald <[email-masked]>
wrote:

> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

-- 

Best regards,
Kathleen

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 21 Nov 2019 04:29:48 +0000

It sounds like having a CWT claim that contains an entire CoSWID is a path forward. It may also make sense to do something similar for ISO SWID tags.

Am I right in thinking that this CWT work can be done in RATS, referencing CoSWID once it is published as a normative reference? This would allow CoSWID to go forward to the IESG, while the CoSWID CWT claim is worked in parallel in RATS.

Kathleen, if this is true, does this way forward address your CWT-related comments?

Regards,
Dave

________________________________
From: sacm <[email-masked]> on behalf of Kathleen Moriarty <[email-masked]>
Sent: Wednesday, November 20, 2019 9:10 PM
To: Ira McDonald <[email-masked]>
Cc: [email-masked] <[email-masked]>; sacm <[email-masked]>; Laurence Lundblade <[email-masked]>
Subject: Re: [sacm] [Rats] CoSWID and EAT and CWT

Great, thanks Laurence.  If that's easier I think having the CoSWID in one claim should be ok and would have the same result as the suggestion I made.  Changing the CoSWID format is a big enough process that it shouldn't happen very often.

Best regards,
Kathleen

On Wed, Nov 20, 2019 at 8:00 PM Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:
Hi Laurence,

That seems like a good suggestion for a simple way to integrate CoSWID content
into EAT.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic<https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fblueroofmusic&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=GDIVVIesvqqXnuU6TtLbK7GJ4eI1b1EcYSPoXsHlj04%3D&reserved=0>
http://sites.google.com/site/highnorthinc<https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=7z%2BoMcYSSFD8hAYHmELqNoyGAxTBE9gknbV6kAzKWX8%3D&reserved=0>
mailto: [email-masked]<mailto:[email-masked]>
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Nov 20, 2019 at 7:35 PM Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

This would also be the way I’d like to have it in EAT attestation. We’ve done a mini version of this with the location claim<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rats-eat-01%23section-3.8&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070426961&sdata=%2Fhi008Am2dlY6tBQHdPVVGZzEcWNmqd5MvgPOM14jE8%3D&reserved=0>.

LL

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070426961&sdata=fdpXMIU%2BNkMSn3RJ4X5AsSuMU7pbokHXltsX8ZYP9E0%3D&reserved=0>
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070436893&sdata=okSPAqVHj9KBxPtViQdnffsfhlMF4t0%2F87PXXY78fA0%3D&reserved=0>

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 Nov 2019 06:37:58 -0500

Sent from my mobile device

> On Nov 20, 2019, at 11:29 PM, Waltermire, David A. (Fed) <[email-masked]> wrote:
> 
> 

Hi Dave,

I think the signature may have to be on the CWT as opposed to on the claim that is the CoSWID or SWID.  We can define it fully in another draft, but should state it here so that option is understood.  It’s a simple write up, I think.

Thank you,
Kathleen 
> On Wed, Nov 20, 2019 at 8:00 PM Ira McDonald <[email-masked]> wrote:
> Hi Laurence,
> 
> On Wed, Nov 20, 2019 at 7:35 PM Laurence Lundblade <[email-masked]> wrote:
> Hi,
> 
> This would also be the way I’d like to have it in EAT attestation. We’ve done a mini version of this with the location claim.
>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 21 Nov 2019 13:24:31 +0000

Ok. Can you send some text?

Thanks,
Dave

-------- Original Message --------
From: Kathleen Moriarty <[email-masked]>
Date: Thu, November 21, 2019 7:38 PM +0800
To: "Waltermire, David A. (Fed)" <[email-masked]>
CC: Ira McDonald <[email-masked]>, [email-masked], sacm <[email-masked]>, Laurence Lundblade <[email-masked]>
Subject: Re: [sacm] [Rats] CoSWID and EAT and CWT

Hi Dave,

Thank you,
Kathleen

Regards,
Dave

Best regards,
Kathleen

Cheers,
- Ira

http://sites.google.com/site/blueroofmusic<https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fblueroofmusic&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C85a323f673924389c45e08d76e7745e5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637099330879448050&sdata=HNKKsYDUx5jZoxujKDqJicqUBZ9oe9mxXcTjJ1JlhHM%3D&reserved=0>
http://sites.google.com/site/highnorthinc<https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C85a323f673924389c45e08d76e7745e5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637099330879448050&sdata=PPUqVo1NgGXTgtO10NkLvTHqh5OEqfAeoObWvguIzwY%3D&reserved=0>

This would also be the way I’d like to have it in EAT attestation. We’ve done a mini version of this with the location claim<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rats-eat-01%23section-3.8&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C85a323f673924389c45e08d76e7745e5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637099330879458044&sdata=ssqf1hrDm3bHXDTpewMd%2BhxK9Yh7mNDfmJH%2B9Lk8JsM%3D&reserved=0>.

LL

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C85a323f673924389c45e08d76e7745e5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637099330879458044&sdata=K4z%2BpZK5s6Ng%2B7amizoONuHllxjshmG5aTzP3yO8adU%3D&reserved=0>
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C85a323f673924389c45e08d76e7745e5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637099330879468039&sdata=JviOvpKGQLNyMiV2fEFSE1qZA3XosOoECBCQuiTK4Lo%3D&reserved=0>

--

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 21 Nov 2019 17:01:48 +0000

I think there are two conversations that could make sense (1) definition of a software integrity claim that can be asserted by an Attester as Evidence; (2) definition of a software integrity claim that can be asserted by an Endorser (aka supply chain entity) as Endorsement.

In (1) there is interest in an EAT token definition that likely will result in a JWT/CWT realization and signature. Possibly it makes sense to include an unsigned CoSWID / SWID structure inside a JWT/CWT or it makes sense to deviate from the JWT/CWT realization but keep the information and data model claims definition but allow use of CoSWID native signatures.
In (2) this is technically out of scope for RATS. However, it could result in a CoSWID / SWID structure using the built in signature method. It isn’t known yet if a token (CWT/JWT) realization makes sense for Endorsers.

From: RATS <[email-masked]> on behalf of "Waltermire, David A. (Fed)" <david.waltermire=[email-masked]>
Date: Thursday, November 21, 2019 at 5:24 AM
To: Kathleen Moriarty <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Ira McDonald <[email-masked]>, sacm <[email-masked]>, Laurence Lundblade <[email-masked]>
Subject: Re: [Rats] [sacm] CoSWID and EAT and CWT

Thanks,
Dave

-------- Original Message --------
From: Kathleen Moriarty <[email-masked]>
Date: Thu, November 21, 2019 7:38 PM +0800
To: "Waltermire, David A. (Fed)" <[email-masked]>
CC: Ira McDonald <[email-masked]>, [email-masked], sacm <[email-masked]>, Laurence Lundblade <[email-masked]>
Subject: Re: [sacm] [Rats] CoSWID and EAT and CWT

Hi Dave,

Thank you,
Kathleen

Regards,
Dave

Best regards,
Kathleen

Cheers,
- Ira

LL

--

Best regards,
Kathleen

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Nov 2019 00:08:36 +0000

Hi all

Can someone send an example around how this would actually look like?

Ciao
Hannes

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Thursday, November 21, 2019 8:35 AM
To: [email-masked]; [email-masked]
Subject: [Rats] CoSWID and EAT and CWT

Hi,

This would also be the way I’d like to have it in EAT attestation. We’ve done a mini version of this with the location claim<https://tools.ietf.org/html/draft-ietf-rats-eat-01#section-3.8>.

LL

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.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 22 Nov 2019 08:45:16 +0800

Hi Ned,

> On Nov 22, 2019, at 1:01 AM, Smith, Ned <[email-masked]> wrote:
> 
> It isn’t known yet if a token (CWT/JWT) realization makes sense for Endorsers.

This is probably far afield for SACM.

I think it is probably out of scope for RATS too. I assume the endorser is not a sub-part of the attester and it not on the device, but instead part of the device manufacturing infrastructure. I assume the endorser is not part of the verifier either. 

I believe the endorser is part of or all of the mechanism that facilitates the placing of the private key material in the attester and the corresponding public key material in the verifier. I believe these interactions are out of scope for RATS. In many cases they will be highly proprietary and highly dependent on the manufacturing system.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 22 Nov 2019 18:06:40 +0100

Hi Kathleen,
hi SACM, SUIT & RATS list,

the corresponding *SWID authors discussed this issue and are proposing:

> https://github.com/ietf-rats-wg/eat/issues/46

This includes an extended scope to include the option of SUIT Manifest 
related Claim values, next to various *SWID Claim values. We permutated 
"signed" & "not-signed" as well as "payload tags" and "evidence tags" 
for *SWID tags in this proposal. The authors are convinced that the 
"not-signed" variants are of essence (as CWT does not allow "not-signed 
CBOR items", but also do not imply any implications to the SUIT Manifest 
Claim definition (although there are strong similarities and there could 
be some).

The current *SWID contributors prefer this contribution as a parallel 
effort to the EAT I-D, SUIT Manifest I-D, the CoSWID I-D and existing 
ISO XML SWID standard. This proposal includes the primitive to not delay 
corresponding IETG I-D in their respective WGs.

Having said that, we would like to get feedback for the proposal 
references above.

If there is no dissent or push-back on either the SUIT, SACM, and RATS 
lists, our proposed way forward is a unified creation of EAT Claim Sets 
in the RATS WG that enables the use of various *SWID variants & the SUIT 
Manifest as payloads for RATS via the RATS EAT I-D.

In summary, we would like to create this interop I-D in concert and 
welcome every joint effort in this domain.

Viele Grüße,

Henk

On 21.11.19 12:37, Kathleen Moriarty wrote:
>> It sounds like having a CWT claim that contains an entire CoSWID is a 
>> path forward. It may also make sense to do something similar for ISO 
>> SWID tags.
>>
>> Am I right in thinking that this CWT work can be done in RATS, 
>> referencing CoSWID once it is published as a normative reference? This 
>> would allow CoSWID to go forward to the IESG, while the CoSWID CWT 
>> claim is worked in parallel in RATS.
>>
> I think the signature may have to be on the CWT as opposed to on the 
> claim that is the CoSWID or SWID.  We can define it fully in another 
> draft, but should state it here so that option is understood.  It’s a 
> simple write up, I think.
> 
> Thank you,
> Kathleen
>>
>> Regards,
>> Dave
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* sacm <[email-masked]> on behalf of Kathleen Moriarty 
>> <[email-masked]>
>> *Sent:* Wednesday, November 20, 2019 9:10 PM
>> *To:* Ira McDonald <[email-masked]>
>> *Cc:* [email-masked] <[email-masked]>; sacm <[email-masked]>; Laurence 
>> Lundblade <[email-masked]>
>> *Subject:* Re: [sacm] [Rats] CoSWID and EAT and CWT
>> Great, thanks Laurence.  If that's easier I think having the CoSWID in 
>> one claim should be ok and would have the same result as the 
>> suggestion I made.  Changing the CoSWID format is a big enough process 
>> that it shouldn't happen very often.
>>
>> Best regards,
>> Kathleen
>>
>>     <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fblueroofmusic&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=GDIVVIesvqqXnuU6TtLbK7GJ4eI1b1EcYSPoXsHlj04%3D&reserved=0>
>>     <https://gcc01.safelinks.protection..outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=7z%2BoMcYSSFD8hAYHmELqNoyGAxTBE9gknbV6kAzKWX8%3D&reserved=0>
>>     mailto: [email-masked] <mailto:[email-masked]>
>>     On Wed, Nov 20, 2019 at 7:35 PM Laurence Lundblade
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Hi,
>>
>>         That way CoSWID can grow and develop on its own without lots
>>         of adds and subtracts to the CWT registry. It has its own IANA
>>         registry with its own experts and such. Seems like the
>>         coupling / factoring is about right.
>>
>>         This would also be the way I’d like to have it in EAT
>>         attestation. We’ve done a mini version of this with the
>>         location claim
>>         <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rats-eat-01%23section-3.8&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070426961&sdata=%2Fhi008Am2dlY6tBQHdPVVGZzEcWNmqd5MvgPOM14jE8%3D&reserved=0>.
>>
>>         Then if you just want to sign a CoSWID CWT style, this works
>>         pretty well too. It has a slight overhead compared to having
>>         all the CoSWID data items as direct CWT claims in that it will
>>         have an additional map layer, but that is only about three bytes.
>>
>>         LL
>>
>>         [email-masked] <mailto:[email-masked]>
>>         <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070426961&sdata=fdpXMIU%2BNkMSn3RJ4X5AsSuMU7pbokHXltsX8ZYP9E0%3D&reserved=0>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070436893&sdata=okSPAqVHj9KBxPtViQdnffsfhlMF4t0%2F87PXXY78fA0%3D&reserved=0>
>>
>>
>>
>> -- 
>>
>> Best regards,
>> Kathleen
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 22 Nov 2019 13:26:54 -0500

Hi Henk,

I am not entirely following you, so I am not stating agreement yet.

> Claim definition (although there are strong similarities and there could

Can you write the above again?  Are you saying this in terms of a CWT?
Wouldn't the claims and the text value in a CWT be represented as-is, then
signed, so you'd get what you are saying is needed?

> corresponding IETG I-D in their respective WGs.

Are you saying you don't want to add text stating the use of a CWT is a
possible alternative, as that is what was requested.  I offered to write a
separate document to put the CoSWID in a CWT in SACM as I think that's the
right home, referencing EAT work.

> Manifest as payloads for RATS via the RATS EAT I-D.

I think this should be in SACM.  And I've offered to help.  I do think that
a little text saying it's possible should be in the CoSWID draft and will
provide that soon as not to delay progress of the CoSWID document.

Best regards,
Kathleen

> >>     <
> https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fblueroofmusic&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=GDIVVIesvqqXnuU6TtLbK7GJ4eI1b1EcYSPoXsHlj04%3D&reserved=0
> >
> >>     <https://gcc01.safelinks.protection..
> outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=7z%2BoMcYSSFD8hAYHmELqNoyGAxTBE9gknbV6kAzKWX8%3D&reserved=0
> >
> >>         <
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rats-eat-01%23section-3.8&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070426961&sdata=%2Fhi008Am2dlY6tBQHdPVVGZzEcWNmqd5MvgPOM14jE8%3D&reserved=0
> >.
> >>
> >>         <
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070426961&sdata=fdpXMIU%2BNkMSn3RJ4X5AsSuMU7pbokHXltsX8ZYP9E0%3D&reserved=0
> >
> >>
> >>     <
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070436893&sdata=okSPAqVHj9KBxPtViQdnffsfhlMF4t0%2F87PXXY78fA0%3D&reserved=0
> >
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen
> >

-- 

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 22 Nov 2019 19:39:38 +0000

Regarding issue 46 (link below), the proposed (9) claims distinguish between Evidence, “Payload” and SUIT Manifest variations. Evidence is defined by RATS architecture, SUIT Manifest by SUIT WG, but not sure where “Payload” is defined and how it differs from Evidence. Possibly 8 claims can be collapsed into 4?

From: RATS <[email-masked]> on behalf of Kathleen Moriarty <[email-masked]>
Date: Friday, November 22, 2019 at 10:27 AM
To: Henk Berkholz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, sacm <[email-masked]>, "[email-masked]" <[email-masked]>, Laurence Lundblade <[email-masked]>, Ira McDonald <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] [sacm] CoSWID and EAT and CWT

Hi Henk,

On Fri, Nov 22, 2019 at 12:06 PM Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kathleen,
hi SACM, SUIT & RATS list,

Can you write the above again?  Are you saying this in terms of a CWT?  Wouldn't the claims and the text value in a CWT be represented as-is, then signed, so you'd get what you are saying is needed?

Are you saying you don't want to add text stating the use of a CWT is a possible alternative, as that is what was requested.  I offered to write a separate document to put the CoSWID in a CWT in SACM as I think that's the right home, referencing EAT work.

I think this should be in SACM.  And I've offered to help.  I do think that a little text saying it's possible should be in the CoSWID draft and will provide that soon as not to delay progress of the CoSWID document.

Best regards,
Kathleen

Viele Grüße,

Henk

On 21.11.19 12:37, Kathleen Moriarty wrote:
>> On Nov 20, 2019, at 11:29 PM, Waltermire, David A. (Fed)
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>> *From:* sacm <[email-masked]<mailto:[email-masked]>> on behalf of Kathleen Moriarty
>> <[email-masked]<mailto:[email-masked]>>
>> *To:* Ira McDonald <[email-masked]<mailto:[email-masked]>>
>> *Cc:* rats@ietf..org<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; sacm <[email-masked]<mailto:[email-masked]>>; Laurence
>> Lundblade <[email-masked]<mailto:[email-masked]>>
>> On Wed, Nov 20, 2019 at 8:00 PM Ira McDonald <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>     Hi Laurence,
>>
>>     <https://gcc01.safelinks.protection..outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=7z%2BoMcYSSFD8hAYHmELqNoyGAxTBE9gknbV6kAzKWX8%3D&reserved=0<http://outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=7z%2BoMcYSSFD8hAYHmELqNoyGAxTBE9gknbV6kAzKWX8%3D&reserved=0>>
>>     mailto: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>         Hi,
>>
>>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>         https://www.ietf..org/mailman/listinfo/rats<https://www.ietf.org/mailman/listinfo/rats>
>>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

--

Best regards,
Kathleen

---

From: Henk Birkholz <[email-masked]>
Date: Sun, 24 Nov 2019 14:44:31 +0100

Hi Kathleen,

I'll provide comments and replies in-line. I hope that is okay.

> I am not entirely following you, so I am not stating agreement yet.

Of course, I was typing very hastily before take-off.

> 
> On Fri, Nov 22, 2019 at 12:06 PM Henk Birkholz 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Kathleen,
> Wouldn't the claims and the text value in a CWT be represented as-is, 
> then signed, so you'd get what you are saying is needed?

Let me attempt to rephrase :)

1.) In order to be semantic interoperable with ISO SWID, CoSWID most 
enable signed and un-signed software identification tags. I.e. signing 
is optional for evidence tags and recommended for payload tags according 
to ISO/IEC 19770-2:2015 and it is recommended for evidence tags and 
mandatory for payload tags according to NISTIR 8060:2016.
These statements stand by themselves and have nothing to do with CWT.

2.) The CoSWID authors/editors would like to see CoSWID as claim values 
in EAT, and therefore as an extension as CWT Claims (as this is how EAT 
works with respect to new Claims for EAT).
There are two types of software identification tags defined by ISO/SWID 
& CoSWID, respectively, that we think are important to RATS in this 
first context: the payload resource-collection and the evidence 
resource-collection.
* Payload is the content for (RATS) Appraisal Policy messages (formerly 
named Reference Values). They are the "intended software installation 
and configuration state for a well-defined scope of software components" 
signed by the creator of the software, potentially co-signed by 
certification authorities (e.g. CC-certified), or 
countersigned/co-signed by local administration authorities.
* Evidence is the content for (RATS) Attestation Evidence. They are 
created on the target of evaluation (the Attester) and represent "a 
measurement of actually installed software components and their 
configuration". They can be signed by an Attesting Environment on the 
Attester, or they can be unsigned (if there is no RTR, such as a TEE 
with Android Keystore API or a {p|f|v}TPM'esque interface).

3.) Therefore, if a *SWID is a value in a Claim of an EAT, this value 
can be at least one of these eight options:

Appraisal Policy Content:
* signed payload tag CoSWID
* signed payload tag ISO/SWID
* unsigned payload tag CoSWID
* unsigned payload tag ISO/SWID

Attestation Evidence Content:
* signed evidence tag CoSWID
* signed evidence tag ISO/SWID
* unsigned evidence tag CoSWID
* unsigned evidence tag ISO/SWID

It is quite beneficial to register a CWT Claim for each one of these 
eight flavors for the use in EAT: to simplify CWT parsing and retain the 
well defined semantics of each of these *SWID tag flavors.

4.) Additionally, to register a CWT Claim for the SUIT Manifest is quite 
useful, in order to create attestation evidence about firmware and its 
metadata (that is not well-defined in CoSWID, but - please note - can 
also be represented in CoSWID, it just not that elegant).

Hence the proposal in the EAT issue #46. We were preparing at least two 
CoSWID related documents for a while now (waiting for CoSWID to pass 
IESG). The other CoSWID realted I-D might address Yaron's issue, but the 
write-up is not complete yet (the last 20% take the longest...).

> possible alternative, as that is what was requested.  I offered to write 
> a separate document to put the CoSWID in a CWT in SACM as I think that's 
> the right home, referencing EAT work.

I am trying to say here that we want to write a new I-D. I am not 
entirely sure anymore, where you want to add text about that. I am not 
sure how useful it would be refer to a new I-D in the CoSWID document, 
which is now closing in on it's end of the WGLC. I think it might be 
more useful and expedite the process to do it in a way like other "Claim 
drafts" do it, such as:

> https://datatracker.ietf.org/doc/draft-mandyam-rats-qwestoken/

and

> https://datatracker.ietf.org/doc/draft-tschofenig-rats-psa-token/

This seems to be the common pattern. Is there a reason to diverge from that?

> I think this should be in SACM.  And I've offered to help.  I do think 
> that a little text saying it's possible should be in the CoSWID draft 
> and will provide that soon as not to delay progress of the CoSWID document.

Well, we can do this new I-D in SACM, but I am not sure why SACM is the 
more suitable place for that. Both the qwes-token and the psa-token 
define Claims that can be used in EAT are at least related to RATS (I 
think Hannes mentioned he wanted to be individual stream in the end, but 
I might be mistake). In any case, I am not against doing this in SACM, 
we did a lot of cross-wg and cross-area I-D in cooperation with SACM 
already and even got the "cross-area" Hackathon award for that - so 
while slightly in favor of RATS, I am not against SACM, if there is a 
good reason for that. We plan to relate the the 2nd upcoming CoSWID 
related I-D with RATS, though.

I am most certainly not against "a little text saying it's possible" in 
the CoSWID draft. I am only stepping very carefully when putting in a 
reference to a future document, which there is no guarantee for that it 
will actually work out or that it will be the thing that was promised in 
that text before.
In this specific case, I am also not sure what the problem is we are 
trying to solve by adding new content at this stage. Having said that, I 
am not against it, if we achieve "not do to delay progress of the CoSWID 
document" as you highlighted :)

> Kathleen

Viele Grüße from Manchester,

Henk

>      >> <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      >>
>      >> 
>      >> *From:* sacm <[email-masked]
>     <mailto:[email-masked]>> on behalf of Kathleen Moriarty
>      >> <[email-masked]
>     <mailto:[email-masked]>>
>      >> *Cc:* [email-masked] <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>; sacm <[email-masked]
>     <mailto:[email-masked]>>; Laurence
>      >> Lundblade <[email-masked] <mailto:[email-masked]>>
>      >> On Wed, Nov 20, 2019 at 8:00 PM Ira McDonald
>     <[email-masked] <mailto:[email-masked]>
>      >> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>
>      >>     Hi Laurence,
>      >>
>       <https://gcc01.safelinks.protection..outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=7z%2BoMcYSSFD8hAYHmELqNoyGAxTBE9gknbV6kAzKWX8%3D&reserved=0 <http://outlook.com/?url=http%3A%2F%2Fsites.google.com%2Fsite%2Fhighnorthinc&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C92a2dcbadd8d47661b9608d76e282847%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637098991070417006&sdata=7z%2BoMcYSSFD8hAYHmELqNoyGAxTBE9gknbV6kAzKWX8%3D&reserved=0>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>
>      >>         Hi,
>      >>
>      >>         My thought is to register one claim for CWT that is an
>     entire
>      >>         CoSWID (in CDDL the concise-swid-tag).
>      >>
>      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Henk Birkholz <[email-masked]>
Date: Sun, 24 Nov 2019 16:44:12 +0100

Hi Ned,

"Evidence" and "Payload" are two of the four pre-defined (and 
extensible) types of resource-collection defined by ISO/IEC 
19770-2:2015, CoSWID and NISTIR 8060:2016, respectively.

They are defined here:

> https://tools.ietf.org/html/draft-ietf-sacm-coswid-13#section-2.3

Fortunately, Evidence is semantically very well aligned with the meaning 
of Evidence in the context of RATS, it is effectively created by an 
Attesting Environment of an Attester as a measurement:

>    o  evidence-entry (index 3): This item can be used to record the
>       results of a software discovery process used to identify untagged
>       software on an endpoint or to represent indicators for why
>       software is believed to be installed on the endpoint.  In either
>       case, a CoSWID tag can be created by the tool performing an
>       analysis of the software components installed on the endpoint.
>       Described in Section 2.9.4.

In general, Payload lists the files that may be installed with a 
software product, and could be a superset of those files. Semantically, 
they are the equivalent to Appraisal Policies (formerly know as 
Reference Values). This differs from the use of Evidence, which is used 
to store results from a scan that indicate why the product is believed 
to be installed:

>    o  payload (index 6): This item represents a collection of software
>       artifacts (described by child items) that compose the target
>       software.  For example, these artifacts could be the files
>       included with an installer for a corpus tag or installed on an
>       endpoint when the software component is installed for a primary or
>       patch tag.  The artifacts listed in a payload may be a superset of
>       the software artifacts that are actually installed.  Based on user
>       selections at install time, an installation might not include
>       every artifact that could be created or executed on the endpoint
>       when the software component is installed or run.  Described in
>       Section 2.9.3.

Viele Grüße,

Henk

On 22.11.19 20:39, Smith, Ned wrote:
> Regarding issue 46 (link below), the proposed (9) claims distinguish 
> between Evidence, “Payload” and SUIT Manifest variations. Evidence is 
> defined by RATS architecture, SUIT Manifest by SUIT WG, but not sure 
> where “Payload” is defined and how it differs from Evidence. Possibly 8 
> claims can be collapsed into 4?
> 
> *From: *RATS <[email-masked]> on behalf of Kathleen Moriarty 
> *Date: *Friday, November 22, 2019 at 10:27 AM
> *To: *Henk Berkholz <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, sacm <[email-masked]>, 
> "[email-masked]" <[email-masked]>, Laurence Lundblade 
> <[email-masked]>, Ira McDonald <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [Rats] [sacm] CoSWID and EAT and CWT
> 
> Hi Henk,
> 
>      >> *Cc:* rats@ietf..org <mailto:[email-masked]> <[email-masked]
>      >> https://www.ietf..org/mailman/listinfo/rats
>     <https://www.ietf.org/mailman/listinfo/rats>
>      >>

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 26 Nov 2019 23:51:20 +0000

Hi Hannes,

> Can someone send an example around how this would actually look like?

For something such as TF-M, it should look like this:

{
  / tag-id, globally unique identifier for the software component /
  0: "trustedfirmware.org/TF-M",

  / tag-version (here: 0, i.e. initial tag) /
  12: 0,

  / software component name /
  1: "TF-M",

  / version of the software component /
  13: "1.0.0-rc1+build.123",

  / (optional) version scheme (here: semver) /
  14: 16384,

  / entity, i.e. organizations responsible for producing or releasing
    the software component /
  2: {
    / entity name /
    31: "Linaro Limited",

    / entity role (here: software creator) /
    33: 2,

    / thumbprint of the entity public key (algo -- here; SHA-256 -- and value) /
    34: [
      1,
      h'5e73c2e6a96be594e56b218418a3ea03f1397934a2517d781855195fe3c5916b'
    ]
  },

  / payload /
  6: {
    / filesystem item (name and hash) /
    17: {
      24: "tfm.bin",
      7: [
        1,
        h'4a039f284d8ad68ca5b4d1592977c7c964c4abb5d08d87e4a0346b80cce5c74d'
      ]
    }
  }
}

At least this would be my interpretation of the CoSWID draft.  I'm a bit
unsure whether a "filesystem" item is the most appropriate payload for a
firmware thingy.  Surely Henk can suggest something better.

Cheers!

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 26 Nov 2019 16:48:46 -0800

Looks good, Thomas

Here’s a signed EAT with the CoSWID as a claim with label 21.

In EATs with submods, there would likely be a CoSWID per submod (not shown below).

LL

18(
    [
        / protected parameters, bstr wrapped / << {
            / alg / 1: -7 / ECDSA 256 /
        } >>,

        / unprotected parameters / {
            / kid / 4: h'4173796d6d657472696345434453413
                          23536' / 'AsymmetricECDSA256' /
        },

        / COSE payload, the EAT, bstr wrapped / << {
            / nonce  /
            7:h'948f8860d13a463e8e',
    
            / UEID /
            8:h'0198f50a4ff6c05861c8860d13a638ea4fe2f',
    
            / boot_state (based on the -01 draft) /
            12:{true, true, true, true, false},
    
            / time stamp /
            6:1526542894,
    
            / The CoSWID /
            21: {

           / payload /
           6: {

                  24: "tfm.bin",
                  7: [
                      1,
   } >>,

   / signature / h'5427c1ff28d23fbad1f29c4c7c6a555e601d6fa29f
                   9179bc3d7438bacaca5acd08c8d4d4f96131680c42
                   9a01f85951ecee743a52b9b63632c57209120e1c9e
                   30'
]
)

> On Nov 26, 2019, at 3:51 PM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi Hannes,
>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 27 Nov 2019 09:49:05 +0000

Hi Laurence,

> In EATs with submods, there would likely be a CoSWID per submod (not

Yeah, that would sound like a fairly plausible way to translate PSA's
arm_psa_sw_components into EAT.  (One needs to work out the gory details
and confirm.)

cheers, thanks!

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 27 Nov 2019 14:08:08 +0100

Hi Laurence, hi thomas,
hi list,

Thomas, thank you for the nice example write-up! And Laurance, thank you 
for the write-up of an example of a COSE signed EAT including an 
unsigned payload coswid tag.

This is a write-up one option 3.) in issue #46.

Option 4.) would wrap the CoSWID map in a COSE before putting it into an 
EAT using another key (let's say 22 instead of 21 - that's just an 
example). A reason could be that an external entity, such as the SIWD 
role software-creator [1], created the tag and signed it. Other keys 
would follow for XML encoding, type of resource collection, as outlined 
in #46.

Viele Grüße,

Henk

[1] https://tools.ietf.org/html/draft-ietf-sacm-coswid-13#section-4.2

On 27.11.19 01:48, Laurence Lundblade wrote:
>            0: "trustedfirmware.org/TF-M <http://trustedfirmware.org/TF-M>",
> 
> 
>> On Nov 26, 2019, at 3:51 PM, Thomas Fossati <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Hannes,
>>
>> On 22/11/2019, 00:08, [email-masked] 
>> <mailto:[email-masked]>> wrote:
>>> Hi all
>>>
>>  0: "trustedfirmware.org/TF-M <http://trustedfirmware.org/TF-M>",
>>
>> 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.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 27 Nov 2019 14:24:47 +0100

Hello Thomas,

yes there are ways to deal with firmware in SWID, namely the resource 
type (index 19) in the set of SWID resource-collection [1] in 
combination with the rel type (index 40) entries.

This way, you would not have to use filesystem-items, but this way is 
also a bit clunky and would require an informational guidance document 
describing how to use *SWID for that. There are some quite smart ways to 
do that actually with filesystem-items, but I think it is more feasible 
to use a SUIT manifest here to describe everything relevant to the 
"firmware thingy" and then put a CoSWID into the SUIT manifest's outer 
wrapper [2] that then represents the rest of the semantics that is not 
covered by the manifest but by CoSWID. This method is fine, as the COSE 
envelope around the EAT will make tempering with the outer wrapper of 
the SUIT Manifest evident.

I think that is a more elegant way to do it, actually, and the reason 
why issue #46 in the EAT repo proposes to define a Claim to include a 
SUIT Manifest in an EAT, too.

Viele Grüße,

Henk

[1] https://tools.ietf.org/html/draft-ietf-sacm-coswid-13#section-2.9.2
[2] https://tools.ietf.org/html/draft-ietf-suit-manifest-02#section-7.2

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 27 Nov 2019 08:38:42 -0500

> On Nov 27, 2019, at 8:08 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence, hi thomas,
> hi list,
> 
> Thomas, thank you for the nice example write-up! And Laurance, thank you for the write-up of an example of a COSE signed EAT including an unsigned payload coswid tag.
> 
> Option 4.) would wrap the CoSWID map in a COSE before putting it into an EAT using another key (let's say 22 instead of 21 - that's just an example). A reason could be that an external entity, such as the SIWD role software-creator [1], created the tag and signed it. Other keys would follow for XML encoding, type of resource collection, as outlined in #46.

Having the option for both would meet the requirements for a signed or unsigned SWID/CoSWID previously discussed.

Best regards,
Kathleen 

>>>> On Nov 26, 2019, at 3:51 PM, Thomas Fossati <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Hannes,
>>> 
>>> On 22/11/2019, 00:08, [email-masked] <mailto:[email-masked]>> wrote:
>>>> Hi all
>>>>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 27 Nov 2019 16:59:28 +0000

Hi Henk

Thanks very much for your input.

On 27/11/2019, 13:24, "Henk Birkholz" <[email-masked]> wrote:
> describing how to use *SWID for that.

That's interesting because initially I also tried to use the resource
type -- which looked like the less wrong among all the available types
in the resource collection.  However it wasn't clear to me how to
associate a checksum to the component, hence I went for the
filesystem-item.  Maybe I was just looking in the wrong place or maybe,
as you say, there's a magic firmware recipe that's worth documenting
here.

> There are some quite smart ways to do that actually with
> filesystem-items, but I think it is more feasible to use a SUIT
> manifest here to describe everything relevant to the "firmware thingy"
> and then put a CoSWID into the SUIT manifest's outer wrapper [2] that
> then represents the rest of the semantics that is not covered by the
> manifest but by CoSWID. This method is fine, as the COSE envelope
> around the EAT will make tempering with the outer wrapper of the SUIT
> Manifest evident.
>

I'll look into this, thanks for the pointer.

Stepping back for a second and looking from the perspective of my
immediate requirement (i.e., "Is it possible to translate PSA's software
component claim using purely EAT constructs?"), ideally I'd like to have
something that is expressive enough to encode my semantics (i.e.: SW
component name, version, signer and measurement) without being overly
complex.

So my knee-jerk reaction is if that implies pulling a dependency on
SUIT maybe it's a bit too much?  But I confess haven't yet looked at
the details of your proposal nor I can claim enough SUIT-foo to really
grok the complexity involved.  As said, I'll have a look shortly.

cheers!

---

From: Adrian Shaw <[email-masked]>
Date: Wed, 27 Nov 2019 17:13:22 +0000

While there is some synergy with the SUIT definition, I’m unconvinced that it should be the way to express a software component metadata. Firstly, there are legacy systems without SUIT that would want to use EAT, and such a dependency would make it hard for incremental adoption. Secondly, not all the data from the SUIT manifest is needed for this claim.

Adrian

> On 27 Nov 2019, at 16:59, Thomas Fossati <[email-masked]> wrote:
>
> Hi Henk
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 27 Nov 2019 18:18:41 +0100

Hello Thomas,

we have a coswid extension in the queue that allows for the inclusion of 
hash-entries to very kind of resource-collection type (and also 12-14 
additional indexes, I think, that allow for the creation of Reference 
Integrity Manifests, including hashes for running processes). But this 
will not be submitted this year anymore, I am afraid. Very early next year!

You were not looking at the wrong place, it simply is not there yet, 
because the inclusion of hash-entries is done via "any attributes" in 
ISO XML SWIDs and NISTIR 8060 is focusing on files (not 
filesystem-items, which would include directories).

But we are very aware of that and will remediate that very soon (aka the 
CDDL is already written and passed multi-peer internal review).

It will be less of a "magic firmware recipe", though. If there is 
interest, we can increase the detail about how to reference and locate 
SUIT manifest content (the CDDL unpack operator can help with that, 
therefore retaining the semantic relationship with the SUIT manifest 
however you want to use it).

Viele Grüße,

Henk

> component name, version, signer and measurement) without being overly

Your examples look very close to the CoSWID as RIM, maybe the gaps to 
fill here in order to represent "filesystem-less" firmware is in fact 
relatively small. We will submit the CoSWID RIM part in a few weeks and 
will get some feedback on that (e.g. hash-entries for resources).

> grok the complexity involved.  As said, I'll have a look shortly.

The SUIT manifest can look very complex (CDDL-wise), but please keep in 
mind that most members (content items) are optional, so an actual 
instance of SUIT manifest can be quite... concise :) While I see the 
point in doing it "all in one thing" the SUIT manifest is an excellent 
representation for what is needed in updating small and big or cloudy 
things and redundant semantics in data formats often create 
corresponding friction in semantic interoperability later on (iotdir hat 
on opinion). So my first reaction is to combine the functionality of 
both and not to recreate the functionality redundantly on each side.

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 27 Nov 2019 18:27:21 +0100

Hi Adrian,

to your first point: I am not sure what legacy systems that would be 
able to create/process EAT would not be able to process a SUIT manifest. 
Could you elaborate on that? I'd maybe not call that a dependency, but 
rather synergy in data models, but I am under the suspicion that I 
simply don't understand the scenario that you are talking about.

To your second point, as the SUIT manifest CDDL specification allows for 
a lot of optional types or members, a small paragraph of which ones to 
use when (like NISTIR 8060 does it for SWID, only on a very much larger 
level) could address that?

Then again, if there is enough interest to do a small subset of new 
firmware related CDDL content as highlighted by Thomas

> ideally I'd like to have

we could add that to the upcoming CoSWID extension. Again, I would like 
to have these additional items as close as possible to the SUIT manifest 
semantically, so there will never be any kind of confusion what each 
value is intended to express and interoperability is "a piece of cake". 
And with respect to firmware semantics, SUIT has the lead here, I think

Viele Grüße,

Henk

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 27 Nov 2019 12:50:15 -0500

On Wed, Nov 27, 2019 at 12:13 PM Adrian Shaw <[email-masked]> wrote:

> While there is some synergy with the SUIT definition, I’m unconvinced that
> it should be the way to express a software component metadata. Firstly,
> there are legacy systems without SUIT that would want to use EAT, and such
> a dependency would make it hard for incremental adoption. Secondly, not all
> the data from the SUIT manifest is needed for this claim.
>

Agreed, there are other standards for software update that have been
adopted and use alternate formats for manifests.  I like the idea of
SWID/CoSWID as well.

Best regards,
Kathleen

> 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.
> 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.

-- 

Best regards,
Kathleen

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 28 Nov 2019 16:47:23 +0000

Hi Henk,

> will not be submitted this year anymore, I am afraid. Very early next year!

Very interesting, thanks.  If possible, I'd like to have a look at the
proposal.  (No worries, I'll ask around here first, there should be a
couple of colleagues with access to the RIV work-in-progress in the room
next to mine.)

However, if I extrapolate correctly from what you say, this new CoSWID
extension would pop up on the RIM side rather than being a way to wrap
the measurements coming from the device in an attestation report?
If so, it makes a lot of sense to me.

[...]

I've done a bit of reading in the last two days and the more I look at
CoSWID the more I'm persuaded that while they'd work perfectly well for
a "software inventory" claim, the semantic overlap with a TPM/TEE/PSA
measurement is a bit tenuous and probably not enough to justify their
usage in those contexts.

My understanding is that in TPM/TEE/PSA the *measurement*, i.e. the
result of a function computed at {boot,run}-time on a piece of
executable and/or static memory, is the first class object of the
attestation.  A measurement comes with a bunch of optional metadata
attached (e.g., the measured software/firmware component name and
version, its signer, etc.), but these are effectively only metadata, not
necessary attributes -- in fact, our implementation of the verifier
doesn't care if they are not found in the submitted token.  On the other
hand, the entity modelled by a SWID is a *software component*, so using
that to wrap a measurement would look like a slight semantic abuse?

(As a meta comment, it seems to me that the risk associated with
CoSWID's excellent syntactic malleability is its semantics can be
stretched a tad too much.)

OK, concluding this long (and boring) rambling with an arc back to
Laurence's email "More claims? When is EAT done?" [1] and the related
discussion in Singapore, my current take on this is:
1. SW Inventory claim: yes, with CoSWID;
2. Measurements and Integrity Checks claim: yes please, with a new ad
   hoc format.

> both and not to recreate the functionality redundantly on each side.

At the moment it still looks like a stretch to me, but I'd like to take
some more time to mull it over and discuss it with my fellow SUIT
colleagues because I think it's an interesting thought.

Cheers, thanks!

[1] https://mailarchive.ietf.org/arch/msg/rats/LXq1JH-w16L6qXeyBblKTkQ_-FA

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Nov 2019 13:53:29 -0800

I am very much agreement with Adrian.

SUIT is far from wide adoption, yet billions of devices have verified/secure boot* and do a good job of SW update. Some of these devices like mobile phones have very complex boot and multifaceted SW updated, other are very simple lost cost single-use devices.

For many use cases, a simple EAT with only a few claims will suffice. Maybe the only claims are the UEID and the version of THE software for the device because it only has one SW component. Only the mandatory CoSWID fields, plus version, are filled in for the single SW component. Such an EAT would have 8 claims as in the example below. It is critical IMO that EAT keeps tokens for these simple use case simple. The minimum CoSWID is 5 claims right now. Wouldn’t want to increase that.

Constructing the payload for this EAT is pretty simple. The only claim that varies from one token to the next is the nonce. The CoSWID part could be a hard-coded byte array containing the encoded CBOR since it will never change. The harder part of EAT here will be COSE and signing key set up, not claim construction.

Importantly, the boot SW of this simple device need not be touched. The EAT implementation automatically gets the security from whatever boot security it has. 

Even on a complex device such as one with a TEE and TA’s, the TA’s most likely get all the security from the boot sequence and TEE OS without having to modify the boot sequence or the TEE OS (I am quite sure of this having done it for Qualcomm's Hardware Token here <https://www.qualcomm.com/products/features/mobile-security>).

LL

* Generally agree with Monty’s recent definition of verified boot; some people call this secure boot

18(
    [

            / UEID /
    
            / The CoSWID /
            21: {

          31: "Linaro Limited”,

           },

       }
   } >>,

> On Nov 27, 2019, at 9:13 AM, Adrian Shaw <[email-masked]> wrote:
>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 29 Nov 2019 03:38:56 +0100

Hi Laurence,

I absolutely agree.

1.) the complexity of a solution should be appropriate to the problem.

=> EAT is very flexible and can scale from simple to (maybe even overly 
- we should avoid that) complex.

2.) It is critical to not use an overly complex solution for a simple 
problem.

3.) There could be "hardcoded" (but in that case mandating their own 
signature) CoSWID Claims for specific type/model composites that cannot 
be differentiated via their software components (because they are all 
the same, for example) and that is fine (as an analogy, I think there 
could be binary YANG telemetry that is composed of hardcoded 
building-blocks, if the device the custom subscription is created with 
is simple enough).

4.) If the boot SW is not intended to be touched, it is not touched. 
Although I think, an EAT should highlight that in it's CoSWID or a 
related claim in the EAT, to steer its "superior's"/management system's 
decision as a "hint".

5.) It should not be excluded to allow for complex composition of CoSWID 
and SUIT claims for more complex devices that can deal with elaborate 
update and remediation scenarios.

=> Again, EAT provides the flexibility for that - we should leverage 
that, I think.

Happy Thanks Giving!

Henk

p.s. alas a CoSWID will never be a "a hard-coded byte array", please 
never cut out a portion out of a CoSWID, but deliver it "in its 
entirety". Your example used the index 21 (which I assume is an example 
for an EAT Claim), but please prefix the COSE CBOR tag (if the CoSWID 
tag is signed) and always prefix the CoSWID CBOR tag (inside the body of 
the COSE envelope, too, if applicable) :)

On 28.11.19 22:53, Laurence Lundblade wrote:
> SUIT is far from wide adoption, yet billions of devices have 
> verified/secure boot* and do a good job of SW update. Some of these 
> devices like mobile phones have very complex boot and multifaceted SW 
> updated, other are very simple lost cost single-use devices.
> 
> For many use cases, a simple EAT with only a few claims will suffice. 
> Maybe the only claims are the UEID and the version of THE software for 
> the device because it only has one SW component. Only the mandatory 
> CoSWID fields, plus version, are filled in for the single SW component. 
> Such an EAT would have 8 claims as in the example below. It is critical 
> IMO that EAT keeps tokens for these simple use case simple. The minimum 
> CoSWID is 5 claims right now. Wouldn’t want to increase that.
> 
> Constructing the payload for this EAT is pretty simple. The only claim 
> that varies from one token to the next is the nonce. The CoSWID part 
> could be a hard-coded byte array containing the encoded CBOR since it 
> will never change. The harder part of EAT here will be COSE and signing 
> key set up, not claim construction.
> 
> Importantly, the boot SW of this simple device need not be touched. The 
> EAT implementation automatically gets the security from whatever boot 
> security it has.
> 
> Even on a complex device such as one with a TEE and TA’s, the TA’s most 
> likely get all the security from the boot sequence and TEE OS without 
> having to modify the boot sequence or the TEE OS (I am quite sure of 
> this having done it for Qualcomm's Hardware Token here 
> <https://www.qualcomm.com/products/features/mobile-security>).
> 
> LL
> 
> 
> 18( [ / protected parameters, bstr wrapped / << { / alg / 1: -7 / ECDSA 
> 256 / } >>,
> 
> / unprotected parameters / { / kid / 4: 
> h'4173796d6d657472696345434453413 23536' / 'AsymmetricECDSA256' / },
> 
> 
> / COSE payload, the EAT, bstr wrapped / << { / nonce /
> 
> 7:h'948f8860d13a463e8e',
> 
> / UEID /
> 
>     9a01f85951ecee743a52b9b63632c57209120e1c9e 30'
> 
>     ]
> 
> )
> 
> 
> 
> 
> 
>> On Nov 27, 2019, at 9:13 AM, Adrian Shaw <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> While there is some synergy with the SUIT definition, I’m unconvinced 
>> that it should be the way to express a software component metadata. 
>> Firstly, there are legacy systems without SUIT that would want to use 
>> EAT, and such a dependency would make it hard for incremental 
>> adoption. Secondly, not all the data from the SUIT manifest is needed 
>> for this claim.
>>
>> Adrian
>>
>>> On 27 Nov 2019, at 16:59, Thomas Fossati <[email-masked] 
>>> On 27/11/2019, 13:24, "Henk Birkholz"