> What signalling would be required for the validator to insist > on ML-DSA-44 if it sees a DS for it?
I wonder if we can bend the rules a bit. Assume a zone that is signed with both ML-DSA and ECDSA and has DS records for both algorithms. Then according to the current protocol, a validator that only supports ML-DSA can successfully validate the zone, which implies that all authoritative records in the zone have to be signed with ML-DSA. According to the current rules, a validator that supports both algorithms has to accept any path. However, we know that the ML-DSA path has to exist. So what if the validator (upon seeing the DS with an ML-DSA algorithm) just pretends that it doesn't support any of the legacy algorithms. On any properly signed zone this cannot lead to failure. This would turn the discussion into a local validator policy decision. We can write an information RFC about it explaining how it should work. Whether a validator implements this and whether it would be enabled by default is just be a local issue that does not need further coordination. It doesn't affect the signer. The signer just signs with two algorithms. I think this does conflict massively with the multi-algorithm proposal. So we may need explicit signalling for that use-case. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
