[dnsext] draft-jabley-dnsop-validator-bootstrap-00

Joe Abley <jabley@hopcount.ca> Mon, 31 January 2011 19:29 UTC

Return-Path: <jabley@hopcount.ca>
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 2A7753A6C62; Mon, 31 Jan 2011 11:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 L9xI2KV46Hhs; Mon, 31 Jan 2011 11:29:23 -0800 (PST)
Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id EE37C3A6C4C; Mon, 31 Jan 2011 11:29:22 -0800 (PST)
Received: from [127.0.0.1] (helo=[IPv6:::1]) by monster.hopcount.ca with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <jabley@hopcount.ca>) id 1PjzYT-000A53-6g; Mon, 31 Jan 2011 19:36:54 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Joe Abley <jabley@hopcount.ca>
Date: Mon, 31 Jan 2011 14:32:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca>
To: dnsext List <dnsext@ietf.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>
X-Mailer: Apple Mail (2.1082)
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: jabley@hopcount.ca
X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false
Cc: Knight Dave <dave.knight@icann.org>
Subject: [dnsext] draft-jabley-dnsop-validator-bootstrap-00
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "dnsop@ietf.org WG" <dnsop@ietf.org>
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: Mon, 31 Jan 2011 19:29:24 -0000

Hi all,

Per below, Dave and I scribbled some thoughts down about how we might recommend validators obtain a useful root zone trust anchor on startup.

It's scrappy, and it's little more than I have said on this list in the past week, but I thought it might be handy to have in written form. I used a dnsop tag rather than a dnsext one at Andrew Sullivan's suggestion, since this looks like operations more than it looks like protocol work.

dnsoppers: there's a party going on in dnsext. Look over the fence for context.

Reply-To set.


Joe

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission@ietf.org>
> Date: 31 January 2011 14:24:56 EST
> To: Joe Abley <joe.abley@icann.org>
> Cc: Dave Knight <dave.knight@icann.org>
> Subject: New Version Notification for draft-jabley-dnsop-validator-bootstrap-00 
> 
> 
> A new version of I-D, draft-jabley-dnsop-validator-bootstrap-00.txt has been successfully submitted by Joe Abley and posted to the IETF repository.
> 
> Filename:	 draft-jabley-dnsop-validator-bootstrap
> Revision:	 00
> Title:		 Establishing an Appropriate Root Zone DNSSEC Trust Anchor at Startup
> Creation_date:	 2011-01-31
> WG ID:		 Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> Domain Name System Security Extensions (DNSSEC) allow cryptographic
> signatures to be used to validate responses received from the Domain
> Name System (DNS).  A DNS client which validates such signatures is
> known as a validator.
> 
> The choice of appropriate root zone trust anchor for a validator is
> expected to vary over time as the corresponding cryptographic keys
> used in DNSSEC are changed.
> 
> This document provides guidance on how validators might determine an
> appropriate trust anchor for the root zone to use at start-up, or
> when other mechanisms intended to allow key rollover to be tolerated
> gracefully are not available.
> 
> 
> 
> The IETF Secretariat.
> 
>