Re: [VoT] vot Digest, Vol 10, Issue 4

Peter Alterman <palterman@safe-biopharma.org> Tue, 04 August 2015 13:27 UTC

Return-Path: <palterman@safe-biopharma.org>
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 60DCF1AC3AF for <vot@ietfa.amsl.com>; Tue, 4 Aug 2015 06:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UZKEo5RytiHC for <vot@ietfa.amsl.com>; Tue, 4 Aug 2015 06:27:09 -0700 (PDT)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (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 85BDF1ACD46 for <vot@ietf.org>; Tue, 4 Aug 2015 06:26:24 -0700 (PDT)
Received: by obnw1 with SMTP id w1so6776746obn.3 for <vot@ietf.org>; Tue, 04 Aug 2015 06:26:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=HKj83drRVr0UdWZpNDkn3MPju0DZ1HTEoTY1Q9GHqNo=; b=GkDcKEpHGqCcQ32DeHiGioXt6nsAvAXy4+aEUum5Jy0EKQPe5H9bhQ9eM4QUHQ8smw jX9iNcUoPT9Nv5JcoJwX506dk33vuQceS/YNkMRA8sSH3P40YqR7foPwAHK69+rexroM LpzC7nkm2J+uneqjfnAJd8VCrDixmBzVUEIwsqaWstsdUk7SsR/nBAibJubZGnzNP3S1 K7cJSl4n4x6ksEETydVAI4VO+2mFYMyzU8s6KJBLzdPHJ+cX3tz7Mv6yTs3vphNRARp/ J2Q+UdYihmxlWwINxxpjpUxvNLtmdAyNjkC2G9+U04Vr0P4ARH5iyMJ5ovRqr4tpD2oB pX8g==
X-Gm-Message-State: ALoCoQlcpW/Ja0mU4f48DItXtS1c33ROqazP72LlH5BIEeSXY9SWR6Mu4mawsnhx9LvdXt/ygfJo
MIME-Version: 1.0
X-Received: by 10.60.46.73 with SMTP id t9mr3064993oem.63.1438694783858; Tue, 04 Aug 2015 06:26:23 -0700 (PDT)
Received: by 10.202.197.147 with HTTP; Tue, 4 Aug 2015 06:26:23 -0700 (PDT)
In-Reply-To: <mailman.311.1438651480.3844.vot@ietf.org>
References: <mailman.311.1438651480.3844.vot@ietf.org>
Date: Tue, 4 Aug 2015 09:26:23 -0400
Message-ID: <CAAbgyEDZ8YhJtUgE77KHxpw4PhCzQba5Edr67_9j9gaxhAg0OA@mail.gmail.com>
From: Peter Alterman <palterman@safe-biopharma.org>
To: vot@ietf.org
Content-Type: multipart/alternative; boundary=089e01537eb48851d1051c7c3bd7
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/BX9QypJ9LHlW_Dfzh0fWRoeB_EY>
Subject: Re: [VoT] vot Digest, Vol 10, Issue 4
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 13:27:13 -0000

+1
Any document that links assurance to risk mitigation is valuable whether it
comes from ISO, ITU-T, NIST or the Songmasters of Tuvalu.
P

------------------------------------------------------------
Peter Alterman, Ph.D.
Chief Operating Officer
SAFE-BioPharma Association
cell: 301-943-7452



On Mon, Aug 3, 2015 at 9:24 PM, <vot-request@ietf.org> wrote:

> Send vot mailing list submissions to
>         vot@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/vot
> or, via email, send a message with subject or body 'help' to
>         vot-request@ietf.org
>
> You can reach the person managing the list at
>         vot-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vot digest..."
>
> Today's Topics:
>
>    1. Re: Vectors of Trust I-D feedback (Salvatore D'Agostino)
>
>
> ---------- Forwarded message ----------
> From: "Salvatore D'Agostino" <sal@idmachines.com>
> To: "'Nat Sakimura'" <sakimura@gmail.com>om>, "'Joanne Knight'" <
> Joanne.Knight@dia.govt.nz>
> Cc: "'Jim Fenton'" <fenton@bluepopcorn.net>et>, "'Rainer Hoerbe'" <
> rainer@hoerbe.at>gt;, "'Justin Richer'" <jricher@mit.edu>du>, vot@ietf.org
> Date: Mon, 3 Aug 2015 21:24:29 -0400
> Subject: Re: [VoT] Vectors of Trust I-D feedback
>
> +1
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Nat Sakimura
> *Sent:* Monday, August 03, 2015 9:14 PM
> *To:* Joanne Knight
> *Cc:* Jim Fenton; Rainer Hoerbe; Justin Richer; vot@ietf.org
> *Subject:* Re: [VoT] Vectors of Trust I-D feedback
>
>
>
> 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>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
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>