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" > <[email protected] on behalf of [email protected]> 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 [email protected] Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
