[DNSOP] trust-history-01 text changes

"W.C.A. Wijngaards" <wouter@NLnetLabs.nl> Tue, 16 March 2010 16:04 UTC

Return-Path: <wouter@nlnetlabs.nl>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 4ADA43A69E6 for <dnsop@core3.amsl.com>; Tue, 16 Mar 2010 09:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id IOwI8bv2C5V0 for <dnsop@core3.amsl.com>; Tue, 16 Mar 2010 09:04:23 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 8819B3A681E for <dnsop@ietf.org>; Tue, 16 Mar 2010 09:04:22 -0700 (PDT)
Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o2GG4SuO061641 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsop@ietf.org>; Tue, 16 Mar 2010 17:04:28 +0100 (CET) (envelope-from wouter@nlnetlabs.nl)
Message-ID: <4B9FAC0C.1080305@nlnetlabs.nl>
Date: Tue, 16 Mar 2010 17:04:28 +0100
From: "W.C.A. Wijngaards" <wouter@NLnetLabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc11 Thunderbird/3.0.3
MIME-Version: 1.0
To: dnsop@ietf.org
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 16 Mar 2010 17:04:28 +0100 (CET)
Subject: [DNSOP] trust-history-01 text changes
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2010 16:04:24 -0000

Hash: SHA1


Changes to trust-history draft that are to be done are listed below.
There are no open issues that I am aware of.

Section 3.
* step 1. change: Otherwise, store the DNSKEY RR set as result
to: Otherwise, store the possibly empty DNSKEY RR set as result.

* step 1. change: Otherwise, the history lookup fails.
to: The algorithm should not continue but fails.

* step 2. change: Fetch the trust history list end points.
to: Fetch the trust history list names for the first and last key set.

* step 2, put after: "trying to update the trust-anchor for",
text: or lookup the TALINK in the zone.

* step 3, change: "Go backwards through the trust history list as
provided by the TALINK linked list."
to: "Step backwards through the trust history list as provided by the
TALINK linked list until valid with the currently configured
trust-anchor, then go to step 4.  At each step perform the following checks.

* step 3, remove 'Editor note: Are we shure that there are no server
implementations that will not server expired RRSIG, are such smart
servers allowed by the specs. In other words do we need clarification in
the DNSSEC-updates document? '.
There are no known obstacles to publishing signatures with old dates.

Section 5.
* instead of h0,h1,h2 make the example have the domains in the list: h0,
h1, .., hi-1, hi.  Luckily hi-1 is LDH and an allowed hostname :-)

Section 6.
* change the first line: "The trust history is advertised with TALINK
RRs at the zone apex"
to: "The trust history can be and may be advertised with TALINK RRs at
the zone apex".

Section 7 (security considerations)
* Insert a new heading: "Revoked Keys" before the paragraph that
discusses 5011. remove the last line from that paragraph, 'The old keys
that the ... if they are revoked' and instead put: If the final result
of the algorithm contains revoked keys then those keys must be put in
state REVOKED and not state VALID.  The check in step 4 must of course
succeed with the currently configured keys that are in state VALID.

* Insert a new heading "Trust history versus 5011" before the paragraph
'Depending on choices by the validator operator".
* Insert a new heading "Time".

* Remove the paragraph 'The algorithm can be used to get inception and
expiration ... visible to others'.  Instead put: the expiration times
are not checked during the history algorithm, but the final keyset
should validate with the current time, as it represents the keyset
currently in use.   [ And this naturally leads to Barwood's comments
about influencing the validator clock ]

Best regards,
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/