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

[Henk Birkholz <[e-mail]>]

Hi Laurence,

on a more generic but related topic. I think any CWT can use any EAT 
Claims, in general, as somehow we arrived at the decision to use the CWT 
Claims registry for EAT.

Even, if we would miraculously progress at some point to the next step 
at which we discuss adding columns to the CWT registry that indicate 
which Claims can be used in RATS Evidence and which can be used in RATS 
Attestation Results, it is not prohibited to use any kind of EAT Claims 
in CWTs - already, today. EAT Claims would just serve well-defined 
purposes in CWT and come with EAT-specified requirements how to use them 
in CWT, because that is how the EAT I-D is worded today.

Hence, even if AISS token where not EAT (which they clearly are), they 
don't have to be EAT in order to use EAT Claims as they are in the CWT 
Claims and AISS tokens are at the very minimum always CWTs.

And yes... this is where we arrived at.

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
>