an alternative to K* files
Jim Reid
jim at rfc1035.com
Thu Feb 11 14:50:30 UTC 2010
I agree wholeheartedly with Johan. It would be be nice if there was
something better than these K*.{private,key} files. They are rather
clunky and won't work for very long domain names: the prefix and
suffix cruft will make the resulting file name bigger than the OS will
allow. [IIRC POSIX says file names can't be longer than 255
characters.] It's also easy to confuse KSKs with ZSKs, so a clearer
naming convention for the key files would reduce those sorts of
mistakes. I think too that the intelligence about identifying the
right key(s) belongs in the signing tools and file contents/ It
shouldn't need hints embedded in the file names.
So, how about zsk.{private,public} and ksk.{private,public} files?
These could have all the keys needed for all the zones held on the
server, say in the name server's default directory. Or there could be
zone-specific ones to over-ride that default. Something like:
zone "foo" {
type master;
...
key-directory "bar";
zsk-file "not-the-default-one";
ksk-file "local-choice";
}
These hypothetical files would need to be structured in some way so
that the keys could be tagged. Which may be no bad thing. It would be
good to have human readable meta information to assist with key
management and general server administration: ie This is a 2048-bit
RSA-SHA256 ZSK for domain foo which was generated by bar using foobar
on <date> and will be withdrawn on <date>. Its key id is <tag>. Use
that tag whenever the key needs to be manipulated with the management
and signing tools.
More information about the bind-workers
mailing list