[openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Mon, 2016-02-22 at 15:59 +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse"
> <openssl-dev-bounces at openssl.org on behalf of dwmw2 at infradead.org> wrote:
> 
> > > It may even be better, instead of pushing for different engines for
> > > different hardware, to make PKCS#11 the only API used to talk to
> > > hardware. There is a quite functional (and active as project) pkcs11
> > > engine for openssl [0].
> > 
> > Agreed. With the caveat that I *really* want libp11 and engine_pkcs11
> > to die, and be replaced by native code in openssl/crypto/pkcs11/
> 
> Would you mind explaining what you mean by “native code” that presumably
> could replace the current libp11, and who in your opinion would support it?

Really, I mean "code within OpenSSL itself". In an ideal world, that
might actually *be* libp11, which is basically written as if it resides
in openssl/crypto/pkcs11/ already — except for its licence (qv).

So "die and be replaced by" would be the wrong wording for me to have
used. I want libp11 to stop being a *separate* project.

In particular — if I pick some random OpenSSL-using application, like
wpa_supplicant, and pass it a PKCs#11 URI instead of a filename as the
certificate/key, then I want it to Just Work™ through the normal
OpenSSL APIs, without the application author having to jump through
additional hoops to *make* it work.

(Note: the first part of that, "shall accept PKCS#11 URI in place of
filename" is part of the Fedora packaging guidelines these days. It is
expected that software packaged for Fedora SHOULD work that way. The
second part, with normal OpenSSL APIs actually facilitating that
improvement, is what we're talking about here.)

As for who would work work on it... well, it would be part of an
OpenSSL (1.2?) release, so the OpenSSL team would have a certain amount
of responsibility for it. But I expect that anyone who has had an
interest in libp11 in the days *before* OpenSSL 1.2 would continue to
have contributions for crypto/pkcs11/ in OpenSSL 1.2 onwards. As well
as *more* interest especially from the Linux distribution side, once we
make it possible to have coherent CA trust settings across the
distribution by having the trust database in PKCS#11, etc.

In fact, libp11 wasn't seeing a huge amount of development work before
people started adding EC support to it, was it? Other than keeping it
up to date with OpenSSL releases, of course...

I don't anticipate that it would be a large maintenance burden.

-- 
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/20160223/2f043adf/attachment-0001.bin>