Re: [VoT] Clause 7 edgy on scope? (RE: Vectors of Trust I-D)

"Grassi, Paul A." <paul.grassi@nist.gov> Tue, 30 June 2015 01:36 UTC

Return-Path: <paul.grassi@nist.gov>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4608F1A87EF for <vot@ietfa.amsl.com>; Mon, 29 Jun 2015 18:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 CroGAyoAponK for <vot@ietfa.amsl.com>; Mon, 29 Jun 2015 18:36:07 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D5D1A87E3 for <vot@ietf.org>; Mon, 29 Jun 2015 18:36:07 -0700 (PDT)
Received: from SN1PR09MB0720.namprd09.prod.outlook.com (10.162.2.17) by SN1PR09MB0718.namprd09.prod.outlook.com (10.162.2.156) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 30 Jun 2015 01:35:48 +0000
Received: from SN1PR09MB0720.namprd09.prod.outlook.com ([10.162.2.17]) by SN1PR09MB0720.namprd09.prod.outlook.com ([10.162.2.17]) with mapi id 15.01.0201.000; Tue, 30 Jun 2015 01:35:48 +0000
From: "Grassi, Paul A." <paul.grassi@nist.gov>
To: Justin Richer <jricher@mit.edu>
Thread-Topic: [VoT] Clause 7 edgy on scope? (RE: Vectors of Trust I-D)
Thread-Index: AdCywAdxGV06rU/8R4OLexR95fMGDAADohkAAAGh2mU=
Date: Tue, 30 Jun 2015 01:35:48 +0000
Message-ID: <69B21050-7E52-4B85-8081-8DE210DE432A@nist.gov>
References: <147EE18440E5AF44834B220ED35BA530014AB1AEC1@WLGPRDMBX02.dia.govt.nz>, <F54072E0-5653-49B2-A370-E1C6318E7985@mit.edu>
In-Reply-To: <F54072E0-5653-49B2-A370-E1C6318E7985@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;
x-originating-ip: [96.231.131.239]
x-microsoft-exchange-diagnostics: 1; SN1PR09MB0718; 5:rD+8GJayKO+mg67fyTBHKDGJrFIoTPGKJI4n4aBl9zuHDdlykrMXkmMq59vMwgorO0QMFlG1EHAuA+WWgzVCsUKMi527Euf5xQ+fq5q6BwEWGTSbM3IkYcrfi7a4vmmVcHb8l27HLUp7G+tDIF/fyQ==; 24:LXU8I41/c1IYrHn7y6SMpa/jR349Fmj3JKwZDjPw3YWVrxrdsn64pTOaYj6bp0X33V10ghPVBGvzmpMfR6h9IaT+QS5FxEIiU++f3G9x6zI=; 20:uIkmQ84NSQ7Pq4E/+5p1FQZg/Kpp+cm21rieUUdOgbdA3d/VPFyZwPrY9GhdnKecC+bYDIhokcGsdg/vpUngWg==
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:SN1PR09MB0718;
x-microsoft-antispam-prvs: <SN1PR09MB0718454A1A7658F0EAA966A891A90@SN1PR09MB0718.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR09MB0718; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB0718;
x-forefront-prvs: 06237E4555
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(53754006)(51444003)(66654002)(110136002)(15975445007)(102836002)(76176999)(62966003)(2950100001)(5001960100002)(2900100001)(77096005)(66066001)(77156002)(189998001)(83716003)(82746002)(40100003)(54356999)(50986999)(92566002)(122556002)(5002640100001)(46102003)(16236675004)(33656002)(561944003)(19625215002)(19617315012)(2171001)(87936001)(86362001)(2656002)(19580395003)(19580405001)(36756003)(99286002)(104396002)(19607625011); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0718; H:SN1PR09MB0720.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_69B210507E524B8580818DE210DE432Anistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 01:35:48.2833 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0718
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/rDEN4s-T9AEu0TXkAeus4NvXkoQ>
Cc: Colin Wallis <Colin.Wallis@dia.govt.nz>, "vot@ietf.org" <vot@ietf.org>
Subject: Re: [VoT] Clause 7 edgy on scope? (RE: Vectors of Trust I-D)
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list <vot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vot>, <mailto:vot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vot/>
List-Post: <mailto:vot@ietf.org>
List-Help: <mailto:vot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vot>, <mailto:vot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 01:36:11 -0000

I personally like the idea of discoverability at the onset, and the discussion that will follow.

This was great to read, thanks to you and Leif for the work!

On Jun 29, 2015, at 8:49 PM, "Justin Richer" <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:

Colin, that's a great question, because I'm honestly not sure what the answer is yet. I think that the vectors only make sense in the context of some kind of trust framework setup, but that sometimes those policies will be hard-coded at configuration time and won't need to be dynamically bound or discovered. That said, I think the real value of this is going to be cross-domain where an RP could subscribe to (and understand) multiple trust marks and be able to validate them at runtime. Still, that piece might be separable enough, and perhaps substantive enough, to be its own draft.

That said, I figured I'd write it down down and figure out where it's actually supposed to go later. :)

 - Justin

On Jun 29, 2015, at 7:14 PM, Colin Wallis <Colin.Wallis@dia.govt.nz<mailto:Colin.Wallis@dia.govt.nz>> wrote:

Many thanks Justin and Leif

I've done a first pass/light read, and from that, I think it is a terrific first cut that gets us on the path to normalizing the discussions over the past 9 months.

Aside from a few tidy ups, I just have this slight concern whether all of Clause 7 (Discovery and Verification) is in scope for normative text?
I certainly appreciate that in most implementations and deployments, there would be a dependency on an operational trust framework and trustmark.
But is it too big a stretch to make that normative for this work?
Just a thought.. and more than happy to be proven wrong.. :).

Cheers
Colin


From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Saturday, 27 June 2015 3:15 p.m.
To: vot@ietf.org<mailto:vot@ietf.org>
Subject: [VoT] Vectors of Trust I-D

Hi Everyone,

I have taken the initial strawman proposal along with a substantial number of edits and inputs from several folks and have created an initial I-D of the document:

https://tools.ietf.org/id/draft-richer-vectors-of-trust-00

It's still a very drafty draft, but hopefully it's starting to make this a concrete thing. Please read it over and discuss it here on the list.

I would like to propose a bar-BoF in Prague for VoT for anyone who would like to discuss this. If you're interested (and will be there in person), let me know!

 - Justin

_______________________________________________
vot mailing list
vot@ietf.org<mailto:vot@ietf.org>
https://www.ietf.org/mailman/listinfo/vot