[openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Sat, 2016-02-20 at 12:40 -0800, Sander Temme wrote:
> However, I’m intrigued by the notion of a PKCS#11 Engine in OpenSSL:
> it’s a standard (an OASIS standard now); it’s fairly fully featured;
> everyone in the industry supports it including Thales; and you can
> build a program that calls it without needing a vendor SDK, because
> there are standard headers and a well defined way to get to the entry
> points.  If we can come up with a way to pick a PKCS#11 slot and log
> into it that makes sense (e.g. not by poking PINs into a system wide
> config file etc.) then I think we’d have a winner.

OK, let's explore that. Let's assume, purely for the sake of this
discussion, that we ditch the engine from OpenSSL 1.1 and go *purely*
with a solution based around the existing engine_pkcs11.

From your point of view, what problems are there with that scenario?

You talk about "a way to pick a PKCS#11 slot and log into it"... that's
basically handled by RFC7512, isn't it? The PKCS#11 URI gives us a
standard way to specify not only the slot but also the object therein.
It *also* allows a pin-value attribute to be encoded within the URI if
you want to do that.

If you don't want to encode the PIN, it can be requested at runtime via
a UI_METHOD that you provide. I see the Chil engine also supports an
alternative callback function... does that really provide any more
functionality than your own UI_METHOD does? We could potentially add
that... if we must.

Are there any (other) gaps in required functionality?

Note that engine_pkcs11 doesn't currently support the ?module-path=
query attribute. The code flow of the engine doesn't make that trivial,
since we initialise the engine (and load the provider module) first and
only *later* do we get given a URI to deal with. It's not beyond the
wit of man to fix that though, if we need to.

We *haven't* needed to care about it so far, though. General-purpose
builds (such as building packages for Linux distributions) tend to just
use p11-kit-proxy.so as the default module. That just makes us obey the
*system* configuration for which PKCS#11 modules should be visible to
which applications. And special-purpose use cases can specify a module
in advance when loading the engine. Anyone migrating code which
explicitly uses the Chil engine to engine_pkcs11 would be able to
specify the appropriate module path when loading the engine.

For sanely maintained Linux distributions at least, I want to get to a
point where *any* application which can take certs/keys from a file,
should *also* accept a PKCS#11 URI in place of a file name and should
just work. The Fedora packaging guidelines already say that this SHOULD
be the case, FWIW.

> What I would like to see though is for such a PKCS#11 Engine to be
> part of OpenSSL proper,

Yeah yeah, but not for 1.1. Some of us are hoping to fix that for 1.2
(and not necessarily as an ENGINE but more by having PKCS#11 support
properly integrated). We have agreement from copyright-holders of most
of the existing engine (and libp11, where most of the *functionality*
lies) to relicense it and include it in OpenSSL.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160229/cd21896a/attachment-0001.bin>