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

[Henk Birkholz <[e-mail]>]

Hi Ned,

that is a perfectly valid point of view. And that's why I think that has 
to be spelled out: what's it gonna be? It can't be all of the things. 
Let's say in the end, a media-type/content-type comes along and intends 
to tell you what it is is in order to help the corresponding RATS role 
to identify the content to be consumed. You can't simply say "RATS". You 
must point out a conceptual message type.

Hence, I can follow Ned's line of thought that an AISS token also could 
look like an Endorsement. So which RATS conceptual message is it 
intended to be?

Viele Grüße,

Henk

On 29.04.22 19:41, Smith, Ned wrote:
> I read parts of it differently as the focus of the claims is on the RoT which in one instance (section 3.3) described as a RoT that can be 'immutable' and goes on to say that RoT details are from a manufacturer. I interpret this to mean the aiss claims are Endorsements provided by Endorsers.
> 
> -Ned
> 
> On 4/29/22, 12:38 AM, "RATS on behalf of Henk Birkholz" <[e-mail] on behalf of [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
>