1 Lis
2013
1 Lis
'13
11:01
On Nov 1, 2013, at 10:25 , Miek Gieben wrote:
[ Quoting <johani(a)johani.org> in "Re:
[knot-dns-users] Knot DNS 1.3.3..." ]
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.
Hi,
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. Thus I don't think that filesystem as
database is incompatible with this concept.
I agree. As long as the user interface is sufficiently abstract, and has
suitable safe guards ("no, you don't want to delete the active KSK")
I'm
happy. The existence of files in a filesystem behind the scenes is not the
issue, as long as that isn't the suggested interface. There's always a
behind-the-scenes interface where you can mess stuff up if you set your mind
to it. So for chatting with the key-manager, I would think
you'll need:
* creat(e) <zone>:
makes a : KSK and ZSK
* get <zone>:
returns current keysset
* emergency <zone>:
makes a new: KSK and ZSK
* clear <zone>:
remove keys from manager.
and emergency is actually just the same as 'create'. Leaves the tiny
issue of pushing DS records to your parent, but meh.
Yeah, the first time I saw that I hurt my head as I fell over backwards...
Johan
That said, I'll comment a bit on the
consequences of keeping the keys in
separate files in the file system below.
And this is why I argue that exposing the key files to the users are, umm, not the way to
go in 2013.
I agree. Also having keys live inside an HSM does mean that you also need to
sign with help from the HSM. Just saying. But it seems to me that an HSM and
exporting private keys to sign with dnssec-signzone are incompatible. Unless one
goes the BIND9 route, where the .priv file contain a reference to the HSM and
not the actual priv key material...