Re: [Rats] Composite Evidence

Michael Richardson <> Thu, 23 January 2020 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA651120860 for <>; Thu, 23 Jan 2020 12:36:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NEdB7OhoWxpe for <>; Thu, 23 Jan 2020 12:35:59 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6C21120823 for <>; Thu, 23 Jan 2020 12:35:58 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 8A15338982 for <>; Thu, 23 Jan 2020 15:35:24 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id DFA84C50 for <>; Thu, 23 Jan 2020 15:35:57 -0500 (EST)
From: Michael Richardson <>
To: "rats\" <>
In-Reply-To: <>
References: <> <25403.1579747229@localhost> <> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Thu, 23 Jan 2020 15:35:57 -0500
Message-ID: <14896.1579811757@localhost>
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 20:36:01 -0000

Smith, Ned <> 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.

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 [%].