Re: [Rats] Early feedback for draft-tschofenig-rats-aiss-token

[Henk Birkholz <[e-mail]>]

Hi Laurence,

I am a bit perplexed by your interpretation. This is the very first 
sentence in the entire document (the abstract):

> This specification defines a profile of the Entity Attestation Token (EAT) for use in special System-on-Chip (SoC) designs that are generated automatically utilizing a methodology currently developed in a DARPA funded project.

How much more up front could it be? ;-)

Please do not forget that this is a -00, that the text is therefore not 
intended to be complete or even consistent, and that the "how to profile 
an EAT" exactly is an open one up to today. The notion of how AISS 
tokens profile EAT could benefit from its own section, though.

Viele Grüße,

Henk

On 30.04.22 02:39, Laurence Lundblade wrote:
> My read of this doc is that it is a definition of token format like an EAT, that borrows some claims from EAT, but is not an EAT.
> 
> If it was an EAT, or a profile of an EAT, it would say so up front explicitly.
> 
> Since it’s not an EAT, you can’t rely on what’s generally defined in EAT. For example, you’ll have to write your own security considerations, say if/how additional claims are registered, say what the relationship to CWT is and such.
> 
> LL
> 
> 
> 
>> On Apr 29, 2022, at 1:37 AM, Henk Birkholz <[e-mail]> wrote:
>>
>> Hi authors,
>>
>> considering this is a -00 it was a quick an comprehensive read. I am aware that in this state the document is basically a list of Claim definitions and corresponding CDDL.
>>
>> A few questions and comments:
>>
>> 1.) It seems that an AISS is Evidence as it is consumed by a Verifier and reference values and policies are used to appraise it:
>>
>>> https://www.ietf.org/archive/id/draft-tschofenig-rats-aiss-token-00.html#section-7
>>
>> As "Verification" is a bit of an ambiguous term nowadays, I'd recommend to rename Section 7 to "AISS Token Appraisal". Also, I would clearly state that an AISS token is Evidence early on.
>>
>> 2.) The colloquial term "verification service" is used in:
>>
>>> https://www.ietf.org/archive/id/draft-tschofenig-rats-aiss-token-00.html#section-3.3
>>
>> which currently only implies that that is a Verifier conducting AISS token Evidence appraisal, I think. Just defining what a verification service is (see 1.) would help as there are other colloquial terms that mean the same thing, such as attestation service (which also are ambiguous).
>>
>> 3.) Are the reports mentioned in:
>>
>>> https://www.ietf.org/archive/id/draft-tschofenig-rats-aiss-token-00.html#section-3.4
>>
>> self-assertions or Evidence or something else? Are they produced by a RoT or a higher Attesting Environment? Are these states Claims that can be collected from Target Environments that are "the silicon" or are they derived in a different manner?
>>
>> 4.) I am wondering which Attesting Environment is supposed to produce the AISS token Evidence. In your definition of a RoT (Which I'll come to in the next item) it is highlighted that a boot loader can be a RoT, which would imply in that example that the bootloader is the first Attesting Environment in layered attestation.
>>
>> Is the first Attesting Environment always the producer of an AISS token or can later Attesting Environment also do that? I am asking because, if you look at the scenario from a certain angle, it seems as if the Attestation Environment (bootloader) would collect claims from Target Environments that would be the parts of the Silicon. Is that correct?
>>
>> 5.) What's the intended output of an AISS token appraisal? Theft and Overouse seem to be two characteristics as stated in:
>>
>>> https://www.ietf.org/archive/id/draft-tschofenig-rats-aiss-token-00.html#section-3.6
>>
>> Are there others? I assume that determining certain Attestation Results is the whole point of producing AISS tokens in the first place. Defining those categories of outcomes seem to be in-scope?
>>
>> 6.) In March Kathleen advised the RATS WG to include an explicit definition of Root of Trust in the RATS architecture. AFAIK, that is that only remaining open issue with the document. Maybe we can collaborate on that definition as you started one here and I don't think it's an awful definition? :o) That would be cool and hopefully move the RATS architecture, which seems to be stuck for quite a while now and that issue might have been the reason.
>>
>> 7.) I like how most of your Claims used/defined are matching the layout of CoRIM :-) (obviously) and thanks for naming it AISS and not AISST and therefore avoid calling them AISST tokens later :-)
>>
>> Viele Grüße,
>>
>> Henk
>>
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
>