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

[Laurence Lundblade <[e-mail]>]

> On May 1, 2022, at 7:30 AM, Henk Birkholz <[e-mail]> wrote:
> 
> 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? ;-)

Well, it could say it in section 1 or section 2 in a more explicitly normative way. (when I was checking for this explicit statement I failed to check the abstract).

> 
> 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.

EAT has a whole section on profiles <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-12#section-7>. Happy to improve it if needed.

> The notion of how AISS tokens profile EAT could benefit from its own section, though.

It would be cool if AISS had text for each of the issues mentioned in the profiles section of EAT. 

In some cases perhaps the issue won’t be addressed. That’s OK, but it makes it an incomplete profile, perhaps a “sub-profile” that needs a further profile to guarantee interoperability.  For example AISS doesn’t pick signing algorithms. You can’t have interop unless you pick signing algorithm.

It’s probably good that AISS doesn’t pick signing algorithms so it can be broadly applied, but as I said that means it's not a complete interoperability-guaranteeing profile.


> 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.

Agreed


> 
> 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.

Yes, agreed.


> 
> 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.

Yes, agreed (noting that AISS doesn’t say it is a CWT in a normative either, -00 draft and all)

But, if it is not an EAT then all the general text in EAT doesn’t apply and you have to write your own general text. Things like what extra claims are allowed, how to register them, whether it is a CWT or not, security consideration…


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

Yes, agreed. I thought about all that when I wrote my comment.

LL


> 
> 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