IETF Logo Mail Archive

Re: [keyassure] Bare keys again

Henry Story <henry.story@bblfish.net> Fri, 25 March 2011 06:53 UTC

Return-Path: <henry.story@bblfish.net>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51473A6964 for <keyassure@core3.amsl.com>; Thu, 24 Mar 2011 23:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.293
X-Spam-Level:
X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec1lhsNFiNNT for <keyassure@core3.amsl.com>; Thu, 24 Mar 2011 23:53:57 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A11A83A6811 for <keyassure@ietf.org>; Thu, 24 Mar 2011 23:53:56 -0700 (PDT)
Received: by bwz13 with SMTP id 13so727546bwz.31 for <keyassure@ietf.org>; Thu, 24 Mar 2011 23:55:30 -0700 (PDT)
Received: by 10.204.73.206 with SMTP id r14mr352980bkj.181.1301036129641; Thu, 24 Mar 2011 23:55:29 -0700 (PDT)
Received: from [192.168.1.10] (ALagny-751-1-3-15.w86-218.abo.wanadoo.fr [86.218.42.15]) by mx.google.com with ESMTPS id w3sm473670bkt.17.2011.03.24.23.55.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2011 23:55:28 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <4003BE42-F5AA-4AD2-BF27-21891975F7CE@vpnc.org>
Date: Fri, 25 Mar 2011 07:55:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F4784C6-6ED2-4BA7-A2E4-A4296BFFFF4A@bblfish.net>
References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <alpine.LFD.1.10.1103201932370.20162@newtla.xelerance.com> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <alpine.LFD.1.10.1103202028110.20162@newtla.xelerance.com> <1300669586.2117.12.camel@localhost> <alpine.LFD.1.10.1103202211390.20162@newtla.xelerance.com> <1300739370.2117.40.camel@localhost> <alpine.LFD.1.10.1103211631260.20162@newtla.xelerance.com> <AANLkTimyOXv66UeG2q2dmt1-e_Ek6WPPH-coueFc7fDS@mail.gmail.com> <AANLkTin1QjUbVFN8FqjL2SPRLSRRw4Ahs4zbhy4ZdZuX@mail.gmail.com> <alpine.LFD.1.10.1103211727150.28224@newtla.xelerance.com>, <alpine.LFD.1.10.1103230625150.18330@newtla.xelerance.com> <E6B327026515F942B2668762387B1DE303228CBD@MBX202.domain.local> <4003BE42-F5AA-4AD2-BF27-21891975F7CE@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1082)
Cc: "keyassure@ietf.org" <keyassure@ietf.org>
Subject: Re: [keyassure] Bare keys again
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2011 06:53:58 -0000

On 23 Mar 2011, at 16:19, Paul Hoffman wrote:

> On Mar 23, 2011, at 7:15 AM, Jeff Schmidt wrote:
> 
>> I'm new here, so I please accept all relevant apologies and I ask for all relevant leniance and guidance.
> 
> Guidance: read the list archives relevant to your concern. Search for issue #14, which was finished some time ago, and "bare key". This current thread is an attempt to re-open the issue.

Just to make that simpler, you can find it here:

http://trac.tools.ietf.org/wg/dane/trac/ticket/14

It was a long thread, so I added a pointer to one mail where I tried to summarise the issues on that issue page. There is at least a reasonably standard way to publish the keys, the one defined by X509 itself. 

What was still open was why one should add bare public keys, other than for reasons of elegance and bandwidth (which could be important, tests needed) to the options specified in Dane. Those arguing against claimed it could make things very difficult for a lot of software.

Henry

v2.23.0 | Report a Bug | By Email