IETF Logo Mail Archive

Re: [keyassure] publishing the public key

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 21 February 2011 02:42 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 B727C3A6D52 for <keyassure@core3.amsl.com>; Sun, 20 Feb 2011 18:42:22 -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 P8hhHrq2UiIY for <keyassure@core3.amsl.com>; Sun, 20 Feb 2011 18:42:21 -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 6D3DD3A6F57 for <keyassure@ietf.org>; Sun, 20 Feb 2011 18:42:19 -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=1298256182; x=1329792182; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20hallam@gmail.com,=20paul@xelerance.com|Subject:=20 Re:=20[keyassure]=20publishing=20the=20public=20key|Cc: =20keyassure@ietf.org|In-Reply-To:=20<AANLkTinnRJjf0p8c8z JO_hNKvrKeYOLjR6_5XaziJM+L@mail.gmail.com>|Message-Id:=20 <E1PrLjg-00071d-FO@login01.fos.auckland.ac.nz>|Date:=20Mo n,=2021=20Feb=202011=2015:42:52=20+1300; bh=pSTq/tKrMrMhECOCV6JjxOtp7nNiDT0W2yTmEq+t1x4=; b=APyTgf0iZcvM0Xw7vlymg+nOrqLVaXysAW44NM7gm6Tj8O9tcoFN++Pf PDRAP5Q5UVX/PsmU3X1i+oEOvzN/gmayqewB9EYsMwKrt6PKzxzO0C9XQ BI3jCyNil2fWoGovpHY99LKd6ZWEj7/hMUPcxqVvabtOoeqOdborp2Xym c=;
X-IronPort-AV: E=Sophos;i="4.62,197,1296990000"; d="scan'208";a="47074700"
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; 21 Feb 2011 15:42:52 +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 1PrLjg-000811-Hp; Mon, 21 Feb 2011 15:42:52 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PrLjg-00071d-FO; Mon, 21 Feb 2011 15:42:52 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: hallam@gmail.com, paul@xelerance.com
In-Reply-To: <AANLkTinnRJjf0p8c8zJO_hNKvrKeYOLjR6_5XaziJM+L@mail.gmail.com>
Message-Id: <E1PrLjg-00071d-FO@login01.fos.auckland.ac.nz>
Date: Mon, 21 Feb 2011 15:42:52 +1300
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: Mon, 21 Feb 2011 02:42:22 -0000

Phillip Hallam-Baker <hallam@gmail.com> writes:

>You do not make code simpler by introducing additional code paths. You only
>make code simpler if you remove them. The way to make this code base simpler
>is to remove the code path that you are proposing.

Couldn't have put it better myself.  To respond to the OP, instead of guessing 
what implementers might in theory do if you bothered to ask them, why not 
actually ask them?  As a TLS implementer myself, I have absolutely zero 
interest in supporting yet another arbitrary key format (and the ensuing 
increase in complexity and attack surface), particularly one that serves no 
purpose that I've been able to identify.

Peter.

v2.23.0 | Report a Bug | By Email