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...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
