PKCS#11 vs OpenSSL (BIND Future Development Question)

[Ondřej Surý]

> On 4 Jun 2018, at 10:21, Mathieu Arnold <mat at FreeBSD.org> wrote:
> 
> On Sun, Jun 03, 2018 at 06:00:08AM +0000, Ondřej Surý wrote:
>> The PKCS#11 interface is very fragile, as the different vendors implement different parts of the
>> standard, and BIND needs to be compiled with a specific PKCS#11 provider defined at the
>> compile time.  This is certainly suboptimal, and we are looking at ways how to improve that.
> 
> My understanding was that you had to choose at compile time wether you
> needed PKCS#11 or OpenSSL, and that, even if you could link with a
> specific provider during the build, you could opt-out and start named
> with -E /path/to/engine.so. At least, it is the way it is done in the
> FreeBSD ports tree.

That’s only sort of true, see lib/isc/include/pk11/README.site for more detailed description,
but there are some HSMs that need compile time flags in site.h, and the default is

/* Default is for Thales nCipher */
#ifndef PK11_FLAVOR
#define PK11_FLAVOR PK11_THALES_FLAVOR
#endif

#if PK11_FLAVOR == PK11_THALES_FLAVOR
#define PK11_DH_PKCS_PARAMETER_GEN_SKIP
/* doesn't work but supported #define PK11_DSA_PARAMETER_GEN_SKIP */
#define PK11_MD5_HMAC_REPLACE
#endif

So, even if you can specify a runtime PKCS#11 library, it doesn’t mean it will work
as expected.

To my best understanding, if we keep only the Public-Key crypto for PKCS#11,
there’s only one parameter that will need tuning PK11_RSA_PKCS_REPLACE
and we could either declare that the HSM must support EMSA-PKCS#1-v1.5
or turn that into runtime detection (as this would be the only workaround that
we would need to keep).

Ondrej
--
Ondřej Surý
ondrej at isc.org