Re: [keyassure] publishing the public key

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 19 February 2011 01:41 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 0DC893A6CEF for <keyassure@core3.amsl.com>; Fri, 18 Feb 2011 17:41:15 -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=[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 ncmhKPBuBMND for <keyassure@core3.amsl.com>; Fri, 18 Feb 2011 17:41:14 -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 BAEF83A6C77 for <keyassure@ietf.org>; Fri, 18 Feb 2011 17:41:13 -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=1298079709; x=1329615709; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20keyassure@ietf.org,=20paul.hoffman@vpnc.org |Subject:=20Re:=20[keyassure]=20publishing=20the=20public =20key|In-Reply-To:=20<4D5A9C2F.6050205@vpnc.org> |Message-Id:=20<E1PqbpT-0000pd-Kz@login01.fos.auckland.ac .nz>|Date:=20Sat,=2019=20Feb=202011=2014:41:47=20+1300; bh=ao8H5hRi42B2yGvcgl7YoSM9430XZBO2U0LuT3GDJ18=; b=BMQGVoa/HUjyDtDsaydIvA8dmuv8ZpS8jban6lTFP06XITzhoLW8TPQK w83fYQB7n7PwM4E6TjQ2DDD9UjZYpjmotAEDy24I0KppI0wWD3/Jtronq 8fEVhWK/mZthCIZeBexs0/p8FfiWXf9CWw6IqWgiw1nKuqdt7zhhv6NX4 Q=;
X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46882521"
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; 19 Feb 2011 14:41:47 +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 1PqbpT-0004G9-IO; Sat, 19 Feb 2011 14:41:47 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PqbpT-0000pd-Kz; Sat, 19 Feb 2011 14:41:47 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: keyassure@ietf.org, paul.hoffman@vpnc.org
In-Reply-To: <4D5A9C2F.6050205@vpnc.org>
Message-Id: <E1PqbpT-0000pd-Kz@login01.fos.auckland.ac.nz>
Date: Sat, 19 Feb 2011 14:41:47 +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 01:41:15 -0000

Paul Hoffman <paul.hoffman@vpnc.org> writes:

>I disagree that us using bare keys for identifying TLS server certificates is
>impossible.

It's not impossible, but close to it (and for ECC algos it may well be
impossible).  This is a really, really bad way to identify a cert.  For
relatively simple algorithms like RSA "all" you need to do is decode the key
in the cert (assuming your PKI API actually gives you access to it, if it just
treats the cert as a blob used for signing or encryption then you may not be
able to get to it), decode the key in DNS, canonicalise the two in some
manner, and then compare the components (as opposed to storing a hash of the
cert, for which you call memcmp(), thus the "all" in quotes above).  For ECC
keys there are so many ways to store the same key (different parameter
encodings, optional parameters, different ways of identifying the same
parameters and in different formats) that in general there's no really
reliable way to compare them.  Even with the simplest key type, RSA, it was
hard enough, I've got code that mostly works most of the time and that's way
more complicated than it has to be.

If you want to uniquely identify a certificate, use the SHA-1 hash like
everything else does.

Peter.