Hi Libor,
I'm open to implement this for the next version, at
least for the
manual key management, as you suggested.
I'm tentative for enabling this with automatic key management, since
it's quite complicated, and with algorithm rollover maybe even
fragile:
https://tools.ietf.org/html/rfc6781.html#section-4.1.4.2
It's super complicated. I "fondly" recall how 5011 brought me the very
first CVE with my name on it! I know Evan wasn't amused. :-)
Anyway, I'd like to ask you for an operational
opinion: for how long
period would you publish the old KSK with 'revoked' flag before
deleting it
RFC5011 specifies add/remove hold-down timers of 30 days each, but if we
do this with manual key management, I think it should be either
configurable or be defined by the operator, a bit like active= and
retire= work: just let the operator specify a (relative) time. (This is
particularly important for testing, as BIND and Unbound have switches
with which to reduce the 30 days to, say, minutes, if I want.)
I'd be fine with manual mode permitting me to have keymgr(8) revoke the
key, and sometime later, at my discretion, remove the key as we do now.
To the side note: For the sake of simplicity, when
manual key
management is enabled, knotd is simply not allowed to modify the keyset
in any way
Understood, thank you.
-JP