From nobody Sun Aug 2 02:59:55 2015 Return-Path: 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 A74591A89C7 for ; Sun, 2 Aug 2015 02:59:53 -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 PtyECMya8toU for ; Sun, 2 Aug 2015 02:59:51 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 7C5D31A89B5 for ; Sun, 2 Aug 2015 02:59:50 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so79888257wib.1 for ; Sun, 02 Aug 2015 02:59:49 -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=mcbHC3innqmRM6ATAYanKZJFDVo+pNLH2wH+9FTq2HY=; b=pZK/MbSTjLaqGr1FJSnT7toqUgKZo682T4Jvm5aFkp1FAfW3ow/kI8woTaEd3QaQ11 abjcMDnyIXyRFLGKovjOaTAkiCJDigQTXFuxterCtTwEweOX0rF58OFfiQrgC2ZPyPkE uzztVStGgLfxxWm9iZgUsYNUsVyj2MRYBJwDVdOTH8Vk5UJyFHIzcFTkRbXcL9D2YxpY yckLkmdy21jmwrHSKZ9KuIIiBfFpzmYnATDHkV46+kSHkYygvxAaPLXXQObjcxO+sCd8 +dA3phnP1RKZT+eTLMRuGIfX5wVUnvi1Dmf/DSf7xstA1I0MEknEQIwmTeaOjZyWjWUb uAyQ== MIME-Version: 1.0 X-Received: by 10.180.107.70 with SMTP id ha6mr22480598wib.20.1438509589230; Sun, 02 Aug 2015 02:59:49 -0700 (PDT) Received: by 10.28.144.85 with HTTP; Sun, 2 Aug 2015 02:59:49 -0700 (PDT) In-Reply-To: References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> Date: Sun, 2 Aug 2015 18:59:49 +0900 Message-ID: From: Nat Sakimura To: Rainer Hoerbe Content-Type: multipart/alternative; boundary=e89a8f234d09127c71051c511d17 Archived-At: Cc: "vot@ietf.org" , Justin Richer 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 09:59:53 -0000 --e89a8f234d09127c71051c511d17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 2015-07-31 17:44 GMT+09:00 Rainer Hoerbe : > See my proposed changes in the attached word document. > > Another point: I wonder if there is consistent understanding wrt. > Credential Management levels. How do people grade strong credentials tha= t > rely on a weak recovery mechanisms like eMail and KBA? When multiple > C-levels are asserted, they are reducing the risk, but joining session > authentication and credential recovery is increasing the risk. I think th= at > VoT should be include a rule how to handle this. > > - Rainer > > > Am 30.07.2015 um 14:12 schrieb Justin Richer : > > Rainer, > > Thanks for this input, this is helpful. When Leif and I picked the term > "Vectors of Trust" we knew that each part of that phrase was problematic = in > some fashion, but we've yet to hear something that's more serviceable. Th= is > is the reasoning behind the explanatory section at the beginning, actuall= y. > Can you suggest some text for a better way to situate the terms? > > -- Justin > > On 7/30/2015 7:20 AM, Rainer Hoerbe wrote: > > The term vector seems to stick since Bob Morgan=E2=80=99s visualization s= ome years > ago despite some resistance. However its connotation in =E2=80=9E2.2 Comp= onent > Architecture=E2=80=9C is misleading, because all the language about =E2= =80=9Emathematical > construct=E2=80=9C, =E2=80=9Ecoordinate system=E2=80=9C and =E2=80=9Emust= be orthogonal=E2=80=9C is not properly > put into context by "need for simplicity=E2=80=9C and "somewhat elided mo= del=E2=80=9C. > > I suggest to use stronger wording to make it clear to the newcomer that > this kind of taxonomy is by its nature an oversimplification. Fitting a > square peg into a round hole is the only option to reduce the complexity = of > trust frameworks. There should be an emphasis that the number of vectors, > their orthogonality and composition will never be a clean and undisputed > derivation from real trust models, but an extension and improvement from > current practices like 800-63. VoT is taking facts that are measurable ou= t > of the trust framework leaving the amorphous rest to TLDR risk assessment= s. > > - Rainer > > Am 30.07.2015 um 06:28 schrieb Joanne Knight : > > Hi All > > > Due to workloads it has taken me a while to catch-up and I am sorry I was > unable to make the Bar BoF. > > > I have attached a paper with my thoughts on the drafty draft as well as > where my own framework has evolved to so far. I have recently latched on = to > a resource to aid me in progressing the Identity-related risk assessment = so > let me know if anyone is interested in the out-comes as not directly VoT > related. > > > Thoughts only, take them at your whim. > > > Cheers > > > Joanne > > > > > *From:* Justin Richer [ mailto:jricher@MIT.EDU > ] > *Sent:* Saturday, 27 June 2015 3:15 p.m. > *To:* vot@ietf.org > *Subject:* [VoT] Vectors of Trust I-D > > > > Hi Everyone, > > > > I have taken the initial strawman proposal along with a substantial numbe= r > of edits and inputs from several folks and have created an initial I-D of > the document: > > > > https://tools.ietf.org/id/draft-richer-vectors-of-trust-00 > > > > It=E2=80=99s still a very drafty draft, but hopefully it=E2=80=99s starti= ng to make this a > concrete thing. Please read it over and discuss it here on the list. > > > > I would like to propose a bar-BoF in Prague for VoT for anyone who would > like to discuss this. If you=E2=80=99re interested (and will be there in = person), > let me know! > > > > =E2=80=94 Justin > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --e89a8f234d09127c71051c511d17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that we should split out the credential management= and the credential usage.=C2=A0
Each should have different "grade= s".=C2=A0

Right now, -00 has:=C2=A0

3.1. Ide= ntity Proofing=C2=A0
3.2. Credential Management
3.3. Assertion Presen= tation=C2=A0

Instead, it could = be

3.1 Identity Proofing
3.2 Credential = Management
3.3 Credential Usage
3.4 Assertion Presentat= ion

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

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

Best,=C2=A0

Nat




=
2015-07-31 17:44 GMT+09:00 Rainer Hoerbe <rainer= @hoerbe.at>:
See my proposed changes in the attached word document= .

Another point: =C2=A0I wonder if there is consistent u= nderstanding wrt. Credential Management =C2=A0levels. How do people grade s= trong credentials that rely on a weak recovery mechanisms like eMail and KB= A? When multiple C-levels are asserted, they are reducing the risk, but joi= ning session authentication and credential recovery is increasing the risk.= I think that VoT should be include a rule how to handle this.

- Rainer
<= div>

=
Am 30.07.2015 um 14:12 schrieb Just= in Richer <jricher@= mit.edu>:

=20 =20 =20
Rainer,

Thanks for this input, this is helpful. When Leif and I picked the term "Vectors of Trust" we knew that each part of that phrase= was problematic in some fashion, but we've yet to hear something that&#= 39;s more serviceable. This is the reasoning behind the explanatory section at the beginning, actually. Can you suggest some text for a better way to situate the terms?

=C2=A0-- Justin

On 7/30/2015 7:20 AM, Rainer Hoerbe wrote:
=20 The term vector seems to stick since Bob Morgan=E2=80=99s visualizati= on some years ago despite some resistance. However its connotation in =E2=80=9E2.2 Component Architecture=E2=80=9C is misleading, because a= ll the language about =E2=80=9Emathematical construct=E2=80=9C, =E2=80=9Ecoo= rdinate system=E2=80=9C and =E2=80=9Emust be orthogonal=E2=80=9C is not properly put into context= by "need for simplicity=E2=80=9C and "somewhat elided model=E2=80=9C.

I suggest to use stronger wording to make it clear to the newcomer that this kind of taxonomy is by its nature an oversimplification. Fitting a square peg into a round hole is the only option to reduce the complexity of trust frameworks. There should be an emphasis that the number of vectors, their orthogonality and composition will never be a clean and undisputed derivation from real trust models, but an extension and improvement from current practices like 800-63. VoT is taking facts that are measurable out of the trust framework leaving the amorphous rest to TLDR risk assessments.

- Rainer

Am 30.07.2015 um 06:28 schrieb Joanne Knight <Joanne.Knight@dia.govt.nz>:

=20 =20

Hi All=

=C2=A0
<= /div>

Due to workloads it = has taken me a while to catch-up and I am sorry I was unable to make the Bar BoF.

=C2=A0

I have attached a paper with my thoughts on the drafty draft as well as where my own framework has evolved to so far. I have recently latched on to a resource to aid me in progressing the Identity-related risk assessment so let me know if anyone is interested in the out-comes as not directly VoT related.

=C2=A0

Thoughts only, take them at your whim.

=C2=A0

Cheers

= =C2=A0

Joanne

=C2=A0
=C2=A0<= /span>
=C2=A0

From: Justin Richer [mailto:jricher@MIT.EDU]
Sent: Saturday, 27 June 2015 3:15 p.m.
To: vot@ietf.org
Subject: [VoT] Vectors of Trust I-D

=C2=A0

Hi Everyone,

=C2=A0

I have taken the initial strawm= an proposal along with a substantial number of edits and inputs from several folks and have created an initial I-D of the document:

=C2=A0

=C2=A0

It=E2=80=99s still a very draft= y draft, but hopefully it=E2=80=99s starting to make this a conc= rete thing. Please read it over and discuss it here on the list.

=C2=A0

I would like to propose a bar-B= oF in Prague for VoT for anyone who would like to discuss this. If you=E2=80=99re interested (and will be there in person), let me know!

=C2=A0

=C2=A0=E2=80=94 Justin

<VoT Feedback.docx>_____________________________________= __________
vot mailing list
vot@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/vot


_______________________________________________
vot mailing list
vot@ietf.org
https://ww= w.ietf.org/mailman/listinfo/vot

<= /div>
_______________________________________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--e89a8f234d09127c71051c511d17-- From nobody Mon Aug 3 15:31:35 2015 Return-Path: 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 55A7E1A8A87 for ; Mon, 3 Aug 2015 15:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 WF8Fn57GeSe0 for ; Mon, 3 Aug 2015 15:31:32 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAA71ACED2 for ; Mon, 3 Aug 2015 15:31:32 -0700 (PDT) Received: from splunge.local (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t73MVOQX005184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 3 Aug 2015 15:31:25 -0700 To: Nat Sakimura , Rainer Hoerbe References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> From: Jim Fenton X-Enigmail-Draft-Status: N1110 Message-ID: <55BFEBC2.7070209@bluepopcorn.net> Date: Mon, 3 Aug 2015 15:31:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050104000800070903030508" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1438641085; bh=v4PWnvOg5l/urmx6wGk4azqu0Yv3XFzHL7MUW7kiAc4=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=PRiI6tpq630YZkkeDYEpLWsWngJFBLLv8oU6wIa2K9MGoIL9/ml9zzmNr/L+sC3/C 6xxsHSYmWGv67H7aFU52yljqaqJiJzmOJ0rLbz/7NSduBg+fSrhu/VQZFvcLMaqH4t FwqCHhCvKVjd4Vq38VN9nYKtqla2jkaF4sbAke18= Archived-At: Cc: "vot@ietf.org" , Justin Richer 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 22:31:34 -0000 This is a multi-part message in MIME format. --------------050104000800070903030508 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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.=20 > Each should have different "grades".=20 > > Right now, -00 has:=20 > > 3.1. Identity Proofing=20 > 3.2. Credential Management > 3.3. Assertion Presentation=20 > > > 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.=20 > Note: they are missing 3.4.=20 > > We also need to define vtm.=20 > I imagine that vtm uri would point to the policy documents of the > trust framework,=20 > but that is not explicitly there.=20 > > Best,=20 > > Nat > > --------------050104000800070903030508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
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



--------------050104000800070903030508-- From nobody Mon Aug 3 16:23:07 2015 Return-Path: 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 230561B29BE for ; Mon, 3 Aug 2015 16:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 hJmfGBbchDAm for ; Mon, 3 Aug 2015 16:23:03 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 402FE1B29CB for ; Mon, 3 Aug 2015 16:23:03 -0700 (PDT) Received: by igk11 with SMTP id 11so82048870igk.1 for ; Mon, 03 Aug 2015 16:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GIkSnq8sCvo/L+HjXlEmzYpogBB31bxhfYPtsbNE0L0=; b=tGdmcwmc0jB1zmkXvDZ3JDGtLwV/2NBv4a79PlAaxEK5frOpOC0ys8uSQUcjTn6ZyG beb0fAw4X9F53h5pPVIq1nfbfEYxa5Mb71b/uSQVfggyeBVUaT2KN/7qEN0sDZ5xiZPa BFNaZGaLPpcScl8k++8DikQYxsdksnEa8Wm71C78t5gZggltNB9qafTLYHmM9MssnpQa cwKyIPMjg0ytTT2RvG6bXu5PBST/dud0dor0C91o7H89Fuef+cBZXZQC55J+qvoHxDyS /ZFLTSLdOWyBEyaTZU7nASx2nUMMNDqvRLiS07LRdehuaTAKGui/+HyP3p9ad8UY9KFL QlPw== X-Received: by 10.50.43.134 with SMTP id w6mr24219141igl.74.1438644182691; Mon, 03 Aug 2015 16:23:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.176.149 with HTTP; Mon, 3 Aug 2015 16:22:43 -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> <55BFEBC2.7070209@bluepopcorn.net> From: Ira McDonald Date: Mon, 3 Aug 2015 19:22:43 -0400 Message-ID: To: Jim Fenton , Ira McDonald Content-Type: multipart/alternative; boundary=089e01184b0c77b503051c7073bc Archived-At: Cc: Nat Sakimura , Rainer Hoerbe , Justin Richer , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:23:06 -0000 --089e01184b0c77b503051c7073bc Content-Type: text/plain; charset=UTF-8 Hi, And for those who forgot (I did), ISO 29115 is technically equivalent to ITU-T X.1254 (and the latter's available online for free download in PDF). Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Aug 3, 2015 at 6:31 PM, Jim Fenton 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 > > > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --089e01184b0c77b503051c7073bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

And for those who for= got (I did), ISO 29115 is technically equivalent to
ITU-T X.1254 (= and the latter's available online for free download in PDF).

Cheers,
- Ira


Ira McDonald = (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO = Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protoco= l WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music /= High North Inc
http://sites.google.com/sit= e/blueroofmusic
http://sites.google.com/= site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter=C2=A0 579 Park Pla= ce=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
Summer=C2=A0 PO Box 2= 21=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Mon, Aug 3, 2015 at 6:31 PM, Jim Fenton <= span dir=3D"ltr"><fenton@bluepopcorn.net> wrote:
=20 =20 =20
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 attribut= e 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.=C2=A0
Each should have different "grades".=C2=A0

Right now, -00 has:=C2=A0

3.1. Identity Proofing=C2=A0
3.2. Credential Management
3.3. Assertion Presentation=C2=A0

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.=C2=A0
Note: they are missing 3.4.=C2=A0

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

Best,=C2=A0

Nat




_______________________________________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot


--089e01184b0c77b503051c7073bc-- From nobody Mon Aug 3 16:45:27 2015 Return-Path: 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 886621AD06C for ; Mon, 3 Aug 2015 16:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_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 JaRdVEOD3cgv for ; Mon, 3 Aug 2015 16:45:23 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 17C441B29AF for ; Mon, 3 Aug 2015 16:45:23 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so154484755wic.0 for ; Mon, 03 Aug 2015 16:45:21 -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=Ie+qhgpwS6PD9vHOnMXE7VaH+dcM8DvpR0YnxzS+eMA=; b=j0D/Wl39rst4MZCrwlv6j5NyFyul0b5Na+1w8+MhG0LXnnjqpiXFT1q6nyMgxPzRUx 4qkg0cei/IcxM34qnbgPkHiT4hwElq5ZtPMc+KRE0DpRcB1hKyfiDhL+9q01xsP9jOjM Fear5mIoeml4EVz1DYefBbWd3Wcej4iVKbdXLebjEn9fXvyaNpQ0z5FjLKdCWU2ZbzTd yoNluIHOtgVZhuM163gJTz8xT+w6K1Mg8gmJ1fs2Bo0YltFfYyvwMQnyd6+zOfAGuaYc TFKZy0jjSsLNfAFcE6j45dMEpM7vdjaewtSazl0WdtpYpoac0nbnFDNlajwQCc8zg/mN u7PA== MIME-Version: 1.0 X-Received: by 10.194.119.161 with SMTP id kv1mr1150784wjb.157.1438645521803; Mon, 03 Aug 2015 16:45:21 -0700 (PDT) Received: by 10.28.144.85 with HTTP; Mon, 3 Aug 2015 16:45:21 -0700 (PDT) In-Reply-To: References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <55BFEBC2.7070209@bluepopcorn.net> Date: Tue, 4 Aug 2015 08:45:21 +0900 Message-ID: From: Nat Sakimura To: Ira McDonald Content-Type: multipart/alternative; boundary=089e01227ba048f039051c70c31f Archived-At: Cc: Jim Fenton , Rainer Hoerbe , Justin Richer , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:45:25 -0000 --089e01227ba048f039051c70c31f Content-Type: text/plain; charset=UTF-8 Yup. If I remember correctly, only three words are different between X.1254 and ISO/IEC 29115. X.1254 can be downloaded from here: https://www.itu.int/rec/T-REC-X.1254-201209-I/en 2015-08-04 8:22 GMT+09:00 Ira McDonald : > Hi, > > And for those who forgot (I did), ISO 29115 is technically equivalent to > ITU-T X.1254 (and the latter's available online for free download in PDF). > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > On Mon, Aug 3, 2015 at 6:31 PM, Jim Fenton 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 >> >> >> >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> >> > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e01227ba048f039051c70c31f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yup. If I remember correctly, only three words are differe= nt between X.1254 and ISO/IEC 29115. X.1254 can be downloaded from here:=C2= =A0https://www= .itu.int/rec/T-REC-X.1254-201209-I/en
<= br>
2015-08-04 8:22 GMT+09:00 Ira McDonald <blueroofmusic@gmail.com>:
Hi,

And for those who fo= rgot (I did), ISO 29115 is technically equivalent to
ITU-T X.1254 = (and the latter's available online for free download in PDF).

Cheers,
- Ira


Ira McDonald (Musician / Software Arch= itect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Fou= ndation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
= Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated E= xpert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
= mailto: bluero= ofmusic@gmail.com
Winter=C2=A0 579 Park Place=C2=A0 Saline, MI=C2=A0= 48176=C2=A0 734-944-0094
Summer=C2=A0 PO Box 221=C2=A0 Grand Marais, MI= 49839=C2=A0 906-494-2434


On Mon, Aug 3, 2015 a= t 6:31 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:
=20 =20 =20
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 attribut= e 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.=C2=A0
Each should have different "grades".=C2=A0

Right now, -00 has:=C2=A0

3.1. Identity Proofing=C2=A0
3.2. Credential Management
3.3. Assertion Presentation=C2=A0

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.=C2=A0
Note: they are missing 3.4.=C2=A0

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

Best,=C2=A0

Nat




__________________________________________= _____
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot





--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--089e01227ba048f039051c70c31f-- From nobody Mon Aug 3 17:35:31 2015 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 To: 'Jim Fenton' , Nat Sakimura , Rainer Hoerbe Thread-Topic: [VoT] Vectors of Trust I-D feedback Thread-Index: AdDKgCb4PeFKa76GSTyFc+9OUdaFR5368U9Q Date: Tue, 4 Aug 2015 00:05:17 +0000 References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <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: Cc: "vot@ietf.org" , Justin Richer 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 00:35:29 -0000 --_000_569AD906E45DB44A8AFF11D61F5DA791014ADEF3DCWLGPRDMBX02di_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 hav= e 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 i= n 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 serie= s of aspects that must be added to the other Vectors. They may not be measu= rable, 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. Ji= m, 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 Ident= ity 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 circumsta= nces 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 sec= ure authentication, but why not just represent that as less secure authenti= cation? 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogonal to aut= hentication 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 o= ther day that Assertion Presentation should be visible to the RP already. F= or 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 a= ssertions to be presented to it, but that seems like more of a general opti= on 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 credenti= al 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 fra= mework, but that is not explicitly there. Best, Nat --_000_569AD906E45DB44A8AFF11D61F5DA791014ADEF3DCWLGPRDMBX02di_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ISO/IEC 29115 has been no= thing but a headache for me for a number of years.

 <= /p>

If we want to be evolutio= nary 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.=

 <= /p>

I am still out to lunch o= n Assertion Presentation. Just because it exists in my framework and has (t= hanks 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 asp= ects that must be added to the other Vectors. They may not be measurable, i= n which case they become guidance.

 <= /p>

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.

 <= /p>

Cheers<= /p>

 <= /p>

Joanne<= /p>

 <= /p>

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 wou= ld need to rename Identity Proofing as Enrolment, and Credential Usage as A= uthentication.

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 circumsta= nces a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Auth= entication. There are credential management practices that would make a cre= dential unsuitable for highly secure authentication, but why not just repre= sent 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogonal to aut= hentication 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 o= ther day that Assertion Presentation should be visible to the RP already. F= or 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 Vect= or.

-Jim

On 8/2/15 2:59 AM, Nat Sakimura wrote:

I agree that we should split out the credential mana= gement 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 doc= uments of the trust framework, 

but that is not explicitly there. 

 

Best, 

 

Nat

 

 

 

--_000_569AD906E45DB44A8AFF11D61F5DA791014ADEF3DCWLGPRDMBX02di_-- From nobody Mon Aug 3 17:53:50 2015 Return-Path: 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 ; 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 ; 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 ; Mon, 3 Aug 2015 17:53:46 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so143915554wib.0 for ; 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> <55BFEBC2.7070209@bluepopcorn.net> Date: Tue, 4 Aug 2015 09:53:44 +0900 Message-ID: From: Nat Sakimura To: Jim Fenton Content-Type: multipart/alternative; boundary=001a11c33bb0dbcb65051c71b758 Archived-At: Cc: Rainer Hoerbe , Justin Richer , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 00:53:49 -0000 --001a11c33bb0dbcb65051c71b758 Content-Type: text/plain; charset=UTF-8 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 : > 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 --001a11c33bb0dbcb65051c71b758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, X.1254 | ISO/IEC 29115 says:=C2=A0

  1. 8.1 =C2=A0Enrolment phase=C2=A0

  2. 8.2 =C2=A0Credential manage= ment phase=C2=A0

  3. 8.3 =C2=A0Entity authentication phase

    4. <= /ol>
It also has=C2=A0
=09 =09 =09

  1. 9 =C2=A0Management and organizational considerations.=C2=A0=

My point is that this I-D seems to use "Credential = Management" for "Entity Authentication" (BTW, at one point o= f the draft, it was called "Credential Usage", or at least, JP NB= proposed the name because this entire framework is "Entity Authentica= tion" 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 attribut= e 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.=C2=A0
Each should have different "grades".=C2=A0

Right now, -00 has:=C2=A0

3.1. Identity Proofing=C2=A0
3.2. Credential Management
3.3. Assertion Presentation=C2=A0

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.=C2=A0
Note: they are missing 3.4.=C2=A0

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

Best,=C2=A0

Nat






--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--001a11c33bb0dbcb65051c71b758-- From nobody Mon Aug 3 18:14:17 2015 Return-Path: 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 ; 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 ; 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 ; Mon, 3 Aug 2015 18:14:12 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so2907684wib.1 for ; 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> <55BFEBC2.7070209@bluepopcorn.net> <569AD906E45DB44A8AFF11D61F5DA791014ADEF3DC@WLGPRDMBX02.dia.govt.nz> Date: Tue, 4 Aug 2015 10:14:11 +0900 Message-ID: From: Nat Sakimura To: Joanne Knight Content-Type: multipart/alternative; boundary=f46d043893f9f616f5051c720081 Archived-At: Cc: Jim Fenton , Rainer Hoerbe , Justin Richer , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 01:14:16 -0000 --f46d043893f9f616f5051c720081 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 : > ISO/IEC 29115 has been nothing but a headache for me for a number of year= s. > > > > If we want to be evolutionary I would not constrain myself to trying to b= e > consistent with it =E2=80=93 especially since it is currently being revie= wed. 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 ti= me > 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 b= e > measurable, in which case they become guidance. > > > > As it was Nat who lit the spark that there is this other =E2=80=98thing= =E2=80=99 in the > mix, I am hoping for a flu free ISO meeting to have an academic brainstor= m. > 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 time= s > (or, in the case of Credential Management, over a long period of time) an= d > 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 a= re > credential management practices that would make a credential unsuitable f= or > highly secure authentication, but why not just represent that as less > secure authentication? VoT should be only as complex as required; it shou= ld > 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 o= f > 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 > > > > > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --f46d043893f9f616f5051c720081 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi.=C2=A0

I think X.1254 | ISO/IEC 2911= 5 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.=C2=A0

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 framew= ork should decide what needs to be verified to achieve "identity proof= ing." In the private sector usage, it may just be a validity of paymen= t instrument and contact method.=C2=A0

29115 is no= t being reviewed at this time. There is an SP but it is just an SP (study p= eriod) and not review. Review is supposed to start in December 2016.=C2=A0<= /div>

Sort of assertion presentation has been in SP800-6= 3 for sometime.=C2=A0
In the most recent one [SP800-63], it is cl= ause 9.=C2=A0





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

ISO/IEC 29115 has been no= thing but a headache for me for a number of years.

=C2=A0

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

=C2=A0

I am still out to lunch o= n Assertion Presentation. Just because it exists in my framework and has (t= hanks 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 asp= ects that must be added to the other Vectors. They may not be measurable, i= n which case they become guidance.

=C2=A0

As it was Nat who lit the= spark that there is this other =E2=80=98thing=E2=80=99 in the mix, I am ho= ping 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.

=C2=A0

Cheers

=C2=A0

Joanne

=C2=A0

From:= Jim Fenton [mailto:= fenton@bluepopc= orn.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

=C2=A0

To be entirely consistent with ISO/IEC 29115, we wou= ld need to rename Identity Proofing as Enrolment, and Credential Usage as A= uthentication.

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 circumsta= nces a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Auth= entication. There are credential management practices that would make a cre= dential unsuitable for highly secure authentication, but why not just repre= sent 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogona= l 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 al= ready. For example, if the assertion is encrypted in transit, the RP will k= now 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 Vect= or.

-Jim

On 8/2/15 2:59 AM, Nat Sakimura wrote:

I agree that we should split out the credential mana= gement and the credential usage.=C2=A0

Each should have different "grades".=C2=A0=

=C2=A0

Right now, -00 has:=C2=A0

=C2=A0

3.1. Identity Proofing=C2=A0
3.2. Credential Management
3.3. Assertion Presentation=C2=A0

=C2=A0

Instead, it could be

=C2=A0

3.1 Identity Proofing

3.2 Credential Management

3.3 Credential Usage

3.4 Assertion Presentation

=C2=A0

Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115= , which is good.=C2=A0

Note: they are missing 3.4.=C2=A0

=C2=A0

We also need to define vtm.=C2=A0

I imagine that vtm uri would point to the policy doc= uments of the trust framework,=C2=A0

but that is not explicitly there.=C2=A0

=C2=A0

Best,=C2=A0

=C2=A0

Nat

=C2=A0

=C2=A0

=C2=A0




--
Nat Sakimura (=3Dnat)
--f46d043893f9f616f5051c720081-- From nobody Mon Aug 3 18:24:40 2015 Return-Path: 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 8B1881A701E for ; Mon, 3 Aug 2015 18:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 pG_VBhfef6x9 for ; Mon, 3 Aug 2015 18:24:36 -0700 (PDT) Received: from atl4mhob01.myregisteredsite.com (atl4mhob01.myregisteredsite.com [209.17.115.39]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9A1A879B for ; Mon, 3 Aug 2015 18:24:35 -0700 (PDT) Received: from mailpod1.hostingplatform.com (atl4obmail04pod1.mgt.hosting.qts.netsol.com [10.30.71.116]) by atl4mhob01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t741OX1a020701 for ; Mon, 3 Aug 2015 21:24:33 -0400 Received: (qmail 27202 invoked by uid 0); 4 Aug 2015 01:24:33 -0000 X-TCPREMOTEIP: 71.255.164.247 X-Authenticated-UID: sal@idmachines.com Received: from unknown (HELO salPC) (sal@idmachines.com@71.255.164.247) by 0 with ESMTPA; 4 Aug 2015 01:24:32 -0000 From: "Salvatore D'Agostino" To: "'Nat Sakimura'" , "'Joanne Knight'" References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <55BFEBC2.7070209@bluepopcorn.net> <569AD906E45DB44A8AFF11D61F5DA791014ADEF3DC@WLGPRDMBX02.dia.govt.nz> In-Reply-To: Date: Mon, 3 Aug 2015 21:24:29 -0400 Message-ID: <026601d0ce54$5001bbd0$f0053370$@com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDOUuUYIuxBbguvS/yvPNzT0q92hwAAWRVg Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_025F_01D0CE32.C8394EF0" Archived-At: Cc: 'Jim Fenton' , 'Rainer Hoerbe' , 'Justin Richer' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 01:24:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_025F_01D0CE32.C8394EF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0260_01D0CE32.C8394EF0" ------=_NextPart_001_0260_01D0CE32.C8394EF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 =20 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 =20 Hi.=20 =20 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.=20 =20 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.=20 =20 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.=20 =20 Sort of assertion presentation has been in SP800-63 for sometime.=20 In the most recent one [SP800-63], it is clause 9.=20 =20 =20 [SP800-63] = http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf= ,=20 =20 =20 =20 2015-08-04 9:05 GMT+09:00 Joanne Knight : ISO/IEC 29115 has been nothing but a headache for me for a number of = years. =20 If we want to be evolutionary I would not constrain myself to trying to = be consistent with it =E2=80=93 especially since it is currently being = reviewed. I have also suggested that it look this way ;-) rather than = the other way around. =20 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. =20 As it was Nat who lit the spark that there is this other = =E2=80=98thing=E2=80=99 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. =20 Cheers =20 Joanne =20 From: Jim Fenton [mailto:fenton@bluepopcorn.net]=20 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 =20 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. =20 Each should have different "grades".=20 =20 Right now, -00 has:=20 =20 3.1. Identity Proofing=20 3.2. Credential Management 3.3. Assertion Presentation=20 =20 Instead, it could be =20 3.1 Identity Proofing 3.2 Credential Management 3.3 Credential Usage 3.4 Assertion Presentation =20 Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115, which is good.=20 Note: they are missing 3.4.=20 =20 We also need to define vtm.=20 I imagine that vtm uri would point to the policy documents of the trust = framework,=20 but that is not explicitly there.=20 =20 Best,=20 =20 Nat =20 =20 =20 =20 --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ------=_NextPart_001_0260_01D0CE32.C8394EF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

 

 

 

 

 

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

<= div>

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 =E2=80=93 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 = =E2=80=98thing=E2=80=99 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 = (=3Dnat)

Chairman, OpenID = Foundation
http://nat.sakimura.org/
@_nat_en

=
------=_NextPart_001_0260_01D0CE32.C8394EF0-- ------=_NextPart_000_025F_01D0CE32.C8394EF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ+jCCBTAw ggQYoAMCAQICEQC4wu85GwmiNlwDLceYGwvrMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMjQwMDAwMDBaFw0xNTEwMjQyMzU5NTla MCMxITAfBgkqhkiG9w0BCQEWEnNhbEBpZG1hY2hpbmVzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAKZhIgvX7iWpOOAeCHd0L3sRMWvDIH3eWcnEei4VBCb3GKEwTNzdBczr5hyD bHtij8zHn4WQtWoi+Eq3NUWN1YAPbkdSaYBiGcnwXucikNvt8Yk8wb456unIhQmQwRwrUtHXxJUq 1vZCJVpegl/jms01K4pUg3s7tN5fQitNNo8OePrO2wZ5/3qgYp4iqcsxDBv/u/8dq0vU2/uJL4aq 8yXqvbig/uWGLFiTyPia224VRyLjuDRfJ4F2mTS1NMlZodQfkS/PAZKyaCLXlV4GWT/HYR6ImVsa HgbYOUpM7/728WIvp5tkauc1y8w7NSkzLii292OSS9rnpWy8g48p5jECAwEAAaOCAegwggHkMB8G A1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQisqimHMrSWTmbZo0BmXYj g8ZZpjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB0GA1Ud EQQWMBSBEnNhbEBpZG1hY2hpbmVzLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAvFa8XUBHNrcw+VTz 0rhosO+YZdEYINo0IIzu3TfnjIN8CneO+5H/89e/aGJ+GRTXx0y+korvHGhyyGzWLrComdXyat1b Ove5WLJSY1WeouOoSlU1yYooZwioUeUDPG2Ccqyb+xGEN2yhDUoSMkrBDqpC5+4jwwAS8R8Zc9bk QguLalJy+OUcKkVh8CdXz9CbVjT60SWqqlDY5wJGu1jXKwBvxn0Epf/OEBo8f4LUj9uKqCIFvl4n Gat0hHIu35klUC576AvoixdHnn5v3TBLAF18czfTqzVNNNLZqCDhGmClJKuG11K9zgjdebiNLv5p FmVS2cUAT/LANw43e6sXlDCCBdgwggPAoAMCAQICEEyq+crbY2/gH/dO2FsDhp0wDQYJKoZIhvcN AQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8g UlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEwMDExOTAwMDAwMFoXDTM4MDExODIzNTk1 OVowgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNB IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA kehUktIKVrGsDSTdxc9EZ3SZKzejfSNwAHG8U9/E+ioSj0t/EFa9n3Byt2F/yUsPF6c947AEYe7/ EZfH9IY+Cvo+XPmT5jR62RRr55yzhaCCenavcZDX7P0N+pxs+t+wgvQUfvm+xKYvT3+Zf7X8Z0Ny vQwA1onrayzT7Y+YHBSrfuXjbvzYqOSSJNpDa2K4Vf3qwbxstovzDo2a5JtsaZn4eEgwRdWt4Q08 RWD8MpZRJ7xnw8outmvqRsfHIKCxH2XeSAi6pE6p8oNGN4Tr6MyBSENnTnIqm1y9TBsoilwie7Sr mNnu4FGDwwlGTm0+mfqVF9p8M1dBPI1R7Qu2XK8sYxrfV8g/vOldxJuvRZnio1oktLqpVj3Pb6r/ SVi+8Kj/9Lit6Tf7urj0Czr56ENCHonYhMsT8dm74YlguIwoVqwUHZwK53Hrzw7dPamWoUi9PPev tQ0iTMARgexWO/bTouJbt7IEIlKVgJNp6I5MZfGRAy1wdALqi2cVKWlSArvX31BqVUa/oKMoYX9w 0MOiqiwhqkfOKJwGRXa/ghgntNWutMtQ5mv0TIZxMOmm3xaG4Nj/QN370EKIf6MzOi5cHkERgWPO GHFrK+ymircxXDpqR+DDeVnWIBqv8mqYqnK8V0rSS527EPywTEHl7R09XiidnMy/s1Hap0flhFMC AwEAAaNCMEAwHQYDVR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBBjAP BgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBDAUAA4ICAQAK8dVGhLeuUbtssk1BFACTTJzL5cBU z6AljgL5/bCiDfUgmDwTLaxWorDWfhGS6S66ni6acrG9GURsYTWimrQWEmlajOHXPqQa6C8D9K5h HRAbKqSLesX+BabhwNbI/p6ujyu6PZn42HMJWEZuppz01yfTldo3g3Ic03PgokeZAzhd1Ul5ACkc x+ybIBwHJGlXeLI5/DqEoLWcfI2/LpNiJ7c52hcYrr08CWj/hJs81dYLA+NXnhT30etPyL2HI7e2 SUN5hVy665ILocboaKhMFrEamQroUyySu6EJGHUMZah7yyO3GsIohcMb/9ArYu+kewmRmGeMFAHN aAZqYyF1A4CIim6BxoXyqaQt5/SlJBBHg8rN9I15WLEGm+caKtmdAdeUfe0DSsrw2+ipAT71VpnJ Ho5JPbvlCbngT0mSPRaCQMzMWcbmOu0SLmk8bJWx/aode3+Gvh4OMkb7+xOPdX9Mi0tGY/4ANEBw wcO5od2mcOIEs0G86YCR6mSceuEiA6mcbm8OZU9sh4de826g+XWlm0DoU7InnUq5wHchjf+H8t68 jO8X37dJC9HybjALGg5Odu0R/PXpVrJ9v8dtCpOMpdDAth2+Ok6UotdubAvCinz6IPPE5OXNDajL kZKxfIXstRRpZg6C583OyC2mUX8hwTVThQZKXZ+tuxtfdDCCBeYwggPOoAMCAQICEGqb4Tg7/ytr nwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAw MDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1h bmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0w OwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDz JXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoym Mv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGt kGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VX j9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxS xt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYD VR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRy dXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcN AQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42aw GGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQe dXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j /Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEh Nhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoq NSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3f ciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icg c7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVz mehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdE ZOofSlZHynoSMYIEdDCCBHACAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAuMLvORsJojZcAy3HmBsL6zAJBgUrDgMCGgUAoIICmzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4MDQwMTI0MjlaMCMGCSqGSIb3DQEJBDEWBBQh Jis9+tBNRjD9kE0LsBdWIEGL6jCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJ YIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALjC7zkbCaI2XAMtx5gbC+sw gcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIRALjC7zkbCaI2XAMtx5gbC+swDQYJKoZIhvcNAQEBBQAEggEAAA1+hY5gT052eTxvPO1Z 6cZp5dcfNzAVeE4EXtRJwlR8jN3ybAJGoNTNP1+qEuL410MTywlwt5u0Q0vwTR2GfctVPn8728WT If6mEf/AP+foFf7m2s1M1unRv6wHl/F+q321iOcxT7NMUcmmxD95cU4K9eOgizH3EdW7ipuFfWxb om6I0W1Hk0bc272mjXo0HkLKA2mDDRMvalNgj424aV0IbsE05qL7+s3P2LNH929eK363a6a7lm13 wpuXXBbZrWobgduysohJ0qMLJ6xFmfdYqmt8yI39AHCrKEysFPF1zL66vqnbtSCVk37vN9lNKBmu P6kZ4JL0mRhjdw6kTAAAAAAAAA== ------=_NextPart_000_025F_01D0CE32.C8394EF0-- From nobody Mon Aug 3 23:12:35 2015 Return-Path: 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 BA51E1B3637 for ; Mon, 3 Aug 2015 23:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 YZ7Y_1gYXmCM for ; Mon, 3 Aug 2015 23:12:32 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) (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 CCF811B361D for ; Mon, 3 Aug 2015 23:12:31 -0700 (PDT) Received: from [81.217.70.83] (helo=[192.168.1.33]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1ZMVSh-0008Nv-1r; Tue, 04 Aug 2015 08:12:31 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Rainer Hoerbe In-Reply-To: <55BFEBC2.7070209@bluepopcorn.net> Date: Tue, 4 Aug 2015 08:12:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at> References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <55BFEBC2.7070209@bluepopcorn.net> To: Fenton Jim X-Mailer: Apple Mail (2.2102) X-Df-Sender: cmhAaWRlbnRpbmV0aWNzLmNvbQ== Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 06:12:33 -0000 Am 04.08.2015 um 00:31 schrieb Jim Fenton : >=20 > To be entirely consistent with ISO/IEC 29115, we would need to rename = Identity Proofing as Enrolment, and Credential Usage as Authentication. >=20 > 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. For a targeted attack the weak credential recovery will lower the = adversary=92s effort significantly, whereas in large numbers a 2F AuthN = combined will still reduce the overall risk. > 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. +1. However, I remember a discussion at IIW where someone argued that an = important use case for VoT is the combination of C4 (U2F) with P1 = (self-asserted) for social ids. But social networks are prioritizing = usability over security with a weak recovery mechanism. - Rainer From nobody Mon Aug 3 23:38:14 2015 Return-Path: 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 D7C521B365D for ; Mon, 3 Aug 2015 23:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 0OCgNml2ppjO for ; Mon, 3 Aug 2015 23:38:11 -0700 (PDT) Received: from www.sakimura.org (www.sakimura.org [52.69.28.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96DA61B365C for ; Mon, 3 Aug 2015 23:38:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (uid 33) by www.sakimura.org with local; Tue, 04 Aug 2015 06:39:57 +0000 id 00000000002437C1.0000000055C05E3D.00005546 To: vot@ietf.org X-PHP-Originating-Script: 0:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 04 Aug 2015 15:39:57 +0900 From: sakimura In-Reply-To: <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at> References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <55BFEBC2.7070209@bluepopcorn.net> <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at> Message-ID: <8fe18b4b73d09bd1f9820492acb46b7d@imap.gmail.com> X-Sender: sakimura@gmail.com User-Agent: Roundcube Webmail/0.9.5 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 06:38:13 -0000 2015-08-04 15:12 ã« Rainer Hoerbe ã•ã‚“ã¯æ›¸ãã¾ã—ãŸ: > Am 04.08.2015 um 00:31 schrieb Jim Fenton : >> >> To be entirely consistent with ISO/IEC 29115, we would need to rename >> Identity Proofing as Enrolment, and Credential Usage as >> Authentication. Actually, renaming it as Enrollment may have some merit. Identity Proofing is only a process within Enrollment. There are whole bunch of other stuff that has to happen then. Even if the Identity Proofing was done perfectly, if the act of creating the record to the identity register is broken, it is broken. >> >> 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. > For a targeted attack the weak credential recovery will lower the > adversary’s effort significantly, whereas in large numbers a 2F AuthN > combined will still reduce the overall risk. +1. That is one of the reason I feel it is worthwhile to differentiate them. > >> 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. > > +1. However, I remember a discussion at IIW where someone argued that > an important use case for VoT is the combination of C4 (U2F) with P1 > (self-asserted) for social ids. But social networks are prioritizing > usability over security with a weak recovery mechanism. In private sector, there are lots of cases where identity proofing in the traditional sense does not matter but the secure authentication matters. I actually co-authored a paper on it last month. > > - Rainer > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot From nobody Mon Aug 3 23:42:35 2015 Return-Path: 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 75ACE1B365E for ; Mon, 3 Aug 2015 23:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] 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 AnnGLSWA80Td for ; Mon, 3 Aug 2015 23:42:33 -0700 (PDT) Received: from www.sakimura.org (www.sakimura.org [52.69.28.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEAC1B365C for ; Mon, 3 Aug 2015 23:42:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (uid 33) by www.sakimura.org with local; Tue, 04 Aug 2015 06:44:19 +0000 id 00000000002437C1.0000000055C05F43.0000561C To: vot@ietf.org X-PHP-Originating-Script: 0:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 04 Aug 2015 15:44:19 +0900 From: sakimura In-Reply-To: <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at> References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <55BFEBC2.7070209@bluepopcorn.net> <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at> Message-ID: X-Sender: sakimura@gmail.com User-Agent: Roundcube Webmail/0.9.5 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 06:42:34 -0000 2015-08-04 15:12 ã« Rainer Hoerbe ã•ã‚“ã¯æ›¸ãã¾ã—ãŸ: > Am 04.08.2015 um 00:31 schrieb Jim Fenton : >> >> To be entirely consistent with ISO/IEC 29115, we would need to rename >> Identity Proofing as Enrolment, and Credential Usage as >> Authentication. Actually, renaming it as Enrollment may have some merit. Identity Proofing is only a process within Enrollment. There are whole bunch of other stuff that has to happen then. Even if the Identity Proofing was done perfectly, if the act of creating the record to the identity register is broken, it is broken. >> >> 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. > For a targeted attack the weak credential recovery will lower the > adversary’s effort significantly, whereas in large numbers a 2F AuthN > combined will still reduce the overall risk. +1. That is one of the reason I feel it is worthwhile to differentiate them. > >> 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. > > +1. However, I remember a discussion at IIW where someone argued that > an important use case for VoT is the combination of C4 (U2F) with P1 > (self-asserted) for social ids. But social networks are prioritizing > usability over security with a weak recovery mechanism. In private sector, there are lots of cases where identity proofing in the traditional sense does not matter but the secure authentication matters. I actually co-authored a paper on it last month. > > - Rainer > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot From nobody Tue Aug 4 00:07:10 2015 Return-Path: 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 47A861B3694 for ; Tue, 4 Aug 2015 00:07:09 -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 KBnCkGgDPhcj for ; Tue, 4 Aug 2015 00:07:07 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 C620D1B3693 for ; Tue, 4 Aug 2015 00:07:06 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so136169156wic.1 for ; Tue, 04 Aug 2015 00:07:05 -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 :content-type; bh=XV71dqqHRSI+e26ktjQ5MdvQxQ0e/d/gIZOhTxiexNY=; b=KewD9+1nw+4Ssmv0z6CvuPkuls6Yx6tu9JW5Q7WZcCE1V9TtUNXcCt1aiDIopOvoKb CdenWKrkZ8qbBBC0L/ftJjBZTexhjCpBtOwyO+MRWtQI83iFH1TVvbdqsQyDRHlT1Y+7 aKBjBwB/MUL5HHns8IG+VZ8cdkOAcxaIQmuSr4E1yxqwinDLZP0UUT4IjThJ/2r8LVzX 4VJqNyhn6hvPw5JYLKkFPePetbXs2ewj1NIIk839D/L4si3Z/AaLPlF5wReMWO1paS2H C+/w6foZS7YwRJGVIxDxcZxpsf4vRb9o8wdW2K784wZ1UGbxny8uHeGnSSdk2SPrdbxg Z+Rg== MIME-Version: 1.0 X-Received: by 10.194.206.65 with SMTP id lm1mr4726631wjc.117.1438672025547; Tue, 04 Aug 2015 00:07:05 -0700 (PDT) Received: by 10.28.144.85 with HTTP; Tue, 4 Aug 2015 00:07:05 -0700 (PDT) In-Reply-To: References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <55BFEBC2.7070209@bluepopcorn.net> <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at> Date: Tue, 4 Aug 2015 16:07:05 +0900 Message-ID: From: Nat Sakimura To: "vot@ietf.org" Content-Type: multipart/alternative; boundary=047d7b8739d207fa89051c76ef19 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 07:07:09 -0000 --047d7b8739d207fa89051c76ef19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I have been experiencing network problems that the signal went up / down many times. Apparently, the web mail was reloading each time that happened and somehow sending out the message each time. I sincerely apologize it. Nat 2015-08-04 15:44 GMT+09:00 sakimura : > 2015-08-04 15:12 =E3=81=AB Rainer Hoerbe =E3=81=95=E3=82=93=E3=81=AF=E6= =9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F: > >> Am 04.08.2015 um 00:31 schrieb Jim Fenton : >> >>> >>> To be entirely consistent with ISO/IEC 29115, we would need to rename >>> Identity Proofing as Enrolment, and Credential Usage as Authentication. >>> >> > Actually, renaming it as Enrollment may have some merit. Identity Proofin= g > is only a process within Enrollment. > There are whole bunch of other stuff that has to happen then. > Even if the Identity Proofing was done perfectly, if the act of creating > the record to the identity register is broken, it is broken. > > >>> 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 w= hich >>> circumstances a Relying Party would act differently to an indication of >>> less secure Credential Management vs. less secure Authentication. >>> >> For a targeted attack the weak credential recovery will lower the >> adversary=E2=80=99s effort significantly, whereas in large numbers a 2F = AuthN >> combined will still reduce the overall risk. >> > > +1. That is one of the reason I feel it is worthwhile to differentiate > them. > > >> 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 relyi= ng >>> party does not need. >>> >> >> +1. However, I remember a discussion at IIW where someone argued that >> an important use case for VoT is the combination of C4 (U2F) with P1 >> (self-asserted) for social ids. But social networks are prioritizing >> usability over security with a weak recovery mechanism. >> > > In private sector, there are lots of cases where identity proofing in the > traditional sense does not > matter but the secure authentication matters. I actually co-authored a > paper on it last month. > > >> - Rainer >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b8739d207fa89051c76ef19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I have been experiencing network problems that the = signal went up / down many times.=C2=A0
Apparently, the web mail was re= loading each time that happened and somehow sending out the message each ti= me.=C2=A0

I sincerely apologize it.=C2=A0

Nat

2015-08-04 15:44 GMT+09:00 sakimura <= sakimura@gmail.com<= /a>>:
2015-08-= 04 15:12 =E3=81=AB Rainer Hoerbe =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81= =8D=E3=81=BE=E3=81=97=E3=81=9F:
Am 04.08.2015 um 00:31 schrieb Jim Fenton <fenton@bluepopcorn.net>:

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

Actually, renaming it as Enrollment may have some merit. Identity Proofing = is only a process within Enrollment.
There are whole bunch of other stuff that has to happen then.
Even if the Identity Proofing was done perfectly, if the act of creating th= e record to the identity register is broken, it is broken.


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 circumsta= nces a Relying Party would act differently to an indication of less secure = Credential Management vs. less secure Authentication.
For a targeted attack the weak credential recovery will lower the
adversary=E2=80=99s effort significantly, whereas in large numbers a 2F Aut= hN
combined will still reduce the overall risk.

+1. That is one of the reason I feel it is worthwhile to differentiate them= .


There are credential management practices that would make a credential unsu= itable 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.

+1. However, I remember a discussion at IIW where someone argued that
an important use case for VoT is the combination of C4 (U2F) with=C2=A0 P1<= br> (self-asserted) for social ids. But social networks are prioritizing
usability over security with a weak recovery mechanism.

In private sector, there are lots of cases where identity proofing in the t= raditional sense does not
matter but the secure authentication matters. I actually co-authored a pape= r on it last month.


- Rainer

_______________________________________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--047d7b8739d207fa89051c76ef19-- From nobody Tue Aug 4 03:53:18 2015 Return-Path: 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 95EDE1B379F for ; Tue, 4 Aug 2015 03:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 8TLAVzNaUuFd for ; Tue, 4 Aug 2015 03:53:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0059.outbound.protection.outlook.com [65.55.169.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680201B379C for ; Tue, 4 Aug 2015 03:53:11 -0700 (PDT) Received: from SN1PR06MB1839.namprd06.prod.outlook.com (10.162.133.18) by SN1PR06MB1840.namprd06.prod.outlook.com (10.162.133.15) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 10:53:07 +0000 Received: from SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) by SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 10:53:07 +0000 From: Robin Wilton To: "vot@ietf.org" Thread-Topic: Credential usage, presentation and verification Thread-Index: AQHQzqO/oFoecV6rT0ilHVMwCwr8Vg== Date: Tue, 4 Aug 2015 10:53:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [94.174.34.240] x-microsoft-exchange-diagnostics: 1; SN1PR06MB1840; 5:KegUn13N49xP/N+CxtzqEzRrF6EiMYC30i51bKsKdSRetyL5fxrWYTkwkvGiaK51sHInrLiEQEEK7SLuzJcI0R+pRwCh4cd/+myZlm1CyZBwSbHO/7JV9WQTzRx3SM91z5L07QBrWCYBLzhthDJZfQ==; 24:k2L3nxR6nzE52DnAKPTSZ8d7/aBQyEvN26p91923Y3go70jLltmoVCeOM6hhRqdhJVXtD72IKsTVPugmNyDFhkzfQsglEjztbJ58DQ0Zgjo=; 20:TnnvI2sRVyrOW6DFM7sQvh10+9qpz/G+zG38Fe2H4ClJtSPwr4a4JvOOgc/ptzvGOE+m9twXPjdhu8VgIkCiXw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB1840; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR06MB1840; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1840; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(243025005)(124975003)(199003)(189002)(377454003)(24454002)(501624003)(377424004)(479174004)(66066001)(87936001)(76176999)(110136002)(54356999)(106356001)(5001960100002)(86362001)(105586002)(2351001)(68736005)(19617315012)(102836002)(16236675004)(106116001)(107886002)(36756003)(64706001)(99286002)(229853001)(2501003)(5001830100001)(2420400006)(5001860100001)(77096005)(77156002)(189998001)(62966003)(50986999)(101416001)(82746002)(81156007)(19580405001)(46102003)(33656002)(83716003)(97736004)(15975445007)(4001540100001)(2656002)(2900100001)(92566002)(122556002)(2950100001)(5002640100001)(19580395003)(40100003)(99936001)(450100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1840; H:SN1PR06MB1839.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/signed; boundary="Apple-Mail=_FEC0EE2E-AE56-48B5-A825-2516C089ECC2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 10:53:07.5344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1840 Archived-At: Subject: [VoT] Credential usage, presentation and verification X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 10:53:17 -0000 --Apple-Mail=_FEC0EE2E-AE56-48B5-A825-2516C089ECC2 Content-Type: multipart/alternative; boundary="Apple-Mail=_BE593D21-E1CD-4C18-8956-DB68E67675FD" --Apple-Mail=_BE593D21-E1CD-4C18-8956-DB68E67675FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Apologies for top-posting, but I wanted to make some comments which = refer partly to both Joanne=92s and Jim=92s preceding posts, and there = wasn=92t a neat way to do so inline. If you look at the whole credential lifecycle, there are trust factors = (not vectors!) throughout it. VoT looks at a subset of them: - how reliably the issuing party establishes the identity of the = applicant; - how strongly the credential is bound to the applicant; - how reliably the credential is presented. However, there are significant trust factors at other stages in the = lifecycle: - how reliably the credential is verified when it is presented (by = analogy, think of the cursory check a retail clerk gives your = =93signature=94 compared to the one on your credit card) - how robust the processes are for amending, revoking and/or destroying = a credential. Of these two, the second could be put neatly under the heading of = =93credential management=94 and represented by the same vector. The first (reliability of the credential verification process upon = presentation) is harder to account for, and I think this is because it = is generally partly or wholly outside the control of the IDP. (Again, by = analogy, think of Point of Sale terminals; these are, essentially, an = attempt by the IDP [card issuer] to retain control over the verification = step, essentially taking the RP out of the loop. But they do so at the = cost of significant effort, and the =91remote=92 part of the process is = still susceptible to subversion.) I am not yet sure it can be sensibly formalised in a vector - but I = think it=92s worth considering, because it=92s a significant trust = factor in the over-all lifecycle. Here=92s a straw-man use case, just to kick around=85 An IDP issues electronic credentials, and offers RPs a range of = verification alternatives: when one of our credentials is presented, 3 - you will verify it using a black box that we require you to install = at your premises, and which not only checks the credential itself, it = also =93phones home=94 to do a real-time revocation check or 2 - there=92s no black box; we will provide you with a software = verification module that you run, to verify the credential and do a = revocation check or 1 - we=92ll expose a web services API at our end, for credential = verification and revocation status or 0 - we just issue the credentials; how you verify them on presentation = is up to you The IDP=92s liability model would vary accordingly. One issue with this straw-man is that the IDP is telling the RP stuff = that they both already know=85 On the other hand, exchanging a message to that effect does create an = audit trail, which might be useful for compliance purposes. Any thoughts? R >=20 > From: Joanne Knight > Subject: Re: [VoT] Vectors of Trust I-D feedback > Date: 4 August 2015 01:05:17 BST > To: 'Jim Fenton' , Nat Sakimura = , Rainer Hoerbe > Cc: "vot@ietf.org" , Justin Richer >=20 >=20 > ISO/IEC 29115 has been nothing but a headache for me for a number of = years. >=20 > If we want to be evolutionary I would not constrain myself to trying = to be consistent with it =96 especially since it is currently being = reviewed. I have also suggested that it look this way ;-) rather than = the other way around. >=20 > 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. >=20 > As it was Nat who lit the spark that there is this other =91thing=92 = 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. >=20 > Cheers >=20 > Joanne >=20 > 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 >=20 > To be entirely consistent with ISO/IEC 29115, we would need to rename = Identity Proofing as Enrolment, and Credential Usage as Authentication. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > -Jim >=20 > 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". >=20 > Right now, -00 has: >=20 > 3.1. Identity Proofing > 3.2. Credential Management > 3.3. Assertion Presentation >=20 > Instead, it could be >=20 > 3.1 Identity Proofing > 3.2 Credential Management > 3.3 Credential Usage > 3.4 Assertion Presentation >=20 > Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115, which is good. > Note: they are missing 3.4. >=20 > 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. >=20 > Best, >=20 > Nat >=20 >=20 >=20 >=20 >=20 >=20 > From: Nat Sakimura > Subject: Re: [VoT] Vectors of Trust I-D feedback > Date: 4 August 2015 01:53:44 BST > To: Jim Fenton > Cc: Rainer Hoerbe , Justin Richer , = "vot@ietf.org" >=20 >=20 > Right, X.1254 | ISO/IEC 29115 says: > 8.1 Enrolment phase >=20 > 8.2 Credential management phase >=20 > 8.3 Entity authentication phase >=20 > It also has > 9 Management and organizational considerations. >=20 > 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.) >=20 > 2015-08-04 7:31 GMT+09:00 Jim Fenton : > To be entirely consistent with ISO/IEC 29115, we would need to rename = Identity Proofing as Enrolment, and Credential Usage as Authentication. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > -Jim >=20 > 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". >>=20 >> Right now, -00 has: >>=20 >> 3.1. Identity Proofing >> 3.2. Credential Management >> 3.3. Assertion Presentation >>=20 >> Instead, it could be >>=20 >> 3.1 Identity Proofing >> 3.2 Credential Management >> 3.3 Credential Usage >> 3.4 Assertion Presentation >>=20 >> Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115, which is good. >> Note: they are missing 3.4. >>=20 >> 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. >>=20 >> Best, >>=20 >> Nat >>=20 >>=20 >=20 >=20 >=20 >=20 > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 >=20 > From: Nat Sakimura > Subject: Re: [VoT] Vectors of Trust I-D feedback > Date: 4 August 2015 02:14:11 BST > To: Joanne Knight > Cc: Jim Fenton , Rainer Hoerbe = , Justin Richer , "vot@ietf.org" = >=20 >=20 > Hi. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Sort of assertion presentation has been in SP800-63 for sometime. > In the most recent one [SP800-63], it is clause 9. >=20 >=20 > [SP800-63] = http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf,= >=20 >=20 >=20 > 2015-08-04 9:05 GMT+09:00 Joanne Knight : > ISO/IEC 29115 has been nothing but a headache for me for a number of = years. >=20 > If we want to be evolutionary I would not constrain myself to trying = to be consistent with it =96 especially since it is currently being = reviewed. I have also suggested that it look this way ;-) rather than = the other way around. >=20 > 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. >=20 > As it was Nat who lit the spark that there is this other =91thing=92 = 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. >=20 > Cheers >=20 > Joanne >=20 > 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 >=20 > To be entirely consistent with ISO/IEC 29115, we would need to rename = Identity Proofing as Enrolment, and Credential Usage as Authentication. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > -Jim >=20 > 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". >=20 > Right now, -00 has: >=20 > 3.1. Identity Proofing > 3.2. Credential Management > 3.3. Assertion Presentation >=20 > Instead, it could be >=20 > 3.1 Identity Proofing > 3.2 Credential Management > 3.3 Credential Usage > 3.4 Assertion Presentation >=20 > Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115, which is good. > Note: they are missing 3.4. >=20 > 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. >=20 > Best, >=20 > Nat >=20 >=20 >=20 >=20 >=20 >=20 > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --Apple-Mail=_BE593D21-E1CD-4C18-8956-DB68E67675FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Apologies for top-posting, but I wanted to make some = comments which refer partly to both Joanne=92s and Jim=92s preceding = posts, and there wasn=92t a neat way to do so = inline.

If you look at the whole credential = lifecycle, there are trust factors (not vectors!) throughout it. VoT = looks at a subset of them:
- how reliably the issuing party = establishes the identity of the applicant;
- how strongly the = credential is bound to the applicant;
- how reliably the = credential is presented.

However, there are = significant trust factors at other stages in the = lifecycle:

- how reliably the credential is = verified when it is presented (by analogy, think of the cursory check a = retail clerk gives your =93signature=94 compared to the one on your = credit card)
- how robust the processes are for amending, = revoking and/or destroying a credential.

Of = these two, the second could be put neatly under the heading of = =93credential management=94 and represented by the same = vector.

The first (reliability of the = credential verification process upon presentation) is harder to account = for, and I think this is because it is generally partly or wholly = outside the control of the IDP. (Again, by analogy, think of Point of = Sale terminals; these are, essentially, an attempt by the IDP [card = issuer] to retain control over the verification step, essentially taking = the RP out of the loop. But they do so at the cost of significant = effort, and the =91remote=92 part of the process is still susceptible to = subversion.)

I am not yet sure it can be = sensibly formalised in a vector - but I think it=92s worth considering, = because it=92s a significant trust factor in the over-all = lifecycle.

Here=92s a straw-man use case, just = to kick around=85

An IDP issues electronic = credentials, and offers RPs a range of verification = alternatives:

when one of our credentials is = presented, 

3 - you will verify it using a = black box that we require you to install at your premises, and which not = only checks the credential itself, it also =93phones home=94 to do a = real-time revocation check
or

2 - = there=92s no black box; we will provide you with a software verification = module that you run, to verify the credential and do a revocation = check 
or

1 - we=92ll expose a = web services API at our end, for credential verification and revocation = status
or 

0 - we just issue the = credentials; how you verify them on presentation is up to = you


The IDP=92s = liability model would vary = accordingly. 

One issue with this = straw-man is that the IDP is telling the RP stuff that they both already = know=85 
On the other hand, exchanging a message to that = effect does create an audit trail, which might be useful for compliance = purposes.


Any = thoughts?


R

  

From: Joanne Knight <Joanne.Knight@dia.govt.nz>
Subject: Re: [VoT] Vectors of Trust I-D = feedback
Date: 4 August 2015 01:05:17 = BST
To: 'Jim Fenton' <fenton@bluepopcorn.net>, Nat = Sakimura <sakimura@gmail.com>, Rainer = Hoerbe <rainer@hoerbe.at>
Cc: "vot@ietf.org" = <vot@ietf.org>, Justin Richer <jricher@mit.edu>


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 =96 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 =91thing=92 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
 
 
 



From: Nat Sakimura <sakimura@gmail.com>
Subject: Re: [VoT] Vectors of Trust I-D = feedback
Date: 4 August 2015 01:53:44 = BST
To: Jim Fenton <fenton@bluepopcorn.net>
Cc: Rainer Hoerbe <rainer@hoerbe.at>, Justin Richer = <jricher@mit.edu>, "vot@ietf.org" <vot@ietf.org>


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 (=3Dnat)
Chairman, OpenID = Foundation
http://nat.sakimura.org/
@_nat_en

=

From: Nat Sakimura <sakimura@gmail.com>
Subject: Re: [VoT] Vectors of Trust I-D = feedback
Date: 4 August 2015 02:14:11 = BST
To: Joanne Knight <Joanne.Knight@dia.govt.nz>
Cc: Jim Fenton <fenton@bluepopcorn.net>, Rainer = Hoerbe <rainer@hoerbe.at>, Justin Richer = <jricher@mit.edu>, "vot@ietf.org" <vot@ietf.org>


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. 





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 =96 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 =91thing=92 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 (=3Dnat)
Chairman, OpenID = Foundation
http://nat.sakimura.org/
@_nat_en

=
_______________________________________________
vot mailing = list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot

= --Apple-Mail=_BE593D21-E1CD-4C18-8956-DB68E67675FD-- --Apple-Mail=_FEC0EE2E-AE56-48B5-A825-2516C089ECC2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlXAmgoACgkQx1kEWLxmyT3s/ACeIu4FsOaIF3d64tqPuW2vPQJk nmAAn3mVWLTefP3MA3+UoWpBm55FNs69 =oGld -----END PGP SIGNATURE----- --Apple-Mail=_FEC0EE2E-AE56-48B5-A825-2516C089ECC2-- From nobody Tue Aug 4 05:46:29 2015 Return-Path: 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 7E3A71A8938 for ; Tue, 4 Aug 2015 05:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 KuIObsO6rgRz for ; Tue, 4 Aug 2015 05:46:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0075.outbound.protection.outlook.com [207.46.100.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D9F1A88C5 for ; Tue, 4 Aug 2015 05:46:25 -0700 (PDT) Received: from BLUPR0601MB1667.namprd06.prod.outlook.com (10.163.212.149) by BLUPR0601MB1668.namprd06.prod.outlook.com (10.163.212.15) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 12:46:20 +0000 Received: from BLUPR0601MB1667.namprd06.prod.outlook.com ([10.163.212.149]) by BLUPR0601MB1667.namprd06.prod.outlook.com ([10.163.212.149]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 12:46:20 +0000 From: Steve Olshansky To: "vot@ietf.org" Thread-Topic: Notes: VoT BoF 22-July-2015 (@IETF93, Prague) Thread-Index: AQHQzrOP4QkuhYTRVES4C9PXihEkJA== Date: Tue, 4 Aug 2015 12:46:19 +0000 Message-ID: <4E082799-7ECC-402F-AD7C-DD0773F19E96@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=olshansky@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [70.59.29.196] x-microsoft-exchange-diagnostics: 1; BLUPR0601MB1668; 5:Ej/cnulbD5zmXK6sY/gyDulAz5ABoLhR2BQ5y5mS0sGM5Jpgsxsi2kcWEfVZpuj8Jfv8yDMDfDkEtPDjfBB0pJ+HArKm8/gkCmuX4cwDqLQaBWHCACqZXGvBFPFIxxShttm2nGsxM+PZIAU39MAnIg==; 24:bwJDSQpIeO56D2/hDW01aJ9VkJfynyq75CfDb/56o1q0QiXIWeQoz0hIGfiCxqEsorPFbjB9KAWrIpqKw1nJs3ESo76BvgYqY8ABRZp50SA=; 20:GTR/njek3JCViKiwMq35J1xyJ0pAnESvGYyAOH5FSYJoX61bFuKvHV9Itf2UVqu3f6NgQ4fdnKIIrmN3kH10yA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0601MB1668; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR0601MB1668; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0601MB1668; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51444003)(199003)(189002)(2351001)(105586002)(36756003)(99936001)(50986999)(229853001)(101416001)(450100001)(122556002)(2900100001)(40100003)(99286002)(62966003)(551934003)(77156002)(46102003)(68736005)(2656002)(77096005)(106116001)(102836002)(54356999)(15975445007)(106356001)(230783001)(81156007)(82746002)(2501003)(92566002)(4001540100001)(33656002)(83716003)(5001860100001)(15974865002)(5001830100001)(64706001)(5002640100001)(19580395003)(97736004)(110136002)(66066001)(86362001)(5001920100001)(189998001)(5001960100002)(107886002)(87936001)(104396002)(18886075002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0601MB1668; H:BLUPR0601MB1667.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/signed; boundary="Apple-Mail=_D94C456D-7157-4AEF-BA88-F5CB842D6A1B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 12:46:19.8472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0601MB1668 Archived-At: Subject: [VoT] Notes: VoT BoF 22-July-2015 (@IETF93, Prague) X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 12:46:28 -0000 --Apple-Mail=_D94C456D-7157-4AEF-BA88-F5CB842D6A1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 VoT BoF: 22-July-2015 (@IETF93, Prague) ***NOTE on making changes to the ID*** =3D> While discussion about the ID on the list is interesting and useful = for fleshing out the issues, ultimately the only things that will impact = the draft are actual suggested text to add or change. We can use the = existing GitHub tracker: https://github.com/vectorsoftrust/strawman/issues And we will use the this mailing list as the side-channel at least for = now, for those uncomfortable with using GitHub. =20 *Attending* Remote: Jim Fenton, Colin Wallis, Nov Matake=20 In the room: Leif Johansson, Steve Olshansky, Justin Richer, Robin = Wilton, Karen O=E2=80=99Donoghue, Nat Sakimura=20 *Action Items* [AI_1] (Justin) rev the ID (at least) once more, including adding more = explanatory text [AI_2] (Steve) set up liaison relationships with other SDOs to encourage = participation *Discussion* Nat: (ITU-T) X.1254 and (ISO/IEC) 29115 tackle the issue of common trust = frameworks and defined policies, across different jurisdictions, already = and are more accommodating than 800-63. We should look at those to see = if there is anything we can use or refer to. Justin: NIST needs a mechanism for conveying the various categories = separately Vectors need to be evaluated by RP in a context. How simple can we make = this work, without it being too simple? Unbundling attributes leads to expressing them as vectors and not LoA COMMENTS - responses - Default values have led to some objections, but they are simply = a starting point - orthogonality =E2=80=93 the vectors should not overlap, but = should be conceptually as different from each other as possible - VoT should be an expression construct for these types of = semantics - we need guidance language re what orthogonality means in this = context =E2=80=93 these things are not completely orthogonal Nat: in P3, legal contractual relationship is not quite identity = proofing Justin: feedback from Kantara in other contexts was related to legally = binding relationship with a person, e.g. for payroll Leif: we can tweak the language to reflect this. Another category / = vector could be degree of liability protection. Does this merit = inclusion in the core, v. as an extension? Attestation of proofing is contextual to authn, otherwise you are = leaking private info.=20 Keep in mind that the goal here is targeted to provide context for user = authn =E2=80=93 how certain am I that this person is identified = correctly, and how certain can you be in my assertion about this? Robin: extensions can lead to breaking down into pairwise agreements = between stakeholders, and for liability this would be a good thing. If user is presenting same credential, do we want system to assert = different VoT? Justin: OpenID Connect (OIC) has notion of pairwise identifiers, and = regardless of assurances that IdP has about me binding to an account it = will not convey that because I told it not to =E2=80=93 high assurance = anonymous transaction Robin: re: credential lifecycle, verification and enrollment, how = reliable is this, and can the credential be forged or tampered with in = presentation? A typical =E2=80=98credential lifecycle=E2=80=99 model runs like this: 1. Do identity proofing, verification and enrolment; 2. Bind credential to user (e.g. through biometrics, shared secret, = etc.) 3. Issue credential (hopefully a nice robust one that is hard to = forge/tamper with) 4. Credential gets presented by the user 5. Credential gets verified by RPs 6. Credential may get modified/updated by issuer 7. Credential may get revoked/reactivated 8. Credential destruction The VoT model specifies the attributes IDPs and RPs can exchange = concerning steps 1, 2 and 4. My question was about the reliability of step 5. By analogy: when your bank issues you with a payment card, they can be = reasonably confident that they are issuing it to the right account = holder; they can assume that when you sign it, you sign it with your own = signature, and that you make the same signature when you=E2=80=99re = buying something (that=E2=80=99s steps 1, 2 and 4). But retail staff = never do a good job of comparing your signature to what=E2=80=99s on the = card=E2=80=A6 so the model breaks down at step 5. Robin: In the current draft, the vector message and the trustmark = message both use the same variable labels (iss and sub), even though the = labels refer to different things in the two types of message. I think = that=E2=80=99s likely to lead to confusion, and sooner of later to = someone making a coding/verification error. C =3D primary credential A =3D derived federated credential Trustmarks will provide ultimate definitions of the vectors=E2=80=A6 We need a way to handle: - account chooser - liability expressions - (+what else?) Nat: why not just use existing documents like 29115 for definitions? Justin: this is what we want people to use in the real world. Doc has = general case examples. We could use these other definitions, but making = them up forces people to think about them rather than lazily just using = ours. Ultimately we could certainly do that if that makes more sense. = eIDAS is referencing 29115. Colin: suggest adding a cookbook or appendix referencing definitions = from other sources Q: where should the syntax pieces live? IANA registry?=20 2 dimensions to this work at a high level: 1. what are the categories? 2. what should be in them, are they ordered, does order matter? Solution could be to =E2=80=9Clead by example=E2=80=9D in the document = and expect people to adapt to their own needs Q: Do we want to have one trustmark definition across entire vector, or = should that be separable as well into components? J: yes just one, send a URI for each vector Robin: In IoT we will have a number of things talking to each other, = each with its own baggage of T&Cs. So expecting RP to look each one up = is not realistic Notwithstanding the questions of where this work should take place,=20 would it make sense to setup liaison relationships to other SDOs to = encourage participation? Q: Do we have right expertise within the IETF community? The general sentiment in the room was =E2=80=9Cnot quite.=E2=80=9D Note = that this work originated from discussion at an Internet Society = workshop held last September. While the mailing list is hosted by IETF, = and this work *may* at some point make its way toward becoming a = chartered working group there, setting up an IETF non-working group = mailing list for this work was a choice made as a matter of convenience = at the beginning of this effort, and due to a friendly IPR framework. = That being said, there is no reason that this work couldn=E2=80=99t or = shouldn=E2=80=99t move to another forum at some point if that seems = beneficial. Thus, in order to mitigate the fact that the IETF community may not have = the right expertise, and toward obtaining the best result from our work, = we reached the conclusion that creating liaison relationship with other = SDOs like ISO and ITU-T would be a good idea, so that we can leverage = their knowledge and experience in this work=20 [AI_2] (Steve) set up liaison relationships with other SDOs to encourage = participation =20 -- Steve Olshansky Trust & Identity Program Lead Internet Society www.internetsociety.org --Apple-Mail=_D94C456D-7157-4AEF-BA88-F5CB842D6A1B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBTwwggQkoAMCAQICEQCsrNI8U0nhrK796HidRQx9MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTUwNTA2MDAwMDAwWhcNMTYw NTA1MjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJvbHNoYW5za3lAaXNvYy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMErOndCeIY2bRe4mefO5/p2NPVcaCzo12LD9996nVtwRr BL2FAfWYVzBiC0C8L81aIpDappBhENRKTevBNw9KeLer8Tmp9/9sV26n3TyO5WPYMV7kZCBkOmfM 2o3+A+X81f4VebmgMvyoUNu+Lyh1fmms+MMUJOwHq5iWNIPuX0l6mtU+NJR8TswzDwzNVxmyB8oG YzurKm/2b/Mx1zb6t6xR5/5isP5K0Jy45weVx3pihINUwOjhV7/C8j6WUE4yYU+49r5+UJ+RnZEU CHirAJ8CpcYEsatadqUHHDwTsBHF/bmGreaGwsa+0gE2BM4Jp3s19+xPKVl7MwmXg3i5AgMBAAGj ggHwMIIB7DAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUAktCJg7A cCMvkRujhVOUz8Mg1RowDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsG AQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGll bnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSBgzCBgDBY BggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0 aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au Y29tb2RvY2EuY29tMB0GA1UdEQQWMBSBEm9sc2hhbnNreUBpc29jLm9yZzANBgkqhkiG9w0BAQsF AAOCAQEAMA/TS/muw/+D72S5R/a3y76O8zUw9ovpTFtjiEsEvc86qpJ9U8/yZxbK8uBh8t1E4zVo w9V0QyqmbomTSHi2hwF8F7tbiyl6bqR3SWsM1rvdLjP2vvUcWLsfsFS+pA3vzXH2Kqkyt52DYmnL xPrKi0sWVH+OP8hhtKM0EtBWIxMlSViDuGvQryuf0+UKE/ZsEPW4kjFqCd+W9HhRQKALbORECs/X W284KLr9gDaP70bebYyNX4w5RcT0Zp/u6XA7Z/jUd1BcQ+e4+GRnL7655nBcyibYM4wlBargN07w g7+Uxzd4sqBwRFjxJ0ZbBnaCxTn1MpKbuWwOxc0yZfyWTzGCA8YwggPCAgEBMIGxMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCsrNI8U0nhrK796HidRQx9MAkG BSsOAwIaBQCgggHpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDgwNDEyNDYyMVowIwYJKoZIhvcNAQkEMRYEFMk5nQvtzksU0viqaqkwyr+i8f6aMIHCBgkrBgEE AYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AKys0jxTSeGsrv3oeJ1FDH0wgcQGCyqGSIb3DQEJEAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCsrNI8U0nhrK796HidRQx9MA0GCSqGSIb3DQEB AQUABIIBAJb8OycVa5uVAlbUqA/5eELlYzSOK3wK6on7eFxSQXH/LRIOb61C/tao0mLr5fY8vH33 ezI84xrqWBGBb13eGI5kAEyx83IMGpAX/7MGTpRh/lkMXBPOtJ7ig6LXSPB86feRG+/5eqg//XOo ORuddc8F2wmpwCZ8YsOJXcryJc1rcaLHbUh9AH3ApuxHxeNzRANqtY3zHwjyWXsprUa5mCQQP17J jbSwCiMgKf2mK1nK38InQt5crdb+DJ+XBr+Ke1acCD7MBUDW3l+w1y63KHVPms9gcc3ntObYsqMY y5uEOFQm+wsa1hBHYRY/xIZwzFGn64FTwVxEb0Iocp7A9CkAAAAAAAA= --Apple-Mail=_D94C456D-7157-4AEF-BA88-F5CB842D6A1B-- From nobody Tue Aug 4 06:00:44 2015 Return-Path: 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 3AC5D1B36FD for ; Tue, 4 Aug 2015 01:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 PSMo3Nrr8k8y for ; Tue, 4 Aug 2015 01:26:28 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DE91B36FF for ; Tue, 4 Aug 2015 01:26:27 -0700 (PDT) Received: from weemac2.home ([62.7.176.12]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0MCZWc-1ZVqwR3LG6-009Reh; Tue, 04 Aug 2015 10:26:22 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_2F9B6DB1-48EB-49D3-8C3D-D07DB2994B18" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Patrick Curry In-Reply-To: <55BFEBC2.7070209@bluepopcorn.net> Date: Tue, 4 Aug 2015 09:26:17 +0100 Message-Id: <685CF42D-38F3-443D-A637-B5EB95705775@bbfa.info> References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <55BFEBC2.7070209@bluepopcorn.net> To: Jim Fenton X-Mailer: Apple Mail (2.2102) X-Provags-ID: V03:K0:droN5uuTz/qAVj2h+TKS0kII58evu9KhF/fLFNJEJfIo2xV9pF4 LOayd8e4aZufiRD5eR5/dETNBySWXr3N6c7N6YySlirq87n/aXzq6QVi7l+z4XwjjhNfKwS eL4VzI/ps+/h73A/58NHneXomstI8uBMkNVEBYzS0ML2Hwxv5/5SHe3IAiJUnwO04lYnDTO R+9iUAKG1kUnbJaBmWOtQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:gjsGAGfoxF4=:ceJDC1VuC/LVkorpZrfm/+ ldV29kJm2UpPC9vSPXk/xgf5kgxhuoj9eLsmriSdzNvNDuHSc1zVDbfeOXoej6p83FYt9Mx8k c8Jm52a2T46d94ylNgcJhmDxqONGa1l+Gw6Mwt0OBUcMLn2/wtuyMBBW6zQfioPO0aAMOCnr1 fLgV0d536zwGQtLleZaIEh0JfP4uVihGUKswa12ygXjQ6oHW2ggkve/bdj4DfzxqkBhVKl5Z7 Epdfen8vf+JZRyKeHC3ckfSmXdHYiu9lLUaNCnj8BgWrY4N17NcjsWCBYcxhfFObhYlzKuvhL 5V7eUDhQQdu440Fqyo3Vg2eT0C/EA02wkaKrTn3SGrcZitEZ/JQnu2S9d9ODvO4hEFYwTFmjK RvdPDgzGzr9Kww/ltuxP4o1ag+l2G94ffcbQoMhBAiZeLZ9GTa0mzbmF7FUHwlLDKBfpkzfbK mXO4pnuMJr0+mBxm6PidPwTiqkHhcDMyuQePdqAHljsdR5JzDUIC1ZwoXSzNEjrREKo1XpgCC dc7XupQKKy+pt2sGnXZByhMnNvIgJhQ+rYYMiYp9rYpXRrg2a7j5tjc7BD5sr2Mos8j5kV9DH lpiWTJI+6uXNw4JsfvbKJh9r78zls88gn2tfQMMJUxl766kErB555qRrq0mT+PwscsMQ7pfia d/XegigiFSp78CSFzzgSEYNrI+SY6rMM8odi/f7/2apY0mg== Archived-At: X-Mailman-Approved-At: Tue, 04 Aug 2015 06:00:43 -0700 Cc: Nat Sakimura , =?utf-8?Q?Rainer_H=C3=B6rbe?= , Justin Richer , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 08:26:31 -0000 --Apple-Mail=_2F9B6DB1-48EB-49D3-8C3D-D07DB2994B18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 29115 kept things at a pretty high level and approximated with its use = of language, which is understandable given that we don=92t have enough = nouns and verbs, in particular, to describe the increasing & changing = complexity of all things identity. SC27 WG5 agreed that other standards = that are going into more detail than 29115 cannot be constrained by = 29115=92s imprecision. There is a pressing requirement, articulated = also in EU, US SSCA and ITU-T for more precision, consistency and = interoperability in these standards. As rapporteur for the ISO Study = Period on Anonymous Attribute Assurance and co-editor 29003, I see this = as vital. So, to help=85 in most industries and governments these days, enrolment = is the process that starts with or after application, going right = through to registration of identity attributes into an authoritative = register (if the identity proofing is successful and the application is = approved). That register is then used to start the credential issuance = phase, which is also part of/linked to credential production; production = starts much earlier with the secure procurement of the physical, logical = and cryptographic components that eventually comprise the credential = container that is bound to the identity and entity. The end of the = issuance phase is the issuance (and account provisioning) to the = end-user, the authenticated activation of the = credential/token/cryptography, a functional check and the transfer of = legal liability and ownership. The credential/token etc is now ready = for use. The usage phase may include updates and suspensions, but = ultimately it will end in revocation and, depending on policy, = destruction and data purging & archiving. Credential management occurs = from the register forward and is linked to, but not the same as, card = management or card operations (Card Ops) which are other common terms. = All this said, some of these terms will continue to mean other things to = other people. The important point is that we are able to describe the = processes and functional breakdown in a way that can be described and = used in a standard. Without wishing to upset VoT thinking, there are developments in the = mobile and blockchain worlds that are adding further options to the = proofing process, some of which is about big data use and links back to = antecedent data. One aspect of this is exploring how to use online = credentials to support offline credentials, consequently, your birth = certificate and passport (for example) may no longer be primary identity = documents unless they are supported by an online credential held in a = trusted & secure device and capable of a secure end-to-end connection to = the Authoritative Source, where =93end=94 is the user interface, not the = (vulnerable) operating system. There is work to do, but discussion has = begun on how this alters/improves/enables Chains of Trust and Derived = Credentials. Given that some of the technology will go live at scale in = the next few months, might these developments be of interest to VoT? The UK government has committed to introduce legislation for online age = verification for adult media content. This requires an unspecified = degree of anonymity at each point in the access control process. The = debate continues on how much strength there should be in the anonymous = AV attribute being asserted to the RP. Two of the several different = views seek a strong and a weak solution. One wants a LoA2+ AV attribute = bound to a compliant identity at LoA 2+; in this case they see the = strength of the attribute deriving from the authentication strength. = The second is based on scraping the use of a LoA 1 ID attribute e.g. = email address, to derive a behaviour profile that would give confidence = that a person is over 18; whilst cheap, this raises a load of legal = issues. I mention this because attribute orthogonality may be the norm = but it isn=92t always so, depending on the context. I agree about the attribute presentation to the RP. Finally, does anyone know how VoT fits with the emerging US ANSI IDPV = standard? Patrick Patrick Curry Director British Business Federation Authority - BBFA Ltd M: +44 786 024 9074 T: +44 1980 620606 patrick.curry@bbfa.info www.bbfa.info =96 a not-for-profit, self-regulating body=20 =20 On 3 Aug 2015, at 23:31, Jim Fenton 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.=20 > Each should have different "grades".=20 >=20 > Right now, -00 has:=20 >=20 > 3.1. Identity Proofing=20 > 3.2. Credential Management > 3.3. Assertion Presentation=20 >=20 > Instead, it could be >=20 > 3.1 Identity Proofing > 3.2 Credential Management > 3.3 Credential Usage > 3.4 Assertion Presentation >=20 > Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115, which is good.=20= > Note: they are missing 3.4.=20 >=20 > We also need to define vtm.=20 > I imagine that vtm uri would point to the policy documents of the = trust framework,=20 > but that is not explicitly there.=20 >=20 > Best,=20 >=20 > Nat >=20 >=20 _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot --Apple-Mail=_2F9B6DB1-48EB-49D3-8C3D-D07DB2994B18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
29115 kept things at a pretty high level and = approximated with its use of language, which is understandable given = that we don=92t have enough nouns and verbs, in particular, to describe = the increasing & changing complexity of all things identity. =  SC27 WG5 agreed that other standards that are going into more = detail than 29115 cannot be constrained by 29115=92s imprecision. =  There is a pressing requirement, articulated also in EU, US SSCA = and ITU-T for more precision, consistency and interoperability in these = standards.  As rapporteur for the ISO Study Period on Anonymous = Attribute Assurance and co-editor 29003, I see this as vital.

So, to help=85 in most = industries and governments these days, enrolment is the process that = starts with or after application, going right through to registration of = identity attributes into an authoritative register (if the identity = proofing is successful and the application is approved).  That = register is then used to start the credential issuance phase, which is = also part of/linked to credential production; production starts much = earlier with the secure procurement of the physical, logical and = cryptographic components that eventually comprise the credential = container that is bound to the identity and entity. The end of the = issuance phase is the issuance (and account provisioning) to the = end-user, the authenticated activation of the = credential/token/cryptography, a functional check and the transfer of = legal liability and ownership.  The credential/token etc is now = ready for use. The usage phase may include updates and suspensions, but = ultimately it will end in revocation and, depending on policy, = destruction and data purging & archiving.   Credential = management occurs from the register forward and is linked to, but not = the same as, card management or card operations (Card Ops) which are = other common terms.  All this said, some of these terms will = continue to mean other things to other people.  The important point = is that we are able to describe the processes and functional breakdown = in a way that can be described and used in a standard.

Without wishing to upset = VoT thinking, there are developments in the mobile and blockchain worlds = that are adding further options to the proofing process, some of which = is about big data use and links back to antecedent data.  One = aspect of this is exploring how to use online credentials to support = offline credentials, consequently, your birth certificate and passport = (for example) may no longer be primary identity documents unless they = are supported by an online credential held in a trusted & secure = device and capable of a secure end-to-end connection to the = Authoritative Source, where =93end=94 is the user interface, not the = (vulnerable) operating system.  There is work to do, but discussion = has begun on how this alters/improves/enables Chains of Trust and = Derived Credentials.  Given that some of the technology will go = live at scale in the next few months, might these developments be of = interest to VoT?

The UK government has committed to introduce legislation for = online age verification for adult media content.  This requires an = unspecified degree of anonymity at each point in the access control = process.  The debate continues on how much strength there should be = in the anonymous AV attribute being asserted to the RP.  Two of the = several different views seek a strong and a weak solution.  One = wants a LoA2+ AV attribute bound to a compliant identity at LoA 2+; in = this case they see the strength of the attribute deriving from the = authentication strength.  The second is based on scraping the use = of a LoA 1 ID attribute e.g. email address, to derive a behaviour = profile that would give confidence that a person is over 18; whilst = cheap, this raises a load of legal issues.  I mention this because = attribute orthogonality may be the norm but it isn=92t always so, = depending on the context.

I agree about the attribute presentation to the RP.

Finally, does anyone = know how VoT fits with the emerging US ANSI IDPV standard?

Patrick

Patrick Curry
Director

British Business Federation Authority = - BBFA Ltd
M: +44 786 024 9074
T: =   +44 1980 620606
patrick.curry@bbfa.info
www.bbfa.info =96 a = not-for-profit, self-regulating body 

 

On 3 Aug 2015, at 23:31, Jim Fenton = <fenton@bluepopcorn.net> wrote:

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



_______________________________________________
vot = mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot

= --Apple-Mail=_2F9B6DB1-48EB-49D3-8C3D-D07DB2994B18-- From nobody Tue Aug 4 06:27:16 2015 Return-Path: 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 ; 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 ; 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 ; Tue, 4 Aug 2015 06:26:24 -0700 (PDT) Received: by obnw1 with SMTP id w1so6776746obn.3 for ; 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: References: Date: Tue, 4 Aug 2015 09:26:23 -0400 Message-ID: From: Peter Alterman To: vot@ietf.org Content-Type: multipart/alternative; boundary=089e01537eb48851d1051c7c3bd7 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 13:27:13 -0000 --089e01537eb48851d1051c7c3bd7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +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, 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" > To: "'Nat Sakimura'" , "'Joanne Knight'" < > Joanne.Knight@dia.govt.nz> > Cc: "'Jim Fenton'" , "'Rainer Hoerbe'" < > rainer@hoerbe.at>, "'Justin Richer'" , 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 fro= m > 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 identit= y > is {name, dob, address + some other attributes}. It is policy based so th= at > 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 a= n > 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 : > > ISO/IEC 29115 has been nothing but a headache for me for a number of year= s. > > > > If we want to be evolutionary I would not constrain myself to trying to b= e > consistent with it =E2=80=93 especially since it is currently being revie= wed. 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 ti= me > 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 b= e > measurable, in which case they become guidance. > > > > As it was Nat who lit the spark that there is this other =E2=80=98thing= =E2=80=99 in the > mix, I am hoping for a flu free ISO meeting to have an academic brainstor= m. > 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 time= s > (or, in the case of Credential Management, over a long period of time) an= d > 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 a= re > credential management practices that would make a credential unsuitable f= or > highly secure authentication, but why not just represent that as less > secure authentication? VoT should be only as complex as required; it shou= ld > 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 o= f > 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 (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --089e01537eb48851d1051c7c3bd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1
Any document that l= inks assurance to risk mitigation is valuable whether it comes from ISO, IT= U-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:
Se= nd vot mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/li= stinfo/vot
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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:

=C2=A0 =C2=A01. Re: Vectors of Trust I-D feedback (Salvatore D'Agostino= )


---------- Forwarded message ----------
From:=C2=A0"Salvato= re D'Agostino" <sal@idmac= hines.com>
To:=C2=A0"'Nat Sakimura'" <sakimura@gmail.com>, "'Joan= ne Knight'" <Joann= e.Knight@dia.govt.nz>
Cc:=C2=A0"'Jim Fenton'" &= lt;fenton@bluepopcorn.net>= , "'Rainer Hoerbe'" <rainer@hoerbe.at>, "'Justin Richer'" <jricher@mit.edu>, vot@ietf.org
Date:=C2=A0Mon, 3 Aug 2015 21:24:29 -0400Subject:=C2=A0Re: [VoT] Vectors of Trust I-D feedback

+1

=C2=A0

From: vot [mailto:vot-bounces@ietf.org] O= n Behalf Of Nat Sakimura
Sent: Monday, August 03, 2015 9:14 P= M
To: Joanne Knight
Cc: Jim Fenton; Rainer Hoerbe; Just= in Richer; vot@ietf.org
Subject: Re: [VoT] Vectors of Trust I-D feedback=

=C2=A0

Hi.=C2=A0

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

<= /div>

=C2=A0

29115 is not being reviewed at this time. There is an SP bu= t it is just an SP (study period) and not review. Review is supposed to sta= rt in December 2016.=C2=A0

=C2=A0

Sort of assert= ion presentation has been in SP800-63 for sometime.=C2=A0

=

In the most recent one [SP800-63], it is = clause 9.=C2=A0

= =C2=A0

=C2=A0

=

= =C2=A0

=C2=A0

=

=C2=A0

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

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

=C2=A0=

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

=C2=A0=

I am s= till out to lunch on Assertion Presentation. Just because it exists in my f= ramework and has (thanks to Justin) got a label, I have not had time to thi= nk through exactly what it is and means. It may be that it is a series of a= spects that must be added to the other Vectors. They may not be measurable,= in which case they become guidance.<= /u>

=C2=A0

As it was Nat who lit = the spark that there is this other =E2=80=98thing=E2=80=99 in the mix, I am= hoping for a flu free ISO meeting to have an academic brainstorm. Jim, I s= eem to have missed your review of I-D, so would appreciate if you can send = me your thoughts on Assertion Presentation.<= /u>

=C2=A0

Cheers

=C2=A0=

Joanne

=C2=A0

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] V= ectors of Trust I-D feedback

=C2= =A0

To be entirely consistent with ISO/IEC 29115, we would need to rename Ide= ntity 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 circumst= ances 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 se= cure authentication, but why not just represent that as less secure authent= ication? 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&#= 39;s the reliability of that attribute assertion that's orthogonal to a= uthentication strength, and not all of the other aspects of enrolment.
<= br>Finally, I'll repeat my comment that's buried in my review of th= e 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 wil= l 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 g= eneral option to me and not part of the Vector.

-Jim

On 8/2/1= 5 2:59 AM, Nat Sakimura wrote:

I agree that we should split out the credential manageme= nt and the credential usage.=C2=A0

Each should have different "grades= ".=C2=A0

=C2=A0

Right now, -00 has:=C2=A0=

=C2=A0=

=

3.1. I= dentity Proofing=C2=A0
3.2. Credential Management
3.3. Assertion Pres= entation=C2=A0

=C2=A0

Instead, it could be

=C2=A0

3= .1 Identity Proofing

3.2 Credential Management

=

3.3 Credential Usage=

3.4 Assertion Presentation

=C2=A0

Then, 3.1 - 3.3 aligns with = X.1254 and ISO/IEC 29115, which is good.=C2=A0

Note: they are missing 3= .4.=C2=A0

=C2=A0

We also need to define vtm.=C2=A0

I imagine th= at vtm uri would point to the policy documents of the trust framework,=C2= =A0

but that is not explicitly there.=C2=A0

=C2=A0

Best,=C2=A0<= u>

=C2=A0

Nat

=C2=A0

=C2=A0

=C2=A0=



=C2=A0

<= /div>

--

Nat Sakimura (=3Dnat)

Chairm= an, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

=

_______________________________________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot


--089e01537eb48851d1051c7c3bd7-- From nobody Tue Aug 4 06:55:47 2015 Return-Path: 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 029531ACC83 for ; Tue, 4 Aug 2015 06:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_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 GIvgRXs16REj for ; Tue, 4 Aug 2015 06:55:42 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0085.outbound.protection.outlook.com [65.55.169.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F081B3844 for ; Tue, 4 Aug 2015 06:51:18 -0700 (PDT) Received: from DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) by BY2PR0601MB1670.namprd06.prod.outlook.com (10.163.107.24) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 13:51:15 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) by DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 13:51:15 +0000 From: Karen O'Donoghue To: Steve Olshansky Thread-Topic: [VoT] Notes: VoT BoF 22-July-2015 (@IETF93, Prague) Thread-Index: AQHQzrOP4QkuhYTRVES4C9PXihEkJJ3729oA Date: Tue, 4 Aug 2015 13:51:15 +0000 Message-ID: References: <4E082799-7ECC-402F-AD7C-DD0773F19E96@isoc.org> In-Reply-To: <4E082799-7ECC-402F-AD7C-DD0773F19E96@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.233.206.22] x-microsoft-exchange-diagnostics: 1; BY2PR0601MB1670; 5:D1A1RqTcEs8GVP4BLbYMsAUDfcB17jo35qsifHtV0vAj4aIo6QEeLCooo9tCv35wKaQcKgwaZRkzIhuMz+1/erx/xIqG1ZgCWM/dNcnRWQdRtD7QJ/ap+nJV7IxGaPHx0iB68D2O4zKdyOQIjjRBpg==; 24:gocbgPwn5pTBhrE47UXB9T8eAPhmtPuYFw2tL6XJa+zwfm5xcdI0V2xKtFr3RTtVi8x5j3e5gSBHRTcgS457tVFHQzZu/T3D1jMR2lCXFpk=; 20:62VCHYs1lIWv0RkQxJ63gdnj3T5a9sO5YRO4lqvjzoV5HzCMaLy0b6onW4VJKry9zQlkp2xwMio96IF3VIuPYg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0601MB1670; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR0601MB1670; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0601MB1670; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(87936001)(5001830100001)(110136002)(5001960100002)(4001540100001)(2656002)(5001860100001)(97736004)(99286002)(86362001)(33656002)(2900100001)(81156007)(40100003)(105586002)(62966003)(36756003)(46102003)(101416001)(106356001)(106116001)(450100001)(76176999)(83716003)(50986999)(77156002)(122556002)(4001450100002)(99936001)(54356999)(68736005)(189998001)(230783001)(102836002)(66066001)(2950100001)(92566002)(5002640100001)(19580405001)(19580395003)(77096005)(5890100001)(15975445007)(64706001)(82746002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0601MB1670; H:DM2PR0601MB1118.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/mixed; boundary="_003_B336F219928D45F7AB2851E3AA7BEF75isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 13:51:15.1576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0601MB1670 Archived-At: Cc: "vot@ietf.org" Subject: Re: [VoT] Notes: VoT BoF 22-July-2015 (@IETF93, Prague) X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 13:55:45 -0000 --_003_B336F219928D45F7AB2851E3AA7BEF75isocorg_ Content-Type: text/plain; charset="utf-8" Content-ID: <2EB2421EA021954CBCA62B351157C5F1@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 U3RldmUsDQoNCk15IGFwb2xvZ2llc+KApiBJIHdhcyBlZGl0aW5nIHRoZSBkcmFmdCBub3Rlcywg YW5kIG91ciBlbWFpbHMgY3Jvc3NlZCBpbiB0aGUgZXRoZXLigKYgDQoNClRoZSBiaWcgY2hhbmdl cyBJIG1hZGUgd2VyZSBjb3JyZWN0aW5nIHRoZSBhY3R1YWwgYXR0ZW5kYW5jZeKApg0KQXR0ZW5k aW5nOiBMZWlmIEpvaGFuc3NvbiwgU3RldmUgT2xzaGFuc2t5LCBKdXN0aW4gUmljaGVyLCBSb2Jp biBXaWx0b24sIEthcmVuIA0KT+KAmURvbm9naHVlLCBOYXQgU2FraW11cmEsIFdlbmR5IFNlbHR6 ZXIsIFN0ZXBoYW5pZSBHZWRlcywgYW5kIFN0ZXZlIE1vb3JlDQpSZW1vdGU6IEppbSBGZW50b24g YW5kIENvbGluIFdhbGxpcyANCg0KQW5kIHNwZWNpZnlpbmcgdGhlIG5leHQgc3RlcHMgYXQgdGhl IGVuZC4gVGhlIGFjdGlvbiBpdGVtcyB5b3Ugc3BlY2lmaWVkIGJlbG93IHdlcmUgDQpub3QgaW4g dGhlIGRyYWZ0IG1pbnV0ZXMgYW5kIGFyZSBub3QgcXVpdGUgYWNjdXJhdGUuIFRoZSBpc3N1ZSB0 cmFja2VyIGl0ZW0gaXMgcXVpdGUgaW1wb3J0YW50LA0KYW5kIHdlIHdlcmUgbm90IHB1cnN1aW5n IGZvcm1hbCBsaWFpc29uIHJlbGF0aW9uc2hpcHMgdW50aWwgdGhlcmUgd2FzIGEgd29ya2luZyBn cm91cCB0bw0KbGlhaXNlIHdpdGggKGlmIGl0IHNob3VsZCBjb21lIHRvIHRoYXQpLiANCg0KTmV4 dCBTdGVwczoNCj09PT09PT09PQ0KDQpUbyB3cmFwIHVwIHRoZSBtZWV0aW5nLCB3ZSBkaXNjdXNz ZWQgbmV4dCBzdGVwcyBmb3IgdGhpcyB3b3JrLiBUaGV5IA0KaW5jbHVkZSB0aGUgZm9sbG93aW5n OiANCg0KMS4gSnVzdGluIHdpbGwgcHJvZHVjZSB0aGUgbmV4dCBlZGl0aW9uIG9mIHRoZSBkb2N1 bWVudC4gQ29tbWVudHMgDQpjYW4gYmUgc2VudCBlaXRoZXIgdmlhIHB1bGwgcmVxdWVzdHMgb24g R2l0SHViIG9yIHRvIHRoZSBtYWlsaW5nIGxpc3QgDQoodm90QGlldGYub3JnKS4gR2VuZXJhbCBk aXNjdXNzaW9uIHNob3VsZCB0YWtlIHBsYWNlIG9uIHRoZSBtYWlsaW5nIA0KbGlzdC4gDQoNCjIu IFdlIG5lZWQgdG8gZW5zdXJlIHRoYXQgd2UgYXJlIHRyYWNraW5nIGFuZCBwcm9wZXJseSBhZGRy ZXNzaW5nIGFsbCANCmlzc3VlcyByYWlzZWQuIFdlIG5lZWQgdG8gZW5zdXJlIHRoYXQgd2UgYXJl IGNsZWFyIGFuZCB0cmFuc3BhcmVudCBpbiANCnRoaXMgZWZmb3J0IGVzcGVjaWFsbHkgYXMgd2Ug dHJ5IHRvIGNvb3JkaW5hdGUgd2l0aCBncm91cHMgYW5kIA0KaW5kaXZpZHVhbHMgd2hvIGFyZSBu b3QgYXMgZmFtaWxpYXIgd2l0aCB0aGUgSUVURiBwcm9jZXNzIGFuZCANCnNob3J0aGFuZC4gV2Ug d2lsbCB1c2UgdGhlIGV4aXN0aW5nIEdpdEh1YiBpc3N1ZSB0cmFja2VyOg0KaHR0cHM6Ly9naXRo dWIuY29tL3ZlY3RvcnNvZnRydXN0L3N0cmF3bWFuL2lzc3Vlcw0KV2UgbmVlZCB0byBlbnN1cmUg YWxsIGV4aXN0aW5nIGlzc3VlcyBnZXQgYWRkZWQgdG8gdGhlIHRyYWNrZXIuIA0KDQozLiBXZSBu ZWVkIHRvIGVuc3VyZSBjb29yZGluYXRpb24gd2l0aCBvdGhlciBTRE9zIHdvcmtpbmcgaW4gdGhp cyANCnNwYWNlLiBBIHJlY3VycmluZyBxdWVzdGlvbiB3YXMgd2hlcmUgdGhpcyB3b3JrIHNob3Vs ZCB0YWtlIHBsYWNlLiANClRoZSBJRVRGIGRvZXMgbm90IHNlZW0gdG8gaGF2ZSBxdWl0ZSB0aGUg cmlnaHQgZXhwZXJ0aXNlLCBidXQgaXQgaXMgbm90IA0KY2xlYXIgdGhlcmUgaXMgYSBiZXR0ZXIg Zm9ydW0uIEluIG9yZGVyIHRvIGJlIHN1Y2Nlc3NmdWwsIHRoaXMgd29yayB3aWxsIA0KcmVxdWly ZSBjbG9zZSBjb29yZGluYXRpb24gd2l0aCBhIG51bWJlciBvZiBvdGhlciBTRE9zIGVuZ2FnZWQg aW4gDQpyZWxhdGVkIHdvcmsuIFdlIG5lZWQgdG8gZW5zdXJlIHRoYXQgdGhlcmUgaXMgY29vcmRp bmF0aW9uIHdpdGggdGhvc2UgDQpTRE9zIChsaWtlIElTTyBhbmQgSVRVLVQpIHNvIHRoYXQgd2Ug Y2FuIGxldmVyYWdlIHRoZWlyIGV4cGVydGlzZSBpbiANCnRoaXMgd29yay4gSWYgd2UgZW5kIHVw IGVzdGFibGlzaGluZyBhbiBJRVRGIHdvcmtpbmcgZ3JvdXAsIHRoZXJlIHdpbGwgDQpwcm9iYWJs eSBiZSBvZmZpY2lhbCBsaWFpc29ucyBlc3RhYmxpc2hlZCB3aXRoIHRoZXNlIFNET3MuIFVudGls IHRoZW4sIGl0IA0Kd2lsbCBiZSB1cCB0byB1cyB0byBjb29yZGluYXRlIGxldmVyYWdpbmcgb24g b3VyIGV4aXN0aW5nIGNvbm5lY3Rpb25zIA0KYW5kIHJlbGF0aW9uc2hpcHMuIA0KDQpJIGhhdmUg YXR0YWNoZWQgbXkgZWRpdGVkIG5vdGVzIGZvciByZWZlcmVuY2UuIE15IGFwb2xvZ2llcyBmb3Ig dGhlIGRlbGF5LCBidXQgSQ0Kd2FzIG9uIHZhY2F0aW9uIGFuZCBqdXN0IGRpZG7igJl0IGdldCB0 byBpdC4gDQoNClJlZ2FyZHMsDQpLYXJlbg0KDQoNCg0K --_003_B336F219928D45F7AB2851E3AA7BEF75isocorg_ Content-Type: text/plain; name="VoT-BoF-Prague_20150722_DRAFT-kfo.txt" Content-Description: VoT-BoF-Prague_20150722_DRAFT-kfo.txt Content-Disposition: attachment; filename="VoT-BoF-Prague_20150722_DRAFT-kfo.txt"; size=5753; creation-date="Tue, 04 Aug 2015 13:51:14 GMT"; modification-date="Tue, 04 Aug 2015 13:51:14 GMT" Content-ID: <20D7A8C1D1BDAA449285474CDE192A56@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 VmVjdG9ycyBvZiBUcnVzdCAoVm9UKSBCYXIgQm9GDTIyLUp1bHktMjAxNSwgODowMCBwbSBDRVNU DQ1BdHRlbmRpbmc6DUxlaWYgSm9oYW5zc29uLCBTdGV2ZSBPbHNoYW5za3ksIEp1c3RpbiBSaWNo ZXIsIFJvYmluIFdpbHRvbiwgS2FyZW4gDU/VRG9ub2dodWUsIE5hdCBTYWtpbXVyYSwgV2VuZHkg U2VsdHplciwgU3RlcGhhbmllIEdlZGVzLCBhbmQgDVN0ZXZlIE1vb3JlDVJlbW90ZTogSmltIEZl bnRvbiBhbmQgQ29saW4gV2FsbGlzIA0NVGhlIG1haW4gcHVycG9zZSBvZiB0aGUgQmFyIEJvRiB3 YXMgdG8gdGFsayBhYm91dCB0aGUgY3VycmVudCBzdGF0ZSANb2YgdGhlIGRvY3VtZW50IGFuZCB0 byBkaXNjdXNzIHBvdGVudGlhbCBuZXh0IHN0ZXBzLiANDURvY3VtZW50IERpc2N1c3Npb246DT09 PT09PT09PT09PT09PT09PQ1KdXN0aW4gUmljaGVyIHByb3ZpZGVkIGEgcXVpY2sgb3ZlcnZpZXcg b2YgdGhlIGN1cnJlbnQgZHJhZnQgKGRyYWZ0LQ1yaWNoZXItdmVjdG9ycy1vZi10cnVzdC0wMCkg YW5kIGEgaGlnaCBsZXZlbCBzdW1tYXJ5IG9mIHRoZSBjb21tZW50cyANcmVjZWl2ZWQgdG8gZGF0 ZSBpbmNsdWRpbmc6IA0NLQlEZWZhdWx0IHZhbHVlcyBoYXZlIGxlZCB0byBzb21lIG9iamVjdGlv bnMsIGJ1dCB0aGV5IGFyZSBzaW1wbHkgDWEgc3RhcnRpbmcgcG9pbnQNLQlPcnRob2dvbmFsaXR5 INAgdGhlIHZlY3RvcnMgc2hvdWxkIG5vdCBvdmVybGFwLCBidXQgc2hvdWxkIGJlIA1jb25jZXB0 dWFsbHkgYXMgZGlmZmVyZW50IGZyb20gZWFjaCBvdGhlciBhcyBwb3NzaWJsZQ0tCVZvVCBzaG91 bGQgYmUgYW4gZXhwcmVzc2lvbiBjb25zdHJ1Y3QgZm9yIHRoZXNlIHR5cGVzIG9mIA1zZW1hbnRp Y3MNLQlXZSBuZWVkIGd1aWRhbmNlIGxhbmd1YWdlIHJlIHdoYXQgb3J0aG9nb25hbGl0eSBtZWFu cyBpbiANdGhpcyBjb250ZXh0INAgdGhlc2UgdGhpbmdzIGFyZSBub3QgY29tcGxldGVseSBvcnRo b2dvbmFsDQ1UaGVyZSB3YXMgZGlzY3Vzc2lvbiBvbiBzZXZlcmFsIGFzcGVjdHMgb2YgdGhlIGN1 cnJlbnQgZHJhZnQgDWluY2x1ZGluZzogDQ0oTmF0KSAoSVRVLVQpIFguMTI1NCBhbmQgKElTTy9J RUMpIDI5MTE1IHRhY2tsZSB0aGUgaXNzdWUgb2YgDWNvbW1vbiB0cnVzdCBmcmFtZXdvcmtzIGFu ZCBkZWZpbmVkIHBvbGljaWVzIGFjcm9zcyBkaWZmZXJlbnQgDWp1cmlzZGljdGlvbnMgYWxyZWFk eSwgYW5kIHRoYXQgd29yayBpcyBtb3JlIGFjY29tbW9kYXRpbmcgdGhhbiANTklTVCA4MDAtNjMu IFdlIHNob3VsZCBsb29rIGF0IHRob3NlIHRvIHNlZSBpZiB0aGVyZSBpcyBhbnl0aGluZyB3ZSAN Y2FuIHVzZSBvciByZWZlciB0by4gDQ1WZWN0b3JzIG5lZWQgdG8gYmUgZXZhbHVhdGVkIGJ5IGEg cmVseWluZyBwYXJ0eSAoUlApIGluIGEgY29udGV4dC4gDUhvdyBzaW1wbGUgY2FuIHdlIG1ha2Ug dGhpcyB3b3JrLCB3aXRob3V0IGl0IGJlaW5nIHRvbyBzaW1wbGU/DQ1VbmJ1bmRsaW5nIGF0dHJp YnV0ZXMgbGVhZHMgdG8gZXhwcmVzc2luZyB0aGVtIGFzIHZlY3RvcnMgYW5kIG5vdCBhcyANbGV2 ZWxzIG9mIGFzc3VyYW5jZSAoTG9BKS4gDQ1MaWFiaWxpdHk6IChOYXQpIEluIFAzLCBhIGxlZ2Fs IGNvbnRyYWN0dWFsIHJlbGF0aW9uc2hpcCBpcyBub3QgcXVpdGUgDWlkZW50aXR5IHByb29maW5n LiAoSnVzdGluKSBGZWVkYmFjayBmcm9tIEthbnRhcmEgaW4gb3RoZXIgY29udGV4dHMgDXdhcyBy ZWxhdGVkIHRvIGEgbGVnYWxseSBiaW5kaW5nIHJlbGF0aW9uc2hpcCB3aXRoIGEgcGVyc29uLCBl LmcuIGZvciANcGF5cm9sbC4gKExlaWYpIFdlIGNvdWxkIGFkZCBhbm90aGVyIGNhdGVnb3J5IC8g dmVjdG9yIGZvciBkZWdyZWUgb2YgDWxpYWJpbGl0eSBwcm90ZWN0aW9uLiBEb2VzIHRoaXMgbWVy aXQgaW5jbHVzaW9uIGluIHRoZSBjb3JlIG9yIGFzIGFuIA1leHRlbnNpb24/DQ1BdHRlc3RhdGlv biBvZiBwcm9vZmluZyBpcyBjb250ZXh0dWFsIHRvIGF1dGhuLCBvdGhlcndpc2UgeW91IGFyZSAN bGVha2luZyBwcml2YXRlIGluZm8uIA0NS2VlcCBpbiBtaW5kIHRoYXQgdGhlIGdvYWwgaGVyZSBp cyB0YXJnZXRlZCB0byBwcm92aWRlIGNvbnRleHQgZm9yIHVzZXIgDWF1dGhuINAgaG93IGNlcnRh aW4gYW0gSSB0aGF0IHRoaXMgcGVyc29uIGlzIGlkZW50aWZpZWQgY29ycmVjdGx5LCBhbmQgDWhv dyBjZXJ0YWluIGNhbiB5b3UgYmUgaW4gbXkgYXNzZXJ0aW9uIGFib3V0IHRoaXM/DQ0oUm9iaW4p IEV4dGVuc2lvbnMgY2FuIGxlYWQgdG8gYnJlYWtpbmcgZG93biBpbnRvIHBhaXJ3aXNlIA1hZ3Jl ZW1lbnRzIGJldHdlZW4gc3Rha2Vob2xkZXJzLCBhbmQgZm9yIGxpYWJpbGl0eSB0aGlzIHdvdWxk IGJlIGEgDWdvb2QgdGhpbmcuDQ1JZiBhIHVzZXIgaXMgcHJlc2VudGluZyB0aGUgc2FtZSBjcmVk ZW50aWFsLCBkbyB3ZSB3YW50IHRoZSBzeXN0ZW0gdG8gDWFzc2VydCBkaWZmZXJlbnQgVm9UPw1K dXN0aW46IE9wZW5JRCBDb25uZWN0IGhhcyBhIG5vdGlvbiBvZiBwYWlyd2lzZSBpZGVudGlmaWVy cyBmb3IgYSBoaWdoIA1hc3N1cmFuY2UgYW5vbnltb3VzIHRyYW5zYWN0aW9uLiBSZWdhcmRsZXNz IG9mIGFzc3VyYW5jZXMgdGhhdCANdGhlIElkUCBoYXMgYWJvdXQgbWUgYmluZGluZyB0byBhbiBh Y2NvdW50LCBpdCB3aWxsIG5vdCBjb252ZXkgdGhhdCANaW5mb3JtYXRpb24gYmVjYXVzZSBJIHRv bGQgaXQgbm90IHRvLiANDShSb2JpbikgSG93IHJlbGlhYmxlIGlzIHRoZSBjcmVkZW50aWFsIGxp ZmVjeWNsZSwgdmVyaWZpY2F0aW9uIGFuZCANZW5yb2xsbWVudC4gQ2FuIHRoZSBjcmVkZW50aWFs IGJlIGZvcmdlZCBvciB0YW1wZXJlZCB3aXRoIGluIA1wcmVzZW50YXRpb24/DQ1DID0gcHJpbWFy eSBjcmVkZW50aWFsDUEgPSBkZXJpdmVkIGZlZGVyYXRlZCBjcmVkZW50aWFsDQ1UcnVzdG1hcmtz IHdpbGwgcHJvdmlkZSB1bHRpbWF0ZSBkZWZpbml0aW9ucyBvZiB0aGUgdmVjdG9ycy4gDQ1XZSBu ZWVkIGEgd2F5IHRvIGhhbmRsZToNLQlhY2NvdW50IGNob29zZXINLQlsaWFiaWxpdHkgZXhwcmVz c2lvbnMNLQkoK3doYXQgZWxzZT8pDQ0oTmF0KSBXaHkgbm90IGp1c3QgdXNlIGV4aXN0aW5nIGRv Y3VtZW50cyBsaWtlIDI5MTE1IGZvciBkZWZpbml0aW9ucz8NKEp1c3RpbikgVGhpcyBpcyB3aGF0 IHdlIHdhbnQgcGVvcGxlIHRvIHVzZSBpbiB0aGUgcmVhbCB3b3JsZC4gRG9jIGhhcyANZ2VuZXJh bCBjYXNlIGV4YW1wbGVzLiBXZSBjb3VsZCB1c2UgdGhlc2Ugb3RoZXIgZGVmaW5pdGlvbnMsIGJ1 dCANbWFraW5nIHRoZW0gdXAgZm9yY2VzIHBlb3BsZSB0byB0aGluayBhYm91dCB0aGVtLiBVbHRp bWF0ZWx5IHdlIA1jb3VsZCBjZXJ0YWlubHkgZG8gdGhhdCBpZiB0aGF0IG1ha2VzIG1vcmUgc2Vu c2UuIGVJREFTIGlzIHJlZmVyZW5jaW5nIA0yOTExNS4NDShDb2xpbikgUGVyaGFwcyB3ZSBzaG91 bGQgYWRkIGEgY29va2Jvb2sgb3IgYXBwZW5kaXggcmVmZXJlbmNpbmcgDWRlZmluaXRpb25zIGZy b20gb3RoZXIgc291cmNlcy4gDQ1XaGVyZSBzaG91bGQgdGhlIHN5bnRheCBwaWVjZXMgbGl2ZT8g SUFOQSByZWdpc3RyeT8gDQ1UaGVyZSBhcmUgMiBkaW1lbnNpb25zIHRvIHRoaXMgd29yayBhdCBh IGhpZ2ggbGV2ZWw6DQktIHdoYXQgYXJlIHRoZSBjYXRlZ29yaWVzPw0JLSB3aGF0IHNob3VsZCBi ZSBpbiB0aGVtLCBhcmUgdGhleSBvcmRlcmVkLCBkb2VzIG9yZGVyIG1hdHRlcj8NDVNvbHV0aW9u IGNvdWxkIGJlIHRvINJsZWFkIGJ5IGV4YW1wbGXTIGluIHRoZSBkb2N1bWVudCBhbmQgZXhwZWN0 IA1wZW9wbGUgdG8gYWRhcHQgdG8gdGhlaXIgb3duIG5lZWRzDQ1EbyB3ZSB3YW50IHRvIGhhdmUg b25lIHRydXN0bWFyayBkZWZpbml0aW9uIGFjcm9zcyBlbnRpcmUgdmVjdG9yLCBvciANc2hvdWxk IHRoYXQgYmUgc2VwYXJhYmxlIGFzIHdlbGwgaW50byBjb21wb25lbnRzPyAoSnVzdGluKSBZZXMs IGp1c3QgDW9uZSwgc2VuZCBhIFVSSSBmb3IgZWFjaCB2ZWN0b3IuIA0NKFJvYmluKSBJbiBJb1Qg d2Ugd2lsbCBoYXZlIGEgbnVtYmVyIG9mIHRoaW5ncyB0YWxraW5nIHRvIGVhY2ggb3RoZXIsIA1l YWNoIHdpdGggaXRzIG93biBiYWdnYWdlLiBTbyBleHBlY3RpbmcgUlAgdG8gbG9vayBlYWNoIG9u ZSB1cCBpcyANbm90IHJlYWxpc3RpYy4gDQ1UaGUgcG9pbnQgYWJvdXQgKG5vdCkgdXNpbmcgdGhl IGxhYmVscyDSc3Vi0yBhbmQg0mlzc9MgZm9yIHZlY3RvcnMgYW5kIA10cnVzdG1hcmtzIG5lZWRz IHRvIGJlIGludmVzdGlnYXRlZCBmdXJ0aGVyLiANDU5leHQgU3RlcHM6DT09PT09PT09PQ0NVG8g d3JhcCB1cCB0aGUgbWVldGluZywgd2UgZGlzY3Vzc2VkIG5leHQgc3RlcHMgZm9yIHRoaXMgd29y ay4gVGhleSANaW5jbHVkZSB0aGUgZm9sbG93aW5nOiANDTEuIEp1c3RpbiB3aWxsIHByb2R1Y2Ug dGhlIG5leHQgZWRpdGlvbiBvZiB0aGUgZG9jdW1lbnQuIENvbW1lbnRzIA1jYW4gYmUgc2VudCBl aXRoZXIgdmlhIHB1bGwgcmVxdWVzdHMgb24gR2l0SHViIG9yIHRvIHRoZSBtYWlsaW5nIGxpc3Qg DSh2b3RAaWV0Zi5vcmcpLiBHZW5lcmFsIGRpc2N1c3Npb24gc2hvdWxkIHRha2UgcGxhY2Ugb24g dGhlIG1haWxpbmcgDWxpc3QuIA0NMi4gV2UgbmVlZCB0byBlbnN1cmUgdGhhdCB3ZSBhcmUgdHJh Y2tpbmcgYW5kIHByb3Blcmx5IGFkZHJlc3NpbmcgYWxsIA1pc3N1ZXMgcmFpc2VkLiBXZSBuZWVk IHRvIGVuc3VyZSB0aGF0IHdlIGFyZSBjbGVhciBhbmQgdHJhbnNwYXJlbnQgaW4gDXRoaXMgZWZm b3J0IGVzcGVjaWFsbHkgYXMgd2UgdHJ5IHRvIGNvb3JkaW5hdGUgd2l0aCBncm91cHMgYW5kIA1p bmRpdmlkdWFscyB3aG8gYXJlIG5vdCBhcyBmYW1pbGlhciB3aXRoIHRoZSBJRVRGIHByb2Nlc3Mg YW5kIA1zaG9ydGhhbmQuIFdlIHdpbGwgdXNlIHRoZSBleGlzdGluZyBHaXRIdWIgaXNzdWUgdHJh Y2tlcjoNaHR0cHM6Ly9naXRodWIuY29tL3ZlY3RvcnNvZnRydXN0L3N0cmF3bWFuL2lzc3Vlcw1X ZSBuZWVkIHRvIGVuc3VyZSBhbGwgZXhpc3RpbmcgaXNzdWVzIGdldCBhZGRlZCB0byB0aGUgdHJh Y2tlci4gDQ0zLiBXZSBuZWVkIHRvIGVuc3VyZSBjb29yZGluYXRpb24gd2l0aCBvdGhlciBTRE9z IHdvcmtpbmcgaW4gdGhpcyANc3BhY2UuIEEgcmVjdXJyaW5nIHF1ZXN0aW9uIHdhcyB3aGVyZSB0 aGlzIHdvcmsgc2hvdWxkIHRha2UgcGxhY2UuIA1UaGUgSUVURiBkb2VzIG5vdCBzZWVtIHRvIGhh dmUgcXVpdGUgdGhlIHJpZ2h0IGV4cGVydGlzZSwgYnV0IGl0IGlzIG5vdCANY2xlYXIgdGhlcmUg aXMgYSBiZXR0ZXIgZm9ydW0uIEluIG9yZGVyIHRvIGJlIHN1Y2Nlc3NmdWwsIHRoaXMgd29yayB3 aWxsIA1yZXF1aXJlIGNsb3NlIGNvb3JkaW5hdGlvbiB3aXRoIGEgbnVtYmVyIG9mIG90aGVyIFNE T3MgZW5nYWdlZCBpbiANcmVsYXRlZCB3b3JrLiBXZSBuZWVkIHRvIGVuc3VyZSB0aGF0IHRoZXJl IGlzIGNvb3JkaW5hdGlvbiB3aXRoIHRob3NlIA1TRE9zIChsaWtlIElTTyBhbmQgSVRVLVQpIHNv IHRoYXQgd2UgY2FuIGxldmVyYWdlIHRoZWlyIGV4cGVydGlzZSBpbiANdGhpcyB3b3JrLiBJZiB3 ZSBlbmQgdXAgZXN0YWJsaXNoaW5nIGFuIElFVEYgd29ya2luZyBncm91cCwgdGhlcmUgd2lsbCAN cHJvYmFibHkgYmUgb2ZmaWNpYWwgbGlhaXNvbnMgZXN0YWJsaXNoZWQgd2l0aCB0aGVzZSBTRE9z LiBVbnRpbCB0aGVuLCBpdCANd2lsbCBiZSB1cCB0byB1cyB0byBjb29yZGluYXRlIGxldmVyYWdp bmcgb24gb3VyIGV4aXN0aW5nIGNvbm5lY3Rpb25zIA1hbmQgcmVsYXRpb25zaGlwcy4gDQ0= --_003_B336F219928D45F7AB2851E3AA7BEF75isocorg_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=7629; creation-date="Tue, 04 Aug 2015 13:51:14 GMT"; modification-date="Tue, 04 Aug 2015 13:51:14 GMT" Content-ID: Content-Transfer-Encoding: base64 DQo+IE9uIEF1ZyA0LCAyMDE1LCBhdCA4OjQ2IEFNLCBTdGV2ZSBPbHNoYW5za3kgPG9sc2hhbnNr eUBpc29jLm9yZz4gd3JvdGU6DQo+IA0KPiBWb1QgQm9GOiAyMi1KdWx5LTIwMTUgKEBJRVRGOTMs IFByYWd1ZSkNCj4gDQo+ICoqKk5PVEUgb24gbWFraW5nIGNoYW5nZXMgdG8gdGhlIElEKioqDQo+ ID0+IFdoaWxlIGRpc2N1c3Npb24gYWJvdXQgdGhlIElEIG9uIHRoZSBsaXN0IGlzIGludGVyZXN0 aW5nIGFuZCB1c2VmdWwgZm9yIGZsZXNoaW5nIG91dCB0aGUgaXNzdWVzLCB1bHRpbWF0ZWx5IHRo ZSBvbmx5IHRoaW5ncyB0aGF0IHdpbGwgaW1wYWN0IHRoZSBkcmFmdCBhcmUgYWN0dWFsIHN1Z2dl c3RlZCB0ZXh0IHRvIGFkZCBvciBjaGFuZ2UuIFdlIGNhbiB1c2UgdGhlIGV4aXN0aW5nIEdpdEh1 YiB0cmFja2VyOg0KPiAgICAgICAgIGh0dHBzOi8vZ2l0aHViLmNvbS92ZWN0b3Jzb2Z0cnVzdC9z dHJhd21hbi9pc3N1ZXMNCj4gQW5kIHdlIHdpbGwgdXNlIHRoZSB0aGlzIG1haWxpbmcgbGlzdCBh cyB0aGUgc2lkZS1jaGFubmVsIGF0IGxlYXN0IGZvciBub3csIGZvciB0aG9zZSB1bmNvbWZvcnRh YmxlIHdpdGggdXNpbmcgR2l0SHViLg0KPiANCj4gKkF0dGVuZGluZyoNCj4gUmVtb3RlOiBKaW0g RmVudG9uLCBDb2xpbiBXYWxsaXMsIE5vdiBNYXRha2UgDQo+IEluIHRoZSByb29tOiBMZWlmIEpv aGFuc3NvbiwgU3RldmUgT2xzaGFuc2t5LCBKdXN0aW4gUmljaGVyLCBSb2JpbiBXaWx0b24sIEth cmVuIE/igJlEb25vZ2h1ZSwgTmF0IFNha2ltdXJhIA0KPiANCj4gKkFjdGlvbiBJdGVtcyoNCj4g W0FJXzFdIChKdXN0aW4pIHJldiB0aGUgSUQgKGF0IGxlYXN0KSBvbmNlIG1vcmUsIGluY2x1ZGlu ZyBhZGRpbmcgbW9yZSBleHBsYW5hdG9yeSB0ZXh0DQo+IFtBSV8yXSAoU3RldmUpIHNldCB1cCBs aWFpc29uIHJlbGF0aW9uc2hpcHMgd2l0aCBvdGhlciBTRE9zIHRvIGVuY291cmFnZSBwYXJ0aWNp cGF0aW9uDQo+IA0KPiAqRGlzY3Vzc2lvbioNCj4gTmF0OiAoSVRVLVQpIFguMTI1NCBhbmQgKElT Ty9JRUMpIDI5MTE1IHRhY2tsZSB0aGUgaXNzdWUgb2YgY29tbW9uIHRydXN0IGZyYW1ld29ya3Mg YW5kIGRlZmluZWQgcG9saWNpZXMsIGFjcm9zcyBkaWZmZXJlbnQganVyaXNkaWN0aW9ucywgYWxy ZWFkeSBhbmQgYXJlIG1vcmUgYWNjb21tb2RhdGluZyB0aGFuIDgwMC02My4gV2Ugc2hvdWxkIGxv b2sgYXQgdGhvc2UgdG8gc2VlIGlmIHRoZXJlIGlzIGFueXRoaW5nIHdlIGNhbiB1c2Ugb3IgcmVm ZXIgdG8uDQo+IA0KPiBKdXN0aW46IE5JU1QgbmVlZHMgYSBtZWNoYW5pc20gZm9yIGNvbnZleWlu ZyB0aGUgdmFyaW91cyBjYXRlZ29yaWVzIHNlcGFyYXRlbHkNCj4gDQo+IFZlY3RvcnMgbmVlZCB0 byBiZSBldmFsdWF0ZWQgYnkgUlAgaW4gYSBjb250ZXh0LiBIb3cgc2ltcGxlIGNhbiB3ZSBtYWtl IHRoaXMgd29yaywgd2l0aG91dCBpdCBiZWluZyB0b28gc2ltcGxlPw0KPiANCj4gVW5idW5kbGlu ZyBhdHRyaWJ1dGVzIGxlYWRzIHRvIGV4cHJlc3NpbmcgdGhlbSBhcyB2ZWN0b3JzIGFuZCBub3Qg TG9BDQo+IA0KPiBDT01NRU5UUyAtIHJlc3BvbnNlcw0KPiAtCURlZmF1bHQgdmFsdWVzIGhhdmUg bGVkIHRvIHNvbWUgb2JqZWN0aW9ucywgYnV0IHRoZXkgYXJlIHNpbXBseSBhIHN0YXJ0aW5nIHBv aW50DQo+IC0Jb3J0aG9nb25hbGl0eSDigJMgdGhlIHZlY3RvcnMgc2hvdWxkIG5vdCBvdmVybGFw LCBidXQgc2hvdWxkIGJlIGNvbmNlcHR1YWxseSBhcyBkaWZmZXJlbnQgZnJvbSBlYWNoIG90aGVy IGFzIHBvc3NpYmxlDQo+IC0JVm9UIHNob3VsZCBiZSBhbiBleHByZXNzaW9uIGNvbnN0cnVjdCBm b3IgdGhlc2UgdHlwZXMgb2Ygc2VtYW50aWNzDQo+IC0Jd2UgbmVlZCBndWlkYW5jZSBsYW5ndWFn ZSByZSB3aGF0IG9ydGhvZ29uYWxpdHkgbWVhbnMgaW4gdGhpcyBjb250ZXh0IOKAkyB0aGVzZSB0 aGluZ3MgYXJlIG5vdCBjb21wbGV0ZWx5IG9ydGhvZ29uYWwNCj4gDQo+IE5hdDogaW4gUDMsIGxl Z2FsIGNvbnRyYWN0dWFsIHJlbGF0aW9uc2hpcCBpcyBub3QgcXVpdGUgaWRlbnRpdHkgcHJvb2Zp bmcNCj4gSnVzdGluOiBmZWVkYmFjayBmcm9tIEthbnRhcmEgaW4gb3RoZXIgY29udGV4dHMgd2Fz IHJlbGF0ZWQgdG8gbGVnYWxseSBiaW5kaW5nIHJlbGF0aW9uc2hpcCB3aXRoIGEgcGVyc29uLCBl LmcuIGZvciBwYXlyb2xsDQo+IExlaWY6IHdlIGNhbiB0d2VhayB0aGUgbGFuZ3VhZ2UgdG8gcmVm bGVjdCB0aGlzLiBBbm90aGVyIGNhdGVnb3J5IC8gdmVjdG9yIGNvdWxkIGJlIGRlZ3JlZSBvZiBs aWFiaWxpdHkgcHJvdGVjdGlvbi4gRG9lcyB0aGlzIG1lcml0IGluY2x1c2lvbiBpbiB0aGUgY29y ZSwgdi4gYXMgYW4gZXh0ZW5zaW9uPw0KPiANCj4gQXR0ZXN0YXRpb24gb2YgcHJvb2ZpbmcgaXMg Y29udGV4dHVhbCB0byBhdXRobiwgb3RoZXJ3aXNlIHlvdSBhcmUgbGVha2luZyBwcml2YXRlIGlu Zm8uIA0KPiANCj4gS2VlcCBpbiBtaW5kIHRoYXQgdGhlIGdvYWwgaGVyZSBpcyB0YXJnZXRlZCB0 byBwcm92aWRlIGNvbnRleHQgZm9yIHVzZXIgYXV0aG4g4oCTIGhvdyBjZXJ0YWluIGFtIEkgdGhh dCB0aGlzIHBlcnNvbiBpcyBpZGVudGlmaWVkIGNvcnJlY3RseSwgYW5kIGhvdyBjZXJ0YWluIGNh biB5b3UgYmUgaW4gbXkgYXNzZXJ0aW9uIGFib3V0IHRoaXM/DQo+IA0KPiBSb2JpbjogZXh0ZW5z aW9ucyBjYW4gbGVhZCB0byBicmVha2luZyBkb3duIGludG8gcGFpcndpc2UgYWdyZWVtZW50cyBi ZXR3ZWVuIHN0YWtlaG9sZGVycywgYW5kIGZvciBsaWFiaWxpdHkgdGhpcyB3b3VsZCBiZSBhIGdv b2QgdGhpbmcuDQo+IA0KPiBJZiB1c2VyIGlzIHByZXNlbnRpbmcgc2FtZSBjcmVkZW50aWFsLCBk byB3ZSB3YW50IHN5c3RlbSB0byBhc3NlcnQgZGlmZmVyZW50IFZvVD8NCj4gSnVzdGluOiBPcGVu SUQgQ29ubmVjdCAoT0lDKSBoYXMgbm90aW9uIG9mIHBhaXJ3aXNlIGlkZW50aWZpZXJzLCBhbmQg cmVnYXJkbGVzcyBvZiBhc3N1cmFuY2VzIHRoYXQgSWRQIGhhcyBhYm91dCBtZSBiaW5kaW5nIHRv IGFuIGFjY291bnQgaXQgd2lsbCBub3QgY29udmV5IHRoYXQgYmVjYXVzZSBJIHRvbGQgaXQgbm90 IHRvIOKAkyBoaWdoIGFzc3VyYW5jZSBhbm9ueW1vdXMgdHJhbnNhY3Rpb24NCj4gDQo+IFJvYmlu OiByZTogY3JlZGVudGlhbCBsaWZlY3ljbGUsIHZlcmlmaWNhdGlvbiBhbmQgZW5yb2xsbWVudCwg aG93IHJlbGlhYmxlIGlzIHRoaXMsIGFuZCBjYW4gdGhlIGNyZWRlbnRpYWwgYmUgZm9yZ2VkIG9y IHRhbXBlcmVkIHdpdGggaW4gcHJlc2VudGF0aW9uPw0KPiANCj4gQSB0eXBpY2FsIOKAmGNyZWRl bnRpYWwgbGlmZWN5Y2xl4oCZIG1vZGVsIHJ1bnMgbGlrZSB0aGlzOg0KPiAxLglEbyBpZGVudGl0 eSBwcm9vZmluZywgdmVyaWZpY2F0aW9uIGFuZCBlbnJvbG1lbnQ7DQo+IDIuCUJpbmQgY3JlZGVu dGlhbCB0byB1c2VyIChlLmcuIHRocm91Z2ggYmlvbWV0cmljcywgc2hhcmVkIHNlY3JldCwgZXRj LikNCj4gMy4JSXNzdWUgY3JlZGVudGlhbCAoaG9wZWZ1bGx5IGEgbmljZSByb2J1c3Qgb25lIHRo YXQgaXMgaGFyZCB0byBmb3JnZS90YW1wZXIgd2l0aCkNCj4gNC4JQ3JlZGVudGlhbCBnZXRzIHBy ZXNlbnRlZCBieSB0aGUgdXNlcg0KPiA1LglDcmVkZW50aWFsIGdldHMgdmVyaWZpZWQgYnkgUlBz DQo+IDYuCUNyZWRlbnRpYWwgbWF5IGdldCBtb2RpZmllZC91cGRhdGVkIGJ5IGlzc3Vlcg0KPiA3 LglDcmVkZW50aWFsIG1heSBnZXQgcmV2b2tlZC9yZWFjdGl2YXRlZA0KPiA4LglDcmVkZW50aWFs IGRlc3RydWN0aW9uDQo+IA0KPiBUaGUgVm9UIG1vZGVsIHNwZWNpZmllcyB0aGUgYXR0cmlidXRl cyBJRFBzIGFuZCBSUHMgY2FuIGV4Y2hhbmdlIGNvbmNlcm5pbmcgc3RlcHMgMSwgMiBhbmQgNC4N Cj4gTXkgcXVlc3Rpb24gd2FzIGFib3V0IHRoZSByZWxpYWJpbGl0eSBvZiBzdGVwIDUuDQo+IA0K PiBCeSBhbmFsb2d5OiB3aGVuIHlvdXIgYmFuayBpc3N1ZXMgeW91IHdpdGggYSBwYXltZW50IGNh cmQsIHRoZXkgY2FuIGJlIHJlYXNvbmFibHkgY29uZmlkZW50IHRoYXQgdGhleSBhcmUgaXNzdWlu ZyBpdCB0byB0aGUgcmlnaHQgYWNjb3VudCBob2xkZXI7IHRoZXkgY2FuIGFzc3VtZSB0aGF0IHdo ZW4geW91IHNpZ24gaXQsIHlvdSBzaWduIGl0IHdpdGggeW91ciBvd24gc2lnbmF0dXJlLCBhbmQg dGhhdCB5b3UgbWFrZSB0aGUgc2FtZSBzaWduYXR1cmUgd2hlbiB5b3XigJlyZSBidXlpbmcgc29t ZXRoaW5nICh0aGF04oCZcyBzdGVwcyAxLCAyIGFuZCA0KS4gQnV0IHJldGFpbCBzdGFmZiBuZXZl ciBkbyBhIGdvb2Qgam9iIG9mIGNvbXBhcmluZyB5b3VyIHNpZ25hdHVyZSB0byB3aGF04oCZcyBv biB0aGUgY2FyZOKApiBzbyB0aGUgbW9kZWwgYnJlYWtzIGRvd24gYXQgc3RlcCA1Lg0KPiANCj4g Um9iaW46IEluIHRoZSBjdXJyZW50IGRyYWZ0LCB0aGUgdmVjdG9yIG1lc3NhZ2UgYW5kIHRoZSB0 cnVzdG1hcmsgbWVzc2FnZSBib3RoIHVzZSB0aGUgc2FtZSB2YXJpYWJsZSBsYWJlbHMgKGlzcyBh bmQgc3ViKSwgZXZlbiB0aG91Z2ggdGhlIGxhYmVscyByZWZlciB0byBkaWZmZXJlbnQgdGhpbmdz IGluIHRoZSB0d28gdHlwZXMgb2YgbWVzc2FnZS4gSSB0aGluayB0aGF04oCZcyBsaWtlbHkgdG8g bGVhZCB0byBjb25mdXNpb24sIGFuZCBzb29uZXIgb2YgbGF0ZXIgdG8gc29tZW9uZSBtYWtpbmcg YSBjb2RpbmcvdmVyaWZpY2F0aW9uIGVycm9yLg0KPiANCj4gQyA9IHByaW1hcnkgY3JlZGVudGlh bA0KPiBBID0gZGVyaXZlZCBmZWRlcmF0ZWQgY3JlZGVudGlhbA0KPiANCj4gVHJ1c3RtYXJrcyB3 aWxsIHByb3ZpZGUgdWx0aW1hdGUgZGVmaW5pdGlvbnMgb2YgdGhlIHZlY3RvcnPigKYNCj4gDQo+ IFdlIG5lZWQgYSB3YXkgdG8gaGFuZGxlOg0KPiAtCWFjY291bnQgY2hvb3Nlcg0KPiAtCWxpYWJp bGl0eSBleHByZXNzaW9ucw0KPiAtCSgrd2hhdCBlbHNlPykNCj4gDQo+IE5hdDogd2h5IG5vdCBq dXN0IHVzZSBleGlzdGluZyBkb2N1bWVudHMgbGlrZSAyOTExNSBmb3IgZGVmaW5pdGlvbnM/DQo+ IA0KPiBKdXN0aW46IHRoaXMgaXMgd2hhdCB3ZSB3YW50IHBlb3BsZSB0byB1c2UgaW4gdGhlIHJl YWwgd29ybGQuIERvYyBoYXMgZ2VuZXJhbCBjYXNlIGV4YW1wbGVzLiBXZSBjb3VsZCB1c2UgdGhl c2Ugb3RoZXIgZGVmaW5pdGlvbnMsIGJ1dCBtYWtpbmcgdGhlbSB1cCBmb3JjZXMgcGVvcGxlIHRv IHRoaW5rIGFib3V0IHRoZW0gcmF0aGVyIHRoYW4gbGF6aWx5IGp1c3QgdXNpbmcgb3Vycy4gVWx0 aW1hdGVseSB3ZSBjb3VsZCBjZXJ0YWlubHkgZG8gdGhhdCBpZiB0aGF0IG1ha2VzIG1vcmUgc2Vu c2UuIGVJREFTIGlzIHJlZmVyZW5jaW5nIDI5MTE1Lg0KPiANCj4gQ29saW46IHN1Z2dlc3QgYWRk aW5nIGEgY29va2Jvb2sgb3IgYXBwZW5kaXggcmVmZXJlbmNpbmcgZGVmaW5pdGlvbnMgZnJvbSBv dGhlciBzb3VyY2VzDQo+IA0KPiBROiB3aGVyZSBzaG91bGQgdGhlIHN5bnRheCBwaWVjZXMgbGl2 ZT8gSUFOQSByZWdpc3RyeT8gDQo+IA0KPiAyIGRpbWVuc2lvbnMgdG8gdGhpcyB3b3JrIGF0IGEg aGlnaCBsZXZlbDoNCj4gCTEuIHdoYXQgYXJlIHRoZSBjYXRlZ29yaWVzPw0KPiAJMi4gd2hhdCBz aG91bGQgYmUgaW4gdGhlbSwgYXJlIHRoZXkgb3JkZXJlZCwgZG9lcyBvcmRlciBtYXR0ZXI/DQo+ IA0KPiBTb2x1dGlvbiBjb3VsZCBiZSB0byDigJxsZWFkIGJ5IGV4YW1wbGXigJ0gaW4gdGhlIGRv Y3VtZW50IGFuZCBleHBlY3QgcGVvcGxlIHRvIGFkYXB0IHRvIHRoZWlyIG93biBuZWVkcw0KPiAN Cj4gUTogRG8gd2Ugd2FudCB0byBoYXZlIG9uZSB0cnVzdG1hcmsgZGVmaW5pdGlvbiBhY3Jvc3Mg ZW50aXJlIHZlY3Rvciwgb3Igc2hvdWxkIHRoYXQgYmUgc2VwYXJhYmxlIGFzIHdlbGwgaW50byBj b21wb25lbnRzPw0KPiBKOiB5ZXMganVzdCBvbmUsIHNlbmQgYSBVUkkgZm9yIGVhY2ggdmVjdG9y DQo+IA0KPiBSb2JpbjogSW4gSW9UIHdlIHdpbGwgaGF2ZSBhIG51bWJlciBvZiB0aGluZ3MgdGFs a2luZyB0byBlYWNoIG90aGVyLCBlYWNoIHdpdGggaXRzIG93biBiYWdnYWdlIG9mIFQmQ3MuIFNv IGV4cGVjdGluZyBSUCB0byBsb29rIGVhY2ggb25lIHVwIGlzIG5vdCByZWFsaXN0aWMNCj4gDQo+ IE5vdHdpdGhzdGFuZGluZyB0aGUgcXVlc3Rpb25zIG9mIHdoZXJlIHRoaXMgd29yayBzaG91bGQg dGFrZSBwbGFjZSwgDQo+IHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gc2V0dXAgbGlhaXNvbiByZWxh dGlvbnNoaXBzIHRvIG90aGVyIFNET3MgdG8gZW5jb3VyYWdlIHBhcnRpY2lwYXRpb24/DQo+IA0K PiBROiBEbyB3ZSBoYXZlIHJpZ2h0IGV4cGVydGlzZSB3aXRoaW4gdGhlIElFVEYgY29tbXVuaXR5 Pw0KPiBUaGUgZ2VuZXJhbCBzZW50aW1lbnQgaW4gdGhlIHJvb20gd2FzIOKAnG5vdCBxdWl0ZS7i gJ0gTm90ZSB0aGF0IHRoaXMgd29yayBvcmlnaW5hdGVkIGZyb20gZGlzY3Vzc2lvbiBhdCBhbiBJ bnRlcm5ldCBTb2NpZXR5IHdvcmtzaG9wIGhlbGQgbGFzdCBTZXB0ZW1iZXIuIFdoaWxlIHRoZSBt YWlsaW5nIGxpc3QgaXMgaG9zdGVkIGJ5IElFVEYsIGFuZCB0aGlzIHdvcmsgKm1heSogYXQgc29t ZSBwb2ludCBtYWtlIGl0cyB3YXkgdG93YXJkIGJlY29taW5nIGEgY2hhcnRlcmVkIHdvcmtpbmcg Z3JvdXAgdGhlcmUsIHNldHRpbmcgdXAgYW4gSUVURiBub24td29ya2luZyBncm91cCBtYWlsaW5n IGxpc3QgZm9yIHRoaXMgd29yayB3YXMgYSBjaG9pY2UgbWFkZSBhcyBhIG1hdHRlciBvZiBjb252 ZW5pZW5jZSBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoaXMgZWZmb3J0LCBhbmQgZHVlIHRvIGEgZnJp ZW5kbHkgSVBSIGZyYW1ld29yay4gVGhhdCBiZWluZyBzYWlkLCB0aGVyZSBpcyBubyByZWFzb24g dGhhdCB0aGlzIHdvcmsgY291bGRu4oCZdCBvciBzaG91bGRu4oCZdCBtb3ZlIHRvIGFub3RoZXIg Zm9ydW0gYXQgc29tZSBwb2ludCBpZiB0aGF0IHNlZW1zIGJlbmVmaWNpYWwuDQo+IA0KPiBUaHVz LCBpbiBvcmRlciB0byBtaXRpZ2F0ZSB0aGUgZmFjdCB0aGF0IHRoZSBJRVRGIGNvbW11bml0eSBt YXkgbm90IGhhdmUgdGhlIHJpZ2h0IGV4cGVydGlzZSwgYW5kIHRvd2FyZCBvYnRhaW5pbmcgdGhl IGJlc3QgcmVzdWx0IGZyb20gb3VyIHdvcmssIHdlIHJlYWNoZWQgdGhlIGNvbmNsdXNpb24gdGhh dCBjcmVhdGluZyBsaWFpc29uIHJlbGF0aW9uc2hpcCB3aXRoIG90aGVyIFNET3MgbGlrZSBJU08g YW5kIElUVS1UIHdvdWxkIGJlIGEgZ29vZCBpZGVhLCBzbyB0aGF0IHdlIGNhbiBsZXZlcmFnZSB0 aGVpciBrbm93bGVkZ2UgYW5kIGV4cGVyaWVuY2UgaW4gdGhpcyB3b3JrIA0KPiANCj4gW0FJXzJd IChTdGV2ZSkgc2V0IHVwIGxpYWlzb24gcmVsYXRpb25zaGlwcyB3aXRoIG90aGVyIFNET3MgdG8g ZW5jb3VyYWdlIHBhcnRpY2lwYXRpb24NCj4gDQo+IA0KPiAtLQ0KPiBTdGV2ZSBPbHNoYW5za3kN Cj4gVHJ1c3QgJiBJZGVudGl0eSBQcm9ncmFtIExlYWQNCj4gSW50ZXJuZXQgU29jaWV0eQ0KPiB3 d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdm90IG1haWxpbmcgbGlzdA0KPiB2b3RAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QNCg0K --_003_B336F219928D45F7AB2851E3AA7BEF75isocorg_-- From nobody Tue Aug 4 07:23:27 2015 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: <55BFEBC2.7070209@bluepopcorn.net> Date: Tue, 4 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> <55BFEBC2.7070209@bluepopcorn.net> To: Jim Fenton 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: Cc: Nat Sakimura , Rainer Hoerbe , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 14:23:21 -0000 --Apple-Mail=_D4873E64-C006-4DCC-8942-993E731519BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Just a quick note: I=92ve come to agree that the Assertion Presentation = component is most useful in the client=92s request, where other = protocols don=92t always have such mechanisms. This raises an = interesting question: should each component have a =93target=94? 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. =97 Justin > On Aug 3, 2015, at 6:31 PM, Jim Fenton wrote: >=20 > To be entirely consistent with ISO/IEC 29115, we would need to rename = Identity Proofing as Enrolment, and Credential Usage as Authentication. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > -Jim >=20 > On 8/2/15 2:59 AM, Nat Sakimura wrote: >> I agree that we should split out the credential management and the = credential usage.=20 >> Each should have different "grades".=20 >>=20 >> Right now, -00 has:=20 >>=20 >> 3.1. Identity Proofing=20 >> 3.2. Credential Management >> 3.3. Assertion Presentation=20 >>=20 >> Instead, it could be >>=20 >> 3.1 Identity Proofing >> 3.2 Credential Management >> 3.3 Credential Usage >> 3.4 Assertion Presentation >>=20 >> Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115, which is good.=20= >> Note: they are missing 3.4.=20 >>=20 >> We also need to define vtm.=20 >> I imagine that vtm uri would point to the policy documents of the = trust framework,=20 >> but that is not explicitly there.=20 >>=20 >> Best,=20 >>=20 >> Nat >>=20 >>=20 >=20 --Apple-Mail=_D4873E64-C006-4DCC-8942-993E731519BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Just a quick note: I=92ve come to agree that the Assertion = Presentation component is most useful in the client=92s request, where = other protocols don=92t always have such mechanisms. This raises an = interesting question: should each component have a =93target=94? 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.

 =97 = Justin

On Aug 3, 2015, at 6:31 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:

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




= --Apple-Mail=_D4873E64-C006-4DCC-8942-993E731519BE-- From nobody Tue Aug 4 07:27:43 2015 Return-Path: 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 09C2D1A000E for ; Tue, 4 Aug 2015 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mUYzyPZOxELe for ; Tue, 4 Aug 2015 07:27:39 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9A01A1B1C for ; Tue, 4 Aug 2015 07:25:14 -0700 (PDT) Received: from splunge.local ([216.9.110.11]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t74EP9i8014499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2015 07:25:10 -0700 To: Rainer Hoerbe References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <55BFEBC2.7070209@bluepopcorn.net> <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at> From: Jim Fenton X-Enigmail-Draft-Status: N1110 Message-ID: <55C0CB49.5010104@bluepopcorn.net> Date: Tue, 4 Aug 2015 07:25:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1438698310; bh=HxhwXgnMF7lusQ5clhYAr4gErwgjreSuiA5yG2I1keY=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=XSs0bjT8MPKgSd0jLkfUlEe7xYMIqKIz8yph/v1rZSsi6m4XIASr9uV4GR6+lyGkv d7PzPchiDXlf2RRFBsgPVisXaMjI+mikQBT8If3U+YneN0kzN27HI6MzC1hG454Jo7 Pe0F585Nq+vUZuItnflelP+aUFrO/i9uo7oFmA8s= Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 14:27:41 -0000 On 8/3/15 11:12 PM, Rainer Hoerbe wrote: > Am 04.08.2015 um 00:31 schrieb Jim Fenton : >> 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 t= imes (or, in the case of Credential Management, over a long period of tim= e) and have different threat models. But I would like to ask under which = circumstances a Relying Party would act differently to an indication of l= ess secure Credential Management vs. less secure Authentication. > For a targeted attack the weak credential recovery will lower the adver= sary=92s effort significantly, whereas in large numbers a 2F AuthN combin= ed will still reduce the overall risk. I have trouble understanding how an authentication with weak credential recovery could ever be called two-factor. > >> 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 requ= ired; it should not represent aspects of the process that the relying par= ty does not need. > +1. However, I remember a discussion at IIW where someone argued that a= n important use case for VoT is the combination of C4 (U2F) with P1 (sel= f-asserted) for social ids. But social networks are prioritizing usabilit= y over security with a weak recovery mechanism. We need to make sure that it's clear to everyone that a recovery mechanism is just another way of logging in, and if it's weaker than the primary login method the authentication is weaker overall. -Jim From nobody Tue Aug 4 11:14:01 2015 Return-Path: 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 5CE411A8AD7 for ; Tue, 4 Aug 2015 11:14:00 -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 iFiV4Pa3FoZd for ; Tue, 4 Aug 2015 11:13:58 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 104D31A887F for ; Tue, 4 Aug 2015 11:13:58 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so34858323wib.1 for ; Tue, 04 Aug 2015 11:13:56 -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=PofhIiYLsCjggOPPyiNNHQkePzpPa1wjEF2njUB9LhI=; b=0nk7qZc8ibA4gUBDjEZjoJkPN4tF1ZE7IJ9BkqO0skcu23dBP78xcnhErBaw3PzOIe 7+DXNJCzbZWjqdD5SZ+tOC2rlwKdaLSe2HrPjiVmcz6RKAVpqVk/zSyJ1lRLJPsfLHiu pYFsZ72Z22MHRe+cXa8Q0lMfTFEoLPpw/5ESLiOqyKD3ROVeJ6jVuccYVhvBaBNos+IC k07/oPqJYFOXf5EHstNm8WsUhpMRrKu10LTR3O00/Z8gZd2EsOLO5PpTJABQDe/Ac3po hvIXVaFSTbf8B/Xc0nIKxON39W8MzulxHecRsvzWj64u1BIJaXkiIeTM9iHDgJ7CjHcx XS4w== MIME-Version: 1.0 X-Received: by 10.194.206.65 with SMTP id lm1mr10616153wjc.117.1438712036861; Tue, 04 Aug 2015 11:13:56 -0700 (PDT) Received: by 10.28.144.85 with HTTP; Tue, 4 Aug 2015 11:13:56 -0700 (PDT) In-Reply-To: References: <4E082799-7ECC-402F-AD7C-DD0773F19E96@isoc.org> Date: Wed, 5 Aug 2015 03:13:56 +0900 Message-ID: From: Nat Sakimura To: "Karen O'Donoghue" Content-Type: multipart/alternative; boundary=047d7b8739d2e440bb051c803f86 Archived-At: Cc: Steve Olshansky , "vot@ietf.org" Subject: Re: [VoT] Notes: VoT BoF 22-July-2015 (@IETF93, Prague) X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 18:14:00 -0000 --047d7b8739d2e440bb051c803f86 Content-Type: text/plain; charset=UTF-8 Indeed, and it was one of the reason why we wanted to become a formal WG. For a formal liaison arrangement, we need to be a formal body. 2015-08-04 22:51 GMT+09:00 Karen O'Donoghue : > and we were not pursuing formal liaison relationships until there was a > working group to > liaise with (if it should come to that). > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b8739d2e440bb051c803f86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed, and it was one of the r= eason why we wanted to become a formal WG. For a formal liaison arrangement= , we need to be a formal body.=C2=A0

2015-08-04 22:51 GMT+09:00 Karen O'Donoghue <odonoghue@isoc.org>:
and we were not pursuin= g formal liaison relationships until there was a working group to
liaise with (if it should come to that).



--
Nat Sa= kimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--047d7b8739d2e440bb051c803f86-- From nobody Tue Aug 4 15:29:38 2015 Return-Path: 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 CFCC21A7D81 for ; Tue, 4 Aug 2015 15:29:35 -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 MZcudcVQgJJa for ; Tue, 4 Aug 2015 15:29:25 -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 A6B561A0250 for ; Tue, 4 Aug 2015 15:29:24 -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=1438727362; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc; bh=plGCFOBb+DJom1awfIpKFANMkGe7I2PkX9XmjcTv7w4=; b=cd186XdCrWAgYxAK5MCVqJuyQw0XIdfGgX9zV3W0Ml72q97heuw0KF57eHZFyX7r 0Gt5v6VlWCkTlM6dBlvFOEkUBV1sQYy5gVAfGB6490/3XKO/0zA5/VcpsG7r2em9 SaDGIwjuGaHnU3+MxixWpl3AeZmxKWAxzGwD/1XOSM8=; 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 55C13CC1-0E3738DC@mta1103.omr; Tue, 04 Aug 2015 22:29:21 +0000 Message-ID: <569AD906E45DB44A8AFF11D61F5DA791014ADEF836@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 523220008; Wed, 05 Aug 2015 10:29:18 +1200 (NZST) Received: from WLGPRDCAS02.dia.govt.nz (Not Verified[172.29.0.70]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Wed, 05 Aug 2015 10:29:18 +1200 Received: from WLGPRDMBX02.dia.govt.nz ([fe80::d51f:14cf:8162:8a0b]) by WLGPRDCAS02.dia.govt.nz ([172.29.0.70]) with mapi id 14.03.0235.001; Wed, 5 Aug 2015 10:29:18 +1200 From: Joanne Knight To: 'Robin Wilton' , "vot@ietf.org" Thread-Topic: [VoT] Credential usage, presentation and verification Thread-Index: AQHQzv9UuaaCrL/Yw02UcuXFVzrk/g== Date: Tue, 4 Aug 2015 22:29:17 +0000 References: In-Reply-To: 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_569AD906E45DB44A8AFF11D61F5DA791014ADEF836WLGPRDMBX02di_" Archived-At: Subject: Re: [VoT] Credential usage, presentation and verification X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 22:29:36 -0000 --_000_569AD906E45DB44A8AFF11D61F5DA791014ADEF836WLGPRDMBX02di_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Robin You have succinctly captured where I am at. Though to fit with the real world I have been experiencing, I have had to s= plit 'credential is bound' into to two parts (issuance and use), as invaria= bly organisations are only doing half. I am not sure we can force a maturit= y level where both aspects are recognised as one element (as binding is bec= oming in the 'establish identity' process) but I live in hope. The other thing that may be helpful in understanding my framework is how I = define 'system'. By this I don't mean the online channel, I mean it at a hi= gher level - Collins 'a group or combination of interrelated, interdependen= t, or interacting elements forming a collective entity; a methodical or coo= rdinated assemblage of parts, facts, concepts, etc ' Therefore in my mind processes for amending, revoking and/or destroying a c= redential are not specific to identity but would occur in relation to infor= mation and credentials that are for any purpose. I am trying to apply a sim= ilar filter to elements (systems, processes etc) as we do when separating i= dentity from personal information. Ben Hur and all that. Cheers Jo From: Robin Wilton [mailto:wilton@isoc.org] Sent: Tuesday, 4 August 2015 10:53 p.m. To: vot@ietf.org Subject: [VoT] Credential usage, presentation and verification Apologies for top-posting, but I wanted to make some comments which refer p= artly to both Joanne's and Jim's preceding posts, and there wasn't a neat w= ay to do so inline. If you look at the whole credential lifecycle, there are trust factors (not= vectors!) throughout it. VoT looks at a subset of them: - how reliably the issuing party establishes the identity of the applicant; - how strongly the credential is bound to the applicant; - how reliably the credential is presented. However, there are significant trust factors at other stages in the lifecyc= le: - how reliably the credential is verified when it is presented (by analogy,= think of the cursory check a retail clerk gives your "signature" compared = to the one on your credit card) - how robust the processes are for amending, revoking and/or destroying a c= redential. Of these two, the second could be put neatly under the heading of "credenti= al management" and represented by the same vector. The first (reliability of the credential verification process upon presenta= tion) is harder to account for, and I think this is because it is generally= partly or wholly outside the control of the IDP. (Again, by analogy, think= of Point of Sale terminals; these are, essentially, an attempt by the IDP = [card issuer] to retain control over the verification step, essentially tak= ing the RP out of the loop. But they do so at the cost of significant effor= t, and the 'remote' part of the process is still susceptible to subversion.= ) I am not yet sure it can be sensibly formalised in a vector - but I think i= t's worth considering, because it's a significant trust factor in the over-= all lifecycle. Here's a straw-man use case, just to kick around... An IDP issues electronic credentials, and offers RPs a range of verificatio= n alternatives: when one of our credentials is presented, 3 - you will verify it using a black box that we require you to install at = your premises, and which not only checks the credential itself, it also "ph= ones home" to do a real-time revocation check or 2 - there's no black box; we will provide you with a software verification = module that you run, to verify the credential and do a revocation check or 1 - we'll expose a web services API at our end, for credential verification= and revocation status or 0 - we just issue the credentials; how you verify them on presentation is u= p to you The IDP's liability model would vary accordingly. One issue with this straw-man is that the IDP is telling the RP stuff that = they both already know... On the other hand, exchanging a message to that effect does create an audit= trail, which might be useful for compliance purposes. Any thoughts? R From: Joanne Knight > Subject: Re: [VoT] Vectors of Trust I-D feedback Date: 4 August 2015 01:05:17 BST To: 'Jim Fenton' >, N= at Sakimura >, Rainer Hoerbe = > Cc: "vot@ietf.org" >= , Justin Richer > 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 hav= e 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 i= n 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 serie= s of aspects that must be added to the other Vectors. They may not be measu= rable, 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. Ji= m, 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 Ident= ity 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 circumsta= nces 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 sec= ure authentication, but why not just represent that as less secure authenti= cation? 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogonal to aut= hentication 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 o= ther day that Assertion Presentation should be visible to the RP already. F= or 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 a= ssertions to be presented to it, but that seems like more of a general opti= on 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 credenti= al 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 fra= mework, but that is not explicitly there. Best, Nat From: Nat Sakimura > Subject: Re: [VoT] Vectors of Trust I-D feedback Date: 4 August 2015 01:53:44 BST To: Jim Fenton > Cc: Rainer Hoerbe >, Justin Riche= r >, "vot@ietf.org" > 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 >: To be entirely consistent with ISO/IEC 29115, we would need to rename Ident= ity 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 circumsta= nces 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 sec= ure authentication, but why not just represent that as less secure authenti= cation? 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogonal to aut= hentication 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 o= ther day that Assertion Presentation should be visible to the RP already. F= or 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 a= ssertions to be presented to it, but that seems like more of a general opti= on 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 credenti= al 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 fra= mework, but that is not explicitly there. Best, Nat -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From: Nat Sakimura > Subject: Re: [VoT] Vectors of Trust I-D feedback Date: 4 August 2015 02:14:11 BST To: Joanne Knight > Cc: Jim Fenton >, Rai= ner Hoerbe >, Justin Richer >, "vot@ietf.org" <= vot@ietf.org> Hi. I think X.1254 | ISO/IEC 29115 is actually quite good if you read deeply in= to it especially from private sector point of view. It has departed from th= e 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 ach= ieve "identity proofing." In the private sector usage, it may just be a val= idity 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 2= 016. 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.80= 0-63-2.pdf, 2015-08-04 9:05 GMT+09:00 Joanne Knight >: 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 hav= e 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 i= n 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 serie= s of aspects that must be added to the other Vectors. They may not be measu= rable, 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. Ji= m, 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 Ident= ity 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 circumsta= nces 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 sec= ure authentication, but why not just represent that as less secure authenti= cation? 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogonal to aut= hentication 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 o= ther day that Assertion Presentation should be visible to the RP already. F= or 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 a= ssertions to be presented to it, but that seems like more of a general opti= on 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 credenti= al 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 fra= mework, but that is not explicitly there. Best, Nat -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot --_000_569AD906E45DB44A8AFF11D61F5DA791014ADEF836WLGPRDMBX02di_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Robin

 <= /p>

You have succinctly captu= red where I am at.

 <= /p>

Though to fit with the re= al world I have been experiencing, I have had to split ‘credential is= bound’ into to two parts (issuance and use), as invariably organisat= ions are only doing half. I am not sure we can force a maturity level where bot= h aspects are recognised as one element (as binding is becoming in the R= 16;establish identity’ process) but I live in hope.=

 <= /p>

The other thing that may = be helpful in understanding my framework is how I define ‘system̵= 7;. By this I don’t mean the online channel, I mean it at a higher le= vel – Collins ‘a group or combination of interrelated, interdependent, or = interacting elements forming a collective entity; a methodical or coordinat= ed assemblage of parts, facts, concepts, etc  ‘

Therefore in my mind proc= esses for amending, revoking and/or destroying a credential are not specifi= c to identity but would occur in relation to information and credentials that are for any purpose. I am trying to apply a similar f= ilter to elements (systems, processes etc) as we do when separating identit= y from personal information. Ben Hur and all that.  =

 <= /p>

Cheers<= /p>

 <= /p>

Jo

 <= /p>

From: Robin Wilton [mailto:wilton@isoc.org]
Sent: Tuesday, 4 August 2015 10:53 p.m.
To: vot@ietf.org
Subject: [VoT] Credential usage, presentation and verification<= /o:p>

 

Apologies for top-posting, but I wanted to make some= comments which refer partly to both Joanne’s and Jim’s precedi= ng posts, and there wasn’t a neat way to do so inline.

 

If you look at the whole credential lifecycle, there= are trust factors (not vectors!) throughout it. VoT looks at a subset of t= hem:

- how reliably the issuing party establishes the ide= ntity of the applicant;

- how strongly the credential is bound to the applic= ant;

- how reliably the credential is presented.

 

However, there are significant trust factors at othe= r stages in the lifecycle:

 

- how reliably the credential is verified when it is= presented (by analogy, think of the cursory check a retail clerk gives you= r “signature” compared to the one on your credit card)

- how robust the processes are for amending, revokin= g and/or destroying a credential.

 

Of these two, the second could be put neatly under t= he heading of “credential management” and represented by the sa= me vector.

 

The first (reliability of the credential verificatio= n process upon presentation) is harder to account for, and I think this is = because it is generally partly or wholly outside the control of the IDP. (A= gain, by analogy, think of Point of Sale terminals; these are, essentially, an attempt by the IDP [card issuer= ] to retain control over the verification step, essentially taking the RP o= ut of the loop. But they do so at the cost of significant effort, and the &= #8216;remote’ part of the process is still susceptible to subversion.)

 

I am not yet sure it can be sensibly formalised in a= vector - but I think it’s worth considering, because it’s a si= gnificant trust factor in the over-all lifecycle.

 

Here’s a straw-man use case, just to kick arou= nd…

 

An IDP issues electronic credentials, and offers RPs= a range of verification alternatives:

 

when one of our credentials is presented, =

 

3 - you will verify it using a black box that we req= uire you to install at your premises, and which not only checks the credent= ial itself, it also “phones home” to do a real-time revocation = check

or

 

2 - there’s no black box; we will provide you = with a software verification module that you run, to verify the credential = and do a revocation check 

or

 

1 - we’ll expose a web services API at our end= , for credential verification and revocation status

or 

 

0 - we just issue the credentials; how you verify th= em on presentation is up to you

 

 

The IDP’s liability model would vary according= ly. 

 

One issue with this straw-man is that the IDP is tel= ling the RP stuff that they both already know… 

On the other hand, exchanging a message to that effe= ct does create an audit trail, which might be useful for compliance purpose= s.

 

 

Any thoughts?

 

 

R

 

  

 

From: Joanne Knight &= lt;Joanne.Knight@dia.govt.nz>

Subject: Re: [Vo= T] Vectors of Trust I-D feedback

Date: 4 August 2015 0= 1:05:17 BST

To: 'Jim Fenton' <= fent= on@bluepopcorn.net>, Nat Sakimura <sakimura@gmail.com>, Rainer Hoerbe <rainer@hoerbe.at>

Cc: "vot@ietf.org&q= uot; <vot@ietf.= org>, Justin Richer <jricher@mit.edu>=

&n= bsp;

ISO/IEC 29115 has been no= thing but a headache for me for a number of years.

 <= /p>

If we want to be evolutio= nary 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.

 <= /p>

I am still out to lunch o= n Assertion Presentation. Just because it exists in my framework and has (t= hanks 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 asp= ects that must be added to the other Vectors. They may not be measurable, i= n which case they become guidance.

 <= /p>

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.

 <= /p>

Cheers<= /p>

 <= /p>

Joanne<= /p>

 <= /p>

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

 

To be entirely consistent with ISO/IEC 29115, we wou= ld need to rename Identity Proofing as Enrolment, and Credential Usage as A= uthentication.

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 circumsta= nces a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Auth= entication. There are credential management practices that would make a cre= dential unsuitable for highly secure authentication, but why not just repre= sent 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogonal to aut= hentication 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 o= ther day that Assertion Presentation should be visible to the RP already. F= or 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 Vect= or.

-Jim

On 8/2/15 2:59 AM, Nat Sakimura wrote:

I agree that we should split out the credential mana= gement 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 doc= uments of the trust framework, 

but that is not explicitly there. 

 

Best, 

 

Nat

 

 

 



From: Nat Sakimura &l= t;sakimu= ra@gmail.com>

Subject: Re: [Vo= T] Vectors of Trust I-D feedback

Date: 4 August 2015 0= 1:53:44 BST

To: Jim Fenton <fenton= @bluepopcorn.net>

Cc: Rainer Hoerbe <= ;rainer@ho= erbe.at>, Justin Richer <jricher@mit.edu>, "vot@ietf.org" <vot@ietf.org>

&n= bsp;

Right, X.1254 | ISO/IEC 29115 says:&nb= sp;

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 considera= tions. 

My point is that this I-D seems to use= "Credential Management" for "Entity Authentication" (B= TW, 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 Auth= entication" and not this specific phase.)

 

2015-08-04 7:31 GMT+09:00 Jim Fent= on <fent= on@bluepopcorn.net>:

To be entirely consistent with ISO/IEC= 29115, we would need to rename Identity Proofing as Enrolment, and Credent= ial 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 circumsta= nces a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Auth= entication. There are credential management practices that would make a cre= dential unsuitable for highly secure authentication, but why not just repre= sent 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogonal to aut= hentication 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 o= ther day that Assertion Presentation should be visible to the RP already. F= or 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 Vect= or.

-Jim

On 8/2/15 2:59 AM, Nat Sakimura wrote:

I agree that we should split out the c= redential management and the credential usage. 

Each should have different "grade= s". 

 

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<= /span>

 

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 (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



From: Nat Sakimura &l= t;sakimu= ra@gmail.com>

Subject: Re: [Vo= T] Vectors of Trust I-D feedback

Date: 4 August 2015 0= 2:14:11 BST

To: Joanne Knight <= ;= Joanne.Knight@dia.govt.nz>

Cc: Jim Fenton <fenton= @bluepopcorn.net>, Rainer Hoerbe <rainer@hoerbe.at>, Justin Richer <jricher@mit.edu= >, "vo= t@ietf.org" <vot@ietf.= org>

&n= bsp;

Hi. 

 

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

 

What's really good about it is its dep= arture from the notion that identity is {name, dob, address + some othe= r attributes}. It is policy based so that the policy in the framework should decide what needs to be verified to achieve "identit= y 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 ti= me. There is an SP but it is just an SP (study period) and not review. Revi= ew is supposed to start in December 2016. 

 

Sort of assertion presentation has bee= n in SP800-63 for sometime. 

In the most recent one [SP800-63], it = is clause 9. 

 

 

 

 

 

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

ISO/IEC 29115 has been no= thing but a headache for me for a number of years.

 <= /p>

If we want to be evolutio= nary 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.

 <= /p>

I am still out to lunch o= n Assertion Presentation. Just because it exists in my framework and has (t= hanks 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 asp= ects that must be added to the other Vectors. They may not be measurable, i= n which case they become guidance.

 <= /p>

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.

 <= /p>

Cheers<= /p>

 <= /p>

Joanne<= /p>

 <= /p>

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

 

To be entirely consistent with ISO/IEC 29115, we wou= ld need to rename Identity Proofing as Enrolment, and Credential Usage as A= uthentication.

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 circumsta= nces a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Auth= entication. There are credential management practices that would make a cre= dential unsuitable for highly secure authentication, but why not just repre= sent 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 b= eyond identity proofing and the binding of those attributes in a credential= . It's the reliability of that attribute assertion that's orthogonal to aut= hentication 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 o= ther day that Assertion Presentation should be visible to the RP already. F= or 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 Vect= or.

-Jim

On 8/2/15 2:59 AM, Nat Sakimura wrote:

I agree that we should split out the credential mana= gement 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 doc= uments of the trust framework, 

but that is not explicitly there. 

 

Best, 

 

Nat

 

 

 



 

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



_______________________________________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot

 

--_000_569AD906E45DB44A8AFF11D61F5DA791014ADEF836WLGPRDMBX02di_-- From nobody Tue Aug 18 12:28:43 2015 Return-Path: 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 330F11A1DBD for ; Tue, 18 Aug 2015 12:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, 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 dqZxzfbU9xio for ; Tue, 18 Aug 2015 12:28:40 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E261A1B61 for ; Tue, 18 Aug 2015 12:28:40 -0700 (PDT) X-AuditID: 12074424-f79b46d000001e7f-d6-55d38767757f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id B3.26.07807.76783D55; Tue, 18 Aug 2015 15:28:39 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t7IJScqI014624 for ; Tue, 18 Aug 2015 15:28:39 -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 t7IJSa1b005687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Aug 2015 15:28:38 -0400 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <87EB01BE-5CD9-4586-A0A4-F1917E499AEB@mit.edu> Date: Tue, 18 Aug 2015 15:28:36 -0400 To: vot@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixG6nrpvefjnUYNpLEYuGnw9YHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0b/wDVvBK+6KzjNbWBoYH3N2MXJySAiYSEy5940RwhaTuHBv PVsXIxeHkMBiJol9BycyQjhHGCWm3jnKDOF8YZJ4f+YgO0gLm4CqxPyVt5hAbGYBdYk/8y4x Q9jaEssWvgazhQWkJTYemcsGYvMKWEnsP3KBFcRmAepd8uUkWI2IgIBEz+If7BA1ehI9575A nSQrsfVNK9MERr5ZSFbMQrJiFpKWBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RS U0o3MYLDzEVlB2PzIaVDjAIcjEo8vBcKLoUKsSaWFVfmHmKU5GBSEuU93XQ5VIgvKT+lMiOx OCO+qDQntfgQowQHs5IIb2gJUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxW hoNDSYLXqw2oUbAoNT21Ii0zpwQhzcTBCTKcB2Q4SA1vcUFibnFmOkT+FKOilDgvK0hCACSR UZoH1wtLA68YxYFeEeadDVLFA0whcN2vgAYzAQ0+POEiyOCSRISUVANjoUuTWveEif2b8i1a Z9R8WWO3S66+vv1GhrdXS7Ejn7fDMoVqv/NCR3br3558KCv0EX9Ddd3c4Py3csYBbu0KAh8X sgY+iAhc8HPHrYSVFS8/ymQ/91Dc+Gznf4aMj2wV0RPK/HXWha//GZVQ8d5p9rG0Bvmdfx+c nmp17Oa5d9u2Vjxb1CimxFKckWioxVxUnAgANkPXPt4CAAA= Archived-At: Subject: [VoT] Updating the Draft X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 19:28:42 -0000 I=E2=80=99m updating the draft based on the initial feedback we got from = folks, both here on the list and at the BoF in Prague. The biggest = change is adding a fourth core category: Primary Credential Management, = and renaming the former =E2=80=9CCredential Management / Credential = Binding=E2=80=9D category to Primary Credential Usage.=20 - =E2=80=9Cusage=E2=80=9D is meant to to convey the strength of = verifiability of the credential itself by the IdP.=20 - =E2=80=9Cmanagement=E2=80=9D is meant to capture the lifecycle of = issuance, rotation, and revocation by the credential issuer (usually the = IdP) and how =E2=80=9Cstrongly=E2=80=9D it gets bound to a specific = account. I=E2=80=99m also tightening down the definition of the syntax, such that = the component name is a single ASCII letter (currently case-sensitive) = and the value is a single alphanumeric ASCII character (currently case = sensitive).=20 I=E2=80=99m also adding a (nominal so far) IANA registry for the = categories and their markers, and at least noting that =E2=80=9Cvot=E2=80=9D= , =E2=80=9Cvtr=E2=80=9D, and =E2=80=9Cvtm=E2=80=9D all need to be = registered in the JWT Registry. There=E2=80=99s formal language for = establishing these that we=E2=80=99ll use later if this gets picked up = as an IETF standards track document. Thanks for all the comments so far, and hopefully I=E2=80=99ll have = another I-D for you all to throw rocks at within a week=E2=80=99s time. =E2=80=94 Justin=