Re: [keyassure] publishing the public key

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 19 February 2011 19:45 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
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 C52F03A6D6A for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 11:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 YamOMBrEkdh9 for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 11:45:35 -0800 (PST)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A9F4E3A6E28 for <keyassure@ietf.org>; Sat, 19 Feb 2011 11:45:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298144772; x=1329680772; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20henry.story@bblfish.net,=20keyassure@ietf.org |Subject:=20Re:=20[keyassure]=20publishing=20the=20public =20key|In-Reply-To:=20<A2CF8378-6577-4AF2-9CD5-4992EE9B13 B8@bblfish.net>|Message-Id:=20<E1Pqskq-0004pb-JY@login01. fos.auckland.ac.nz>|Date:=20Sun,=2020=20Feb=202011=2008:4 6:08=20+1300; bh=hK/7t3JDPksvDPytjLFERHGIdzLpkdDx654c+9phUOw=; b=j0PDMB5zDpOIGwmK5kzW6jkyOMQbgntAtD5qmRmVcJQnzgeAjfbh7ljy f68AacDT/0qAGXYrXzaOx86k6CFqu57U6stUQXT4z1ZazVeiSCDDEwN8Z x8Xg+OBMarexsvY4M00E9wrRD6DTPAkXfd7eUMFOlnN3AYidX55PPZFA9 M=;
X-IronPort-AV: E=Sophos;i="4.62,192,1296990000"; d="scan'208";a="46927781"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Feb 2011 08:46:09 +1300
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Pqskq-0000gd-IE; Sun, 20 Feb 2011 08:46:08 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Pqskq-0004pb-JY; Sun, 20 Feb 2011 08:46:08 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: henry.story@bblfish.net, keyassure@ietf.org
In-Reply-To: <A2CF8378-6577-4AF2-9CD5-4992EE9B13B8@bblfish.net>
Message-Id: <E1Pqskq-0004pb-JY@login01.fos.auckland.ac.nz>
Date: Sun, 20 Feb 2011 08:46:08 +1300
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 19:45:36 -0000

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.