Re: [keyassure] publishing the public key

Phillip Hallam-Baker <hallam@gmail.com> Sat, 19 February 2011 20:33 UTC

Return-Path: <hallam@gmail.com>
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 0D38D3A6FB9 for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 12:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.523
X-Spam-Level:
X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FqTSjbOEXz7o for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 12:33:38 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8CCB03A6FA1 for <keyassure@ietf.org>; Sat, 19 Feb 2011 12:33:38 -0800 (PST)
Received: by iwl42 with SMTP id 42so1600033iwl.31 for <keyassure@ietf.org>; Sat, 19 Feb 2011 12:34:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vBEJCnsDV92mTUD2/tkBfN30uISjlru+M2Rcivdxelg=; b=ALInhwb0fEm7l+BMbke5fBdZMELApJrm09ycJ3TZcCZTeYrkeet8Karho4QryBBQaO PiyIXDDvtVbFatNiv89aUj9R3FXrx4mMRKith7WpfJsXcX1JfNmRU62ntI49Km/2+q1/ u73SME4d8mbqD9bxESwdQ1ugVciTvVsBAgv34=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vxl8DSvfBV8Adw3XEfIRV3bIKesO+q2BfRaWGAM8u0yTbCufIWVVsfLiK8JeFOteZ9 w0NztUKi160tCkZ54PtzgqtRI5iOpIlaMvOfl3QbjKr9Qt02dNy6kte/mvQbpeRiXZOh ppwKOjj8s3ZUTzZGQFC5Ik3P5o/9DtTBYMx/E=
MIME-Version: 1.0
Received: by 10.42.4.1 with SMTP id 1mr2724355icq.370.1298147655365; Sat, 19 Feb 2011 12:34:15 -0800 (PST)
Received: by 10.42.215.140 with HTTP; Sat, 19 Feb 2011 12:34:15 -0800 (PST)
In-Reply-To: <E1Pqskq-0004pb-JY@login01.fos.auckland.ac.nz>
References: <A2CF8378-6577-4AF2-9CD5-4992EE9B13B8@bblfish.net> <E1Pqskq-0004pb-JY@login01.fos.auckland.ac.nz>
Date: Sat, 19 Feb 2011 12:34:15 -0800
Message-ID: <AANLkTikab+En5hMgGLV-hXQT2XCSBO676z-WDQhdpduX@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="0016e68f67d8dd363e049ca88d2e"
Cc: keyassure@ietf.org
Subject: Re: [keyassure] publishing the public key
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: Sat, 19 Feb 2011 20:33:40 -0000

I agree with Peter here.

Folk who are bike-shedding this one need to understand that he is the person
they need to persuade to write the code.


At RSA he demonstrated a large number of issues with PKI that largely come
from it giving more options than people care to know what to do with. DNSSEC
is already more complex than X.509 was at a similar stage of deployment.

What appears to be a simpler mechanism to implement is only going to save
time and effort if it REPLACES the existing mechanism completely and
ELIMINATES the need to code for it.


Comparison to the design choices in FOAF is not very helpful since 1) FOAF
has something of a traction/deployment problem in itself and 2) use in FOAF
does not disrupt an existing deployed infrastructure.

Predicting the security implications for a design change for a security
protocol deployed for 16 years is going to be very error prone.


On Sat, Feb 19, 2011 at 11:46 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz>wrote:

> Henry Story <henry.story@bblfish.net> writes:
>
> >My question is: what do people use now to pass public keys?
>
> X.509 key bags.
>
> >I know an X509 cert contains the public key, though I don't know if it can
> >contain ECC keys.
>
> It can contain any kind of key for any algorithm likely to be used with
> TLS.
>
> >If it does then there is another simple answer: extract the part of that
> >document that contains both the type of the key and the details of it, and
> >use that.
>
> In that case why not just stick with X.509?  This is bizarre, you have a
> universally-agreed-on, universally-supported format, and you're proposing
> to
> extract a subset of that requiring custom coding in each implementation to
> support and use that?
>
> Another reason to stick with X.509 as key bags is that eventually you're
> going
> to want to put policy in the DNS ("must connect with TLS", "must use EV
> certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS
> algorithms", and so on).  Guess what X.509v3 key bags were specifically
> designed for?
>
> The end result is that you'll end up reinventing X.509 as a container
> format,
> only it'll be some homebrew parallel format that needs custom code to
> support
> and endless kludging as things get bolted on that'd be automatically
> supported
> in the X.509 key bag format.  It's reinventing the wheel, but making it
> square
> just to be different.
>
> Peter.
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
>



-- 
Website: http://hallambaker.com/