Re: [Rats] Composite Evidence

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 23 January 2020 02:40 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F2712006F for <rats@ietfa.amsl.com>; Wed, 22 Jan 2020 18:40:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZE9VlPDVUSV for <rats@ietfa.amsl.com>; Wed, 22 Jan 2020 18:40:30 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C60120018 for <rats@ietf.org>; Wed, 22 Jan 2020 18:40:30 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EBEE93897E for <rats@ietf.org>; Wed, 22 Jan 2020 21:39:56 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A86149B0 for <rats@ietf.org>; Wed, 22 Jan 2020 21:40:29 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rats\@ietf.org" <rats@ietf.org>
In-Reply-To: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com>
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: Wed, 22 Jan 2020 21:40:29 -0500
Message-ID: <25403.1579747229@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/b0n7QLV4k_JJDABbrBYXIQZSqXk>
Subject: Re: [Rats] Composite Evidence
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 02:40:33 -0000

Eric Voit (evoit) <evoit@cisco.com> 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.
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.

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


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-