an alternative to K* files

[Evan Hunt]

> I agree wholeheartedly with Johan. It would be be nice if there was  
> something better than these K*.{private,key} files.

I agree that they're clunky and ugly and I would like to see something more
elegant, but I'll add that since I've been working on BIND 9.7 I've
noticed that the K* format we currently use does have some advantages.

For example, the key-id is only a 16-bit field, so it's not that improbable
for two keys to be generated that have the same ID, name and algorithm.
The fact that we use these files, named the way they are and usually living
in a common directory per zone, makes it fairly easy to prevent this sort
of collision from being a problem.

Key security tricks are easier when keys are stored in individual file
pairs too.  Consider that you might want to move the KSK private key
offline (or to a non-public directory or an encrypted filesystem with a
password controlled by a security officer, whatever) while keeping the ZSK
private key accessible to named; you can do this sort of thing with "mv".
It could be considerably more cumbersome if the private keys lived in a
database file.  (Though, figuring out which file you want to move is
admittedly quite cumbersome now.)

I'm not arguing with you at all, the K* files are hideous.  That's one of
the reasons we added the -K option to all the dnssec-* tools in BIND 9.7,
and improved the key-directory option in named.conf so it doesn't need an
absolute path.  "dnssec-keygen -K keys foo.com" puts the K* files into a
directory "keys" that I never have to actually look into, "dnssec-signzone
-SK keys foo.com" pulls them out, and my working directory is much less
cluttered.  This isn't *really* all that different from having a key
database, when you think about it; it's just that the database happens to
be implemented with file/directory semantics instead of sql/xml/whatever.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.