31 Říj
2013
31 Říj
'13
18:45
Top posting from phone:
I think that more clean interface would be to have two flags:
sign and publish
And warn or refuse when sign+no-publish is used.
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 18:32, Miek Gieben
<miek(a)miek.nl> wrote:
[thanks for including me in this discussion]
I will probably write a keymanager in Go at some point in time, my
interaction with HSM is already taken care of because I wrote a PKCS#11
wrapper for Go - just for this purpose :-)
[ Quoting <jan.vcelak(a)nic.cz> in "Re: [knot-dns-users] Knot DNS 1.3.3..."
]
All the previous emails sound right to me. A "lightweight" key-manager
thingy, unlike BIND and unlike OpenDNSSEC.
As for the user interface, that would be rather simple: a key should be
used to sign, or should be carried in the zone at some point in time.
The KSK flag deals with what should be signed.
So you talk to the key-manager, and it responds with:
key1, sign, KSK
key2, carry, KSK
key3, sign , ZSK
and then your smart incremental signer knows what to do, no?
Grtz Miek
--
Miek Gieben
PGP 3880D0F6
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
Do you
parse the timing metadata or do you only use the keying material?
Yes, we parse timing metadata from .private key file. The simpliest
possible way right now... :-(
I'd love to see an alternative to OpenDNSSEC,
but at the same time I must say that OpenDNSSEC really has found the right abstractions
and the right design in many respects.
And we will give you an alternative to OpenDNSSEC. We just need more
time. :-)