> On Feb 8, 2024, at 6:41 AM, Edward Lewis <edward.le...@icann.org> wrote: > > ... > > When DNSSEC was designed, the possibility of tags colliding was known. The > validation process was defined to expect that a tag might lead to a > non-singleton set of keys. When it came to key management, and the practice > of storing keys in files named K<zone>-<sec_alg>-<key_tag>.public was > derived, the lone developer of DNSSEC code (at the time) sidestepped the odds > that key tags would collide by deleting the work done when creating a new key > pair if the file to be used already existed. This side-stepping practice was > never added to a standards document. (BTW, the reason for the "K" in the > filename was that we developed the protocol using a test root zone, meaning > the <zone> would be ".". A filename starting with "." is hidden in the OS > systems we used then, so we needed a prefix.)
This is a mischaracterization of history. Yes, dnssec-keygen would regenerate a key upon tag collision. This seemed like a reasonable thing to do. The behavior was never added into any standards document because it has nothing to do with the standard. The standards documents don’t describe how keys are stored, nor any tooling around their generation. If an implementation chooses to avoid generating keys which have the same key tag, that is an implementation issue, and doesn’t in any way make it noncompliant with the specification. There was no reason at the time why allowing for the generation of colliding keys would be useful, and I believe that’s still the case. The fact that no one’s updated the tools to allow this in almost 25 years is probably significant. If an implementation doesn’t support multiple keys with the same key tag when validating, that would be noncompliant. That was not the case, though. Brian
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
