Re: [Rats] Composite Evidence

["Smith, Ned" <[e-mail]>]

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. 

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.

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?

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.

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.

-Ned

On 1/23/20, 8:47 AM, "RATS on behalf of Eric Voit (evoit)" <[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 =-
    > 
    >