Subject: Re: [Suit] [sacm] [Rats] CoSWID and EAT and CWT

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:
> 
> 
> Sent from my mobile device
> 
>> On Nov 20, 2019, at 11:29 PM, Waltermire, David A. (Fed) 
>> <[email-masked]> 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.
>>
>> Kathleen, if this is true, does this way forward address your 
>> CWT-related comments?
> 
> 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
>>
>> 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,
>>
>>         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://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
>>
>>         _______________________________________________
>>         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
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

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:
>> <[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]>>
> [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]
>     <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]>>
>      >> [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>
>      >>