Re: [Opensc-devel] RFC: Renaming engine_pkcs11.so to libpkcs11.so

[Douglas E E. <dee...@gm...>]

OK, you have answered my questions.


On 4/29/2015 1:00 PM, David Woodhouse wrote:
> On Wed, 2015-04-29 at 11:00 -0500, Douglas E Engert wrote:
>> With this change cause problems in systems where libpkcs11.so
>> already exist in the standard load path?  For example Oracle Solaris.
>> /usr/lib/64/libpkcs11.so.1
>>
>> http://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/chapter1
>> -1/index.html
>>
>>
>> I would assume libpkcs11.so would implement a PKCS#11 module, not an engine for OpenSSL.
>> Will this only work because its in the engine directory and thus only work
>> when using OpenSSL?
>
> This doesn't go in the generic library path (and neither do PKCS#11
> modules need to, for that matter, but that's a different issue). This
> is in the OpenSSL engines directory, for example in my case
> /usr/lib64/openssl/engines/.
>
> That already contains a bunch of engines with generic-sounding
> filenames like libcapi.so, libgmp.so, etc. —the latter of which would
> *definitely* be a conflict with a real shared library in /usr/lib64.
>
> Those are loadable with ENGINE_by_id("foo") or by using '-engine foo'
> on the command line, because they have the standard filename that
> OpenSSL expects. Our engine_pkcs11.so, on the other hand, is not
> because it doesn't have a filename in the correct form. Which is the
> problem I'm trying to solve, of course.
>
> In the past it didn't matter because you had to jump through a lot of
> hoops to preconfigure it to tell it which PKCS#11 provider module to
> load anyway. But now you don't because...
>
>> On 4/29/2015 8:55 AM, David Woodhouse wrote:
>>> I've just fixed the Fedora packages (for F22+) so that this kind of
>>> command line will Just Work with RFC7512 PKCS#11 URIs:
>>>
>>> $ openssl req -new -keyform engine -engine pkcs11 -key
>>> "pkcs11:manufacturer=piv_II;id=%01"
>>
>> The OpenSC engine_pkcs11.so can load any PKCS#11 module, not just
>> the OpenSC version. It could even load the Solaris.
>> /usr/lib/64/libpkcs11.so.1
>
> ... reordering your message a little ...
>
>>> Do you still need an openssl.cnf with something like:
>>>
>>> [engine_section]
>>> pkcs11 = pkcs11_section
>>>
>>> [pkcs11_section]
>>> dynamic_path = /some/path/ssl/engine/libpkcs11.so
>>> [...]
>
> In a system with p11-kit, you don't need that. The engine will by
> *default* load p11-kit-proxy.so, which as its name implies is just a
> proxy which exposes each of the modules specified in the system
> configuration as slots of itself.
>
> You can still have a configuration and specify a different provider
> module, of course. Using p11-kit-proxy.so by default is only changing
> the behaviour in a case that *previously* would have just aborted with
> an error (no provider specified).
>
>>> Ideally, all of that '-engine pkcs11 -keyform engine' will
>>> eventually
>>> go away. When you provide a -key argument that starts with
>>> 'pkcs11:'
>>> it should *infer* that, like GnuTLS and other things do (including
>>> OpenConnect when built against OpenSSL+libp11).
>>
>> That sounds like the equivalent of having the engine code is built
>> in.
>
> Right. That would be nice.
>
>> What do you mean by eventually. Are you saying when OpenSSL supports
>> calling a PKCS#11 module, without using an engine?
>
> Technically, I don't care if it's using an engine or not, to be
> honest. But I *do* want to reach the point where you can just specify
> a key as "pkcs11:..." instead of a filename and it'll Just Work, like
> it does in GnuTLS.
>
> If that's done by having some wrapper code which automatically invokes
> the engine, or if that's done by relicensing libp11 to be compatible
> with the OpenSSL licence and merging it *properly*, or some other
> method, doesn't really matter.
>
> And no, I'm not going to attempt to put any kind of time estimate on
> this "eventually", either. Even if we don't count the part where we
> submit it to OpenSSL and have it ignored for years at a time :)
>
> But it is the end goal that I'd like to keep in mind.
>
>>> But in the meantime, we can settle for this because at least it's a
>>> massive improvement over what we had before.
>>
>> It may work, but just does not sound right to me at this time.
>>
>> Processes like login that use PAM can drag in packages like LDAP,
>> Kerberos and  NSS, some of which also support smart card login via
>> pkcs#11 too.
>
> Yes. And from the Fedora distribution point of view I want to make
> things work consistently. In all cases unless you explicitly *specify*
> a provider, you should have the modules which are present in the
> system's p11-kit configuration. And you should be able to specify
> objects by their PKCS#11 URI wherever you could specify a key or cert
> with a filename.
>
> The fixes for the engine and pkcs11_helper are part of that.
>
> And obviously although I'm *starting* with Fedora because it's easier
> to effect change there and get distro-wide policies like this
> implemented, I do expect that other systems (not just Linux) will
> follow.
>

-- 

  Douglas E. Engert  <DEE...@gm...>