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

Nat Sakimura <sakimura@gmail.com> Tue, 04 August 2015 01:14 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 136B11A877C for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 18:14:16 -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 NSA1V_Hxev1L for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 18:14:13 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 B654B1A877B for <vot@ietf.org>; Mon, 3 Aug 2015 18:14:12 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so2907684wib.1 for <vot@ietf.org>; Mon, 03 Aug 2015 18:14:11 -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=IaZA5m8i+l1CrNDpeNzqlb32/BzGeY5p5JOoDXR3LxI=; b=gfFNEKoASNUAosWzO7sMV1yiQC5g2KuWped0EVPJQnBnmMf2LpRdmQVY1wE9GBaZph AuD5RNdNkYDJHLUELyKlda0jg7A/16d+duWI5npe/W0fAqMCkKkJFInIo0uH5odi9akd rNsha0cQ5dp9r1WgLFEl3mEBwMEb6vK1fDjIsXW/bdzvtpGxn9p6h0TeW+qpW7U9BLMi OGT25vYKGoCcBCB8q6acMokFfjUMXC6jl5Xs4a4KyCJrru5zyhBrfepLBmBrHCTA1Tbj ilBbhiOPmn6rwOrwxDPHCOsfP1qmaxnHn+raAYeg99zkXCHLX6KM1youEv/HfcC2V1CX 7Xqw==
MIME-Version: 1.0
X-Received: by 10.180.76.232 with SMTP id n8mr40489348wiw.72.1438650851521; Mon, 03 Aug 2015 18:14:11 -0700 (PDT)
Received: by 10.28.144.85 with HTTP; Mon, 3 Aug 2015 18:14:11 -0700 (PDT)
In-Reply-To: <569AD906E45DB44A8AFF11D61F5DA791014ADEF3DC@WLGPRDMBX02.dia.govt.nz>
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> <569AD906E45DB44A8AFF11D61F5DA791014ADEF3DC@WLGPRDMBX02.dia.govt.nz>
Date: Tue, 04 Aug 2015 10:14:11 +0900
Message-ID: <CABzCy2ANqsU6kXXMGascqhWZuxmwrknxBZ-Z1i317OABR3qUkA@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Joanne Knight <Joanne.Knight@dia.govt.nz>
Content-Type: multipart/alternative; boundary="f46d043893f9f616f5051c720081"
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/iynr9aw_Qv4P5uEhlLbHIQUkrSA>
Cc: Jim Fenton <fenton@bluepopcorn.net>, 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 01:14:16 -0000

Hi.

I think X.1254 | ISO/IEC 29115 is actually quite good if you read deeply
into it especially from private sector point of view. It has departed from
the government centric approach as it should be as an industry standard,
and the applicability was widened considerably.

What's really good about it is its departure from the notion that identity
is {name, dob, address + some other attributes}. It is policy based so that
the policy in the framework should decide what needs to be verified to
achieve "identity proofing." In the private sector usage, it may just be a
validity of payment instrument and contact method.

29115 is not being reviewed at this time. There is an SP but it is just an
SP (study period) and not review. Review is supposed to start in December
2016.

Sort of assertion presentation has been in SP800-63 for sometime.
In the most recent one [SP800-63], it is clause 9.


[SP800-63]
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf,



2015-08-04 9:05 GMT+09:00 Joanne Knight <Joanne.Knight@dia.govt.nz>:

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



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