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

Justin Richer <jricher@mit.edu> Tue, 04 August 2015 14:23 UTC

Return-Path: <jricher@mit.edu>
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 3ABB21B3853 for <vot@ietfa.amsl.com>; Tue, 4 Aug 2015 07:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 H6tniWq9Ur5B for <vot@ietfa.amsl.com>; Tue, 4 Aug 2015 07:23:17 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C461ACC83 for <vot@ietf.org>; Tue, 4 Aug 2015 07:22:06 -0700 (PDT)
X-AuditID: 12074423-f79496d000001e58-ae-55c0ca8c5ba6
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 31.86.07768.C8AC0C55; Tue, 4 Aug 2015 10:22:04 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t74EM3cV009760; Tue, 4 Aug 2015 10:22:04 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t74EM1nO010443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Aug 2015 10:22:02 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_D4873E64-C006-4DCC-8942-993E731519BE"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <55BFEBC2.7070209@bluepopcorn.net>
Date: Tue, 04 Aug 2015 10:22:00 -0400
Message-Id: <434CC738-3F8F-4F71-8179-94BED6DC37E6@mit.edu>
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>
To: Jim Fenton <fenton@bluepopcorn.net>
X-Mailer: Apple Mail (2.2102)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixCmqrNtz6kCowcmVahbfOmcxW0yc+YLR 4sytFYwWDT8fsDqweDxd9YrJY+esu+weHReXMXssWfKTKYAlissmJTUnsyy1SN8ugStjVf9Z 5oIXLhXNG28yNTAuNe1i5OCQEDCRmNgj0cXICWSKSVy4t56ti5GLQ0hgMZPEpiMvGCGcDYwS Zz78YIZwHjBJvN7RygLSzSyQIDH1vCpIN6+AnkTPuS+MILawgIHE8Ws9YDabgKrE9DUtTCA2 p4C+xMydt9lBbBYBFYmZ728xg9jMAvkSD6fNZISYYyWx/81pVhBbSGArk8STr1kgtoiAusSD jhWMEJfKSmx908o0gVFgFsIVs5BcMQtsqrbEsoWvmSFsA4mnna9YMcX1Jd68m8O0gJFtFaNs Sm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRlBUsLso72D8c1DpEKMAB6MSD6/Ay/2h QqyJZcWVuYcYJTmYlER5q48cCBXiS8pPqcxILM6ILyrNSS0+xCjBwawkwqu9EyjHm5JYWZVa lA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBu/MkUKNgUWp6akVaZk4JQpqJgxNk OA/Q8NMgNbzFBYm5xZnpEPlTjIpS4ry8IAkBkERGaR5cLyxpvWIUB3pFmPffCaAqHmDCg+t+ BTSYCWiwdDzY4JJEhJRUA+O6sKX790ue/fT4u+31DWZTTj62Sr3mwiNkuPb4kz+9q1e/8ui9 zPJvbg9H7M8Hc5z22u3feWeu7JW0BzW7pWTj71wQN5vymSeL3779i5f2jBi/7bv3yjFeUUo9 smCnz/sIEUvt8utT/iqzVHIvPWd2fLnmLaVdWpb1Ud6fxE4/vNYS0eXYumixEktxRqKhFnNR cSIABDKSNjUDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/I-cn5sypjM5uYWZW0J53yuyUNZ0>
Cc: Nat Sakimura <sakimura@gmail.com>, Rainer Hoerbe <rainer@hoerbe.at>, "vot@ietf.org" <vot@ietf.org>
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 14:23:21 -0000

Just a quick note: I’ve come to agree that the Assertion Presentation component is most useful in the client’s request, where other protocols don’t always have such mechanisms. This raises an interesting question: should each component have a “target”? That is, either the response (vot) or the request (vtr), or both. This would be an indicator of the intent of the component, not so much its use in practice.

 — Justin

> On Aug 3, 2015, at 6:31 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:
> 
> 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
>> 
>> 
>