Re: [Rats] EAT claims needed by TEEP

[Dave Thaler <[e-mail]>]

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:

  1.  Device unique identifier -> use ueid claim
  2.  Vendor of the device -> use oemid
  3.  Firmware type -> use sw-name
  4.  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 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

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.