Re: [Rats] looking for better terms -- request for bike shed discussion

Please see my other post that crossed in mail. I don't think the convention holds for DICE layering that DICE layers are "Attesters". 

On 1/8/20, 4:50 PM, "RATS on behalf of Henk Birkholz" <rats-bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de> wrote:

    Oh! I just realized...

    you are referring to the initial topic of layered attestation where 
    there is a sequence of attested environments becoming the attesting 
    environment and so forth. If so, I misunderstood your initial statement, 
    I think.

    The "separate attesters" you were referring to are the staged 
    environments that become attesting environments during boot in a single 
    entity, yes?

    If so, we are in wild agreement and it just took me while to get it...

    Viele Grüße,

    Henk

    On 09.01.20 01:18, Dave Thaler wrote:
    > If you're asking about my example, there's only one device, this is standard DICE cert chain functionality on a single ARM processor.
    > 
    > Dave
    > 
    > -----Original Message-----
    > From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
    > Sent: Wednesday, January 8, 2020 4:10 PM
    > To: Dave Thaler <dthaler@microsoft.com>; Michael Richardson <mcr@sandelman.ca>; Laurence Lundblade <lgl@island-resort.com>
    > Cc: Smith, Ned <ned.smith@intel.com>; Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de>; rats@ietf.org
    > Subject: Re: [Rats] looking for better terms -- request for bike shed discussion
    > 
    > Hm...
    > 
    > on one hand, this seems to imply that the "attester role" in this chain does not reside on the same "entity" (in other words, multiple entities are composing the chain with their individual attester roles). If that is what you were trying to state, I am uncertain what problem this would address.
    > 
    > On the other hand, maybe there is a use case for this? Alas, I am under the impression that this route could imply a tremendous increase of architectural complexity.
    > 
    > On 09.01.20 01:02, Dave Thaler wrote:
    >> I don't think I have any problems with Laurence's terminology but just to test it...
    >>
    >> We have devices running Trusted Apps on OP-TEE over trusted firmware on an ARM TrustZone processor.
    >> The full evidence is a DICE cert chain that has a set of claims for each cert in the chain, where each layer is an attesting environment for the subsequent layer (attested environment):
    >> 	Hardware -> Trusted Firmware -> OP-TEE -> TA Thus there are four
    >> claim sets in a chain.
    >>
    >> Using Laurence's terminology, I believe the suggestion is that attesting environment is an "attester" and an attested environment is a "target".   Thus the example above has 3 attesters (Hardware, TFW, and OP-TEE), and 4 targets (HW where target == attester, TFW, OP-TEE, and TA).
    >>
    >> Are you ok with saying that every claimset in a chain is from a separate "attester"?   I believe this is different from our current definition of Attester (which is the thing that sends the whole chain to a verifier), so want to confirm.
    >>
    >> Dave
    >>
    >> -----Original Message-----
    >> From: RATS <rats-bounces@ietf.org> On Behalf Of Michael Richardson
    >> Sent: Wednesday, January 8, 2020 11:35 AM
    >> To: Laurence Lundblade <lgl@island-resort.com>
    >> Cc: =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?=
    >> <J.Schoenwaelder@jacobs-university.de>; Smith, Ned
    >> <ned.smith@intel.com>; rats@ietf.org
    >> Subject: Re: [Rats] looking for better terms -- request for bike shed
    >> discussion
    >>
    >>
    >> Thank you for this very nice text. I rather like it.
    >>
    >> Laurence Lundblade <lgl@island-resort.com> wrote:
    >>       > Here’s some rough text:
    >>
    >>       > Conceptually, the “attester” produces a set of “claims” about a “target”.
    >>       > The claims are known as “attestation evidence” and are sent to the
    >>       > “verifier”. The verifier additionally takes in “endorsements”, processes
    >>       > the attestation evidence and produces the “attestation result” for the
    >>       > final consumer, the “relying party”.
    >>
    >>
    >>       > This description left conceptual for easy understanding and discussion.
    >>       > Actual implementations are usually more complex in at least one or more
    >>       > of these ways:
    >>
    >>
    >>
    >>       > * The attester is also the target
    >>
    >>
    >>       > * One attester produces claims about several targets
    >> (submodules)
    >>
    >>
    >>       > * The verifier and the relying party are the same
    >>       > * Claims may be simple or complex, many or few
    >>       > * Some claims are measurements and some are not
    >>       > * Some claims in in the attestation evidence may be simply passed
    >>       > through the verifier, others may be heavily processed.
    >>       > * Daisy chaining -- the evidence from one attester goes through a
    >>       > verifier producing results which are taken as claims that are input
    >>       > to another attester that outputs a different set of evidence that
    >>       > goes on through a different verifier.
    >>       > * Daisy chaining may happen on the device producing the attestations
    >>       > or in the infrastructure evaluating the device or both.
    >>
    >>
    >>       > (Next I’d write a plethoras of simple examples for attester, target,
    >>       > claims… assuming only the simplest implementation that maps to the
    >>       > conceptual description )
    >>
    >>
    >>
    >>
    >>
    >>
    >>       > I am starting to prefer the basic conceptual / abstract description over one
    >>       > that is inherently mappable to every possible.
    >>
    >>       > LL
    >>
    >> _______________________________________________
    >> RATS mailing list
    >> RATS@ietf.org
    >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
    >> ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40micr
    >> osoft.com%7C1afca74f029a4dadf1c408d794985931%7C72f988bf86f141af91ab2d7
    >> cd011db47%7C1%7C0%7C637141254420421263&amp;sdata=WexYiuPGPh%2FSoz2tagX
    >> wf3Pe3CScQeOgM%2Bd5zPQdeyY%3D&amp;reserved=0
    >> _______________________________________________
    >> RATS mailing list
    >> RATS@ietf.org
    >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
    >> ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40micr
    >> osoft.com%7C1afca74f029a4dadf1c408d794985931%7C72f988bf86f141af91ab2d7
    >> cd011db47%7C1%7C0%7C637141254420421263&amp;sdata=WexYiuPGPh%2FSoz2tagX
    >> wf3Pe3CScQeOgM%2Bd5zPQdeyY%3D&amp;reserved=0
    >>
    > _______________________________________________
    > RATS mailing list
    > RATS@ietf.org
    > https://www.ietf.org/mailman/listinfo/rats
    > 

    _______________________________________________
    RATS mailing list
    RATS@ietf.org
    https://www.ietf.org/mailman/listinfo/rats