1 Lis
2013
1 Lis
'13
10:25
[ Quoting <johani(a)johani.org> in "Re: [knot-dns-users] Knot DNS 1.3.3..."
]
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.
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.
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. 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...
grtz Miek
--
Miek Gieben
PGP 3880D0F6