>We could say that signers MUST NOT create colliding key tags, and that >verifiers and similar tooling must continue to work as they currently do. > >That way, perhaps in (next decade + 1 year) we can discuss updating the >verifier behavior. > >"The best time to plant a tree was 20 years ago. The second best time is >now" and all that...
I agree with this. For a signer it can be a lot easier to just let collisions happen (and testing is also an issue). With an HSM, creating a key and then deleting it because of a collision is already not pleasant. But some operators generate keys a year in advance. Some operators have a specific procedure for generating ZSKs with an offline KSK. Some procedures for moving from one signer to another involve creating a temporary multi-signer setup. What if the two signers have a different partitioning algorithm? In these cases a clear MUST NOT can help to justify putting in the effort to make sure that all corner cases are handled. Collisions are extremely rare. Without a clear requirement to handle collisions, it is very tempting to ignore them. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
