On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote: > > sander> What I would like to see though is for such a PKCS#11 Engine > sander> to be part of OpenSSL proper, so that our customers and > sander> everyone else’s don’t have to go hunt hither and yon for bits > sander> and bobs of software in order to make their hardware kit work > sander> with OpenSSL. How would OpenSSL obtain a PKCS#11 Engine to > sander> include in its distribution? > > I'm not sure if this is a problem specifically for OpenSSL to solve, > or if it is a packager problem.
I touched on this in a message a few minutes ago, but I *definitely* think it's the former. 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. Then we can also use PKCS#11 for the trust database, which allows us to properly handle the trusted *purposes* in ways that a flat file doesn't. And that flat file is now *exported* from the p11-kit-trust token purely for the benefit of OpenSSL, which it would be nice to stop doing. I am happy to work on this. -- David Woodhouse Open Source Technology Centre [email protected] Intel Corporation ¹ Or "have a parallel function which takes"... but seriously, how often is a string which starts "pkcs11:" going to have been intended as a an actual *filename*? :)
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
