Some comments on draft-ietf-dnsop-dnssec-trust-anchor-01: Section 2, last para
# A validating resolver MAY support #configuration using a truncated DS hash value as a human-factors #convenience: shorter strings are easier to type and less prone to #error when entered manually. There should be some guidance on the amount of truncation allowed. For instance, can the DS hash be truncated to a single byte? (I assume not) ------------- Section 3 : I don't understand the usage of the word "priming" here. The steps that are described are *exactly* what would need to happen during the normal DNSSEC validation process. I can see the need for priming DNSKEYs when trust anchors are also configured as DNSKEYs (in which case priming helps the validator determine if the configured DNSKEYs are the same as the ones published) but I don't see the need for priming DNSKEYs when the trust anchors are specified as DS records. Or, are we instead saying here that DNSKEYs fetched through the priming process will not be subject to TTL expiration (which, I think, shouldn't be the case either)? ------------- Also in Section 3, second-last para # A validating resolver should remove a trust anchor # that has been revoked as indicated by the REVOKE bit in the # corresponding DNSKEY record as described in RFC 5011 [6]. We may not want to necessarily combine resolver behavior with trust anchor management. The two are different tasks and can be accomplished using different tools. I'd suggest simply deleting this sentence and modifying the para to read: "If there are multiple trust anchors configured for a zone, any one of them is sufficient to validate data in the zone. For this reason, old trust anchors SHOULD be removed from a validating resolver's trust anchor list soon after the corresponding keys are no longer used by the zone, as described in RFC 5011 [6]." _______________________________________________ DNSOP mailing list [email protected] http://www.ietf.org/mailman/listinfo/dnsop
