Re: [keyassure] publishing the public key

Henry Story <henry.story@bblfish.net> Tue, 15 February 2011 11:32 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 E135F3A6C8B for <keyassure@core3.amsl.com>; Tue, 15 Feb 2011 03:32:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.383
X-Spam-Level:
X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
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 Y4z+EQ+58y+6 for <keyassure@core3.amsl.com>; Tue, 15 Feb 2011 03:32:24 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id BA3FA3A6B74 for <keyassure@ietf.org>; Tue, 15 Feb 2011 03:32:24 -0800 (PST)
Received: by gyd12 with SMTP id 12so22533gyd.31 for <keyassure@ietf.org>; Tue, 15 Feb 2011 03:32:49 -0800 (PST)
Received: by 10.150.200.20 with SMTP id x20mr5882760ybf.56.1297769569671; Tue, 15 Feb 2011 03:32:49 -0800 (PST)
Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id r24sm2390434yba.6.2011.02.15.03.32.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Feb 2011 03:32:48 -0800 (PST)
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: <alpine.LFD.1.10.1102142148260.3131@newtla.xelerance.com>
Date: Tue, 15 Feb 2011 12:32:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3481D436-8F39-472C-BD8A-1F67415C44A2@bblfish.net>
References: <E1PpApf-00066M-H2@login01.fos.auckland.ac.nz> <alpine.LFD.1.10.1102142148260.3131@newtla.xelerance.com>
To: Paul Wouters <paul@xelerance.com>
X-Mailer: Apple Mail (2.1082)
Cc: keyassure@ietf.org, paul.hoffman@vpnc.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: Tue, 15 Feb 2011 11:32:26 -0000

On 15 Feb 2011, at 03:49, Paul Wouters wrote:

> On Tue, 15 Feb 2011, Peter Gutmann wrote:

( Btw, I could not find the thread of this discussion in context, and this
may be reflected in my reply. It would help to point to the web archive 
if it's an older post that is being replied to here. )

> 
>> A public key contains a number of components and options. For example for ECC
>> there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, h for
>> binary curves), an indication of the underlying field (prime or binary), the
>> point format, whether point compression is used, polynomial vs. normal basis,
>> whether fixed domain parameters are used, and probably some other stuff I've
>> forgotten.  How is all this stuff communicated?
> 
> I see.

At the simplest, can one not just take the  public key part of the ASN.1 that comes in an X.509 certificate, and pop that DER encoded in the yet to be named value field? 

Pro: it clearly is defined
Con: there is a bit of remaining ASN.1, but it's a lot less than before :-)

At least that shows that there is one easy solution. 

> 
>> this (a) ain't gonna cut it because it doesn't cover what's required by TLS
>> and (b) requires that your TLS implementation speak DNSSEC (or at least the
>> DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors being
>> too enthusiastic about this.
> 
> Okay.

Assuming this discussion is about publishing a public key in DNSSEC - let's not
care about the format - I would reply the following

(a) not sure why this answer was made
(b) Using the public key published in DNSSEC does not require that the TLS 
implementation speak DNSSEC. Current browsers that deal with millions of self
signed certificates on the internet will show ugly dialogs as they do now.
But future browser that are DNSSEC aware could use keyassure to give a better
dialog. They might not get EV certificate dialog, but at least they will know that
they have connected to the correct service.

They can do (b) whether the certificate is published in DNSSEC or whether the
public key is published there. It does not matter. After all the certificate contains
the public key, plus extra information.

Henry


> 
> I'll have to do some more reading to ensure I understand everything, and I'll
> write up something for this for you to check.
> 
> Thanks!
> 
> Paul
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure

Social Web Architect
http://bblfish.net/