[DNSOP] trust-history-01 text changes

["W.C.A. Wijngaards" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

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,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkufrAwACgkQkDLqNwOhpPhrrACfeK7P8/wwz2+2iqOtdlvfCFmt
JowAnjqShnty0H8jV5Ha2axXOuAzLtKl
=HLPS
-----END PGP SIGNATURE-----