Re: [DNSOP] Specification of DNSKEY "Private-key-format"

[Evan Hunt <[e-mail]>]

On Fri, Aug 30, 2019 at 09:56:21AM +0530, Mukund Sivaraman wrote:
> For interoperability, there are other BIND-specific formats to consider
> too such as the journal file format, the control channel protocol,
> etc.

Those seem like separate conversations to me, but I'm happy to have them.

I should clarify, while interoperability between Loop's and BIND's private
key files may well be useful, IMHO the main concern would be to prevent
accidents. If Loop uses what appear to be BIND-style K*.private files, but
you bump the format to 1.4, and BIND does the same with incompatible set of
changes, then BIND key files could break Loop, or vice versa.

So either we should ensure that two sets of changes are compatible with
each other (for example, each could recognize-but-ignore any new metadata
fields that are introduced by the other), or, failing that, we should ensure
that the two formats are *so* incompatible that nobody can cross the
streams by mistake.  You could change the K in the filename to some other
letter, for instance, and then BIND couldn't possibly try to load Loop's
keys.

But I'd be happy to discuss your proposed changes in hopes of maintaining
interoperability. We should probably take it off the list, however; I don't
think implementation details on this level are probably of much interest to
dnsop.

> * As you know, historically the BIND tree on unix relied on /dev/urandom
>   and /dev/random (or some custom device) as sources of random
>   numbers.

FYI, no longer the case as of 9.14.

>   There is a ticket to implement the features of what dnssec-keymgr
>   provides within named itself for ease of use of key maintenance

This is on our road map as well. AFAIK it doesn't require changes to
private keys, though.

>   The key material and schedule metadata should be separated into
>   different files.

Yep, that's a design decision I regret. And not just for the reason you
mention, but also because there was no good reason for the metadata to be
secret, and keeping it in a file that isn't publicly readable causes a lot
of inconvenience.  I wish I'd added a third file instead, such as
K*.meta, instead of extending K*.private.

However, IMHO, redesigning it now would inconvenience people rather more
than putting up with it does, so for the time being I don't expect it to
change.

-- 
Evan Hunt -- [e-mail]
Internet Systems Consortium, Inc.