Re: [Rats] Composite Evidence

"Smith, Ned" <> Fri, 24 January 2020 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB398120BE1 for <>; Fri, 24 Jan 2020 11:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n9uhxtpS0IiX for <>; Fri, 24 Jan 2020 11:12:59 -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 5E234120AC9 for <>; Fri, 24 Jan 2020 11:12:58 -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; 24 Jan 2020 11:12:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.70,358,1574150400"; d="scan'208";a="222697373"
Received: from ([]) by with ESMTP; 24 Jan 2020 11:12:57 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 24 Jan 2020 11:12:56 -0800
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Fri, 24 Jan 2020 11:12:56 -0800
From: "Smith, Ned" <>
To: Michael Richardson <>
CC: "" <>
Thread-Topic: [Rats] Composite Evidence
Thread-Index: AdXRgB49sEcLGXWTRbyFhaWoEjRAwwAWWlWAAB2RpAD//6sSAIAAlNyA//+lU4CAAcbpAP//iMmA
Date: Fri, 24 Jan 2020 19:12:55 +0000
Message-ID: <>
References: <> <25403.1579747229@localhost> <> <> <14896.1579811757@localhost> <> <14740.1579889976@localhost>
In-Reply-To: <14740.1579889976@localhost>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
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: Fri, 24 Jan 2020 19:13:02 -0000

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

    Smith, Ned <> 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.
    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
        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.
  mcr>  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. = "AR1".
    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?
        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).
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]        |   ruby on rails    [
    Michael Richardson <>ca>, Sandelman Software Works
     -= IPv6 IoT consulting =-