RFC: Renaming engine_pkcs11.so to libpkcs11.so

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Renaming engine_pkcs11.so to libpkcs11.so

David Woodhouse
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"

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).

But in the meantime, we can settle for this because at least it's a
massive improvement over what we had before.

For now I'm just manually creating a symlink from libpkcs11.so to
engine_pkcs11.so in the Fedora package to make '-engine pkcs11' work
in the above.

I'm not quite sure what is the best way to do that upstream. If we do
actually rename, the old baroque way of doing things will stop
working. Although it's only a minor tweak.

Or perhaps we could make the symlink in the engine_pkcs11 makefiles...
except that seems hard since libtool makes the .so file and we don't
even know what the extension (.so) is.

--
dwmw2

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Renaming engine_pkcs11.so to libpkcs11.so

Douglas E Engert
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?

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

>
> 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.
What do you mean by eventually. Are you saying when OpenSSL supports
calling a PKCS#11 module, without using an engine?

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
[...]

>
> 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.

>
> For now I'm just manually creating a symlink from libpkcs11.so to
> engine_pkcs11.so in the Fedora package to make '-engine pkcs11' work
> in the above.
>
> I'm not quite sure what is the best way to do that upstream. If we do
> actually rename, the old baroque way of doing things will stop
> working. Although it's only a minor tweak.
>
> Or perhaps we could make the symlink in the engine_pkcs11 makefiles...
> except that seems hard since libtool makes the .so file and we don't
> even know what the extension (.so) is.
>

Anyone else feel a little uneasy with this?

>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Renaming engine_pkcs11.so to libpkcs11.so

David Woodhouse
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.

--
dwmw2

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Renaming engine_pkcs11.so to libpkcs11.so

Douglas E Engert
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  <[hidden email]>


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Renaming engine_pkcs11.so to libpkcs11.so

David Woodhouse
On Wed, 2015-04-29 at 16:20 -0500, Douglas E Engert wrote:
> OK, you have answered my questions.

Excellent :)

So, any thoughts on how (if) to transition to 'libpkcs11.so'?

One option is just to go ahead and rename it. That means that existing
users would need to change their configuration to reflect the new
filename. And in fact *mostly* those users will have p11-kit and will
be able to migrate to just doing things the simple way — just
specifying the engine by name (which will now work) and using a
RFC7512 PKCS#11 URI.

It's not nice to *force* them to switch though. Having a symlink might
be nice, but I can't see how to do that since the makefiles don't even
seem to ™know* what the .so extension is on a given platform. We only
ask for 'engine_pkcs11.la'.

In the Fedora packaging for now I *have* just made a symlink, but I
really dislike doing anything only in the distro rather than fixing it
upstream.

--
dwmw2

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment