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

Nat Sakimura <sakimura@gmail.com> Tue, 04 August 2015 00:53 UTC

Return-Path: <sakimura@gmail.com>
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 0EAE41B327D for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 17:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ok_ZgfmnNb1i for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 17:53:46 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE751B2A10 for <vot@ietf.org>; Mon, 3 Aug 2015 17:53:46 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so143915554wib.0 for <vot@ietf.org>; Mon, 03 Aug 2015 17:53:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y9ITb3ECt6OVipfYbg42cGilwm7ZLu3cXy0msMx9qeI=; b=tZ2poWeaYIxBzzuIFpranEz841X4fW7g1yIVGhcMeHJSgE6DlwgsLSIDAgM5V7lqOr Qz0d1sl9+FWCD4MNINO70yIP5i5uUl2agxysqj3av3SQ6XBgWoK7ZApC+8jtof78GfU2 2nHZgfF9pAU6aCXR+wfUYGUR4nr/2Nc/8/90wNu9gCo+Jq98ngD/lBYT9mVNsBkR0fCl UpS/m97Eq+o6Q53ON5J6Hx3Fgy3bgsoEdSGKLe0fAQLI1cPIMWKk1nQRUk0eb8p5xI6o NovA1X6dZvRnW+WGM7UXZ0ZeFkxiOkoHuiobHu5BNfu8pnmMMkMdF+dL57NTpnt9fp/0 fGuA==
MIME-Version: 1.0
X-Received: by 10.180.208.81 with SMTP id mc17mr2532932wic.93.1438649625068; Mon, 03 Aug 2015 17:53:45 -0700 (PDT)
Received: by 10.28.144.85 with HTTP; Mon, 3 Aug 2015 17:53:44 -0700 (PDT)
In-Reply-To: <55BFEBC2.7070209@bluepopcorn.net>
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>
Date: Tue, 04 Aug 2015 09:53:44 +0900
Message-ID: <CABzCy2C8s+B68+fqWNGa49nbbhFmyNjk7ipxZaTT8V_s_3outg@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Jim Fenton <fenton@bluepopcorn.net>
Content-Type: multipart/alternative; boundary="001a11c33bb0dbcb65051c71b758"
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/ICl4b2GxfDbRbXK17whbIkouXYI>
Cc: Rainer Hoerbe <rainer@hoerbe.at>, Justin Richer <jricher@mit.edu>, "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 00:53:49 -0000

Right, X.1254 | ISO/IEC 29115 says:

   1.

   8.1  Enrolment phase
   2.

   8.2  Credential management phase
   3.

   8.3  Entity authentication phase

It also has

   1.

   9  Management and organizational considerations.

My point is that this I-D seems to use "Credential Management" for "Entity
Authentication" (BTW, at one point of the draft, it was called "Credential
Usage", or at least, JP NB proposed the name because this entire framework
is "Entity Authentication" and not this specific phase.)

2015-08-04 7:31 GMT+09:00 Jim Fenton <fenton@bluepopcorn.net>:

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


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en