[openssl-users] [openssl-dev] Ubsec and Chil engines
levitte at openssl.org
Mon Feb 22 11:52:36 UTC 2016
In message <1456140741.4735.272.camel at infradead.org> on Mon, 22 Feb 2016 11:32:21 +0000, David Woodhouse <dwmw2 at infradead.org> said:
dwmw2> On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:
dwmw2> > sander> What I would like to see though is for such a PKCS#11 Engine
dwmw2> > sander> to be part of OpenSSL proper, so that our customers and
dwmw2> > sander> everyone else’s don’t have to go hunt hither and yon for bits
dwmw2> > sander> and bobs of software in order to make their hardware kit work
dwmw2> > sander> with OpenSSL. How would OpenSSL obtain a PKCS#11 Engine to
dwmw2> > sander> include in its distribution?
dwmw2> > I'm not sure if this is a problem specifically for OpenSSL to solve,
dwmw2> > or if it is a packager problem.
dwmw2> I touched on this in a message a few minutes ago, but I *definitely*
dwmw2> think it's the former.
dwmw2> If we integrate the support natively into OpenSSL, then PKCS#11 URIs
dwmw2> (see RFC7512) can be first-class citizens throughout the crypto and SSL
dwmw2> APIs. Any function which takes a filename for a cert or key should also
dwmw2> accept¹ a PKCS#11 URI.
dwmw2> Then we can also use PKCS#11 for the trust database, which allows us to
dwmw2> properly handle the trusted *purposes* in ways that a flat file
dwmw2> doesn't. And that flat file is now *exported* from the p11-kit-trust
dwmw2> token purely for the benefit of OpenSSL, which it would be nice to stop
dwmw2> I am happy to work on this.
That takes me back to crypto/store, which is currently removed in
master but which I have a rework of in a branch, which is meant to
solve this exact problem, but without being exclusively tied to
PKCS#11. The design is to have it work with engine backends, and a
PKCS#11 engine that's part of OpenSSL would fit that bill, so to say.
Shall we talk?
Richard Levitte levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-users