[bind10-dev] OpenDNSSEC HSM, was Planning for next sprint - input required

[Shane Kerr]

Jelte,

On Mon, 2010-11-29 at 21:56 +0100, Jelte Jansen wrote:

> > 
> > DNSSEC Key Interface
> > * HSM interface
> >   - Key generation
> >   - Key addition/removal/listing
> > * File interface
> >   - Key generation
> >   - Key addition/removal/listing
> > 
> > Notes: many top-level domains use HSMs to store their keys and to sign/check the signatures.  Existing BIND code uses key files.  Ideally we want a single abstract key store to which a variety of storage mechanisms can be connected.  PKCS#11 is the default for HSMs (and that would also allow use of SoftHSM); however some sites may want to continue with the key file idea, in which case a PKCS#11-style interface to those files would simplify the code that uses keys.
> > 
> > The issue goes deeper than a single HSM as the issue of HSM replacement - and the movement of keys between HSMs - must be considered. (For reference, OpenDNSSEC allows simultaneous access to multiple HSMs, the idea being that when an HSM is retired, if keys can't be transferred to another HSM a key roll takes place, the new key coming from the new HSM.)
> > 
> 
> OpenDNSSEC has quite a sexy interface for this; the only thing you pass around
> are key identifiers, and it figures out by itself which HSM that is to be used
> in. I suggest we take a similar approach (i.e. not only use pkcs#11 as the
> general backend interface, but also abstract away from HSM's in use and
> configuration).

I wonder if we can't just use this OpenDNSSEC code? After all, we've
tried to minimize wheel-reinvention in BIND 10....

--
Shane