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> > 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> > dwmw2> > I'm not sure if this is a problem specifically for OpenSSL to solve, dwmw2> > or if it is a packager problem.? dwmw2> dwmw2> I touched on this in a message a few minutes ago, but I *definitely* dwmw2> think it's the former. dwmw2> 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> 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> doing. dwmw2> 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/
