Re: [keyassure] publishing the public key

Paul Wouters <paul@xelerance.com> Sun, 20 February 2011 22:56 UTC

Return-Path: <paul@xelerance.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 791923A6DF1 for <keyassure@core3.amsl.com>; Sun, 20 Feb 2011 14:56:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 xbrQTYEIhG43 for <keyassure@core3.amsl.com>; Sun, 20 Feb 2011 14:56:21 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id A711D3A6CD6 for <keyassure@ietf.org>; Sun, 20 Feb 2011 14:56:21 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2AE55C59D; Sun, 20 Feb 2011 17:57:01 -0500 (EST)
Date: Sun, 20 Feb 2011 17:57:00 -0500
From: Paul Wouters <paul@xelerance.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
In-Reply-To: <AANLkTinVzkSa=ELhzWka7FH3=ErswbfjDgVKvk7Qu1mi@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.1102201754130.26752@newtla.xelerance.com>
References: <E1PqbYp-0008EI-Dx@login01.fos.auckland.ac.nz> <A2CF8378-6577-4AF2-9CD5-4992EE9B13B8@bblfish.net> <AANLkTinVzkSa=ELhzWka7FH3=ErswbfjDgVKvk7Qu1mi@mail.gmail.com>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Sun, 20 Feb 2011 22:56:23 -0000

On Sat, 19 Feb 2011, Phillip Hallam-Baker wrote:

> The problem with this approach is that it means that we are going to at best be exercising new code paths in existing
> code. At worst we are going to force people to write new code.
> 
> It is impossible to run TLS without X.509 code in the stack. Everything else is superfluous.
> 
> This is really bikeshedding. It is not going to simplify implementation by an iota and it is going to create yet another
> special case to support. 
> 
> I don't think the crypto community wants to support yet another key format. Even if that format is 'merely' a subset of
> an existing format.

The alternative is shipping a bunch of nonsense fields for eternity. If
you assume that the self signed certs will migrate to DNSSEC validation,
then that would be the vast majority of certificates out there. The
crypto community should not want that either, though I don't claim to
represent them.

Paul