running named built with --enable-native-pkcs11 without HSM provider library

[Tomas Hozza]

----- Original Message -----
> On Wed, Aug 06, 2014 at 05:14:53PM +0100, Tony Finch wrote:
> > > Right now it is not possible, and when named is built with
> > > --enable-native-pkcs11 it can not run without HSM and some PKCS#11
> > > provider library.
> > 
> > Would using SoftHSM solve your problem?
> > 
> > http://www.opendnssec.org/softhsm/
> > http://ftp.isc.org/isc/bind9/9.10.0-P2/doc/arm/Bv9ARM.ch04.html#id2666009
> 
> SoftHSM version 1 doesn't supply enough of the PKCS#11 API to meet all
> of BIND's crypto needs, but SoftHSMv2 works beautifully.  Last I checked,
> version 2 hadn't been formally released yet, but it can be cloned from
> github: https://github.com/opendnssec/SoftHSMv2.
> 
> The way things are currently set up, BIND can only drive one PKCS#11
> provider library at a time.  You build with a default provider, and it
> can be overridden via a command line option, but that's a little
> cumbersome.

As far as I understand, without native-pkcs11 OpenSSL is used for crypto
operations if the provided PKCS#11 library did not support some operation, or
if the PKCS#11 provider library was not provided/was not available at all.

With native-pkcs11 the the PKCS#11 provider library has to be provided
and available all the time. I'm interested if there is any chance to
fall-back to OpenSSL in that case OR specify OpenSSL as provider library
(however preferably without the needed patch) during the build and if needed,
specify e.g. the SoftHSMv2 provider library on the command line using '-E'
during the runtime.

> I've been thinking about using a "shim" provider that would pass along
> PKCS#11 primitives to a "back-end" according to context, so you could
> switch seamlessly between providers -- that might be useful, for example,
> if you wanted to use a proper HSM for your KSK, but SoftHSM for the ZSK
> because it's faster.  It might also enable us to drive an HSM that didn't
> have a complete PKCS#11 implementation, using SoftHSM to fill in the
> functional gaps.  Haven't done any work on it, though.

It sound like it would solve use-case I described.

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com