31 Říj
2013
31 Říj
'13
17:31
On Oct 31, 2013, at 17:10 , Jan Včelák wrote:
Good!
That's ok. I understand that depending on dnssec-keygen is an interim solution,
I'm just concerned that once you create your own tools you should avoid staying with
the (to my mind) broken interfaces provided by the interim solution.
AFAIK Jan V.
is already working on PKCS#11 support (via openssl).
Yes, indeed. I'm working on support for PKCS#11 in Knot DNS. > I'm ok
with using dnssec-keygen, that's fine. However I'm not fine with all the darn K*
files that dnssec-keygen throws around. I hate the K* files with a passion, because they
are left-overs of our early attempts at figuring out DNSSEC more than fifteen years ago.
I'd like to think that we've learnt a thing or two since then.
Well, we are not OK with these tools. The key storage will definitelly
change. We needed some starting point for our implementation. That's why
we have to stick with all ugly ISC tools for now. And therefore we call
the current implementation experimental. (btw, you can name the files with keys anyhow and Knot
should load them,
just the file extension is important)
Do you parse the timing metadata or do you only use the keying material? I'd argue
that while timing metadata is certainly important the way to look at it is as a
"policy", i.e. for zone foo.com I want to use the key-and-signing-policy FOO and
then the timing information should be associated with the policy, not with the individual
keys. I.e. I advise against using timing information stored in K* files.
"Key-and-signing-policy" is what OpenDNSSEC calls "KASP" and that
seems to be the right abstraction here. You want to be able to define multiple policies
and for each zone declare which policy should be used to sign it.
So I realise that it sounds like I'm singing the OpenDNSSEC song here, but frankly
I'm not. 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. I.e. I'm more interested in alternative implementation than inventing yet
another way of describing the problem space.
You're welcome.
Johan