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

[Laurence Lundblade <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.

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 payload format the Verifier needs to handle.

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

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

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 <[e-mail] <mailto:[e-mail]>> on behalf of Kathleen Moriarty <[e-mail] <mailto:[e-mail]>>
> Date: Monday, December 2, 2019 at 10:16 AM
> To: Michael Richardson <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, sacm <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Suit] [Rats] [sacm] CoSWID and EAT and CWT
>  
>  
>  
> On Mon, Dec 2, 2019 at 11:51 AM Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Brendan Moran <[e-mail] <mailto:[e-mail]>> 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...
>  
> 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   [
>> ]     [e-mail] <mailto:[e-mail]>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails    [
>> 
>> 
>> 
>> 
>> --
>> Michael Richardson <[e-mail] <mailto:[e-mail]>>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>> 
>> 
>> 
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
>  
> -- 
>  
> Best regards,
> Kathleen
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>