-----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----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
