Re: [stir] Way outside the "box" use case

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 29 February 2016 20:48 UTC

Return-Path: <prvs=0867c13407=pkyzivat@alum.mit.edu>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1AA1B3BA7 for <stir@ietfa.amsl.com>; Mon, 29 Feb 2016 12:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 90_Fy82uNJfA for <stir@ietfa.amsl.com>; Mon, 29 Feb 2016 12:48:32 -0800 (PST)
Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 840DA1B3BCA for <stir@ietf.org>; Mon, 29 Feb 2016 12:48:32 -0800 (PST)
X-AuditID: 12074413-f03ff7000000516b-22-56d4ae9fbc7e
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 74.C2.20843.F9EA4D65; Mon, 29 Feb 2016 15:48:31 -0500 (EST)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u1TKmU6C008764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <stir@ietf.org>; Mon, 29 Feb 2016 15:48:31 -0500
To: stir@ietf.org
References: <6C117DC2-2F50-410C-81DD-4482B0A76D8F@standardstrack.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56D4AE9D.6030203@alum.mit.edu>
Date: Mon, 29 Feb 2016 15:48:29 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <6C117DC2-2F50-410C-81DD-4482B0A76D8F@standardstrack.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixO6iqDt/3ZUwg4m7NC2Wr93G5MDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7oyrpzYyF+xlrzgx4T97A2MHWxcjJ4eEgInEuuVXgGwuDiGB rYwSXbs7GSGcn0wSjxZdA6sSFjCS6GyaxgxiiwgIStybcZoJxBYScJU4OvEPK4jNJqAlMefQ f5YuRg4OXgFtiRd3uEDCLAKqEldPTmAEsUUF0iRm9U1gAbF5gcacnPkErJxTwE3i9WsJkDCz gK3Enbm7mSFseYnmrbOZJzDyzULSMQtJ2SwkZQsYmVcxyiXmlObq5iZm5hSnJusWJyfm5aUW 6Zrr5WaW6KWmlG5ihASZ8A7GXSflDjEKcDAq8fDOWHolTIg1say4MvcQoyQHk5Io75s1QCG+ pPyUyozE4oz4otKc1OJDjBIczEoivArtQDnelMTKqtSifJiUNAeLkjiv2hJ1PyGB9MSS1OzU 1ILUIpisDAeHkgQvGzCahASLUtNTK9Iyc0oQ0kwcnCDDuaREilPzUlKLEktLMuJBcRdfDIw8 kBQP0F6wdt7igsRcoChE6ylGXY4FP26vZRJiycvPS5US5w1ZC1QkAFKUUZoHtwKWUl4xigN9 LMy7D6SKB5iO4Ca9AlrCBLREYv0lkCUliQgpqQZGlf7/yrGZ0XnV9lendK+v5p4ffDy00ffB 0u27zs1+as4cYX+hjJtp2vHGa2IZ5/U+nIxYcyzge2iqQhi/jrgXo97+i7qXfRecPxiYGNT7 THUyS6Bu/QXv4HnbLY2CS8q1Lzl9Vl95v2qdiVeuJFur/3zt/Pc8b7/dKCywV2Xbv/o8j9on nvtKLMUZiYZazEXFiQBs8TqsBAMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/LpKnR20iC6FVq5BtzYvxYFnMH2s>
Subject: Re: [stir] Way outside the "box" use case
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Feb 2016 20:48:36 -0000

On 2/29/16 12:38 PM, Eric Burger wrote:
> For the people on the STIR list: there is a potential WG being discussed in BA, LURK, that is principally looking at the problem of a content provider somehow allowing a CDN to sign on their behalf so that HTTPS and browsers “do the right thing.” If this sounds /similar/ to the STIR problem of delegated enterprise identity attestation, it should. See:
> https://trac.tools.ietf.org/bof/trac/
> and scroll down to “Security” or search for “LURK”.
> PLEASE, if you care about this issue, continue the discussion on the LURK list, not the STIR list. Thanks. See:
> https://www.ietf.org/mailman/listinfo/lurk

ISTM that these problems are different, because (I think) in the LURK 
case the identity is tied to the DNS naming hierarchy, while in STIR is 
is tied to E.164 numbers. So for LURK I would think there are solutions 
that naturally link to DNS, but for STIR that won't work.

	Thanks,
	Paul