Re: [dnsext] Historical root keys: The Large Router Vendor Speaks

John Bashinski <jbash@cisco.com> Fri, 28 January 2011 17:54 UTC

Return-Path: <jbash@cisco.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A643A6941 for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 09:54:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
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 RS6NkpBn0KGp for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 09:54:47 -0800 (PST)
Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id 5ACB63A68CB for <dnsext@ietf.org>; Fri, 28 Jan 2011 09:54:47 -0800 (PST)
Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 9C3E81A530B; Fri, 28 Jan 2011 12:57:50 -0500 (EST)
Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id B7B836726; Fri, 28 Jan 2011 12:57:49 -0500 (EST)
Message-ID: <4D43039D.4080604@cisco.com>
Date: Fri, 28 Jan 2011 12:57:49 -0500
From: John Bashinski <jbash@cisco.com>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7
MIME-Version: 1.0
To: Alex Bligh <alex@alex.org.uk>
References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> <6E1BDC90802ED85AFE548AD0@Ximines.local>
In-Reply-To: <6E1BDC90802ED85AFE548AD0@Ximines.local>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigF09041A195BF86AE1C66D9A7"
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, dnsext@ietf.org
Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2011 17:54:48 -0000

On 2011-01-28 12:34, Alex Bligh wrote:
>> That person or persons is NOT going to be the same person or persons
>> who generates the software loads. I'm adding a new trusted entity
>> to the system.
> 
> Isn't the person who generates software loads already going to have
> to put the (then current) root key / zone into the image? If so, isn't
> this person already a trusted entity?

Yes, but originally I had *just* the software person. Now I have the
software person *plus* the person who signs new DNSSEC keys for the
DNSSEC discovery process.

Also, the person generating software loads is only trusted at software
installation time. The person generating DNSSEC keys is trusted at
DNSSEC key learning time. So there's a temporal extension of trust
as well.

						-- jbash