Re: [VoT] Vectors of Trust I-D feedback
sakimura <sakimura@gmail.com> Tue, 04 August 2015 06:42 UTC
Return-Path: <sakimura@gmail.com>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ACE1B365E for <vot@ietfa.amsl.com>; 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 <vot@ietfa.amsl.com>; 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 <vot@ietf.org>; 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 <sakimura@gmail.com>
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> <C9563753-E9E2-4990-9B7C-3AFEE232BD01@hoerbe.at> <CABzCy2AUA4ycTcj0-kgu_YaceduJRJYjruXs=X2zE1nowryGEQ@mail.gmail.com> <55BFEBC2.7070209@bluepopcorn.net> <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at>
Message-ID: <b7ac111fe780ea9a3949cd2ce0890967@imap.gmail.com>
X-Sender: sakimura@gmail.com
User-Agent: Roundcube Webmail/0.9.5
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/mGx3ePYfj4cQ9un7gRNDSQmkXzc>
Subject: Re: [VoT] Vectors of Trust I-D feedback
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list <vot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vot>, <mailto:vot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vot/>
List-Post: <mailto:vot@ietf.org>
List-Help: <mailto:vot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vot>, <mailto:vot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 06:42:34 -0000
2015-08-04 15:12 に Rainer Hoerbe さんは書きました: > 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 >> 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
- [VoT] Vectors of Trust I-D feedback Joanne Knight
- Re: [VoT] Vectors of Trust I-D feedback Rainer Hoerbe
- Re: [VoT] Vectors of Trust I-D feedback Justin Richer
- Re: [VoT] Vectors of Trust I-D feedback Rainer Hoerbe
- Re: [VoT] Vectors of Trust I-D feedback Nat Sakimura
- Re: [VoT] Vectors of Trust I-D feedback Jim Fenton
- Re: [VoT] Vectors of Trust I-D feedback Ira McDonald
- Re: [VoT] Vectors of Trust I-D feedback Nat Sakimura
- Re: [VoT] Vectors of Trust I-D feedback Joanne Knight
- Re: [VoT] Vectors of Trust I-D feedback Nat Sakimura
- Re: [VoT] Vectors of Trust I-D feedback Nat Sakimura
- Re: [VoT] Vectors of Trust I-D feedback Salvatore D'Agostino
- Re: [VoT] Vectors of Trust I-D feedback Rainer Hoerbe
- Re: [VoT] Vectors of Trust I-D feedback sakimura
- Re: [VoT] Vectors of Trust I-D feedback sakimura
- Re: [VoT] Vectors of Trust I-D feedback Nat Sakimura
- Re: [VoT] Vectors of Trust I-D feedback Patrick Curry
- Re: [VoT] Vectors of Trust I-D feedback Justin Richer
- Re: [VoT] Vectors of Trust I-D feedback Jim Fenton