PKCS#11 usability improvements

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

PKCS#11 usability improvements

David Woodhouse
The current situation for users who just want to *use* a certificate+key
that resides in a PKCS#11 token is horrid.

Different pieces of client software are configured in *entirely*
different ways, have entirely different methods of specifying which
PKCS#11 object should be used. Sometimes it even varies for *one* given
piece of software depending on which crypto library it's been built with
today.

I'm trying to make that saner, in two ways.

Firstly, it shouldn't be necessary to explicitly specify the PKCS#11
provider module to load. Modern systems will have p11-kit which has a
registry of the tokens which should be visible. And p11-kit-proxy.so
which is a PKCS#11 provider in its own right, which loads the configured
PKCS#11 tokens and represents each of *their* slots as a slot of its own
to the calling application.

So it's really easy for client applications to just use p11-kit-proxy.so
by default if it's available, instead of failing and saying "ERROR: user
*must* explicitly tell me which PKCS#11 provider to use".

That's the first step in making things saner for users. The second is to
use a consistent way of specifying which cert/key we want to use. I was
rather disturbed to find that even *within* the OpenSC project there are
two incompatible forms; pkcs11-helper uses something which looks like
piv_II/PKCS\x2315\x20emulated/108421384210c3f5/PIV_II\x20\x28PIV\x20Card\x20Holder\x20pin\x29/01
while the OpenSSL engine_pkcs11 may refer to the same object as
slot_19-key_01

There is a (nascent) standard for this: the PKCS#11 URI:
      https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16

I've submitted pull requests to both engine_pkcs11¹ and pkcs11-helper²
to make them accept PKCS#11 URIs in addition to their old format, and to
make engine_pkcs11 use p11-kit-proxy.so by default if no other provider
is specified.

I've also submitted patches to OpenVPN³ to make it use p11-kit-proxy.so
by default, and to wpa_supplicant⁴ to make it Just Work™ when PKCS#11
URIs are given in the client_cert and private_key options (which already
did work right when built with GnuTLS, but now does when built with
OpenSSL too).


I'm exploring the best way to make NSS load the p11-kit-configured
modules by default, and will probably provide some helper functions to
locate certificates and keys from a PKCS#11 URI.

I'm also looking at the best option for OpenSSL. There are multiple
options for adding PKCS#11 support to applications using OpenSSL, and
I'm trying to work out which one is the path of least resistance for
upstream application developers. Probably engine_pkcs11, or maybe libp11
(for which I also have some fixes⁵). It would actually be nice to get
something merged *into* OpenSSL upstream so that it's ubiquitous, and
thus easier for applications to make use of it.

I'd be interested in thoughts on what else should be a priority for
fixing...

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation

¹ https://github.com/OpenSC/engine_pkcs11/pull/9
² https://github.com/OpenSC/pkcs11-helper/pull/4
³ http://thread.gmane.org/gmane.network.openvpn.devel/9342
http://lists.shmoo.com/pipermail/hostap/2014-December/031550.html
https://github.com/OpenSC/libp11/pull/12

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
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: PKCS#11 usability improvements

Alon Bar-Lev
On Thu, Dec 18, 2014 at 7:08 PM, David Woodhouse <[hidden email]> wrote:

>
> The current situation for users who just want to *use* a certificate+key
> that resides in a PKCS#11 token is horrid.
>
> Different pieces of client software are configured in *entirely*
> different ways, have entirely different methods of specifying which
> PKCS#11 object should be used. Sometimes it even varies for *one* given
> piece of software depending on which crypto library it's been built with
> today.
>
> I'm trying to make that saner, in two ways.
>
> Firstly, it shouldn't be necessary to explicitly specify the PKCS#11
> provider module to load. Modern systems will have p11-kit which has a
> registry of the tokens which should be visible. And p11-kit-proxy.so
> which is a PKCS#11 provider in its own right, which loads the configured
> PKCS#11 tokens and represents each of *their* slots as a slot of its own
> to the calling application.

You are confusing between software and a standard.

p11-kit is yet another software, while the standard is PKCS#11.
if you want to suggest p11-kit as a new standard for accessing
smartcard this is entirely different discussion.
but until you do, p11-kit is yet another software that enables
accessing to drivers that supports the PKCS#11 standard/specification.

> So it's really easy for client applications to just use p11-kit-proxy.so
> by default if it's available, instead of failing and saying "ERROR: user
> *must* explicitly tell me which PKCS#11 provider to use".

Client may choose to use p11-kit if it makes their lives easer, but
your claims here are similar to the systemd approach... let's
re-invent standards without thinking of their interfaces as such.

> That's the first step in making things saner for users. The second is to
> use a consistent way of specifying which cert/key we want to use. I was
> rather disturbed to find that even *within* the OpenSC project there are
> two incompatible forms; pkcs11-helper uses something which looks like
> piv_II/PKCS\x2315\x20emulated/108421384210c3f5/PIV_II\x20\x28PIV\x20Card\x20Holder\x20pin\x29/01
> while the OpenSSL engine_pkcs11 may refer to the same object as
> slot_19-key_01
>
> There is a (nascent) standard for this: the PKCS#11 URI:
>       https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16
>
> I've submitted pull requests to both engine_pkcs11¹ and pkcs11-helper²
> to make them accept PKCS#11 URIs in addition to their old format, and to
> make engine_pkcs11 use p11-kit-proxy.so by default if no other provider
> is specified.

I am aware of the pkcs11-helper patches, first cycles were not
something I could have merged, I did not have time to see the next
round, anyway, I do not see this as important as you. the id itself
should not be that important. Especially if using the management
interface to present a list of available objects for user to select.

> I've also submitted patches to OpenVPN³ to make it use p11-kit-proxy.so
> by default, and to wpa_supplicant⁴ to make it Just Work™ when PKCS#11
> URIs are given in the client_cert and private_key options (which already
> did work right when built with GnuTLS, but now does when built with
> OpenSSL too).

This is bad, you creating implicit endorsement for specific software,
I hope it will be rejected.
Well, if you go this route, much better approach is to default load
nss as PKCS#11.

Regards,
Alon

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 usability improvements

David Woodhouse
On Thu, 2014-12-18 at 19:24 +0200, Alon Bar-Lev wrote:
> On Thu, Dec 18, 2014 at 7:08 PM, David Woodhouse <[hidden email]> wrote:
> > So it's really easy for client applications to just use p11-kit-proxy.so
> > by default if it's available, instead of failing and saying "ERROR: user
> > *must* explicitly tell me which PKCS#11 provider to use".
>
> Client may choose to use p11-kit if it makes their lives easer, but
> your claims here are similar to the systemd approach... let's
> re-invent standards without thinking of their interfaces as such.

This part is really just configuring a default PKCS#11 provider. If
p11-kit *happens* to be detected on the system at build time, then I'm
patching software to use p11-kit-proxy.so instead of *failing*.

I'm not quite sure what there is there to object to, or why you say it's
confusing software and a standard.

> I am aware of the pkcs11-helper patches, first cycles were not
> something I could have merged, I did not have time to see the next
> round, anyway, I do not see this as important as you. the id itself
> should not be that important. Especially if using the management
> interface to present a list of available objects for user to select.

Well, there's always lots of scope for people to disagree on usability
issues, but I personally find it very much more convenient when the way
I specify a given key is the *same* in every piece of software.

> > I've also submitted patches to OpenVPN³ to make it use p11-kit-proxy.so
> > by default, and to wpa_supplicant⁴ to make it Just Work™ when PKCS#11
> > URIs are given in the client_cert and private_key options (which already
> > did work right when built with GnuTLS, but now does when built with
> > OpenSSL too).
>
> This is bad, you creating implicit endorsement for specific software,
> I hope it will be rejected.

The OpenVPN patches have already been accepted. There's no
"endorsement". Just, as I said above, using p11-kit-proxy.so if it's
found to be present on the system. In a use case where otherwise it
would have failed.

> Well, if you go this route, much better approach is to default load
> nss as PKCS#11.

We already have Linux distributions where packages such as OpenSC and
gnome-keyring are shipped by default with p11-kit module files,
automatically registering their providers with p11-kit. NSS has no such
mechanism, so doesn't really make much sense as a default provider.

But yeah, maybe the logic could be:
 if no provider was given, then instead of failing (as before):
   - Try p11-kit-proxy.so if it's present, else
   - Try nssoftokn3.so configdir=sql:/etc/pki/nssdb, else
   - Try nssoftokn3.so configdir=sql:$HOME/.pki/nssdb

But really, I think that's overkill. Just a single default of p11-kit is
good enough for distributions to make these things Just Work™ for users.
And you can load your NSS databases via p11-kit configuration too.

--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
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: PKCS#11 usability improvements

Anders Rundgren-2
In reply to this post by David Woodhouse
On 2014-12-18 18:08, David Woodhouse wrote:
> The current situation for users who just want to *use* a certificate+key
> that resides in a PKCS#11 token is horrid.

I'm sure about it which is why iOS, Android and Windows do not
(natively) deal with PKCS #11.

In addition, there's a flaw in PKCS #11 that's essentially "incurable":
the lack of end-to-end-security needed for on-line provisioning.

So IMO, PKCS #11 will remain the powerhouse for HSMs on Linux-servers.

Linux needs a new cryptographic architecture but that seems to get
nowhere since the only parties big enough to do this would be Intel
and RedHat but do they really cooperate?

Intel needs to get the TEE now.
https://github.com/Open-TEE

Anders

>
> Different pieces of client software are configured in *entirely*
> different ways, have entirely different methods of specifying which
> PKCS#11 object should be used. Sometimes it even varies for *one* given
> piece of software depending on which crypto library it's been built with
> today.
>
> I'm trying to make that saner, in two ways.
>
> Firstly, it shouldn't be necessary to explicitly specify the PKCS#11
> provider module to load. Modern systems will have p11-kit which has a
> registry of the tokens which should be visible. And p11-kit-proxy.so
> which is a PKCS#11 provider in its own right, which loads the configured
> PKCS#11 tokens and represents each of *their* slots as a slot of its own
> to the calling application.
>
> So it's really easy for client applications to just use p11-kit-proxy.so
> by default if it's available, instead of failing and saying "ERROR: user
> *must* explicitly tell me which PKCS#11 provider to use".
>
> That's the first step in making things saner for users. The second is to
> use a consistent way of specifying which cert/key we want to use. I was
> rather disturbed to find that even *within* the OpenSC project there are
> two incompatible forms; pkcs11-helper uses something which looks like
> piv_II/PKCS\x2315\x20emulated/108421384210c3f5/PIV_II\x20\x28PIV\x20Card\x20Holder\x20pin\x29/01
> while the OpenSSL engine_pkcs11 may refer to the same object as
> slot_19-key_01
>
> There is a (nascent) standard for this: the PKCS#11 URI:
>        https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16
>
> I've submitted pull requests to both engine_pkcs11¹ and pkcs11-helper²
> to make them accept PKCS#11 URIs in addition to their old format, and to
> make engine_pkcs11 use p11-kit-proxy.so by default if no other provider
> is specified.
>
> I've also submitted patches to OpenVPN³ to make it use p11-kit-proxy.so
> by default, and to wpa_supplicant⁴ to make it Just Work™ when PKCS#11
> URIs are given in the client_cert and private_key options (which already
> did work right when built with GnuTLS, but now does when built with
> OpenSSL too).
>
>
> I'm exploring the best way to make NSS load the p11-kit-configured
> modules by default, and will probably provide some helper functions to
> locate certificates and keys from a PKCS#11 URI.
>
> I'm also looking at the best option for OpenSSL. There are multiple
> options for adding PKCS#11 support to applications using OpenSSL, and
> I'm trying to work out which one is the path of least resistance for
> upstream application developers. Probably engine_pkcs11, or maybe libp11
> (for which I also have some fixes⁵). It would actually be nice to get
> something merged *into* OpenSSL upstream so that it's ubiquitous, and
> thus easier for applications to make use of it.
>
> I'd be interested in thoughts on what else should be a priority for
> fixing...
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 usability improvements

Nikos Mavrogiannopoulos
In reply to this post by Alon Bar-Lev
On Thu, 2014-12-18 at 19:24 +0200, Alon Bar-Lev wrote:

> > That's the first step in making things saner for users. The second is to
> > use a consistent way of specifying which cert/key we want to use. I was
> > rather disturbed to find that even *within* the OpenSC project there are
> > two incompatible forms; pkcs11-helper uses something which looks like
> > piv_II/PKCS\x2315\x20emulated/108421384210c3f5/PIV_II\x20\x28PIV\x20Card\x20Holder\x20pin\x29/01
> > while the OpenSSL engine_pkcs11 may refer to the same object as
> > slot_19-key_01
> >
> > There is a (nascent) standard for this: the PKCS#11 URI:
> >       https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16
> >
> > I've submitted pull requests to both engine_pkcs11¹ and pkcs11-helper²
> > to make them accept PKCS#11 URIs in addition to their old format, and to
> > make engine_pkcs11 use p11-kit-proxy.so by default if no other provider
> > is specified.
> I am aware of the pkcs11-helper patches, first cycles were not
> something I could have merged, I did not have time to see the next
> round, anyway, I do not see this as important as you. the id itself
> should not be that important. Especially if using the management
> interface to present a list of available objects for user to select.

That's arguing that having a common filesystem for all applications is
not as important. Indeed applications could work with each one using a
different name for the same object, but PKCS #11 URLs allow for much
more, i.e., object references to be re-used in different applications,
drag and drop a key or certificate in a gui, allow a consistent
reference to the same keys for all applications and configuration files,
etc. I don't see any reason for not using them.

> > I've also submitted patches to OpenVPN³ to make it use p11-kit-proxy.so
> > by default, and to wpa_supplicant⁴ to make it Just Work™ when PKCS#11
> > URIs are given in the client_cert and private_key options (which already
> > did work right when built with GnuTLS, but now does when built with
> > OpenSSL too).
> This is bad, you creating implicit endorsement for specific software,
> I hope it will be rejected.

This is a usability improvement for systems that have the proxy module
installed, and no cost or burden to anyone else. With that change
configuration of PKCS #11 modules becomes an administrative task, while
users will be able to use whatever is installed. Why do you think such a
change is bad?

regards,
Nikos



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 usability improvements

Alon Bar-Lev
On Fri, Dec 19, 2014 at 1:41 AM, Nikos Mavrogiannopoulos
<[hidden email]> wrote:

> > > I've also submitted patches to OpenVPN³ to make it use p11-kit-proxy.so
> > > by default, and to wpa_supplicant⁴ to make it Just Work™ when PKCS#11
> > > URIs are given in the client_cert and private_key options (which already
> > > did work right when built with GnuTLS, but now does when built with
> > > OpenSSL too).
> > This is bad, you creating implicit endorsement for specific software,
> > I hope it will be rejected.
>
> This is a usability improvement for systems that have the proxy module
> installed, and no cost or burden to anyone else. With that change
> configuration of PKCS #11 modules becomes an administrative task, while
> users will be able to use whatever is installed. Why do you think such a
> change is bad?

Proper support for PKCS#11 such as nss or pkcs11-helper already
capable of loading multiple providers without emulation/proxy layer,
instead of adding a new software component, scanning /usr/lib/pkcs11
or whatever location someone invented is better than endorsing yet
another gnome application.

The next phase is application developers to relay on specific features
of this proxy, and after that killing the standards, we had too many
processes of these lately.

A similar effort is now on the way to kill the LDAP standard by using
specific application as a proxy.

Regards,
Alon

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 usability improvements

Nikos Mavrogiannopoulos
On Fri, Dec 19, 2014 at 10:35 AM, Alon Bar-Lev <[hidden email]> wrote:

>> This is a usability improvement for systems that have the proxy module
>> installed, and no cost or burden to anyone else. With that change
>> configuration of PKCS #11 modules becomes an administrative task, while
>> users will be able to use whatever is installed. Why do you think such a
>> change is bad?
>
> Proper support for PKCS#11 such as nss or pkcs11-helper already
> capable of loading multiple providers without emulation/proxy layer,
> instead of adding a new software component, scanning /usr/lib/pkcs11
> or whatever location someone invented is better than endorsing yet
> another gnome application.

Correct, but that requires each application to take care about the loading and
configuration of any possible modules, and also take care of reference counting
if two different parts of the same application open and use the same
PKCS #11 module.
I could understand not wanting to have all software depend on a single
library, but
its advantages are real, and using the proxy module you don't really to depend
on it at all. If it is there you use it, otherwise you work as before.

> The next phase is application developers to relay on specific features
> of this proxy, and after that killing the standards, we had too many
> processes of these lately.

I believe Stef (of p11-kit) is actively working with the OASIS PKCS
#11 group to fix issues
with the PKCS#11 API, so it is not only about the software. However if
a standard has
issues, it is a good thing to work-around to fix them rather than wash
your hands and push
all the burden to application users and developers.

regards,
Nikos

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 usability improvements

David Woodhouse
In reply to this post by Alon Bar-Lev
On Fri, 2014-12-19 at 10:35 +0200, Alon Bar-Lev wrote:

> On Fri, Dec 19, 2014 at 1:41 AM, Nikos Mavrogiannopoulos
> <[hidden email]> wrote:
> > > > I've also submitted patches to OpenVPN³ to make it use p11-kit-proxy.so
> > > > by default, and to wpa_supplicant⁴ to make it Just Work™ when PKCS#11
> > > > URIs are given in the client_cert and private_key options (which already
> > > > did work right when built with GnuTLS, but now does when built with
> > > > OpenSSL too).
> > > This is bad, you creating implicit endorsement for specific software,
> > > I hope it will be rejected.
> >
> > This is a usability improvement for systems that have the proxy module
> > installed, and no cost or burden to anyone else. With that change
> > configuration of PKCS #11 modules becomes an administrative task, while
> > users will be able to use whatever is installed. Why do you think such a
> > change is bad?
>
> Proper support for PKCS#11 such as nss or pkcs11-helper already
> capable of loading multiple providers without emulation/proxy layer,
> instead of adding a new software component, scanning /usr/lib/pkcs11
> or whatever location someone invented is better than endorsing yet
> another gnome application.
Why do you speak of 'endorsing yet another GNOME application'? Which
GNOME application are you talking about?

Did you think libp11-kit is a GNOME application for some reason? It's
neither an application, nor anything to do with GNOME. It's just a
BSD-licensed library with helpers for parsing PKCS#11 URIs, and for
enumerating the PKCS#11 modules that are configured on the system.

For usability and making tokens consistently visible in different
applications, we *need* a system-wide way to list the PKCS#11 modules to
be loaded. It's outside the scope of the PKCS#11 standard, which only
covers the behaviour of a given module.

As you suggested, there's the NSS database which also has some attempt
at listing tokens — you could add things to /etc/pki/nssdb/pkcs11.txt
perhaps. But it's not a format that works well with packaging; you want
PKCS#11 provider packages to be able to drop a *discrete* file into
place somewhere, rather than editing a configuration file — especially
one which is also admin-edited. And more to the point, *even* NSS
applications don't use /etc/pki/nssdb consistently. Most of them
*don't*, in fact. So it's not a good choice.

What p11-kit provides is a solution for that. A distribution's packages
for stuff like OpenSC can just drop their file into the right place.

You say that "scanning /usr/lib/pkcs11 or whatever location someone
invented is better"... and that's fine. Defaulting to p11-kit-proxy.so
when it's available is the *easiest* option for PKCS#11-aware software,
and ties them much less into the specifics; they can change their
default to *any* other provider at the drop of a hat and it's just a
string change. It can be overridable in the configure script, for
packagers to do what they want on *their* system.

But you certainly don't *have* to do it that way. You can just link
against libp11-kit and call its p11_kit_modules_load() function to get
the CK_FUNCTION_LIST of all the providers that are configured in the
system instead.

But I get the impression you don't want to do that *either*. I've
already reimplemented the PKCS#11 URI parsing in my pkcs11-helper
patches because you inexplicably didn't want to use the libp11-kit
implementation of that. It sounds like you now also want to reimplement
the enumeration of modules too, including the parsing of the module file
format (thus making it really hard for it to be extended in future).

That means you'd be gratuitously reimplementing fairly much *all* of
what the minimal BSD-licensed libp11-kit helper library does. And why?
Because for some reason you've decided that it's a GNOME application? It
doesn't even use glib.

Or is it that you don't want to depend on *any* library other than libc?
That's kind of bogus too. You aren't likely to find p11-kit compatible
module files on any system that doesn't *have* libp11-kit. It's not an
unreasonable dependency to have. It *kind* of made a twisted bit of
sense (well, not much but I was playing along) when you didn't want to
use it for URI parsing. But to refuse to use libp11-kit for processing
the p11-kit configuration is *really* quite a strange approach.

> The next phase is application developers to relay on specific features
> of this proxy, and after that killing the standards, we had too many
> processes of these lately.

No, that's a completely bizarre assertion. The p11-kit-proxy is just a
PKCS#11 provider module. It doesn't *give* you any "specific features"
outside the standard, and it's quite hard to imagine *how* it would do
so. It just presents all the slots from the system-configured PKCS#11
providers as slots of its own.

I find it ironic that better-informed people who have actually *looked*
at the software in question are simultaneously complaining that p11-kit
adheres too *consistently* to the standard and makes it hard for them to
use extra "special" entry points like NSS's NSS_ReturnModuleSpecData().

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
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: PKCS#11 usability improvements

helpcrypto helpcrypto
...I like PKCS#11...

One feature I'm missing is handling multiple users/protect keys using different passwords and, as Anders said, end-to-end communication.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 usability improvements

Nikos Mavrogiannopoulos
On Tue, 2014-12-23 at 09:14 +0100, helpcrypto helpcrypto wrote:
> ...I like PKCS#11...
>
>
> One feature I'm missing is handling multiple users/protect keys using
> different passwords

The OASIS PKCS #11 group is responsible for that API, so you should
address comments of PKCS #11 to them. However, what you ask is trivial
to do over PKCS #11. Having support for multiple users in a USB dongle
is pretty much pointless, but an HSM (and I believe most do) can provide
multiple tokens, one for each user.

regards,
Nikos



------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 usability improvements

Martin Paljak-4
I think you need to be more clear in your real goals.

Fixing PKCS#11 is done by fixing the PKCS#11 spec and all the
implementations (providers and users), adding layers above and below
it is an entirely different thing. Eventually you *need* to fix
applications (gui or not) for sustainable future or state clearly that
you build a layered thing around PKCS#11 (still speaking PKCS#11, not
C_SomethingLikeIt) that fixes certain usability issues and provide a
guideline when the layering approach should or should not be used.

There is certainly room in "Linux ecosystem" (not in "PKCS#11
ecosystem") for a "centralized" key access thing (and trust settings
thing, unfortunately plain PKCS#11 won't do for this, because
libraries implementing protocols (such as tsl, ssh or pgp) have their
own mechanisms and piggybacking on PKCS#11 is weird to implement at
this maturity stage).

Suggesting a PKCS#11 wrapper for centralized *client key/certificate*
access with PKCS#11 URL schematic for configuration is nice but I
don't see why apps with good UI-s should not just be able to load the
proxy wrapper and use whatever internal opaque identifier?

This creates a set of assumptions, like what to expect from the proxy
and what are the requirements for the modules to be auto-loaded into
the proxy. OpenSC (a generic smart card driver) might not want all the
cards to appear, while most probably I don't want my HSM to
auto-appear.

Eventually, *users* don't *want* to use keys and certificates via
PKCS#11, they are stuck with applications that assume that PKCS#11 is
a usable thing. So you need to convince *developers* to adopt
something better.


--
Martin
+372 515 6495

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel