On Sun, Dec 03, 2017 at 07:13:16AM +0000, Evan Hunt via RT wrote:
> > > I agree the doc should be updated though. Native PKCS#11 is much more
> > > useful now and ought to be emphasized.
> > 
> > How is it more useful?
> 
> I meant it's more useful than it was when we first shipped it,
> because there are more HSMs that support it now.
> 
> > I want us to minimize the amount of crypto code we have in BIND tree. I
> > want us to drop the native PKCS #11 code and stick to the OpenSSL engine
> > code. With that we'll use a single crypto implementation in the tree.
> 
> Okay, I misunderstood you then, and I disagree. Unless things have
> changed substantially since I last looked, OpenSSL doesn't support
> PKCS#11; the pkcs11 engine is implemented by the patches we provide,
> which were never accepted by the upstream maintainers, and they don't
> really work all that well; debugging is huge pain.

Francis also came back to me with similar arguments about OpenSSL
PKCS #11 support. I have checked that his specific claims are untrue.

If you can list things that don't work, I can check these too.

Look at: https://github.com/OpenSC/libp11

This is the better way to install a PKCS #11 OpenSSL engine, not our
OpenSSL patching and custom build method.

--

As example, with Fedora you can install this as the "engine_pkcs11"
package. If you also have p11-kit installed, you don't have to configure
anything except the HSM provider (there's no need to configure the
OpenSSL engine).

p11-kit list-modules should show you the crypto providers that are
available.

With softhsm2 as module, you can use softhsm2-util to configure the HSM
(create tokens and configure PIN to access them).

To create keys on the tokens, you can use p11tool provided by
gnutls-utils.

After that, OpenSSL can be passed a label string that selects a
particular <hsm-provider,token,key-by-label>, e.g., using
dnssec-keyfromlabel -E pkcs11 -l "<selector>".

If there are any quirks (such as debug logging for extra cases that are
not already provided by the engine), it is better to address them as
patches to the pkcs11 engine rather than implement it BIND.

> I think if we're going to support PKCS#11, native is the better way to
> go. If I recall correctly, the only reason we kept OpenSSL PKCS#11 was
> that you couldn't run native PKCS#11 with the AEP Keyper. (And that
> may not even be true anymore.)

We currently have 2 implementations of code to do crypto in BIND (3 if
you also consider hashing). Which other server maintains so many forms
of crypto?  Application level crypto code should not be like this.

How many operators does native PKCS #11 benefit? Why should we have it
in BIND? From what we have right now, one would imagine root and TLD
operators (and the handful of others who need to use a HSM) would be
funding upwards of a million dollars to hire more people to maintain
native PKCS #11 for their benefit for us to deal with CVEs due to it.

		Mukund