Re: [Rats] Call for 111 RATS presentations

[Laurence Lundblade <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:
>> 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" <[e-mail]> wrote:
>>     Dave Thaler <dthaler=[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>>                Sandelman Software Works Inc, Ottawa and Worldwide
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats