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

From: Brendan Moran <[email-masked]>
Date: Mon, 2 Dec 2019 16:16:32 +0000

Hi Henk,

Thanks for bringing this to my attention. I'm not sure that I understand the goal of using a CWT for a CoSWID or a SUIT manifest. Would you be able to elaborate on why we should use CWT?

From a high level, my concern is that using CWT will introduce a substantial architectural change to the manifest specification: The manifest is structured as:
1. Outer Wrapper (map) {
   1.1 CWT Key Claims (list of CWT)
   1.2 Authentication wrappers (List of COSE Signatures/MACs)
   1.3 Manifest (map)
   1.4 Severable items

(Note that the placement of CWT key claims is new and not in the latest draft--it is a change that was brought in to make PQC handling more elegant)

Within the manifest, there is little overlap with the base set of CWT claims.

What would using CWT for the SUIT manifest accomplish?

Best Regards,
Brendan

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Henk Birkholz
Sent: 24 November 2019 15:44
To: Smith, Ned <[email-masked]>; Kathleen Moriarty <[email-masked]>
Cc: [email-masked]; sacm <[email-masked]>; [email-masked]; Laurence Lundblade <[email-masked]>; Ira McDonald <[email-masked]>; Waltermire, David A. (Fed) <[email-masked]>
Subject: Re: [Suit] [Rats] [sacm] CoSWID and EAT and CWT

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
> <[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,
>
> I am not entirely following you, so I am not stating agreement yet.
>
> On Fri, Nov 22, 2019 at 12:06 PM Henk Birkholz
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>    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).
>
> 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?
>
>
>    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.
>
> 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.
>
>
>    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.
>
> 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
>
>
>    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] <mailto:[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]
>    <mailto:[email-masked]>> on behalf of Kathleen Moriarty
>>> <[email-masked]
>    <mailto:[email-masked]>>
>>> *Sent:* Wednesday, November 20, 2019 9:10 PM
>>> *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]>>
>>> *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]>
>>> <mailto:[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 <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]>>
>>>      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]>
>    <mailto:[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]> <mailto:[email-masked]
>    <mailto:[email-masked]>>
>>> https://www.ietf..org/mailman/listinfo/rats
>    <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]> <mailto:[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] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/sacm
>
>
> --
>
> Best regards,
>
> Kathleen

_______________________________________________
Suit mailing list
[email-masked]
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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Dec 2019 11:51:27 -0500

Brendan Moran <[email-masked]> wrote:
    > Thanks for bringing this to my attention. I'm not sure that I
    > understand the goal of using a CWT for a CoSWID or a SUIT
    > manifest. Would you be able to elaborate on why we should use CWT?

I'm also in need of a diagram of how CoSWID and SUIT manifests and RATS EAT
interact.   I feel that the (optional) layer of signature in the CoSWID is
causing us to lose the forest for the trees...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 2 Dec 2019 13:15:08 -0500

> causing us to lose the forest for the trees...

I see why you might want a CoSWID or SWID in a CWT or EAT, but don't see
the mapping for SUIT being preferred to CoSWID or SWID.

Best regards,
Kathleen

> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

-- 

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 3 Dec 2019 01:38:28 +0000

EAT is a payload that can be exchanged between an Attester-Verifier or Verifier-RelyingParty.
[Co]SWID is a payload that can be exchanged between Endorser-Verifier or (possibly?) Attester-Verifier.

It is the latter use case context (Attester-Verifier) that is potentially confusing because it presumes the [Co]SWID payload should be wrapped by an EAT.

The architecture slides presented at Singapore showed Attester-Verifier interactions supporting multiple signed formats. Therefore, it could be reasonable to consider [Co]SWID as yet another payload format the Verifier needs to handle.

Another consideration might question whether it makes sense for [Co]SWID to be regarded as Evidence. Maybe it should be restricted to Endorsements?

The SWID documentation seems to suggest that SWID structures should be maintained on the Attester and updated when SW/FW updates occur. Possibly, the installer is working with two objects SUIT manifests and [Co]SWID structures keeping both maintained on the Attester? If this is the case, then it might make sense to consider unifying them? That might be the context for some of the list activity surrounding SUIT manifest and [Co]SWID?

The important distinction from the perspective of the RATS architecture is that Endorsements (signed by a mfg – aka “Endorser”) are still Endorsements even if they are stored on the Attester and conveyed to a Verifier over a conveyance protocol that supports conveyance of Evidence. Evidence and Endorsements are signed by different keys. How they are conveyed isn’t interesting to the Verifier per se. except where freshness is a consideration.
-Ned

From: Suit <[email-masked]> on behalf of Kathleen Moriarty <[email-masked]>
Date: Monday, December 2, 2019 at 10:16 AM
To: Michael Richardson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, sacm <[email-masked]>
Subject: Re: [Suit] [Rats] [sacm] CoSWID and EAT and CWT

On Mon, Dec 2, 2019 at 11:51 AM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

I see why you might want a CoSWID or SWID in a CWT or EAT, but don't see the mapping for SUIT being preferred to CoSWID or SWID.

Best regards,
Kathleen

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

--

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 2 Dec 2019 18:17:11 -0800

Hi Ned,

I think of CoSWID has a “data structure” or such that can get defined once and re used for various use cases, attestation related and not attestation related. EAT is one attestation use case. Maybe evidence is another attestation use case, maybe not. There are certainly the use cases it was created for before EAT came along.

> On Dec 2, 2019, at 5:38 PM, Smith, Ned <[email-masked]> wrote:
> 

In EAT, I think of a CoSWID appears as a claim along side the other claims. It’s a big complicated / nest claim, but it is a claim. I don’t think of it as wrapped.  It is necessary to sit along side the other claims in EAT for EAT to do its job.

> The architecture slides presented at Singapore showed Attester-Verifier interactions supporting multiple signed formats. Therefore, it could be reasonable to consider [Co]SWID as yet another payloa…

It doesn’t seem helpful to create another attestation format that is marginally different and confusingly related to EAT.

Maybe there are use cases other than attestation where a CoSWID is signed CWT-style, but I think they are other use cases for other working groups to decide on.

> Another consideration might question whether it makes sense for [Co]SWID to be regarded as Evidence. Maybe it should be restricted to Endorsements?

There are clear EAT-based use cases that want SW inventory in the attestation. ARM’s PSA is like this. Pretty sure the hum in Singapore was in favor of that. Seems also that Cisco wants that for their routers. So, definitely not restricted to Endorsements.

> The SWID documentation seems to suggest that SWID structures should be maintained on the Attester and updated when SW/FW updates occur. Possibly, the installer is working with two objects SUIT mani…

I have little opinion about whether SUIT manifest and CoSWID should be merged somehow, but it seems that SWID and CoSWID have massive use case outside of SUIT and Attestation.

I would hope you could create a CoSWID to represent the SW on the MacOS device I’m using right now. It would be a big one. It certainly doesn’t use SUIT and never will.

> The important distinction from the perspective of the RATS architecture is that Endorsements (signed by a mfg – aka “Endorser”) are still Endorsements even if they are stored on the Attester and co…

Yes. :-)

Never occurred to me that Endorsements would flow that way, but seems like a useful option!

(That said, I’m not sure that the format of an Endorsement is in our charter)

LL

> -Ned
>  
> From: Suit <[email-masked] <mailto:[email-masked]>> on behalf of Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>
> To: Michael Richardson <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, sacm <[email-masked] <mailto:[email-masked]>>
> On Mon, Dec 2, 2019 at 11:51 AM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Brendan Moran <[email-masked] <mailto:[email-masked]>> wrote:
>> ]     [email-masked] <mailto:[email-masked]>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails    [
>> 
>> 
>> 
>> 
>> --
>> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
>  
> -- 
>  
> Best regards,
> Kathleen
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Dec 2019 08:04:30 -0500

Smith, Ned <[email-masked]> wrote:
    > The architecture slides presented at Singapore showed Attester-Verifier
    > interactions supporting multiple signed formats. Therefore, it could be
    > reasonable to consider [Co]SWID as yet another payload format the Verifier
    > needs to handle.

That's an interesting take on things.
My reading of CoSWID is that COSE signatures are almost an afterthought
(appendix A), and in any case, would be produced by manufacturers rather than
as evidence.

It seems that inclusion of an unsigned CoSWID into a SUIT Manifest is
appropriate as the manufacturer is authoritative for both.

    > Another consideration might question whether it makes sense for [Co]SWID to
    > be regarded as Evidence. Maybe it should be restricted to Endorsements?

I think that it makes more sense as Endorsement only, as such it falls
outside of the normative part of the RATS architecture.

    > The important distinction from the perspective of the RATS architecture is
    > that Endorsements (signed by a mfg – aka “Endorser”) are still Endorsements
    > even if they are stored on the Attester and conveyed to a Verifier over a
    > conveyance protocol that supports conveyance of Evidence. Evidence and
    > Endorsements are signed by different keys. How they are conveyed isn’t
    > interesting to the Verifier per se. except where freshness is a
    > consideration.

If the manufacturer-signed Endorsement is communicated within EAT, then it's
not a seperate token format. It's just payload for a Evidence carrying EAT.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 3 Dec 2019 14:09:00 +0100

As the I-D is trying to stay close to the ISO/IEC spec & as COSE is an 
"envelope" encapsulating a CoSWID tag, the guidance on signing is 
actually a bit detached to the structure of a CoSWID.

Having said that. CoSWID can be measurements of installed SW components 
on an Attester and be part of Attestation Evidence. For this, they do 
not have to be signed - this depends on the level of assurance the 
Attest-ING Environment of the Attester can provide (e.g. via 
Endorsements from Endorsers, formerly known as Asserters).

On 03.12.19 14:04, Michael Richardson wrote:
> [email-masked]

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 3 Dec 2019 16:12:19 +0000

Henk,
I'm not clear if you are saying that an unsigned CoSWID is assumed to be a statement from an Attest-ING environment or something else. Normally, I regard unsigned assertions as invalid (verifiers should not make assumptions). 

CoSWID structures can be signed by either Attesters (Attesting env) or Endorsers. The CoSWID formatting is the same but the signers are different and a Verifier might treat the CoSWID content differently based on who signed it. For example, if an Attester signed it then a Verifier would expect to find an Endorser signed CoSWID with which to compare to Evidence. 

Enveloping formats (e.g. EAT[CoSWID] ) doesn't disambiguate who signed what. Both the EAT thing and the CoSWID thing could be signed and by different signers. Alternatively, neither of them could be signed. If the latter, then both the EAT and CoSWID things are invalid.
-Ned

On 12/3/19, 5:09 AM, "Suit on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Dec 2019 16:07:55 -0500

Smith, Ned <[email-masked]> wrote:
    > I'm not clear if you are saying that an unsigned CoSWID is assumed to
    > be a statement from an Attest-ING environment or something
    > else. Normally, I regard unsigned assertions as invalid (verifiers
    > should not make assumptions).

I believe that unsigned CoSWID structures will be inside another signed
structure (such as a SUIT manifest), will be conveyed by secure transport
(i.e. HTTPS or CoAPS transport of a RESTCONF mechanism that retrieves it), or
will be stored in a trusted database.

So, I agree with you that unsigned CoSWID objects in the wild would be
invalid and unusual.

    > CoSWID structures can be signed by either Attesters (Attesting env) or
    > Endorsers. The CoSWID formatting is the same but the signers are
    > different and a Verifier might treat the CoSWID content differently
    > based on who signed it. For example, if an Attester signed it then a
    > Verifier would expect to find an Endorser signed CoSWID with which to
    > compare to Evidence.

I'm a bit uncomfortable with the idea that a CoSWID signed by an Attester is
the way that an Attester indicates what software release it is running.
I would prefer that the structure was instead:
   EAT{protected_map{measurement-of-running-firmware=XX}
       S_endorser{firmware_version=YY,measurement=XX}}

That is, the CoSWID provided by as part of the Evidence would echo the
Endorsement. Of course, the Verifier would still have to be able to verify
the endorser's key, but having done so, it now can consider the policy
question: "is firmware_version YY new enough?"

    > Enveloping formats (e.g. EAT[CoSWID] ) doesn't disambiguate who signed
    > what. Both the EAT thing and the CoSWID thing could be signed and by
    > different signers. Alternatively, neither of them could be signed. If
    > the latter, then both the EAT and CoSWID things are invalid.

I think that we are in violent agreement here.

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 3 Dec 2019 21:32:03 +0000

On 12/3/19, 1:08 PM, "Suit on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    So, I agree with you that unsigned CoSWID objects in the wild would be
    invalid and unusual.
[nms] The unsigned CoSWID that is enveloped by something else that is signed may not be the same as a CoSWID that is (directly) signed because the signing keys could differ. The Verifier should care not only about who asserts the CoSWID but also whether or not that entity is authorized (most authoritative entity) to make the assertion. Even if some other layer 'signs' it, it could still be invalid.

    

[nms] Agree. CoSWID is good at saying M=(S_endorser{firmware_version=YY,measurement=XX}). Verifier doesn't necessarily care if M arrives as an EAT map (above) or some other way. Verifier might care that Attester knew that measurement-of-running-firmware matches M if Attester is also doing Verified Boot or is trusted in some way to make sure XXs match. Simply constructing the map doesn't imply the Attester did the other checks unless there is a specification that mandates the check as a condition of forming the map structure.