Re: [Rats] Composite Evidence

["Eric Voit (evoit)" <[e-mail]>]

Hi Ned,

> From: Smith, Ned, January 23, 2020 2:43 PM
> 
> Eric, Michael,
> The semantics of 'union composite evidence' (below) seems to suggest that
> the local Verifier that produced 'ar' is itself an attestable claim. The Attester
> asserts that the Attestation Results from a local Verifier are trustworthy and
> that they originated from a sub-component of its Target environment.

This is a good example of why Attestation Results should be a subtype of evidence.

> Another way to think about it is the Attesting environment knows that the
> Target environment includes a Verifier and wants to assert that the Verifier
> has trustworthiness properties - possibly by returning its SWID tag value. The
> Remote Verifier can then evaluate the trustworthiness of the SWID tag.

Makes sense.

> Based on that, if the Remote Verifier trusts the Local Verifier then the local
> Attestation Results are not claims asserted by the Attesting environment,
> but claims asserted by the Local Verifier. The only claim that seems to make
> sense from the Attesting environment's perspective is that an 'ar' value from
> its Target was forwarded to a Remote Verifier. Signing the local Verifier's ar
> payload just asserts that the forwarding action has taken place. This is an
> argument for defining an 'Attestation Results forwarded' claim. Maybe this
> isn't that valuable in terms of a trustworthiness claim?

Signing the ar payload (or hashing it, then signing) can prove when the payload was created.  This is what is behind the "TUDA Core concept" within draft-birkholz-rats-tuda.

> If however the Attesting environment wanted to make a stronger
> trustworthiness assertion it would have some other way to collect Evidence
> about the Targeted sub-components (who must already have their own
> Attesting environments). But if the Attesting environment could do this then
> it must be the same environment as the sub-components' Attesting
> environments. In which case, there is no need for a local Verifier - it is just
> complexity for complexity's sake.

If by local verifier, you mean something internal to the Attester, then I agree with you.

> The case of a local Verifier working with a remote Verifier is semantically the
> same as a Remote Verifier working with another Remote Verifier. So, I don't
> see why Evidence and Attestation Results formats need to do anything
> special - like 'union composite evidence'.  It just says that Verifier1 may
> evaluate Evidence about Verifier2 before trusting Attestation Results from
> Verifier2.

I don't consider an Attester deciding what composite evidence to assemble for a "Verifier + Relying Party" as anything special.   What Michael's code says to me that it is important for that Attester to be able to frame all evidence so that the far end can understand the trust assumptions and validations needed to draw some conclusion from the aggregate.

Eric 
 
> -Ned
> 
> On 1/23/20, 8:47 AM, "RATS on behalf of Eric Voit (evoit)" <rats-
> [e-mail] on behalf of [e-mail]> wrote:
> 
>     Hi Michael,
> 
>     > From: Michael Richardson, January 22, 2020 9:40 PM
>     >
>     > Eric Voit (evoit) <[e-mail]> wrote:
>     >     > I promised you a definition for Composite Evidence.  You can see my
>     > proposed
>     >     > definition directly the text below, but I am not willing yet to
>     place
>     >     > it in a
>     >     > Pull Request. I thought an email thread might be helpful first.
>     >
>     > First, I found the diagram confusing, because I think you rotated our
>     > previous diagram 90 degress clockwise.
> 
>     As I was adopting the passport model, I used the Architecture Document
>     Figure 4 in Section 5.1 as a base.
> 
>     > The Verifier A, was in my mind, towards me (in the third dimension) out,
>     > "above" the "Internal Verifier", which we asked to have renamed "Claims
>     > Collector"
>     > (Screw the monochrome SVG debate... lets go VRML)
> 
>     I thought about trying SVG.  But I am not brave enough with the tooling to
>     be an early IETF adopter :-).
> 
>     > Second, I found the extra hash(),@time, stuff distracting, as it went into
>     a
>     > level of detail that just confused me.
> 
>     I need to put together a submission which defines the elements diagram.
>     These details are important for exposing why I see the intersections of
>     evidence types and composite evidence being quite important.  Some of
> these
>     reasons are exposed in my reply to Dave & Ned which dives into three
> types
>     of evidence (i), (ii), & (iii).
> 
>     >     > Anyway my strawman definition for Composite Evidence is:
> Evidence
>     > which
>     >     > includes multiple sub-elements of evidence, more than one of which
>     can
>     > be
>     >     > computationally verified to have been generated by a specific
>     Attester
>     >     > Subcomponent or Verifier.
>     >
>     > I am not sure what "computationally" verified means.
> 
>     Good point, we probably can remove "computationally".
> 
>     > Give an example of something that would not fall into that category.
>     > Maybe you are trying to abstract "has a signature" to things that can be
>     > verified without a asymmetric digital signature. (KerbV Ticket?)
> 
>     It is true I am trying to abstract away from "has a signature".   I didn't
>     want to exclude things like the possibility that Verifier B to go back to
>     Verifier A if a trust relationship hasn't been established between them
> yet.
> 
>     > I think that the key thing that we needed to be able to say is that
>     Composite
>     > Evidence is not:
>     > 1) struct evidence_claims foo[];
>     > -or-
>     > 2) struct attestation_results foo[];
>     >
>     > but rather:
>     >     union composite_evidence {
>     >           struct evidence_claims ec;
>     >           struct attestation_results ar;
>     >     } foo[];
> 
>     I very much agree with your code above. And the definition needs to
> reflect
>     this.   The question which Ned & Dave open up is whether types of
>     evidence_claims need to be exposed in your union composite_evidence.
> This
>     directly hits my question of whether the definition of composite evidence
>     needs to intersect the definition of evidence types (i), (ii), & (iii).
>     The more I think about this in the context of your code above, the more I
> am
>     hoping to keep the two concepts orthogonal.
> 
>     Eric
> 
>     > were I more hip, I'd learn to write this in CDDL.
>     >
>     > --
>     > ]               Never tell me the odds!                 | ipv6 mesh
>     networks [
>     > ]   Michael Richardson, Sandelman Software Works        |    IoT architect
>     [
>     > ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
>     [
>     >
>     >
>     > --
>     > Michael Richardson <[e-mail]>, Sandelman Software
> Works
>     > -= IPv6 IoT consulting =-
>     >
>     >
> 
>