31 Říj
2013
31 Říj
'13
20:18
I think that Johan mentioned this sometime later in our conversation that got private,
that he don't really care about on-disk format, but he cares about UI on top of it.
Thus I don't think that filesystem as database is incompatible with this concept.
O.
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, CZE
mailto:ondrej.sury@nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
On 31. 10. 2013, at 20:14, Ondřej Caletka
<ondrej.caletka(a)gmail.com> wrote:
Hi,
Dne 31.10.2013 14:42, Johan Ihrén napsal(a):
No, I don't want to look inside all the K*
files to be able to figure out which key is only published, which is active and which is
retired. Nor do I want to delete old and retired keys with the Unix "rm"
command, and high probability of erasing the wrong file.
I have different opinion on this. I'm fine with private keys on disk. I
don't want to run SoftHSM using SQLite database full of strange binary
blobs, use three different tools to create, manage and export private
keys and work with long alphanumeric nonsense IDs. I'm happy with KSK
for example.com in file named KSK_example.com.private, the same way I
work with SSL certificates or SSH keys. In case of emergency it is much
more simple to just recover the right key file from backup instead of
going through some lengthy process like [1].
[1]:
https://wiki.opendnssec.org/display/USERDOCREF/Recovery+of+a+single+dnskey+…
So, PKCS11 support would be nice to have, but please don't make it the
only option to deploy DNSSEC using Knot. Same way with the KASP policy.
The best database for me is the filesystem itself.
--
Ondřej Caletka
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users