IETF Logo Mail Archive

[keyassure] publishing the public key

Henry Story <henry.story@bblfish.net> Mon, 14 February 2011 10:20 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 81A823A6CA3 for <keyassure@core3.amsl.com>; Mon, 14 Feb 2011 02:20:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.679
X-Spam-Level:
X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 Rnh5aoQmxyno for <keyassure@core3.amsl.com>; Mon, 14 Feb 2011 02:20:15 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 51A933A6CAA for <keyassure@ietf.org>; Mon, 14 Feb 2011 02:20:14 -0800 (PST)
Received: by fxm9 with SMTP id 9so5503012fxm.31 for <keyassure@ietf.org>; Mon, 14 Feb 2011 02:20:36 -0800 (PST)
Received: by 10.223.85.204 with SMTP id p12mr796833fal.146.1297678835968; Mon, 14 Feb 2011 02:20:35 -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 e17sm958977fak.10.2011.02.14.02.20.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 02:20:35 -0800 (PST)
From: Henry Story <henry.story@bblfish.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 14 Feb 2011 11:20:33 +0100
Message-Id: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net>
To: keyassure@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [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: Mon, 14 Feb 2011 10:20:17 -0000

Hi,

  In draft-dane-04 [1] one can currently only publish either a signature or a certificate in the DNS. That is the only allowed formats of the resource record are as specified in section 2.2

  1 -- Hash of an end-entity certificate
  2 -- Full end-entity certificate in DER encoding
  3 -- Hash of an certification authority's certificate
  4 -- Full certification authority's certificate in DER encoding

Why not publish the only piece of the certificate that is important in public key cryptography: the public key. ( This is what WebID does currently ) This should be shorter than the certificate, and though it will be longer than the signature, it will be a lot more useful, tying the publisher much less to a particular serialisation format. So you reduce the PGP/X509 disagreements.

There is no need to send a full certificate. Many users will only need to tie a name to a public key and to have a guarantee of the integrity of the information. But the integrity is itself assured by DNSSEC. The tying of the name to the public key is done by the lookup in DNS, as with eg: _443._tcp.www.example.com ) So all that is really required is to return the public key - the type (RSA, DSA, ...) and the fields. This can be done in ASN.1.

  The following use case may help: Imagine a future revision of TLS, which permits the server to not send the server certificate, a bit as the client_certificate_url extension of TLS 1.2 allows the client to send a URL to a location of his certificate, instead of sending his certificate in order to save bandwidth. Here the server just tells the client to look up his public key in DNSSEC .  This would then save bandwidth at both ends: the server would not need to send his certificate and DNSSEC would just send the minimal information needed to confirm. 

   The public key by itself would not be able to contain the types of restrictions on usage of the key of course: only use for signing, ... that are available in X509. 

   An important question is of course: how much bandwidth does one save?

Henry

[1] http://tools.ietf.org/html/draft-ietf-dane-protocol-04

Social Web Architect
http://bblfish.net/

v2.23.0 | Report a Bug | By Email