Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[Michael J. <mik...@gm...>]

Engine isn't even a first-class citizen in OpenSSL, doesn't get much
love anymore at all from the developers. Engine does not work on any
RHEL variants at the moment. Reason being is that Engine actually has
a downward dependency on one of it's plugins: Gost (Russian Federal
Crypto standard). If libgost.so is missing from a system, OpenSSL will
refuse to load Engine wholesale. And libgost.so is not included in the
RH builds of OpenSSL. Additionally, Engine has been entirely ripped
out from LibreSSL so that excludes at least OpenBSD as well, maybe
also Free and NetBSD, too.

Building a second OpenSSL on a system just so you can build
libgost.so, and thus be able to use Engine and pkcs11_engine,  is not
a trivial task because OpenSSL contains hardcoded library paths. You
need to actually patch their extremely long Configure script to make
it build with rpath.

After the heartbleed fiasco, RH has been switching as much as possible
to use NSS and stopped linking against OpenSSL. NSS is probably far
more portable than OpenSSL, and would probably be a better target for
integration.

On Fri, Feb 26, 2016 at 8:13 PM, Ludovic Rousseau
<lud...@gm...> wrote:
>
>
> 2016-02-26 15:19 GMT+01:00 David Woodhouse <dw...@in...>:
>>
>> It would be really useful if OpenSSL *included* support for PKCS#11 as
>> a first class citizen.
>>
>> This would mean that it could be natively incorporated into higher
>> level APIs such as SSL_CTX_use_certificate() and friends. Basically any
>> API that can take a filename to reference a certificate, should also be
>> able take a RFC7512 PKCS#11 URI.
>>
>> This would also allow us to use a coherent trust database from PKCS#11,
>> which solves the problem of which *purposes* we trust each CA for,
>> unlike the existing flat-file solutions.
>>
>> And applications would no longer need to jump through additional hoops
>> and have additional dependencies to get PKCS#11 support; we could make
>> it largely Just Work™, like it does for example with GnuTLS.
>>
>>
>>
>> The code in libp11 is basically written to be OpenSSL code. If you
>> dropped it into the crypto/pkcs11 directory of OpenSSL precisely as it
>> stands, it wouldn't look out of place.
>>
>> I propose — as the starting point of a plan which will surely be
>> modified by the time we conclude this thread — that we do so.
>>
>> The biggest barrier to this, of course, is the licence. For reasons
>> which are lost in the mists of time, libp11 is licensed under the
>> LGPLv2, and is not compatible with the OpenSSL licence.
>>
>> Therefore, I propose that we relicense the libp11 project under a
>> standard 3-clause BSD licence.
>
>
> OK for me.
>
> I don't even remember what code I wrote for libp11 :-)
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>