Re: [VoT] Vectors of Trust I-D feedback

Joanne Knight <Joanne.Knight@dia.govt.nz> Tue, 04 August 2015 00:35 UTC

Return-Path: <Joanne.Knight@dia.govt.nz>
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 AF9081B3190 for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 17:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.317
X-Spam-Level:
X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_BIZ=0.288, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_HELO_PASS=-0.001] autolearn=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 kpU11Kgw9COT for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 17:35:26 -0700 (PDT)
Received: from mx1.securemx.biz (mx1.securemx.biz [203.84.134.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF361B2A3E for <vot@ietf.org>; Mon, 3 Aug 2015 17:35:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=nz.smxemail.com; s=alpha; c=relaxed/relaxed; q=dns/txt; i=@nz.smxemail.com; t=1438648522; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC; bh=0Pcu9XSWUbcKVv6f8K9zeY2EMhVj0adHc4Wt9AfzsTA=; b=uVmflJP1P4GB1z4Oy6YrzSbKcGRwy64LnXXWfcvVRJQU0QR2Qc9VBVyy4GRcADS0 Qc12zU2ym1GQ9lgPIdOh/ZorPu3tAbMpi4H+G2U+7GbIhq24v5nGO5Yq6/GogZyz +ipM+vK+yh3jFCqo4u2wyDjl12iOB85hJd3OR9IkMWQ=;
Received: from s111-0006-lnv01 ([131.203.48.73]) by omr.nz.smxemail.com with ESMTP (using TLSv1 with cipher AES256-SHA (256/256 bits)) id 55C008C3-BF5E22FB@mta1103.omr; Tue, 04 Aug 2015 00:35:19 +0000
Message-ID: <569AD906E45DB44A8AFF11D61F5DA791014ADEF3DC@WLGPRDMBX02.dia.govt.nz>
MIME-Version: 1.0
X-MessageIsInfected: false
Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([161.65.142.21]) by s111-0006-lnv01 (JAMES SMTP Server ) with ESMTP ID 1343702709; Tue, 04 Aug 2015 12:05:19 +1200 (NZST)
Received: from WLGPRDCAS01.dia.govt.nz (Not Verified[172.29.0.93]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id <B55c001be0000>; Tue, 04 Aug 2015 12:05:18 +1200
Received: from WLGPRDMBX02.dia.govt.nz ([fe80::d51f:14cf:8162:8a0b]) by WLGPRDCAS01.dia.govt.nz ([172.29.0.93]) with mapi id 14.03.0235.001; Tue, 4 Aug 2015 12:05:18 +1200
From: Joanne Knight <Joanne.Knight@dia.govt.nz>
To: 'Jim Fenton' <fenton@bluepopcorn.net>, Nat Sakimura <sakimura@gmail.com>, Rainer Hoerbe <rainer@hoerbe.at>
Thread-Topic: [VoT] Vectors of Trust I-D feedback
Thread-Index: AdDKgCb4PeFKa76GSTyFc+9OUdaFR5368U9Q
Date: Tue, 04 Aug 2015 00:05:17 +0000
References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <C9563753-E9E2-4990-9B7C-3AFEE232BD01@hoerbe.at> <CABzCy2AUA4ycTcj0-kgu_YaceduJRJYjruXs=X2zE1nowryGEQ@mail.gmail.com> <55BFEBC2.7070209@bluepopcorn.net>
In-Reply-To: <55BFEBC2.7070209@bluepopcorn.net>
Accept-Language: en-NZ, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailadviser: Confirmation not required
x-originating-ip: [172.29.0.162]
Content-Type: multipart/alternative; boundary="_000_569AD906E45DB44A8AFF11D61F5DA791014ADEF3DCWLGPRDMBX02di_"
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/B303-uvihZotlWSXYg58NFKJcFU>
Cc: "vot@ietf.org" <vot@ietf.org>, Justin Richer <jricher@mit.edu>
Subject: Re: [VoT] Vectors of Trust I-D feedback
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, 04 Aug 2015 00:35:29 -0000

ISO/IEC 29115 has been nothing but a headache for me for a number of years.

If we want to be evolutionary I would not constrain myself to trying to be consistent with it - especially since it is currently being reviewed. I have also suggested that it look this way ;-) rather than the other way around.

I am still out to lunch on Assertion Presentation. Just because it exists in my framework and has (thanks to Justin) got a label, I have not had time to think through exactly what it is and means. It may be that it is a series of aspects that must be added to the other Vectors. They may not be measurable, in which case they become guidance.

As it was Nat who lit the spark that there is this other 'thing' in the mix, I am hoping for a flu free ISO meeting to have an academic brainstorm. Jim, I seem to have missed your review of I-D, so would appreciate if you can send me your thoughts on Assertion Presentation.

Cheers

Joanne

From: Jim Fenton [mailto:fenton@bluepopcorn.net]
Sent: Tuesday, 4 August 2015 10:32 a.m.
To: Nat Sakimura; Rainer Hoerbe
Cc: vot@ietf.org; Justin Richer
Subject: Re: [VoT] Vectors of Trust I-D feedback

To be entirely consistent with ISO/IEC 29115, we would need to rename Identity Proofing as Enrolment, and Credential Usage as Authentication.

But ISO/IEC 29115 refers to these as phases: they occur at different times (or, in the case of Credential Management, over a long period of time) and have different threat models. But I would like to ask under which circumstances a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Authentication. There are credential management practices that would make a credential unsuitable for highly secure authentication, but why not just represent that as less secure authentication? VoT should be only as complex as required; it should not represent aspects of the process that the relying party does not need.

Also, Enrolment includes aspects of the credentialing process that go far beyond identity proofing and the binding of those attributes in a credential. It's the reliability of that attribute assertion that's orthogonal to authentication strength, and not all of the other aspects of enrolment.

Finally, I'll repeat my comment that's buried in my review of the I-D the other day that Assertion Presentation should be visible to the RP already. For example, if the assertion is encrypted in transit, the RP will know that without being told. There may be need for the RP to specify how it wants assertions to be presented to it, but that seems like more of a general option to me and not part of the Vector.

-Jim

On 8/2/15 2:59 AM, Nat Sakimura wrote:
I agree that we should split out the credential management and the credential usage.
Each should have different "grades".

Right now, -00 has:

3.1. Identity Proofing
3.2. Credential Management
3.3. Assertion Presentation


Instead, it could be

3.1 Identity Proofing
3.2 Credential Management
3.3 Credential Usage
3.4 Assertion Presentation

Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115, which is good.
Note: they are missing 3.4.

We also need to define vtm.
I imagine that vtm uri would point to the policy documents of the trust framework,
but that is not explicitly there.

Best,

Nat