Wrongly considering signatures-validity in "key lifetime is shorter than the time it takes to do a rollover"

Summary

For testing purposes, I tried to configure as short ZSK lifetime as possible (like 10 seconds). I kept failing with the error key lifetime is shorter than the time it takes to do a rollover until I discovered (by trial and error!) that this error wrongly considers signatures-validity and signatures-refresh.

This is in contrary to the documentation https://bind9.readthedocs.io/en/v9.18.18/reference.html#namedconf-statement-dnskey-ttl which claims that the ZSK lifetime minimum depends only on dnskey-ttl, publish-safety, max-zone-ttl, retire-safety, and zone-propagation-delay. See also #3416 (closed) .

It would be possible to fix this by adjusting the documentation, but I'd prefer to adjust the behaviour: there is no reason why ZSK lifetime should depend on RRSIG validity, only TTLs matter.

BIND version affected

BIND 9.18.18-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)

Steps to reproduce

dnssec-policy "triumph." {
        keys {
                zsk lifetime 18 algorithm ecdsa256;
                ksk lifetime unlimited algorithm ecdsa256;
        };
        dnskey-ttl 3;
        max-zone-ttl 4;
        zone-propagation-delay 2;
        publish-safety 1;
        retire-safety 1;
};

(signatures-validity defaults to 14d and signatures-refresh to 5d, the difference is 9d and the zsk lifetime is denied unless I set it to more than 9d)

What is the current bug behavior?

The configuration load fails with the aforementioned error whenever I set the ZSK lifetime to less than signatures-validity - signatures-refresh, which is contrary to the documentation https://bind9.readthedocs.io/en/v9.18.18/reference.html#namedconf-statement-dnskey-ttl

What is the expected correct behavior?

Either the documentation should be aligned with the observed behavior, or the behavior (appearance of the error and failure to load conf) should be adjusted to not consider signatures-validity.