Re: [Rats] Composite Evidence

"Smith, Ned" <> Thu, 23 January 2020 23:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F9191200C7 for <>; Thu, 23 Jan 2020 15:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JxrD5FczIIgP for <>; Thu, 23 Jan 2020 15:25:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BFAD120041 for <>; Thu, 23 Jan 2020 15:25:34 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2020 15:25:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.70,355,1574150400"; d="scan'208,217";a="428132497"
Received: from ([]) by with ESMTP; 23 Jan 2020 15:25:34 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 23 Jan 2020 15:25:33 -0800
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Thu, 23 Jan 2020 15:25:33 -0800
From: "Smith, Ned" <>
To: "Eric Voit (evoit)" <>, Dave Thaler <>, "Birkholz, Henk" <>, Michael Richardson <>
CC: "" <>
Thread-Topic: [Rats] Composite Evidence
Thread-Index: AQHV0h/jsEcLGXWTRbyFhaWoEjRAw6f4ozQQgABBXAA=
Date: Thu, 23 Jan 2020 23:25:32 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-23T02:04:41.5804837Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f78ab453-bbe8-4b62-9d54-dd2752ed39ae; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7527C725950B4C7F999A28CDF6775B00intelcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Rats] Composite Evidence
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2020 23:25:38 -0000

Eric said “However, it could be that one of these is what you mean by (iii)?
<eric> This is one type of thing covered in (iii).  The generalization of what I intended from (iii) was evidence provided by an Attester which is provably not generated within the Attester.  For example, a recent Time quote from a Time Stamp Authority like in draft-birkholz-rats-tuda could also be included in what is sent to a Verifier/Relying Party.”
[nms] The Time Stamp Authority is an Attester (A1) that claims the time is some value E1. When THE Attester (A2), receives E1. What does he do with it? Does he forward it (see my reply to Michael’s thread) or does he use it to create Evidence E2? I think you’re suggesting it’s the latter. In this case, the evidence consists of a claim that expects the time. E.g. Claim c1 in E2 looks like: = “name of something”, c1.timestamp = E1.time, = …

The question to ask is whether or not provenance of E1.time needs to be communicated to Verifier. Maybe A2 just needs to prove that it uses a secure time source and that’s it? If you’re saying Verifier needs to know which time source it used, then it becomes a question of defining the claim c1 in such a way that it includes E1 (or points to it somehow) – BTW I’m assuming E1 is signed by A1 so it has provenance.

This seems like an interesting possibility / use case.


From: "Eric Voit (evoit)" <>
Date: Thursday, January 23, 2020 at 12:57 PM
To: "Smith, Ned" <>om>, Dave Thaler <>om>, Henk Berkholz <>de>, Michael Richardson <>
Cc: "" <>
Subject: RE: [Rats] Composite Evidence

Hi Ned,

From: Smith, Ned, January 23, 2020 2:04 PM
Can you say more about relayed evidence in terms of how it was obtained and how it is protected as it is ‘relayed’?

The Passport and Background Check models incorporate ‘relaying’ of Evidence, but don’t try to describe the Evidence as ‘relayed evidence’.

<eric> While it isn't 100% clear in the current terminology, I see "Attestation Results"  as a special type of evidence. This is evidence where any trustworthiness claims made of the Attester can be accepted without requiring further evaluation.

The Relying Party needs a way to validate the freshness of whatever comes from the Verifier.   This can be done a number of ways.   For example in my diagram below, the TPM2's timeticks counters can be included in [1] and [4].  As the TPM has predictable incrementing of these counters.  The deltas between the timeticks counters can be trusted, even though both claims were generated from within an Attester Component.

A related question then is whether the Attestation Results in [2] actually match to the TpmQuote from [1].  The Relying party can establish this based on a hash within [2] proving its relation to [1].

In the context of Attesting Environment Collecting Evidence from a Target environment the way it is collected seems to determine whether it would be classified as (i), (ii) or (iii). (Note: there is the category of simple evidence that is just a set of atomic claims – no need to drill deeper into the foo[] data structure – and not represented by (i), (ii) or (iii)
<eric> I agree with other type of evidence/claims relating to the attester in general, and these not needing to be provably associated with any specific sub-component.    This is one of the reasons I am hoping we turn this discussion towards a decomposed set of evidence types, rather than having individual terms for different combinations of composite evidence.

If (i) means the target environment consists of a decomposition of things, then there is expected to be a nesting of Evidence that parallels the decomposition.
<eric> Nesting is certainly possible. So I am fine with this statement.  To match this to my example below, step [4] assembles a composition of this evidence, rather than doing any nesting.  Although perhaps nesting *could* be claimed the Attestation Results in [2] contains a hash of [1].  Is this nesting?  Is this Layering?  I don't know.

If (i) also means the target environment consists of a decomposition of things and where there is a ‘local verifier’ that evaluates Evidence and produces an Attestation Result in the place where the decomposition would otherwise expect nested Evidence then this seems to overload (i) somewhat.
<eric> This is the exact reason why I got caught up attempting a definition of "Layering".  I am not sure what constraints can a 'local verifier' trustworthy, nor when a 'networked verifier' can provide validation into a TCG DICE type Layer.  These are not questions I have looked at closely.

However, it could be that one of these is what you mean by (iii)?
<eric> This is one type of thing covered in (iii).  The generalization of what I intended from (iii) was evidence provided by an Attester which is provably not generated within the Attester.  For example, a recent Time quote from a Time Stamp Authority like in draft-birkholz-rats-tuda could also be included in what is sent to a Verifier/Relying Party.



From: RATS <<>> on behalf of "Eric Voit (evoit)" <<>>
Date: Thursday, January 23, 2020 at 7:40 AM
To: Dave Thaler <<>>, "Smith, Ned" <<>>, Henk Berkholz <<>>, Michael Richardson <<>>
Cc: "<>" <<>>
Subject: Re: [Rats] Composite Evidence

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.


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

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 <<>>
Sent: Wednesday, January 22, 2020 5:54 PM
To: Eric Voit (evoit) <<>>; Birkholz, Henk <<>>; Michael Richardson <<>>; Dave Thaler <<>>
Subject: Re: Composite Evidence

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.


From: "Eric Voit (evoit)" <<>>
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz <<>>, Michael Richardson <<>>, Dave Thaler <<>>, "Smith, Ned" <<>>
Cc: "<>" <<>>
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]
        |     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?