I think this draft is a good idea and should be adopted, but needs some improvements first.
1. In Section 4: "unsecure" should be "insecure". 2. REQ2: What should happen when there are multiple trust anchors, but only one failed to validate? E.g. a validator has both the root and .exampleTLD in its trust store, but missed the root rollover. The .exampleTLD key still validates, but the root doesn't. Should all validation stop? Or set a warning, but continue to validating (succeeding only for .exampleTLD)? 3. REQ18: I don't think I understand this. Wouldn't the best way to see which algorithm(s) are in use for a given zone would be just to send a query? Authoritative zones really may not "know" any algorithm besides SHA-1, as it is likely not doing online signing, but serving whatever a signing utility chose. 4. Should there be a mention as to which algorithms a validator should support? It may not require a direct reference to whichever RFC is current, but simply listing the IANA maintained registry and say "implement all the MUSTs and probably the SHOULDs too". Something like the following: Algorithm Usage in Validators DNSSEC signatures can be generated by different digital signatures algorithms. The current list of algorithms defined for use with DNSSEC is published in an IANA maintained registry [insert IANA link here]. Validators have to be able to understand and validate different algorithms that may be in common use with DNSSEC. The DNSSEC digital signature registry table is regularly updated with guidance as to which algorithms are considered MANDATORY and/or RECOMMENDED. In order to be effective, a validator MUST understand all digital signature algorithms marked as MANDATORY and SHOULD understand all digital signature algorithms marked as RECOMMENDED. REQXX: Validators MUST implement all MANDATORY digital signature algorithms and SHOULD implement all RECOMMENDED digital signature algorithms. Note: This wording isn't the best, and needs some work. I also don't know if the SHOULD in the REQ should be changed to a MAY, but I would prefer SHOULD. Scott
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
