1 Lis
2013
1 Lis
'13
16:52
Hi Miek,
On Nov 1, 2013, at 11:28 , Miek Gieben wrote:
[ Quoting <johani(a)johani.org> in "Re:
[knot-dns-users] Knot DNS 1.3.3..." ]
Or not even that.
Look at it this way: assume that in the next week there are keys that should change state.
What happens if you don't invoke the key-manager? Has the keys changed state or not?
Eventually you do invoke it, and if at that point all the state changes and other stuff
happen in the right order then you're fine.
My point is that the keys inside the key-manager act a bit like Heisenberg's Cat. You
only know their state if you invoke the key-manager. So not invoking it will never cause
anything bad to happen because you'll never need the effect of the changed state until
you eventually invoke it.
So you'll only have to invoke the key-manager whenever you want it to sign something,
however often that is depending on your KASP.
Are you
suggesting that 'delete KSK' would be part of the API? If so, I
do not see the need. IHMO the API needs to be as small as possible and
just provide good defaults. If we want more, there is always OpenDNSSEC.
I don't have a strong position on that. From my POV we want most things to be
automatic, because if manual then some users will screw up (if no one else,
I will). But whether you delete old retired keys via a "delete" operation in
the API or if the key-manager is sufficiently clueful on its own to understand
when to delete keys I don't really care. One concern with making the key-manager smarter
is that I think you want
to avoid ending up with the key-manager running as a server process that
you connect to. Much better to keep it as "invoked on demand", but then you
must avoid making it responsible for anything that should happen on a clock.
Deleting old keys may be deferred until whenever it is called next, so that is
probably ok, though.
A stand alone cmd tool would be preferred, yes. But not running it as a daemon
will mean you have to call it often enough, not to miss any important key
rollover timings. Although thinking about it, making the PublishSafety large
would mean you don't have to query every second, but only 0.5 * PublishSafety
(to make up an equation). Interesting, I was assuming a daemon, but cmd-line
tool which just talks to an
HSM is the next level of awesomeness (sorry JP).
Regards,
Johan