Re: [Rats] EAT claims needed by TEEP

[Laurence Lundblade <[e-mail]>]

This PR <https://github.com/ietf-rats-wg/eat/pull/139> now exists to address class.

I was never quite sure what it was and it seemed TEEP/SUITE specific to me, one of the reasons I didn’t do anything about it for the -11 draft. See if what I’ve got in the PR makes sense.

LL


> On Nov 8, 2021, at 9:20 AM, Dave Thaler <[e-mail]> wrote:
> 
> Following up on the RATS meeting today, I compared the latest EAT document
> against the TEEP requirements discussed most recently at the IETF 111 RATS meeting.
>  
> There were 5 requirements from TEEP for claims, ideally general use ones not profile specific ones.
> My reading is that the latest EAT doc now meets 4 of the 5 and only “device class” is missing,
> and indeed the EAT document discussion of ueid explicitly says
> “It does not identify types, models or classes of devices.”
> but nothing else in the document I could find provides a way to identify such.
>  
> Henk’s proposal there was section 3.1.2 of draft-birkholz-rats-suit-claims:
>  
> > 3.1.2.  class-identifier
> > 
> >   A RFC 4122 UUID representing the class of the Attester or one of its
> >   hardware and/or software components.
> > 
> >   $$system-property-claim //= ( class-identifier => RFC4122_UUID )
>  
> The other four requirements from TEEP can be met as follows, if I understand
> the intent correctly:
> Device unique identifier -> use ueid claim
> Vendor of the device -> use oemid
> Firmware type -> use sw-name
> Firmware version -> use sw-version
>  
> The above claims would go in a claimset about the TEE (which may or may not be
> a separate processor), but EAT already supports different claimsets for different
> components as I understand it, so that’s fine.
>  
> https://github.com/ietf-rats-wg/eat/issues/138 <https://github.com/ietf-rats-wg/eat/issues/138> tracks this issue and my belief
> is it should be simple to add a device class claim into a draft -12 of EAT.
>  
> I will also cover this in the TEEP WG meeting on Friday where I will discuss
> what we need to change in the TEEP protocol spec, where this is tracked by
> https://github.com/ietf-teep/teep-protocol/issues/165 <https://github.com/ietf-teep/teep-protocol/issues/165>
>  
> Dave
>  
> From: Thomas Fossati <[e-mail]> 
> Sent: Thursday, October 29, 2020 2:21 PM
> To: Laurence Lundblade <[e-mail]>
> Cc: [e-mail]; teep <[e-mail]>; Dave Thaler <[e-mail]>; Simon Frost <[e-mail]>; Thomas Fossati <[e-mail]>
> Subject: Re: [Rats] EAT claims needed by TEEP
>  
> On 29/10/2020, 21:07, "RATS" <[e-mail] <mailto:[e-mail]>> wrote:
> > On Oct 29, 2020, at 1:45 PM, Thomas Fossati <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Hi Laurence,
> > 
> > > My understanding is that they are always encoded as CBOR text strings,
> > > so floating-point doesn’t mean #7.25 or such.
> > 
> > Correct.  In (Co)SWID software-version is just a text string and version-scheme
> > is there to do some semantic polishing.  But the underlying type is always #3.
> > 
> > Maybe I'm misunderstanding your proposal here, but I would be circumspect
> > in mixing SWIDs attributes, which are scoped to software artifacts, with HW
> > identifiers.
> > 
> > 
> > Hi Thomas,
> > 
> > All the SW Version stuff would fall under a single EAT claims that
> > contains a full CoSWID.
> > 
> > For HW Version, I was thinking of two EAT claims, one for the version
> > text, another for the version scheme (or we could go off and define a
> > full CoHWID).
>  
> OK, looks like I had misunderstood your plan :-) thanks for the
> clarification!
> 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.