IETF Logo Mail Archive

Re: [stir] current draft charter

"Peterson, Jon" <jon.peterson@neustar.biz> Wed, 12 June 2013 18:23 UTC

Return-Path: <jon.peterson@neustar.biz>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0211E80E8 for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 11:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.53
X-Spam-Level:
X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46w0EEYG775q for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 11:23:10 -0700 (PDT)
Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 253F011E80CC for <stir@ietf.org>; Wed, 12 Jun 2013 11:23:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371061555; x=1686416367; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=dUi8IeYocs E0auLan1ezFnFAKdg/qOEWvS9f4E+oZws=; b=SGNNofIFrjyMAQZiOXOHxSRlsp /3fBo8BEsuzGs7RTLImcW2XzJXlsek1jiNhANlmXBWEi+KQDNHMejz9bhS6w==
Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25012062; Wed, 12 Jun 2013 14:25:54 -0400
Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 14:22:50 -0400
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: Henning Schulzrinne <hgs@cs.columbia.edu>, Dave Crocker <dcrocker@bbiw.net>
Thread-Topic: [stir] current draft charter
Thread-Index: AQHOZwiVGT8OWD09JUqSfli80C7Gm5kxkloA//+WdYCAAPljAIAAcu6AgAADDoD//5sjgA==
Date: Wed, 12 Jun 2013 18:22:50 +0000
Message-ID: <CDDE043A.1F643%jon.peterson@neustar.biz>
In-Reply-To: <66970CD0-556D-4DF4-B20F-567B931B2CD1@cs.columbia.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [192.168.128.117]
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: hndCfVFqq5ICX69N7E6xWQ==
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EED81852D13C144E9C9FAC827BA9AC76@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "stir@ietf.org" <stir@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [stir] current draft charter
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 12 Jun 2013 18:23:14 -0000

Agreed. Though I do think that even for the domain model, we could get
some value from looking at DANE to improve the way that credentials are
managed. Whether we put the keys in the DNS or just point to the approved
cert by reference, we should probably have some means for the successor to
RFC4474 Identity-Info to tip off relying parties to DANE.

But yes, for the telephone model it seems unlikely that casting these as
domain names will get us very far.

Jon Peterson
Neustar, Inc.

On 6/12/13 10:23 AM, "Henning Schulzrinne" <hgs@cs.columbia.edu> wrote:

>The simple semantics sounds similar to the RFC 4744 model for SIP URIs.
>As discussed in various drafts, this model unfortunately doesn't work
>well for the domain-less case, such as telephone numbers.
>
>On Jun 12, 2013, at 1:12 PM, Dave Crocker <dcrocker@bbiw.net> wrote:
>
>> On 6/12/2013 3:21 AM, Stephen Farrell wrote:
>>> That's a fair point. However, I'd argue that the difference between
>>> a DKIM-like and RPKI-like approach is far from just syntax. For
>>> example, in an RPKI-like approach the callee has to verify who
>>> delegated what to whom in order to check the signature (e.g. via
>>> 5280 NameConstraints). With a DKIM-like approach, that's done in
>>> some un- or differently-specified way by some infrastructure (before
>>> making the public key available) and isn't directly visible to the
>>> callee. That's definitely not just syntax I reckon.
>> 
>> 
>> My simplistic description of the DKIM-like model is that the storage
>>location constitutes the cert.
>> 
>> The semantic of the cert is "the owner of this location authorizes use
>>of the key".  Since the 'location' is a place in the DNS, the owner of
>>the domain name at that location is validating use of the private key.
>> 
>> For very simple cert semantics like this, it works.  Semantics that are
>>more complex probably won't.
>> 
>> d/
>> 
>> -- 
>> Dave Crocker
>> Brandenburg InternetWorking
>> bbiw.net
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>> 
>

v2.23.0 | Report a Bug | By Email