Subject: Re: [Rats] Call for 111 RATS presentations

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Sep 2021 11:32:52 -0400

Dave Thaler <dthaler=[email-masked]> wrote:
    > I would like to again bring up “TEEP requirements for EAT” during that
    > slot.
    > The specific draft in question, which has been discussed in RATS
    > before, is draft-birkholz-rats-suit-claims

Given the commonality of chairpersonship, and how TEEP is called out in the
RATS charter, RATS should just adopt already.

(sorry if this sat in my outbox a long time)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 1 Sep 2021 16:25:20 +0000

I believe there were several options presented for how adoption might move forward. One option was inclusion in EAT which is already adopted. Maybe we can get a more crisp proposal for which document will contain TEEP requirements then it will be clear what next steps for adoption will be?
-Ned

On 9/1/21, 8:33 AM, "Michael Richardson" <[email-masked]> wrote:

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 1 Sep 2021 19:13:17 +0200

I am happy with where they are. Adding Brendan.

As these Claims are "grouped by suit" and in a side discussion I assume 
there was some consensus on "these are also somewhat different from the 
Claims currently in the EAT I-D" (please chime in here, if I am putting 
the wrong words in other peoples mouths here), I see no strong reason 
for going through the movements of chopping the document up and also 
make "the remaining parts" retain some sense of consistency and 
readability as a separate I-D. Unless, there is strong argument for 
putting the work into separating content (please mind that these are 
first of all extra steps of work, but also extra references to follow, 
to keep consistent, to look up, etc.).

Any additional thoughts on this?

Viele Grüße,

Henk

On 01.09.21 18:25, Smith, Ned wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 2 Sep 2021 21:16:59 -0700

There definitely seem to be a few SUIT-specific claims, so the document should exist and the claims in it should be renamed to be SUIT-specific.

With some clarification, perhaps some become general claims and get put into EAT, but I’m not certain yet. Requests for more details below.

I think device-identifier should be dropped and UEID from EAT used instead.

Claim by claim:

vendor-identifier
From a conversation with Brendan and others, I take this as a SUIT-vendor-identifer. It’s purpose is to match the SUIT SW vendor to the target device and needs to take into account the HW vendor and the SW vendor. Definitely not the same as any EAT claim.

—> rename it suit-vendor-identifier
—> fill in some more details on what it is to represent that came to light in other discussion

class-identifier
Seems very SUIT-specific.

—> rename it suit-device-class-identifier or such
—> fill in a description of how to generate it

device-identifier
Seems like a UEID to me. Drop this claim and use UEID instead (or say why UEID won’t work).

component-identifier
image-digest
image-size
These are characteristics specifically of the *Attester*. Is that what you really mean? What if the Attester is part in HW? What if the Attester is split across a TPM and something other SW? What if the Attester is just a chunk of code in the TEE kernel, but not the whole kernel?

Maybe this should be generic and not SUIT specific if we really want to send sizes and digests of Attesters around?

—> move to EAT if it is general???
—> rename it attester-image-size…???

minimum-battery
This is described as the "configured minimum battery level of the Attester". So, it is not the current battery charge level being reported as a claim, right? Nor is it the minimum battery level required for a SW update, because that is elsewhere in SUIT. So not really sure what it is in Attestation Evidence.

It seems like a generic claim for battery level would be useful in EAT, but that seems a bit complex to design. You’d want the battery capacity and the current battery charge level, perhaps as a percentage. Would that tell you enough to know if you want to go ahead with a transaction? Maybe you want the current drain rate?  Might require a battery person to tell us more.

version
I think we need more details on this to know what to do with it.

—> At minimum rename it so it is not just “version”, so the claim name says what it is the version of.

LL

> On Sep 1, 2021, at 10:13 AM, Henk Birkholz <[email-masked]> wrote:
> 
> As these Claims are "grouped by suit" and in a side discussion I assume there was some consensus on "these are also somewhat different from the Claims currently in the EAT I-D" (please chime in here, if I am putting the wrong words in other peoples mouths here), I see no strong reason for going through the movements of chopping the document up and also make "the remaining parts" retain some sense of consistency and readability as a separate I-D. Unless, there is strong argument for putting the work into separating content (please mind that these are first of all extra steps of work, but also extra references to follow, to keep consistent, to look up, etc.).
>

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 3 Sep 2021 22:29:30 +0000

> —> At minimum rename it so it is not just “version”, so the claim name says what it is the version of.

I think this point raises a bigger question. “To what do any of the claims pertain?” Today EAT claims are tag-value tuples where the tag “version” is followed by its value. An EAT claim set is a list of tuples that describes something, but that something isn’t named.

Possibly, some of the other CWT claims could be used to do that? For example, ‘sub’ could identify the Target Environment but ‘sub’ is pretty open ended in terms of what it could contain. By contrast, a SUIT manifest relies on vendor name, class identifier etc… In the corim schema environments can be identified by a class identifier or an instance identifier (such as a UEID). The association of a set of claims to an environment should be a central aspect of what we’re trying to accomplish IMHO.

-Ned
From: Laurence Lundblade <[email-masked]>
Date: Thursday, September 2, 2021 at 9:17 PM
To: Henk Berkholz <[email-masked]>
Cc: "Smith, Ned" <[email-masked]>, Michael Richardson <[email-masked]>, Dave Thaler <dthaler=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Brendan Moran <[email-masked]>
Subject: Re: [Rats] Call for 111 RATS presentations

Claim by claim:

vendor-identifier

class-identifier

device-identifier

component-identifier

image-digest

image-size

minimum-battery

version

LL

On Sep 1, 2021, at 10:13 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Viele Grüße,

Henk

I believe there were several options presented for how adoption might move forward. One option was inclusion in EAT which is already adopted. Maybe we can get a more crisp proposal for which document will contain TEEP requirements then it will be clear what next steps for adoption will be?
-Ned
On 9/1/21, 8:33 AM, "Michael Richardson" <[email-masked]<mailto:[email-masked]>> wrote:
    Given the commonality of chairpersonship, and how TEEP is called out in the
    RATS charter, RATS should just adopt already.
    (sorry if this sat in my outbox a long time)
    --
    Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
               Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

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

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 3 Sep 2021 16:46:53 -0700

> On Sep 3, 2021, at 3:29 PM, Smith, Ned <[email-masked]> wrote:
> 
> > version

Hi Ned,

I’m not too worried about this. I think of the CWT/JWT registries as a smorgasbord/mall food court/dim sum of claims for anyone to use for any purpose they wish. The receiver distinguishes the use by context. In one context it might be an authentication token, in another an attestation token. It’s perfectly OK for authentication tokens to use attestation claims. This seems to be the way CWT and JWT work now.

I’m asking that the claims defined for SUIT have SUIT-specific names so no one looks into the CWT/JWT registries and thinks that the vendor-identifier claim and such are intended for identify a vendor in every/any context that a token is every used, that this is THE universal vendor identifier for ALL hardware, firmware and software.

Trying for just a little bit of order in the CWT/JWT registries. :-)

We also have EAT profiles to help manage chaos here. Maybe there should be an EAT profile that says how attestation claims apply to SUIT?

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 10 Sep 2021 16:15:50 +0000

Laurence,
I’m open to working with you / others on how one might represent a ‘triple’ as described in the corim draft in a CWT token.
Thx,
Ned

From: Laurence Lundblade <[email-masked]>
Date: Friday, September 3, 2021 at 4:47 PM
To: "Smith, Ned" <[email-masked]>
Cc: Henk Berkholz <[email-masked]>, Brendan Moran <[email-masked]>, Michael Richardson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Dave Thaler <dthaler=[email-masked]>
Subject: Re: [Rats] Call for 111 RATS presentations

Hi Ned,

LL

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 10 Sep 2021 18:59:25 +0200

I am not entirely sure about this. I'd dare to say that this is not how 
semantic interoperability works. Some kind of taxonomy reflected in the 
registr{y|ies} might make a lot of semantic folks happier. Just a thought.

On 10.09.21 18:15, Smith, Ned wrote:
> This seems to be the way CWT and JWT work now.

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 10 Sep 2021 19:16:34 +0200

This I am really in support of. There is this curious gap between how 
messages look like in the everyday JSON/CBOR space and how RDF modeled 
data looks like in "the semantic space". JSON-LD is a prominent example 
of "doing it better than XML" and still does not always seems to be 
hitting the sweat spot.

Packed CBOR, CoRAL and CRI are addressing some of these issues in the 
CoRE domain, but... still I think there is room for improvement in the 
"naive triple representation in messages" space. CoRIM is a place where 
- after months of refactoring - we arrived at a state where most people 
are happy and content with simplistic triple representation.

I think it is important not to disrupt that CoRIM space. So my explicit 
intend is to shield that work from re-iterating months of consensus 
building.

Instead, I am in strong support of transplanting some of the CoRIM 
output into the CWT space. Of course there should be some kind of 
feedback loop for constructive comments. But let me be very clear here: 
While CoRIM can act as a source for scoped proposals how to frame 
simplistic triples in the CWT space, it is distinctly not the goal to 
let the CWT space seep into the CoRIM space. CoRIM is not a CWT and that 
is a well curated and weighed decision that we will not deviate from 
without a widely supported set of founded requirements.

Viele Grüße,

Henk

On 10.09.21 18:15, Smith, Ned wrote:
> Laurence,
> 
> I’m open to working with you / others on how one might represent a 
> ‘triple’ as described in the corim draft in a CWT token.
> 
> Thx,
> 
> Ned
> 
> *From: *Laurence Lundblade <[email-masked]>
> *Date: *Friday, September 3, 2021 at 4:47 PM
> *To: *"Smith, Ned" <[email-masked]>
> *Cc: *Henk Berkholz <[email-masked]>, Brendan Moran 
> <[email-masked]>, Michael Richardson <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "[email-masked]" 
> <[email-masked]>, Dave Thaler <dthaler=[email-masked]>
> *Subject: *Re: [Rats] Call for 111 RATS presentations
> 
>     > *version*
>     I think this point raises a bigger question. “To what do any of the
>     claims pertain?” Today EAT claims are tag-value tuples where the tag
>     “version” is followed by its value. An EAT claim set is a list of
>     tuples that describes something, but that something isn’t named.
> 
>     Possibly, some of the other CWT claims could be used to do that? For
>     example, ‘sub’ could identify the Target Environment but ‘sub’ is
>     pretty open ended in terms of what it could contain. By contrast, a
>     SUIT manifest relies on vendor name, class identifier etc… In the
>     corim schema environments can be identified by a class identifier or
>     an instance identifier (such as a UEID). The association of a set of
>     claims to an environment should be a central aspect of what we’re
>     trying to accomplish IMHO.
> 
> Hi Ned,
> 
> I’m not too worried about this. I think of the CWT/JWT registries as a 
> smorgasbord/mall food court/dim sum of claims for anyone to use for any 
> purpose they wish. The receiver distinguishes the use by context. In one 
> context it might be an authentication token, in another an attestation 
> token. It’s perfectly OK for authentication tokens to use attestation 
> claims. This seems to be the way CWT and JWT work now.
> 
> I’m asking that the claims defined for SUIT have SUIT-specific names so 
> no one looks into the CWT/JWT registries and thinks that the 
> vendor-identifier claim and such are intended for identify a vendor in 
> every/any context that a token is every used, that this is THE universal 
> vendor identifier for ALL hardware, firmware and software.
> 
> We also have EAT profiles to help manage chaos here. Maybe there should 
> be an EAT profile that says how attestation claims apply to SUIT?
> 
> LL
> 
> 
>