Re: [Rats] Composite Evidence

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 23 January 2020 16:47 UTC

Return-Path: <evoit@cisco.com>
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 2066012012D for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 08:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BSoQzOc2; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=Xj2fdz7W
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 nFJo0l24e95l for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 08:47:12 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E0E120866 for <rats@ietf.org>; Thu, 23 Jan 2020 08:47:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9351; q=dns/txt; s=iport; t=1579798032; x=1581007632; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1NnAwm7UTF3QSbkF/2dMjcTv924EvEAhWFm2WtKKwyQ=; b=BSoQzOc2PAk1pBuHs3iY1Iy11AsWhv3pFaieEJ+j4+jhUuGhfK1y46wI YN13Zm/QgvBydsktszGdUthlkZafwzfQWblwks+MCXnS+0rNqlEZWJNag X4ezKKzC0jModrv2380jbbWY9NG9fqqYMzhiwBbYEjnWOBSFO5QxcUlrY Q=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3ADQWtAh+rab0dmv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcObDkznBPXrdCc9Ws9FUQwt8g=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4FQACzSle/4UNJK1lHgELHINPUAV?= =?us-ascii?q?sKy0gBAsqCodOA4sOToIRmA+BQoEQA1QCBwEBAQkDAQEfDgIBAYFMgnQCgh4?= =?us-ascii?q?kOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQIBEi4BATAIBAsCAQgSAwMuAjA?= =?us-ascii?q?XDgEBBAESCAYUgwWBfU0DDhEPAQKhXAKBOYhhgieCfwEBBYUIGIIFBwmBOIF?= =?us-ascii?q?TijUPGoFBP4ERR4JMPoQWARIBDxKDQIIsjU6JapggCoI5g2eCOJAwmneOXps?= =?us-ascii?q?IAgQCBAUCDgEBBYFpImdxcBWDJwlHGA2IAQsYgnxUilN0gSmKIYEiAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.70,354,1574121600"; d="p7s'?scan'208";a="422356071"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 16:47:11 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 00NGlAgT014176 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2020 16:47:11 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 10:47:10 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 10:47:10 -0600
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 23 Jan 2020 10:47:09 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MqV1mHd1AJjqrCn/XZiNSe78gejkGiItwiwHj2ZFk0/kSw00gNkQfrLXuLRKLsUKSQ4O+y3FXflpgNl5h7mR3/UgVKewgpHSk5RjgNjd7NVt4zpWYdFXTHD3vDQpOjk/W8PGdwJ6E4yr244MbXeI5YJlUBt/5KepmfS8VNU5VnVRQRxc5k0BXJlAx3x/OpczAGwA/D6ndKMQtk1Te95gHZIkRYdOdsqQgCM2GST4SJzYsQhRI/jc9tzy65uVp6r1bNw2vZjJyaEwQ+8j/EJi0NHUdEX6ItbzYvVTVLtYzJ5Sw0+vMQ3kCkImaBbvy85cGlL27IvZeIN39D05DEt0VQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=boqa2+7urWkDMWndqJCbBF5fxeEj0iEF2sdZhABEWKA=; b=BRuG5Tx5JG/4G+iJfHKx7hYB3o85T7oZUmtXys0rRf6v8h19TO6Ofl/NQfL0c+6kFhHxX0qzccsuDO/aKRSPo+79gX+HfrryQA3IwOb7niaxYYrE5kYRbjLsG2e2D12YzK8+Vz5t9J2jcAAvZcruwLMMGG48mYx+SfWGpptaOmyKiGORUGI6XQfMXMQWm5wXx+a44afy0UIxYsNPFC8KkEBUZrOWRP2HgnjzeBxXNnAX4MKO7hncr2T4D9SC3Zg+r61CjxaXfgVl7T8k7fV1K6rYtOoie7sqa1j0iRjLLHVZGlOUr6oboyj1qEGEEDsH9AYIv0i0F9+m+8ZMtCHweg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=boqa2+7urWkDMWndqJCbBF5fxeEj0iEF2sdZhABEWKA=; b=Xj2fdz7WcgNbJw6+sxReeoE4L0FCKqDV4VmO8AYywQLu6/VoGisvW/ebQDIgrX2ynnq8tHNsBE1sDcmMWWqwwYOXCzKQT9YSYVk2xyy3zxfOYbfJZVJb2WKmR+kIokPYHIHYZNnolhfz9ReQjIXkJROLFVWFe3ZrQ9tp8g11rgQ=
Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB3733.namprd11.prod.outlook.com (20.178.238.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Thu, 23 Jan 2020 16:47:08 +0000
Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2665.017; Thu, 23 Jan 2020 16:47:08 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Composite Evidence
Thread-Index: AdXRgB49sEcLGXWTRbyFhaWoEjRAwwAFlsyAABye0OA=
Date: Thu, 23 Jan 2020 16:47:08 +0000
Message-ID: <BYAPR11MB2536EEF62BD7B1C53EC59659A10F0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com> <25403.1579747229@localhost>
In-Reply-To: <25403.1579747229@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: faba6c79-14d5-4e85-cc15-08d7a023e305
x-ms-traffictypediagnostic: BYAPR11MB3733:
x-microsoft-antispam-prvs: <BYAPR11MB37332BF29C91B84455E728B1A10F0@BYAPR11MB3733.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(346002)(39860400002)(136003)(366004)(199004)(189003)(64756008)(66446008)(76116006)(9686003)(8676002)(52536014)(55016002)(66556008)(66476007)(66616009)(66946007)(478600001)(316002)(966005)(110136005)(86362001)(5660300002)(7696005)(2906002)(186003)(6506007)(33656002)(8936002)(26005)(81166006)(81156014)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3733; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: X+rrz+72EAxqk84occjUUUBpFbtE7Z9lbwl/paI62uOhfnnS4Hw7Vu39YMVtUsJNoCwvycDtnq+0ZSjzo5GKg8vxhmcG4u0fjS61NqcgQQF8wAb39Mb4X/tGygf6LVzOOi+IH+F6WxJIUuZhEbJy/x1DqaQtkFM8E6E7n2kihmcKNiv3jB+YvSidPYW2Ma+K9oesIVejUAU++fk0qop+9aDf8LNv64oym0b9jR6lpY8sRNaR/zddLzz9RFQiKZvu4skPb9I6ZVuTjJQasK8xqrsg5tqye+vZ7M44PNalEKoHgexlCa/5zdMfh+trv8BchiwypukJTKXGW/SLIV2XBvRapPOTsyJRV9R9M6r/O53luvBR4r9gORQjPOnFhGk29vlzlcAA3L8yrILBscMB6XLnTwghDeKqzA1F2ZIY9uVxJtGgiZVHe4BkERwNgRaXkx7zUGluzvKVbOC0WQKeQXEhzc7GNGnyPiHsOVuU8sE=
x-ms-exchange-antispam-messagedata: TXZWZc+dUwUdgshWSk3QskxPw06D5wE25qvZYarkIA1LZeAo/0IxK7MZgmC0h/VA2zBfFcZ463CpEtQa8lp1VAd1LrCqhcuLtvqiAMNjzuapfJ+sv3wgKwk4weKAuMGGV8U3+/b8tOlJJEbJMdbYgA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00FA_01D5D1E2.B0AED6C0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: faba6c79-14d5-4e85-cc15-08d7a023e305
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 16:47:08.7473 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NduZmYFr+BdnaK7ceHxZI30hnvcaN9D/fnLiYRwLS/k/SFupiicq/SUwRkiXuOck
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3733
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/K7ycEu4MoXyef-GBqsgZXAEFQKk>
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 16:47:15 -0000

Hi Michael,

> From: Michael Richardson, January 22, 2020 9:40 PM
> 
> 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.

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

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

I thought about trying SVG.  But I am not brave enough with the tooling to
be an early IETF adopter :-).
 
> Second, I found the extra hash(),@time, stuff distracting, as it went into
a
> 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).

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

Good point, we probably can remove "computationally".
    
> 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?)

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

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

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