In your letter dated Wed, 9 Jul 2025 18:02:38 +1000 you wrote: >It also has the ability to specify key tag ranges that >multi-signers can use to prevent key tag collisions between independent >key generators.
Bind does something is not the standard it used to be. To make progress it would be useful to have a draft that describes what Bind does (though I think Knot does something different) and find a way to specify how that should work in practice. Every signer in a multi-signer setup would have to agree what the partitions are and each signer needs to know what partition it is in. And we have to deal with the situation that an extra signer is needed. How signers detect misconfiguration, etc. >One could deprecate all existing algorithms the moment replacement code >points >exist. Code point changes don=E2=80=99t take long to deploy. I think operators will only start signing with a new algorithm when support by validators is essentially ubiquitous. With LTS versions of operating systems, we could easily be looking at 10 years before current validators are all gone. Operators find algorithm rolls scary (and sometimes a TLD even goes insecure for an algorithm roll). Zones that are still on RSA may want to change to the new codepoint for ECDSA. But is very unlikely that many operators that use ECDSA today are willing to go to a new code point for ECDSA. Validators are likely to support what is out there. As long as RSASHA1 is in active use, it will be supported by validators. Creating even less incentive for operators to roll to a new code point. In short, I don't think there is a reasonable timeline for replacing the existing code points. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
