Subject: [Rats] Composite Evidence

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 23 Jan 2020 00:04:29 +0000

Henk,         Dave,

Michael,    Ned,

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.

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 built this definition considering the passport model, which looks like it 
will often needs to use composite evidence.  As an example of why I believe 
this, see the use case below.

    .--------------.

    |  Verifier A  |

    '--------------'

        ^     [2]

        |     Verifier A signed Attestation Results @time(x) (

    evidence(  |  determination, hash(TpmQuote@time(x)))

    TpmQuote   |

    @time(x))  |

       [1]     V

     .-------------.                           .---------------.

     |  Attester   |<------nonce @time(y)---[3]|  Verifier B   |

     |    .-----.  |                           |       /       |

     |    | Tpm |  |[4]-composite evidence ( ->| Relying Party |

     |    '-----'  |      TpmQuote@time(y),    '---------------'

     '-------------'      TpmQuote@time(x),

                          Verifier A signed Attestation Results @time(x) )

In the example above, evidence at time x is generated and signed within a TPM. 
This would *not* be composite evidence.   This evidence would be evaluated by 
Verifier A, signed, and returned as Attestation Results to the Attester.   A 
subsequent request from a Relying Party at time y could pull three 
independently signed elements of evidence from the Attester.  These three 
would comprise the composite evidence which when taken together would allow 
Verifier B / Relying Party to evaluate the current trustworthiness of the 
Attester.

Does this definition meet your needs?

Thanks,

Eric

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 23 Jan 2020 01:54:29 +0000

Eric,
I think there are two types of “composite” things that could be considered (i) decompositions of hardware and software such as a motherboard and the sub-components that could be plugged into it and (ii) time series snapshots of the same component.

You seem to be asserting (ii) where a time series snapshot of the same thing could be considered “composite evidence”.

I think both cases are valid, but maybe it makes sense to use different terms for each as they seem to have distinct properties. (e.g. evidence having multiple entries of a component with the same name  under (i) implies multiple instances of the same type of device – such as two NIC cards. Whereas under (ii) multiple entries implies there is one instance of the NIC sampled over a time interval.

-Ned

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz <[email-masked]>, Michael Richardson <[email-masked]>, Dave Thaler <[email-masked]>, "Smith, Ned" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Composite Evidence

Henk,         Dave,
Michael,    Ned,

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.

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 built this definition considering the passport model, which looks like it will often needs to use composite evidence.  As an example of why I believe this, see the use case below.

    .--------------.
    |  Verifier A  |
    '--------------'
        ^     [2]

In the example above, evidence at time x is generated and signed within a TPM.  This would *not* be composite evidence.   This evidence would be evaluated by Verifier A, signed, and returned as Attestation Results to the Attester.   A subsequent request from a Relying Party at time y could pull three independently signed elements of evidence from the Attester.  These three would comprise the composite evidence which when taken together would allow Verifier B / Relying Party to evaluate the current trustworthiness of the Attester.

Thanks,
Eric

---

From: Dave Thaler <[email-masked]>
Date: Thu, 23 Jan 2020 02:04:41 +0000

Agree with Ned that we should keep composite devices separate from time series snapshots of the same component in terms of concepts.

From: Smith, Ned <[email-masked]>
Sent: Wednesday, January 22, 2020 5:54 PM
To: Eric Voit (evoit) <[email-masked]>; Birkholz, Henk <[email-masked]>; Michael Richardson <[email-masked]>; Dave Thaler <[email-masked]>
Cc: [email-masked]
Subject: Re: Composite Evidence

Eric,

-Ned

From: "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>, Dave Thaler <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Composite Evidence

Henk,         Dave,
Michael,    Ned,

    .--------------.
    |  Verifier A  |
    '--------------'
        ^     [2]

Thanks,
Eric

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jan 2020 21:40:29 -0500

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

Second, I found the extra hash(),@time, stuff distracting, as it went into a
level of detail that just confused me.

    > Subcomponent or Verifier.

I am not sure what "computationally" verified means.
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?)

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[];

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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Thu, 23 Jan 2020 07:53:29 +0000

Hi,
I agree with Ned’s categorization of two, and we need to have different terms for them.

I am also wondering the reason why you want to receive a time series snapshots of the same component? If you want to identify the change of a component’s trustworthiness during a period, maybe a better way is through the on-change evidence notification.

B.R.
Frank

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

发件人: RATS [mailto:[email-masked]] 代表 Smith, Ned
发送时间: 2020年1月23日 9:54
收件人: Eric Voit (evoit) <[email-masked]>; Birkholz, Henk <[email-masked]>; Michael Richardson <[email-masked]>; Dave Thaler <[email-masked]>
抄送: [email-masked]
主题: Re: [Rats] Composite Evidence

Eric,

-Ned

Henk,         Dave,
Michael,    Ned,

    .--------------.
    |  Verifier A  |
    '--------------'
        ^     [2]

Thanks,
Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 23 Jan 2020 15:39:57 +0000

Hi Ned,

Hi Dave,

I agree with Ned's framing of (i) and (ii).  These two are embedded in my passport example below.    We also have (iii): evidence which is relayed from outside the Attester.  I think (iii) needs to be broken out as an evidence type because signed information from the Verifier should be trusted differently from other evidence the Attester.

That makes:

 (i) component evidence

(ii) time-series evidence

(iii) relayed evidence

Beyond (i), (ii), & (iii), do we need term combinations of (i), (ii), & (iii) with the word "composite"?  Hopefully we wouldn't need to define six terms for each combination of these three variants.  Otherwise my example might be called "component, time-series, relayed composite evidence".  And that is a mouthful.

Eric

From: Dave Thaler, January 22, 2020 9:05 PM

From: Smith, Ned < <mailto:[email-masked]> [email-masked]> 
Sent: Wednesday, January 22, 2020 5:54 PM
To: Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]>; Birkholz, Henk < <mailto:[email-masked]> [email-masked]>; Michael Richardson < <mailto:[email-masked]> [email-masked]>; Dave Thaler < <mailto:[email-masked]> [email-masked]>
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: Composite Evidence

Eric,

-Ned

From: "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> >
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz <[email-masked] <mailto:[email-masked]> >, Michael Richardson <[email-masked] <mailto:[email-masked]> >, Dave Thaler <[email-masked] <mailto:[email-masked]> >, "Smith, Ned" <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Composite Evidence

Henk,         Dave,

Michael,    Ned,

    .--------------.             

    |  Verifier A  |

    '--------------'     

        ^     [2]           

    TpmQuote   |                  

    @time(x))  |                        

       [1]     V                        

     |    .-----.  |                           |       /       |

 

Thanks,

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 23 Jan 2020 16:19:33 +0000

Hi Frank,

From: Xialiang, January 23, 2020 2:53 AM

Hi,

<eric> I agree that we need different terms for different types of evidence.  And added a third: relayed evidence.

I suspect it would be better to separate those from the "composite" concept.  It will be interesting to get others' thoughts on this.

I am also wondering the reason why you want to receive a time series snapshots of the same component? 

<eric> A Verifier can make an "ok-validated" evaluation on a particular TPM Quote, and send it back to the Attester.  Subsequently, a Relying Party can get a Quote from the same TPM to establish what are current, fresh measurements.   If both Quotes have the same PCR values, then the current state is in an "ok-validated" state.  This minimizes Verifier transactions, and gives quick/fresh response to the Relying Party.

If more documentation on this is interesting, I could put together something for the WG.

If you want to identify the change of a component’s trustworthiness during a period, maybe a better way is through the on-change evidence notification.

<eric> I initially thought on-change would be sufficient.  However there is quite a bit of volatile evidence which needs to be transmitted only under a certain condition.    For example, *only* when a specific PCR changes, send the full signed TPM quote as well as the log entries for that PCR.   It would be unaffordable/unsupportable to send all PCR quotes on-change as things like nonces/clock counters are continuously updating.

In a perfect world, this conditional push requirement would be a good match to your draft-bryskin-netconf-automation-yang.  However since this draft isn't close to being picked up by the NETCONF WG yet, we can't depend on that functionality.

If we are building from today's available RFCs, I think defining a new "attestation" event stream based on RFC-8639 Subscription to YANG Notifications will be a more stable starting point than starting with RFC-8641 for on-change YANG datastore subscription. 

Eric

B.R.

Frank

发件人: RATS [ <mailto:[email-masked]> mailto:[email-masked]] 代表 Smith, Ned
发送时间: 2020年1月23日 9:54
收件人: Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]>; Birkholz, Henk < <mailto:[email-masked]> [email-masked]>; Michael Richardson < <mailto:[email-masked]> [email-masked]>; Dave Thaler < <mailto:[email-masked]> [email-masked]>
抄送:  <mailto:[email-masked]> [email-masked]
主题: Re: [Rats] Composite Evidence

Eric,

-Ned

From: "Eric Voit (evoit)" < <mailto:[email-masked]> [email-masked]>
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz < <mailto:[email-masked]> [email-masked]>, Michael Richardson < <mailto:[email-masked]> [email-masked]>, Dave Thaler < <mailto:[email-masked]> [email-masked]>, "Smith, Ned" < <mailto:[email-masked]> [email-masked]>
Cc: " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]> [email-masked]>
Subject: Composite Evidence

Henk,         Dave,

Michael,    Ned,

    .--------------.             

    |  Verifier A  |

    '--------------'     

        ^     [2]           

    TpmQuote   |                  

    @time(x))  |                        

       [1]     V                        

     |    .-----.  |                           |       /       |

 

Thanks,

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 23 Jan 2020 16:47:08 +0000

Hi Michael,

> From: Michael Richardson, January 22, 2020 9:40 PM
> 
>     > definition directly the text below, but I am not willing yet to
place
>     > it in a

As I was adopting the passport model, I used the Architecture Document
Figure 4 in Section 5.1 as a base.

> (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 :-).
 
> 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).

>     > includes multiple sub-elements of evidence, more than one of which
can
> be

Good point, we probably can remove "computationally".
    
> 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.
 
>           struct attestation_results ar;

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

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 23 Jan 2020 19:43:10 +0000

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)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Michael,
    
    place

    

    
    can

    

    
    Eric

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jan 2020 15:26:46 -0500

> Figure 4 in Section 5.1 as a base.

Yes, I knew that, but I think we need to meld it into the diagram we have,
so we need to find a way to allow people's visual cortex to map things visually.

    > of evidence (i), (ii), & (iii).

I'm happy if you have "ev(i)","ev(ii)", etc. and explain that in the text.

    > Verifier A if a trust relationship hasn't been established between them yet.

How about "signature (or equivalent)"

    > evidence_claims need to be exposed in your union composite_evidence.

Of course "struct evidence_claims" is a structure, I expect it to often be an EAT.
So I'm not sure I understand the debate.

    > hoping to keep the two concepts orthogonal.

Is the question about how this union is distinguished?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jan 2020 15:35:57 -0500

Smith, Ned <[email-masked]> wrote:
    > 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.

Yes.
As explained by Eric in his diagram, the "ar" results might not be produced
locally, they may be the result of a trip to a different (remote) verifier.
Or as you suggest, they may be produced within some TEE, for which there are
evidence claims about why it's trust worthy.

I think that this all maps to what I understand about TEEP actually.

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

Sure, that is a specific way.
I think that the Chassis+Line Card situation also can work as an example.

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

[%] I think you are saying that rather than documenting that we forward a union
of evidence and attestation results, that we document that will create a kind
of evidence, which includes attestation results?

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

I think that I agree.

It could be that there are competitive or regulatory reasons why the Lead
Attester does not wish to reveal the types of the line cards attached.
Consider an automobile (or passenger rail car, or human-rated Rocket) that
needs to attest that it has four good tires (which passed their 20,000km
inspection), but which does not wish to reveal which manufacturer provided
those tires.  Passing on evidence directly would be a problem.

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

Thus my query up at [%].

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 23 Jan 2020 21:08:34 +0000

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.

> 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-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     Hi Michael,
> 
>     >     > Anyway my strawman definition for Composite Evidence is:
> Evidence
>     > which
> This

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 23 Jan 2020 23:11:26 +0000

See [%] marker inline below.

On 1/23/20, 12:36 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    Yes.

    

    [%] I think you are saying that rather than documenting that we forward a union
    of evidence and attestation results, that we document that will create a kind
    of evidence, which includes attestation results?
Maybe. It really is a case of multiplexing several conversations over the same conveyance mechanism, but otherwise conversations could be de-multiplexed (without creating unnecessary cross-dependencies). For example in both Passport and BK-Check topology models, a message is simply relayed. The endpoints are still the way they're defined in the Roles Arch diagram. 

Email may not be the best way to try to illustrate but here goes. I assert that Eric's diagram can be recast into two graphs where graph (a) is the sub-component attester (A1), the local verifier (V1) and a relying party (RP). The second graph (b) consists of the top level Attester (A2), a remote verifier (V2) and the same relying party (RP). 
Looks something like:
(a) A1 --- E1 ---> V1 --- AR1 ---> RP;
(b) A2 --- E2 ---> V2 --- AR2 ---> RP.

However, since A1 and V1 don't have a conveyance path to RP, they use the one established by (b). The Combination topological model shows a case where the Attester is relying/forwarding attestation results. Normally, an attester doesn't consume attestation results. This same thing is happening in Eric's example because AR1 is piggy backed with E2 on its way to V2 and AR1 is also piggy backed with AR2 on its way to RP. 

I don't think we want to position that because AR1 is piggy backed with E2 that this creates a new type of Evidence (E3). It is still just (AR1, E2). 

If it makes sense to define "routing claims" that assert that A2 intended to piggy back AR1 with E2 then that should imply that if E2 = (c1) and c2 = routing claim then E2' = (c1, c2). The conveyance still carries (AR1, E2') , but possibly the c2 claim names AR1 as the piggy i.e. c2.name = "AR1".

V2 can verify the c2 claim and create an AR2' claim c3.name="AR1" and send (AR1, AR2'); where AR2 = (c4,...,cn) and AR2' = (c3, c4,...,cn). RP can similarly verify c3. Namely, the c3.name="AR1" claim is inspected to have payload AR1 as piggy. 

The "routing" claims are ancillary to the basic roles and messages that are the core basis for trust among the endpoint entities -  IMO. The core flows are separable from routing. Routing shouldn't lead us down a path of having new types of evidence (E3). 

    I think that I agree.
    
[nms] Privacy is an important consideration. If Evidence is privacy sensitive, then it can be encrypted. The routing claims don't require transparent Evidence to name them. Could compute a hash of E or AR or if endpoints have security associations, then E and AR can be encrypted and a digest of ciphertext becomes its name for the purpose of routing claims (see my response above).

    Thus my query up at [%].

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 24 Jan 2020 00:12:59 +0000

> -----Original Message-----
> From: RATS <[email-masked]> On Behalf Of Smith, Ned
> Sent: Thursday, January 23, 2020 6:11 PM
> To: Michael Richardson <[email-masked]>; [email-masked]
> Subject: Re: [Rats] Composite Evidence
> 
> On 1/23/20, 12:36 PM, "RATS on behalf of Michael Richardson" <rats-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> 
> Maybe. It really is a case of multiplexing several conversations over the same
> conveyance mechanism, but otherwise conversations could be de-
> multiplexed (without creating unnecessary cross-dependencies). For example
> in both Passport and BK-Check topology models, a message is simply relayed.
> The endpoints are still the way they're defined in the Roles Arch diagram.
> 
> Email may not be the best way to try to illustrate but here goes. I assert that
> Eric's diagram can be recast into two graphs where graph (a) is the sub-
> component attester (A1), the local verifier (V1) and a relying party (RP). The
> second graph (b) consists of the top level Attester (A2), a remote verifier (V2)
> and the same relying party (RP).
> Looks something like:
> However, since A1 and V1 don't have a conveyance path to RP, they use the
> one established by (b). The Combination topological model shows a case
> where the Attester is relying/forwarding attestation results. Normally, an
> attester doesn't consume attestation results. This same thing is happening in
> Eric's example because AR1 is piggy backed with E2 on its way to V2 and AR1
> is also piggy backed with AR2 on its way to RP.
> 
> I don't think we want to position that because AR1 is piggy backed with E2
> that this creates a new type of Evidence (E3). It is still just (AR1, E2).
> 
> If it makes sense to define "routing claims" that assert that A2 intended to
> piggy back AR1 with E2 then that should imply that if E2 = (c1) and c2 =
> routing claim then E2' = (c1, c2). The conveyance still carries (AR1, E2') , but
> possibly the c2 claim names AR1 as the piggy i.e. c2.name = "AR1".
> 
> V2 can verify the c2 claim and create an AR2' claim c3.name="AR1" and send
> (AR1, AR2'); where AR2 = (c4,...,cn) and AR2' = (c3, c4,...,cn). RP can similarly
> verify c3. Namely, the c3.name="AR1" claim is inspected to have payload AR1
> as piggy.
> 
> The "routing" claims are ancillary to the basic roles and messages that are
> the core basis for trust among the endpoint entities -  IMO. The core flows
> are separable from routing. Routing shouldn't lead us down a path of having
> new types of evidence (E3).

I agree that routing itself doesn't imply a new type of evidence.   What we do have at Attester is some trigger for when to collect the specific set of claims which are needed by the Relying Party to accomplish a particular use case. 

Eric

> [nms] Privacy is an important consideration. If Evidence is privacy sensitive,
> then it can be encrypted. The routing claims don't require transparent
> Evidence to name them. Could compute a hash of E or AR or if endpoints
> have security associations, then E and AR can be encrypted and a digest of
> ciphertext becomes its name for the purpose of routing claims (see my
> response above).
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 23 Jan 2020 16:41:43 -0800

Not up to speed on this thread but two comments:

- It seems the notion of target environment is important here.
- I am interested in implications for EAT submods. Seems you should be able to express this stuff in EAT.

LL

> On Jan 23, 2020, at 4:12 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> 
>

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 24 Jan 2020 01:08:50 +0000

I think the gist is we're looking at cases where submods could be entities that include RATS roles as well as Target and Attesting environments. 
The thread is trying to pull this apart to see if there are ways to simplify by reapplying the basic concepts or if there are new concepts that need to be grappled with.

On 1/23/20, 4:41 PM, "Laurence Lundblade" <[email-masked]> wrote:

    
    LL

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 13:19:36 -0500

Smith, Ned <[email-masked]> wrote:
    mcr> [%] I think you are saying that rather than documenting that we
    mcr> forward a union of evidence and attestation results, that we
    mcr> document that will create a kind of evidence, which includes attestation results?

    Ned> Maybe. It really is a case of multiplexing several conversations
    Ned> over the same conveyance mechanism, but otherwise conversations
    Ned> could be de-multiplexed (without creating unnecessary
    Ned> cross-dependencies). For example in both Passport and BK-Check
    Ned> topology models, a message is simply relayed. The endpoints are
    Ned> still the way they're defined in the Roles Arch diagram.

yes, I agree, we could send a list of evidence and a list of attestion
results from components.  I don't really know what the list of potential
*verification* protocols is.
(I know that I want to include it in RFC8366/BRSKI voucher-requests, once
that is an RFC)

I don't think this communication can ever be via certificate, while the final
attestation results could be placed inside a certificate.

    Ned> Email may not be the best way to try to illustrate but here goes. I
    Ned> assert that Eric's diagram can be recast into two graphs where graph
    Ned> (a) is the sub-component attester (A1), the local verifier (V1) and
    Ned> a relying party (RP). The second graph (b) consists of the top level
    Ned> Attester (A2), a remote verifier (V2) and the same relying party
    Ned> (RP).

    Ned> Looks something like:
    Ned> (a) A1 --- E1 ---> V1 --- AR1 ---> RP;
    Ned> (b) A2 --- E2 ---> V2 --- AR2 ---> RP.

I agree this is a reasonable diagram.

    Ned> If it makes sense to define "routing claims" that assert that A2
    Ned> intended to piggy back AR1 with E2 then that should imply that if E2
    Ned> = (c1) and c2 = routing claim then E2' = (c1, c2). The conveyance
    Ned> still carries (AR1, E2') , but possibly the c2 claim names AR1 as
    Ned> the piggy i.e. c2.name = "AR1".

Are you saying that the fact that (b) is relayed via E1 is important, and
should be communicated by having E1 sign the transaction as well?

    Mcr> It could be that there are competitive or regulatory reasons why the Lead
    Mcr> Attester does not wish to reveal the types of the line cards attached.
    Mcr> Consider an automobile (or passenger rail car, or human-rated Rocket) that
    Mcr> needs to attest that it has four good tires (which passed their 20,000km
    Mcr> inspection), but which does not wish to reveal which manufacturer provided
    Mcr> those tires.  Passing on evidence directly would be a problem.

    Ned> [nms] Privacy is an important consideration. If Evidence is privacy
    Ned> sensitive, then it can be encrypted. The routing claims don't
    Ned> require transparent Evidence to name them. Could compute a hash of E
    Ned> or AR or if endpoints have security associations, then E and AR can
    Ned> be encrypted and a digest of ciphertext becomes its name for the
    Ned> purpose of routing claims (see my response above).

Agreed.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 13:21:27 -0500

>> new types of evidence (E3).

    eric> I agree that routing itself doesn't imply a new type of evidence.
    eric> What we do have at Attester is some trigger for when to collect the
    eric> specific set of claims which are needed by the Relying Party to
    eric> accomplish a particular use case.

I think that it's important.
In my automobile/tire situation, it is important that the attestation result
that my car sends are for tires attached to *my* car.  Even if they were on
your car this morning when they were evaluated.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 13:22:50 -0500

> able to express this stuff in EAT.

yes, I believe that what we are doing is providing *architectural*
justification for features that are probably already in EAT.

I think that this will help with the eventual security evaluation of the
specification(s), because we will know from this use case scenario what the
threat model is.

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 24 Jan 2020 19:12:55 +0000

On 1/24/20, 10:19 AM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    
    mcr> yes, I agree, we could send a list of evidence and a list of attestion
    mcr> results from components.  I don't really know what the list of potential
    mcr> *verification* protocols is.

Nms> I don't know what a verification protocol is. I would describe the interaction between a Verifier and Relying Party as Attestation Results exchange over a conveyance protocol. This implies there is a protocol binding specification needed for each protocol that is used for conveyance.

   mcr> (I know that I want to include it in RFC8366/BRSKI voucher-requests, once
   mcr> that is an RFC)
    
   mcr> I don't think this communication can ever be via certificate, while the final
   mcr> attestation results could be placed inside a certificate.

nms> Both a certificate and token are examples of signed documents that could include both Evidence or Attestation Results

    
  mcr>  I agree this is a reasonable diagram.

    mcr>  Are you saying that the fact that (b) is relayed via E1 is important, and
    mcr>  should be communicated by having E1 sign the transaction as well?
nms> I don't know. If the RATS WG believes it is important then the way to accommodate it is shown above.
nms> If E1 signs something, it should be understood what the signature means explicitly. If c2 is added to the Evidence normally signed by E1 then it is explicit that the signature (now) means c1 and c2. 
nms> The WG might ask whether following Passport, Background Check or some other variant is important. Maybe for privacy protection reasons?

    
    Agreed.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 15:15:31 -0500

Nms> I don't know what a verification protocol is. I would describe the
    Nms> interaction between a Verifier and Relying Party as Attestation
    Nms> Results exchange over a conveyance protocol. This implies there is a
    Nms> protocol binding specification needed for each protocol that is used
    Nms> for conveyance.

I don't know what to call the Attester->Verifier connection.
Yes, it's a conveyance protocol.

    nms> Both a certificate and token are examples of signed documents that
    nms> could include both Evidence or Attestation Results

A certificate (manufacturer signed IDevID...) could convey fresh evidence?
I find that hard to believe.

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 24 Jan 2020 21:04:35 +0000

On 1/24/20, 12:15 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    

 mcr>   I don't know what to call the Attester->Verifier connection.
 mcr>   Yes, it's a conveyance protocol.
nms> Maybe the architecture should give them names?

    
   mcr>  A certificate (manufacturer signed IDevID...) could convey fresh evidence?
   mcr>  I find that hard to believe.
   nms>  Yes, it is possible for a trusted environment to issue a certificate for a key that is dynamically generated and used to attest. Sometimes these signed things aren't called certificates. For example, a TPM "quote" operation can "quote a key" which results in a signed structure that contains a public key. SGX can do something similar too. A JWT/CWT token can include a public key value which someone could say is a 'certificate' because it associates a key with another key (namely the issuer). Additionally, a DICE RoT can sign an X.509.v3 certificate called the "Alias Identity". 
nms> A use case that supports this practice is when a HW or SW module is added to a device after it ships. The module could become a new Target environment that the Attesting environment hashes to produce new Evidence. If the new module in turn supports adding another sub-module, then it may become the Attesting environment to the sub-module. The attestation key it uses may be dynamically generated. One of the claims is that the new key is trustworthy because it belongs to a Target environment that was attested by a trusted Attesting environment. I believe EAT submods claim supports this usage.
    --
    Michael Richardson <[email-masked]>, Sandelman Software Works
     -= IPv6 IoT consulting =-