[openssl-dev] Ubsec and Chil engines

David Woodhouse dwmw2 at infradead.org
Tue Feb 23 12:13:57 UTC 2016


On Mon, 2016-02-22 at 14:46 +0000, Salz, Rich wrote:
> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> > function which takes a filename for a cert or key should also accept¹ a
> > PKCS#11 URI.
> 
> It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible).
> 
> But really doubtful to happen in 1.1 as the API freeze is in a month.

Sure, it'd be insane to target 1.1.... well, except that libp11 is
basically *designed* to be dropped into crypto/pkcs11 except for being
under the LGPL. And its original author has already agreed to relicense
it more sensibly.

But yeah — realistically speaking, we are talking about 1.2 (or
whatever comes next). We have libp11+engine_pkcs11 for now.

I absolutely don't want to waste the effort though, so seeing you say
things like "it'd be great to have" is actually really useful.

So let me outline the plan a little bit and see if you still think it's
a good idea...

I was intending to use libp11-kit for the basic PKCS#11 module
enumeration and handling. On the *nix platforms where PKCS#11 is most
important, p11-kit is fairly much ubiquitous. Obviously the code would
be designed such that if someone really wants to eliminate that
requirement, they could reimplement all the things that libp11-kit
gives us and make it a build-time option. But seriously, why would you?

I'd start by throwing together the code to implement the various
EVP_PKEY types work based on PKCS#11 calls, and then look at Richard's
STORE code and how we'd want to tie that in with the use of PKCS#11
URIs to identify objects.

If other libp11 contributors are happy to relicense, that means I can
lift big chunks of code from there. Otherwise I get to reinvent the
wheel.

-- 
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/82d3cd87/attachment.bin>


More information about the openssl-dev mailing list