Re: [stir] current draft charter

Henning Schulzrinne <hgs@cs.columbia.edu> Wed, 12 June 2013 17:24 UTC

Return-Path: <hgs@cs.columbia.edu>
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 5E43F21F9123 for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 10:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.579
X-Spam-Level:
X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 2T+8KpKHDpJN for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 10:24:04 -0700 (PDT)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id BA37421F9BBC for <stir@ietf.org>; Wed, 12 Jun 2013 10:23:37 -0700 (PDT)
Received: from [172.20.24.193] (65-125-25-71.dia.static.qwest.net [65.125.25.71]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5CHNMWn011001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Jun 2013 13:23:27 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <51B8AC13.5040502@bbiw.net>
Date: Wed, 12 Jun 2013 13:23:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <66970CD0-556D-4DF4-B20F-567B931B2CD1@cs.columbia.edu>
References: <CDDD28BB.1F0A5%jon.peterson@neustar.biz> <51B84BAA.8020004@cs.tcd.ie> <51B8AC13.5040502@bbiw.net>
To: Dave Crocker <dcrocker@bbiw.net>
X-Mailer: Apple Mail (2.1503)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Cc: "stir@ietf.org" <stir@ietf.org>, "Peterson, Jon" <jon.peterson@neustar.biz>, 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 17:24:20 -0000

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
>