The primary use of the key tag is to select the correct key to validate the signature from multiple keys.
-- Mark Andrews > On 10 Feb 2024, at 12:38, Wellington, Brian > <bwelling=40akamai....@dmarc.ietf.org> wrote: > > > >> 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_______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
