PKCS#11 registry

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

PKCS#11 registry

Philipp Gühring-2
Hi,

Since the PKCS#11 standard is missing a driver registry guideline, I would
like to propose the following guideline:

-------------------

The biggest missing point in the PKCS#11 standard is the registration of
PKCS#11 drivers in the system, so that applications can automatically find
all available PKCS#11 drivers on a system.

Our proposal is to use directories as registry for PKCS#11 drivers.
Those directories only contain the drivers that adhere to the PKCS#11
specification (lib*.so, *.DLL), please put all other additional material
(Plugins, data, ...) somewhere else.

Current directories:
 Unix: /usr/lib/pkcs11/
 Unix: /usr/lib64/pkcs11/
 Solaris: /usr/lib/pkcs11/$ISA/
        ($ISA is the architecture: /usr/lib/pkcs11/64/ , ... )
 Windows: WINDOWS\SYSTEM32\pkcs11\*.dll

Applications like Web Browsers, Email Clients, or cryptoframeworks should be
able to automatically load all the drivers in those directories, and be able
to use them, without the user having to specify any driver path anymore.

-----------------

This is the current draft of the registry specification. You can always get
the latest version here: http://wiki.cacert.org/wiki/Pkcs11TaskForce

Now to my question to the OpenSC developers:

As far as I can see, OpenSC already puts it´s PKCS#11 driver(s?) into
the /usr/lib/pkcs11/ directory. Unfortunatley, OpenSC also puts other files
into the same directory.

Now the question is, whether OpenSC can move those other files
into /usr/lib/opensc for example, and also adhere to the registry guideline.

The other possibility would be to change the guideline to /usr/lib/cryptoki/
(someone argued that cryptoki would be more "correct", but most people agreed
that pkcs11 is the well-known name).

Now I welcome your feedback (feel free to add your comments to the Wiki
directly, if you think it makes sense), and I would be happy if OpenSC can
also commit to adhere to the future PKCS#11 driver guideline, as soon as it
will be finished.

Regards,
Philipp Gühring

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Andrej Komelj
Philipp Gühring wrote:

> Our proposal is to use directories as registry for PKCS#11 drivers.
> Those directories only contain the drivers that adhere to the PKCS#11
> specification (lib*.so, *.DLL), please put all other additional material
> (Plugins, data, ...) somewhere else.

Relying on the software providers to remove dependency material from the
PKCS#11 directory is not a good idea.

In my opinion, the application should load every single shared library
(*.DLL, *.so, ...) from the directory and check for the presence of
C_GetFunctionList or C_Initialize function entry points to determine
whether the library is a PKCS#11 module or not. This is generally a good
idea to do anyway...

Best regards,
Andrej.



_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

RE: PKCS#11 registry

peter huang
In reply to this post by Philipp Gühring-2
I think under the linux environment, that is probably ok.  Under windows, most vendors installed their pkcs11 dll in \windows\system32, so moving those (dll) will make the software not functioning and copying those to pkcs11 directory will make vendors' update difficult.   I think it would be enough to have a helper script that setup the registries so opensc will load as many as pkcs11 dll as needed.  One detectioning script will help identify the pkcs11 dlls to easy to loading.

Just my 2 cents
-peter

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andrej Komelj
Sent: Monday, September 19, 2005 9:28 AM
To: Philipp Gühring
Cc: [hidden email]
Subject: Re: [opensc-devel] PKCS#11 registry

Philipp Gühring wrote:

> Our proposal is to use directories as registry for PKCS#11 drivers.
> Those directories only contain the drivers that adhere to the PKCS#11
> specification (lib*.so, *.DLL), please put all other additional
> material (Plugins, data, ...) somewhere else.

Relying on the software providers to remove dependency material from the
PKCS#11 directory is not a good idea.

In my opinion, the application should load every single shared library (*.DLL, *.so, ...) from the directory and check for the presence of C_GetFunctionList or C_Initialize function entry points to determine whether the library is a PKCS#11 module or not. This is generally a good idea to do anyway...

Best regards,
Andrej.



_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Andreas Jellinghaus-2
In reply to this post by Philipp Gühring-2
A proposal such as this adds complexity.
If we are to pay the price of additional complexity,
we need good reasons for it.

My political view:
How many pkcs#11 implementations do I know and care about?
Most likely three: OpenSC, Muscle and pkcs11-spy. The last
one would be a serious problem for any such standard, as
it is a pkcs11 implementation, and people should find it
easy to use it, if they know what it does and want that,
but otherwise it should not be discovered or used accidentialy.

How many applications do I know that use pkcs#11?
mozilla *. opensc pkcs11-tool. pam_p11 and pam_pkcs11.
sslengine. openswan. wpa_supplicant?

many of those are security related and are command line
tools, many with config files or even daemons. I don't think
anyone wants auto discovery for any of those tools.
security is more important.

so which tools might be able to use a pkcs#11 implementation
using auto discoovery? in my view only graphical user applications.
currently that would be the mozilla appss, I don't know any other
application using pkcs#11. maybe some banking app or gnupg?

pkcs#11 is too importand security wise for a try and error approach.
The maximum I can think of, is applications providing a drop down
box of known pkcs#11 modules. still the application should be able
to accept a manualy entered path as well.

so if we are talking about gui apps, I wonder if it isn't too early
to write some sort of standard. also the basic scheme - offer something,
discover something - is nothing specific, so I ask myself: maybe kde
and/or gnome already have mechanisms for that? maybe even a common one?

so I think the best place to discuss issues like that might be
freedesktop. also if there are three independend implementations and
their authors want to find a common standard, that would be a good
start. but are there three applications, I wonder?

So from that point of view I think it is to early.


lets switch from the user/gui head back to system apps and
daemons and pam modules etc.

New directories? different ones on (some) 64 bit architectures?

Here is my suggestion: ldopen("opensc-pkcs11.so").

System software needs to trust it's PATH and LD_LIBRARY_PATH anyway,
so searching a module via LD_LIBRARY_PATH is the best way, and at
least ltdl already does that. Also that way apps don't care bout
those 64bit issues. ld and friends already know those, and they
are the specialists.

Also here is my windows point of view:
your proposal might not work with csp11 or ida csp, as they
want the pkcs11 module in system32, as far as I remember.

And then mac os X is not mentioned. Apple does many things
differently on mac os X anyway, maybe for good reasons, but writing
a standard shoulnd't be done without looking at that plattform, what
they do, why they do it that way, and what we can learn from it.

> Applications like Web Browsers, Email Clients, or cryptoframeworks should be
> able to automatically load all the drivers in those directories, and be able
> to use them, without the user having to specify any driver path anymore.

loading several modules that all implement functions with the same name,
that sounds like asking for trouble to me. Also from a security point
of view: we are talking about software that is supposed to be secure.
even to get some basic information about a token you would need to load
code and call the GetInfo code, right? so you load code and execute it.
sorry, that is a horrible scenario to me.

So here is my counter proposal, a bit refined:
 - for system applications you need to edit the config file or
   pass the soname via command line. it is acceptable to load them
   via the normal ld semantics from the normal libraries, since system
   applications are started with hardened values for them anyway.
   e.g. pkcs11=opensc-pkcs11.so

 - for user applications like email clients and web browsers we should
   turn to the big desktop environments and the freedesktop plattform,
   as there is no need to reinvent the wheel.

   a quick look at my hbci software shows me: there is a share/services/
   directory with a *.desktop file defining a service and a
   share/servicetypes/ directory with two *.desktop files implementing
   that service. at least if I read the code correctly.
   
   I can't find a document on freedesktop.org discussing this.

summary: I'm not sure we need something like that right now,
but if several people speak up, I'm fine with it.

Implementation detail: split/discover by directories.
I hate the idea. For decades we know what a PATH is and
that it works well, and every time someone added a single
directory anywhere and made it a standard, sooner or later
someone was bitten by that limitation and wondered, why
a path system was not choosen.

Implementation detail: load all candidates. maybe call the
GetInfo function? I hate that idea. security wise a very
bad concept: executing many plugins. Also this is asking
for trouble, not every OS might have a good ld() that can
handle it.

Implementation detail: covering windows.
I doubt that it is the right way. I guess the dll's need
to be in system32 anyway, so there is no other choice,
and I doubt it is necessary to be cross plattform here.
The windows natural solution would be registry based.
Also windows has the CSP system and I wonder why windows
applications would use pkcs#11 instead of CSP anyway.

Preference:
wait till at least the authors of three independen applications
want a standard. if so, talk to the kde/gnome/freedesktop people,
they might have what we can use. also talk to debian/suse/redhat/*,
as distributions know those issues well and can guide us.

I think a meta data file with text information is much better.
it could hold an absolute path or only a filename that would
be resolved by ld()/ltld(). the metadata file is much safer
and can be used by any applications preference dialog to show
known pkcs#11 implementations. gnome/kde/freedesktop might have
a nice suggestion for the metadata file.

I think applications should be adviced to have a preference dialog
where a user can pick one of the known/registered pkcs#11 implementations
or use the browse function to nagivate through the filesystem and
pick a *.so file, like mozilla does.


Also here is an issue not covered so far:
the pkcs#11 module to be used - is that a global value or a per application
value? is it a single value or a multi value?

I don't see why two applications would want different pkcs#11 modules.
But then again it might be difficult, if you actualy want those.
How do applications handle stuff like this? The windows system with
"bla is not your default foo, do you to make bla your default foo?"
is not very nice, but offeres something people might find both
useful any annoying.

I'm not a gui expert, but I see a lot of hidden issues, and the proposal
presented does not talk about them.

Is the issue pressing? Is there a need to get a standard done ASAP?
I don't think so.

But then again I know I live in my own small world. I don't use any
PKCS#11 except OpenSC and pkcs11-spy. I don't know many applications
that might use it. I might lack all the important bits and pieces.

So I expect a proposal like that to educate me about the world a bit.
If the proposal is introduced by the authors of several applications
that want to find a common base, and it acked by groups like kde,
gnome or freedesktop, or maybe one or some distributions as a good
idea, sure I would welcome it and implement it as soon as possible.

So that is the direction I think you should go.

Regards, Andreas

P.S. small update on opensc:
opensc up to including 0.9.6 is buggy: it has files in /usr/lib/pkcs11/
and at least some of them should be in /usr/lib/, best is we move all
of them to /usr/lib/. That bug caused problems. The next release 0.10.*
will fix that. opensc-pkcs11.so will be in /usr/lib, too.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Ludovic Rousseau
In reply to this post by Philipp Gühring-2
On 19/09/05, Philipp Gühring <[hidden email]> wrote:
> The biggest missing point in the PKCS#11 standard is the registration of
> PKCS#11 drivers in the system, so that applications can automatically find
> all available PKCS#11 drivers on a system.

This limitation is not clear to me. What problem do you want to solve
exactly? Can you describe a use case, please?

Is it: you want to transparently support different cards using
different PKCS#11 lib using the same application?

If the idea is to _register_ a PKCS#11 driver you should be able to
add an entry in a text file like /etc/pkcs11.list. You can have an
external graphical and/or text application to automatically update
this file using some heuristics to find PKCS#11 libs.

Bye,

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Andreas Jellinghaus-2
On Tuesday 20 September 2005 08:42, Ludovic Rousseau wrote:
> If the idea is to _register_ a PKCS#11 driver you should be able to
> add an entry in a text file like /etc/pkcs11.list. You can have an
> external graphical and/or text application to automatically update
> this file using some heuristics to find PKCS#11 libs.

I believe the desktop environments have better and generic ways
for publishing an interface and registering components that offer
it. at least with my hbci software I found files in .../share/servicetype/
and .../share/services/, they are in the standardized *.desktop format,
and it looks to me like a generic way.

So I would prefer something like that over a central text file,
over moving pkcs#11 modules in special directories (even different
ones depending on 32/64 bit and flavors), or the debian style
*.d mechanisms used in soo many places (order is not an issue here).

Also since the target is graphical user applications, I think the
standard should be coordinated with the usual suspects - kde, gnome,
other projects, authors of software using pkcs#11 - and then often
freedesktop.org is mentioned as communication plattform for such issues.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Jonsy (teleline)
El mar, 20-09-2005 a las 09:29 +0200, Andreas Jellinghaus escribió:
> On Tuesday 20 September 2005 08:42, Ludovic Rousseau wrote:
> > If the idea is to _register_ a PKCS#11 driver you should be able to
> > add an entry in a text file like /etc/pkcs11.list. You can have an
> > external graphical and/or text application to automatically update
> > this file using some heuristics to find PKCS#11 libs.

Aside note:
I use several graphical Linux pkcs11 based applications.
(Mozilla/firefox and Citrix ICA client) All of them provide
in their "preferences" menu an entry to enter the pathname
to pkcs11 library(s). In the case of Mozilla/Firefox,
we can define a list of pkcs11 engines, not only one.
Evolution only handles P12 files, not pkcs11 tokens... :-(

Java-1.5 pkcs11 API interface defines the pathname of the pkcs11
native library by mean of a .properties file

So not sure on a real need to create a library list...

Juan Antonio

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Philipp Gühring-2
In reply to this post by Ludovic Rousseau
Hi,

> > The biggest missing point in the PKCS#11 standard is the registration of
> > PKCS#11 drivers in the system, so that applications can automatically
> > find all available PKCS#11 drivers on a system.
>
> This limitation is not clear to me. What problem do you want to solve
> exactly? Can you describe a use case, please?

The problem I currently see is that you have to find and enter the full path
of every PKCS#11 driver you want to use in applications like Firefox,
Mozilla, KMail, ...

Often you find installation guides on the Internet with the wrong path
distributors sometimes install the drivers in the wrong directories.
I even saw an installation system, that automatically detected one specific
PKCS#11 application (Netscape Navigator 4.7, all other versions are
unsupported), and MODIFIED the configuration of that application.
And I have seen distributions that included both PKCS#11 drivers and
applications, but didn´t pre-configured the applications to use the drivers.
And I have seen applications without a File-Load dialogue, with just a plain
textbox to enter the path to the driver.

From the usability point, it does not work to ask the user to enter a 50
character long path correctly just to be able to use one module. Even there
is no way for the user to find it. The user theoretically has to try each
file on the whole system to find the PKCS driver.

So if we want to make the PKCS#11 infrastructure available, a good, easy and
easily useable driver registry is absolutely necessary now.

> Is it: you want to transparently support different cards using
> different PKCS#11 lib using the same application?

Yes. Plug&Play as far as possible.

> If the idea is to _register_ a PKCS#11 driver you should be able to
> add an entry in a text file like /etc/pkcs11.list.

Bad idea. It isn´t possible with all installation systems currently available
to add entries to textfiles. (ZIP/TarBalls for examples don´t support that.
With RPM it´s difficult, ...)
Just having a designated directory, which contains all the drivers must be
enough. If every vendor includes the vendorname in the filename, we will not
have any

> You can have an
> external graphical and/or text applicationr to automatically update
> this file using some heuristics to find PKCS#11 libs.

I already have the commitment of several vendors and distributors to adhere to
the standard, and I strongly believe that all vendors will do it shortly
after.

By the way, it is possible to install the driver somewhere else, but only add
a symlink to the common directory.

Regards,
Philipp Gühring

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Philipp Gühring-2
In reply to this post by Andreas Jellinghaus-2
Hi,

> I believe the desktop environments have better and generic ways
> for publishing an interface and registering components that offer
> it.

No.
There are only two global standards for registering libraries/drivers:
Putting them in a directory (C:\Windows\System32\ , /lib/, /usr/lib/ ), or
having a textfile (which line-endings did we choose???) which contains all
the pathes.
But having to maintain a textfile is far more complicated for installation
systems than having to install a driver in the correct folder.

> at least with my hbci software I found files in .../share/servicetype/
> and .../share/services/, they are in the standardized *.desktop format,
> and it looks to me like a generic way.

Yes.

> So I would prefer something like that over a central text file,
> over moving pkcs#11 modules in special directories (even different
> ones depending on 32/64 bit and flavors), or the debian style
> *.d mechanisms used in soo many places (order is not an issue here).

I think having a directory (per 32/64 flavor or system) is the only easy and
meaningful way.

> Also since the target is graphical user applications, I think the
> standard should be coordinated with the usual suspects - kde, gnome,
> other projects, authors of software using pkcs#11 - and then often
> freedesktop.org is mentioned as communication plattform for such issues.

As far as I know Microsoft isn´t engaged in freedesktop.org, so this isn´t an
option, I would say.

Regards,
Philipp Gühring

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Philipp Gühring-2
In reply to this post by Andreas Jellinghaus-2
Dear Andreas,

Thank you very very much for your detailled response!
I appreciate it very much!

> A proposal such as this adds complexity.

No. It removes the complexity of finding the driver for the user.
(Which is a too large barrier at the moment)

> If we are to pay the price of additional complexity,
> we need good reasons for it.

Yes.

> My political view:
> How many pkcs#11 implementations do I know and care about?

Take a look there:
http://wiki.cacert.org/wiki/Pkcs11TaskForce

> Most likely three: OpenSC, Muscle and pkcs11-spy. The last
> one would be a serious problem for any such standard, as
> it is a pkcs11 implementation, and people should find it
> easy to use it, if they know what it does and want that,
> but otherwise it should not be discovered or used accidentialy.

Ok, then I would suggest not to put pkcs11-spy in that directory.
As I said, it is not necessary to put the drivers in the directory themself,
they can also be symlinked from somewhere else.
(So perhaps deliver a shellscript that creates the symlink on demand for
pkcs11-spy)

> How many applications do I know that use pkcs#11?
> mozilla *. opensc pkcs11-tool. pam_p11 and pam_pkcs11.
> sslengine. openswan. wpa_supplicant?

KMail, Konqueror

> many of those are security related and are command line
> tools, many with config files or even daemons. I don't think
> anyone wants auto discovery for any of those tools.

That´s not the question. The applications that don´t want auto-discovery are
fine to continue with their config-files. Nothing changes for them.
The problem is those applications that NEED auto-discovery, they are helpless
at the moment.

> security is more important.

The current system makes PKCS#11 unuseable for 99% of the users out there,
which is a Denial of Service.

> so which tools might be able to use a pkcs#11 implementation
> using auto discoovery? in my view only graphical user applications.
> currently that would be the mozilla appss, I don't know any other
> application using pkcs#11. maybe some banking app or gnupg?

Apache, OpenCA, ...

> pkcs#11 is too importand security wise for a try and error approach.

That´s why we finally need a clear standard for it, and all the vendors
adhering to it.

> The maximum I can think of, is applications providing a drop down
> box of known pkcs#11 modules. still the application should be able
> to accept a manualy entered path as well.

Yes. That´s their choice, whether they want to automatically activate the
available drivers, or whether they want to provide a drop down box, or
whatever. But we have to make it possible for them to have that choice.
At the moment, some of them come up with a textbox to enter the full path
manually. (Or a commandline option, which isn´t any better)

> so if we are talking about gui apps, I wonder if it isn't too early
> to write some sort of standard.

It is already too late in my opinion. The non-availability of a decent driver
registry nearly killed PKCS#11 on Windows for example, and also made Apple
use something else as far as I know.

> also the basic scheme - offer something,
> discover something - is nothing specific, so I ask myself: maybe kde
> and/or gnome already have mechanisms for that? maybe even a common one?

Yes, but PKCS#11 is universally available on plattforms KDE, Gnome, ... are
not. So we can´t depend on that. The only availability that is given is a
filesystem with libraries and textfiles.

> so I think the best place to discuss issues like that might be
> freedesktop. also if there are three independend implementations and
> their authors want to find a common standard, that would be a good
> start. but are there three applications, I wonder?

Take a look at the list. There are too many PKCS#11 drivers out there, and too
many applications. And there are far too many users out there, who cannot use
it because of that usability problem.

> So from that point of view I think it is to early.

I don´t think so.

> lets switch from the user/gui head back to system apps and
> daemons and pam modules etc.

> New directories? different ones on (some) 64 bit architectures?

No, old directories and symlinks if you want to.

64 bit architectures are handled by the vendor/distributor in their way.

> Here is my suggestion: ldopen("opensc-pkcs11.so").

> System software needs to trust it's PATH and LD_LIBRARY_PATH anyway,
> so searching a module via LD_LIBRARY_PATH is the best way, and at
> least ltdl already does that. Also that way apps don't care bout
> those 64bit issues. ld and friends already know those, and they
> are the specialists.

I don´t think that is going to happen.
(Develop all the necessary code for Firefox, ... to handle that automagically,
and present me the complete solution.)

> Also here is my windows point of view:
> your proposal might not work with csp11 or ida csp, as they
> want the pkcs11 module in system32, as far as I remember.

I don´t see a problem with CSP11, it´s OpenSource, so we can change it.

> And then mac os X is not mentioned. Apple does many things
> differently on mac os X anyway, maybe for good reasons, but writing
> a standard shoulnd't be done without looking at that plattform, what
> they do, why they do it that way, and what we can learn from it.

The standard defines that there IS A specifc directory on each platform which
contains the drivers. Which specific directory it is, is open for the vendor
to decide, if there isn´t a directory already given.
So Apple and any other vendor can simply add the directory on their system to
the list, no problem. Sun and Novell already sent me their directories (their
64 bit variants, the 32 bit variante is fine for all of them)

> loading several modules that all implement functions with the same name,
> that sounds like asking for trouble to me.

Why is Firefox already doing it then?

> Also from a security point
> of view: we are talking about software that is supposed to be secure.
> even to get some basic information about a token you would need to load
> code and call the GetInfo code, right? so you load code and execute it.
> sorry, that is a horrible scenario to me.

That´s why I only chose System pathes, that aren´t user-writable, so that only
administrators can install the drivers there.

By the way, I heard that at least one of the crypto-frameworks is already
loading the driver in a sandbox and doing some verification first, whether it
is working properly.

> So here is my counter proposal, a bit refined:
>  - for system applications you need to edit the config file or
>    pass the soname via command line.

That´s already given. The application is not forced to automatically detect
all libraries and use them. It is only given the possibility, which it does
not have now.

>    it is acceptable to load them
>    via the normal ld semantics from the normal libraries, since system
>    applications are started with hardened values for them anyway.
>    e.g. pkcs11=opensc-pkcs.so

That way, they could be circumvented with LD_PRELOAD, which is quite bad in
your security model.

> summary: I'm not sure we need something like that right now,
> but if several people speak up, I'm fine with it.

I already have several strong commitments from other vendors.

> Implementation detail: split/discover by directories.
> I hate the idea. For decades we know what a PATH is and
> that it works well, and every time someone added a single
> directory anywhere and made it a standard, sooner or later
> someone was bitten by that limitation and wondered, why
> a path system was not choosen.

I did not suggest to add it to PATH. And I also don´t see a need for it.
Secure apps with configuration files can easily specify libraries that are not
included in the PATH.
GUI applications can also load them easily.
So I don´t see a problem.
Additionally, it´s no problem (and perhaps we should suggest it in the
guideline) to add symlinks to a PATH directory

> Implementation detail: load all candidates. maybe call the
> GetInfo function? I hate that idea. security wise a very.

When the user loads it manually, the GetInfo function is called too.
There is no difference, whether the library is found more easily or less
easily by the user.

> bad concept: executing many plugins. Also this is asking
> for trouble, not every OS might have a good ld() that can
> handle it.

But that problem does not have anything to do with the guideline where the
driver can be found. So it does not belong here.

> Implementation detail: covering windows.
> I doubt that it is the right way. I guess the dll's need
> to be in system32 anyway, so there is no other choice,
> and I doubt it is necessary to be cross plattform here.

No, they don´t need to be there.

> The windows natural solution would be registry based.

There also isn´t a standard way to register drivers of a specific class in the
registry. Any why do it, if installing the file (which is enough) is easy
enough?

> Also windows has the CSP system and I wonder why windows
> applications would use pkcs#11 instead of CSP anyway.

I see most applications on Windows using CSP instead of PKCS#11 nowadays,
because it´s a mess to use PKCS#11.

> wait till at least the authors of three independen applications
> want a standard.

I already have them.

> if so, talk to the kde/gnome/freedesktop people,
> they might have what we can use. also talk to debian/suse/redhat/*,
> as distributions know those issues well and can guide us.

I already have their ok too. OpenSC is the last vendor on my list.

> I think a meta data file with text information is much better.
> it could hold an absolute path or only a filename that would
> be resolved by ld()/ltld(). the metadata file is much safer
> and can be used by any applications preference dialog to show
> known pkcs#11 implementations. gnome/kde/freedesktop might have
> a nice suggestion for the metadata file.

It should work on plain Unix without any GUI too. (With curses based
applications for example)

> I think applications should be adviced to have a preference dialog
> where a user can pick one of the known/registered pkcs#11 implementations
> or use the browse function to nagivate through the filesystem and
> pick a *.so file, like mozilla does.

Please do a usability study. Buy a SmartCard+Reader, take a clean PC, install
any Operating system plainly, and ask your mother to initialize the
SmartCard, get a certificate for it, and send you an encrypted email.
(And say that they have to use PKCS11, that they must not use CSP)

> Also here is an issue not covered so far:
> the pkcs#11 module to be used - is that a global value or a per application
> value? is it a single value or a multi value?

Please explain that question, I don´t understand it.

> I don't see why two applications would want different pkcs#11 modules.
> But then again it might be difficult, if you actualy want those.
> How do applications handle stuff like this? The windows system with
> "bla is not your default foo, do you to make bla your default foo?"
> is not very nice, but offeres something people might find both
> useful any annoying.

Have you ever used SmartCards with Firefox before?

> I'm not a gui expert, but I see a lot of hidden issues, and the proposal
> presented does not talk about them.

There is currently one big issue: Usability for end users.

> Is the issue pressing? Is there a need to get a standard done ASAP?

I would say so. PKCS#11 is currently unuseable without it, according to my
usability experiences.

> I don't think so.

A PKCS#11 driver registry is a an open issue in the PKCS#11 community for a
long time now.

If we can´t get PKCS#11 workable now, I am already thinking of porting
CryptoAPI/CSP to Unix.

> But then again I know I live in my own small world. I don't use any
> PKCS#11 except OpenSC and pkcs11-spy. I don't know many applications
> that might use it. I might lack all the important bits and pieces.

Yes. Please really try it out to use real SmartCards (or any other Hardware
Token with PKCS#11) with Firefox.

> So I expect a proposal like that to educate me about the world a bit.

Yes, I hope it helps.

> If the proposal is introduced by the authors of several applications
> that want to find a common base, and it acked by groups like kde,
> gnome or freedesktop, or maybe one or some distributions as a good
> idea, sure I would welcome it and implement it as soon as possible.

> So that is the direction I think you should go.

> Regards, Andreas
>
> P.S. small update on opensc:
> opensc up to including 0.9.6 is buggy: it has files in /usr/lib/pkcs11/
> and at least some of them should be in /usr/lib/, best is we move all
> of them to /usr/lib/. That bug caused problems. The next release 0.10.*
> will fix that. opensc-pkcs11.so will be in /usr/lib, too.

Ok. Very good. If you just add a symlink of opensc-pkcs11.so
to /usr/lib/pkcs11/ and move the other things to /usr/lib (where they belong,
you are right on that point), I´ll be happy.

Regards,
Philipp Gühring

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Alaric Dailey
In reply to this post by Philipp Gühring-2
Philipp Gühring wrote:

>Hi,
>
>  
>
>>I believe the desktop environments have better and generic ways
>>for publishing an interface and registering components that offer
>>it.
>>    
>>
>
>No.
>There are only two global standards for registering libraries/drivers:
>Putting them in a directory (C:\Windows\System32\ , /lib/, /usr/lib/ ), or
>having a textfile (which line-endings did we choose???) which contains all
>the pathes.
>But having to maintain a textfile is far more complicated for installation
>systems than having to install a driver in the correct folder.
>  
>
Hense the idea (but miserably failing of) the windows registry.  An XML
file could be used nicely :)

>  
>
>>at least with my hbci software I found files in .../share/servicetype/
>>and .../share/services/, they are in the standardized *.desktop format,
>>and it looks to me like a generic way.
>>    
>>
>
>Yes.
>
>  
>
>>So I would prefer something like that over a central text file,
>>over moving pkcs#11 modules in special directories (even different
>>ones depending on 32/64 bit and flavors), or the debian style
>>*.d mechanisms used in soo many places (order is not an issue here).
>>    
>>
>
>I think having a directory (per 32/64 flavor or system) is the only easy and
>meaningful way.
>
>  
>
>>Also since the target is graphical user applications, I think the
>>standard should be coordinated with the usual suspects - kde, gnome,
>>other projects, authors of software using pkcs#11 - and then often
>>freedesktop.org is mentioned as communication plattform for such issues.
>>    
>>
>
>As far as I know Microsoft isn´t engaged in freedesktop.org, so this isn´t an
>option, I would say.
>  
>
Good enough code from other sources has worked its way into MS code
before, POSIX for one, here is the latest example

http://www.eweek.com/article2/0,1895,1859439,00.asp

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

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

Re: PKCS#11 registry

Andreas Jellinghaus-2
In reply to this post by Philipp Gühring-2
On Tuesday 20 September 2005 10:58, Philipp Gühring wrote:
> Dear Andreas,
>
> Thank you very very much for your detailled response!
> I appreciate it very much!
>
> > A proposal such as this adds complexity.
>
> No. It removes the complexity of finding the driver for the user.
> (Which is a too large barrier at the moment)

entering a path is a simply instruction for the user,
for the pkcs#11 developer and for the writer of an application.
your schema is more complex, think lines of codes, things that
can go wrong and so on. please do not try to redefine complexity
in a way that it suits you.

maybe you got the words wrong. an automatic discovery schema
is certainly better in terms of usability for the user.

but only if it works well, and the user does not need to
cope with the hidden complexity if it fails.

[applications]

> Take a look there:
> http://wiki.cacert.org/wiki/Pkcs11TaskForce

only one gui application listed.
count me in once you find three applications, with independend
code and their authors want such a standard.

doing a standard while only one potential user exist, and we don't
even know wether or not mozilla developers are interested in this:
sound like over engineering to me, sorry.

[pkcs11-spy]
> Ok, then I would suggest not to put pkcs11-spy in that directory.

but still users must have the choice to use pkcs11-spy if they want
to. any system that does not allow to do so is less capable then
what we currently have.

> KMail, Konqueror

hmm, my kde 3.3 version is sure outdated. newer versions
can load pkcs#11 modules? didn't know that, great news.
any reason they are not listed in your wiki?

any statement from the author of the kde code to load the
pkcs#11 plugins?

> The current system makes PKCS#11 unuseable for 99% of the users out there,
> which is a Denial of Service.

I care a lot about users. but if they can't follow an instruction like
"enter /usr/lib/opensc-pkcs11.so and click ok" then the problem is not
the software. this is not a perfect level of usuability, but also it
is not a very bad level.

> Apache, OpenCA, ...

apache using smart cards? you are kidding, right?
auto detection? security tools to simply load every module
in some directory? sorry, I think that is not a secure concept.

> > pkcs#11 is too importand security wise for a try and error approach.
>
> That´s why we finally need a clear standard for it, and all the vendors
> adhering to it.

if the standard causes apache to load a bunch of modules automaticaly
it is a failure security wise, from my point of view.

maybe you want to add a chapter on target applications, and tell us
which ones you want to target (server software, command line tools,
gui tools), what your recommendation is how each application works,
and why you recommend it that way.

currently I'm guessing, and discussion guesses is not a good idea.

> > The maximum I can think of, is applications providing a drop down
> > box of known pkcs#11 modules. still the application should be able
> > to accept a manualy entered path as well.
>
> Yes. That´s their choice, whether they want to automatically activate the
> available drivers, or whether they want to provide a drop down box, or
> whatever. But we have to make it possible for them to have that choice.
> At the moment, some of them come up with a textbox to enter the full path
> manually. (Or a commandline option, which isn´t any better)

could you cite which one? mozilla? I'm fine with it. and as you should know
we can install the pkcs11 module without that text box, martin paljak can
give you the details how it is done. so no issue here.

server tools and command line tools: no text box - I hope.

> It is already too late in my opinion. The non-availability of a decent
> driver registry nearly killed PKCS#11 on Windows for example, and also
> made Apple use something else as far as I know.

would you please tell us why you think so?
CSP (both windows and apple) is vastly supperior to pkcs#11 for a number
of details, and registering or not pkcs#11 modules is only a tiny issue,
as far as I know. more important details are an active api, the ability
to write software that will work with or without smartcards and does
not need to be changed nor needs special, complex code, and many other
reasons. but we are getting quite off topic here, right?

> > also the basic scheme - offer something,
> > discover something - is nothing specific, so I ask myself: maybe kde
> > and/or gnome already have mechanisms for that? maybe even a common one?
>
> Yes, but PKCS#11 is universally available on plattforms KDE, Gnome, ... are
> not. So we can´t depend on that. The only availability that is given is a
> filesystem with libraries and textfiles.

sorry, I don't care about plattforms other than kde and gnome.
history has shown that any compromise between those two is usualy good enough
for other desktop environments on linux, too.

and both mac os X and windows have CSP, a far better system than pkcs#11,
so I don't care about those either.

that doesn't mean a standard can't be good enough for those plattforms.
but the design process should be to find the best solutions for the important
plattforms, and then see if it works for others as well. if changes are needed
I would like to see how the benefit of the extra plattform outwights the cost
of changes, or reduction of features or clarity.

> 64 bit architectures are handled by the vendor/distributor in their way.

you still need to duplicate code that is in the expert (ld/ltdl) into
each application, so it looks in the right directory. sorry, I don't
think that is a good concept.

> I don´t think that is going to happen.
> (Develop all the necessary code for Firefox, ... to handle that
> automagically, and present me the complete solution.)

pkcs#11 module can be registered in firefox currently without any
user interaction. martin paljac has code for that, I think it is
in his latest installer for the estonian id card on windows.
I'm sure he will happily share all the details and code.

> > loading several modules that all implement functions with the same name,
> > that sounds like asking for trouble to me.
>
> Why is Firefox already doing it then?

I wonder how simple the code is. I guess quite complex.

[loading modules]
> That´s why I only chose System pathes, that aren´t user-writable,
> so that only administrators can install the drivers there.

that also prevents a user from bringing in his own software and using
it himself, right? or will make that process complex, as he needs to enter
the path himself.

unix style is environment variables, search paths and using something
that is in any of those directories. why do you want something different
that is clearly limitated?

> > So here is my counter proposal, a bit refined:
> >  - for system applications you need to edit the config file or
> >    pass the soname via command line.
>
> That´s already given. The application is not forced to automatically detect
> all libraries and use them. It is only given the possibility, which it does
> not have now.

so please clarify your proposal. a "scope" section would be nice.
also why is that "Quality Assurance" section in this page? to be meant
as a thread? after all you are talking about tests that have nothing
to do with the placement of the drivers, right?

I think testing pkcs#11 implementations and doing QA is a good idea,
but it should be in a seperate document, and not mixed up in any
way with this standard proposal (except your QA might check the file
location if the standard is accepted).

> >    it is acceptable to load them
> >    via the normal ld semantics from the normal libraries, since system
> >    applications are started with hardened values for them anyway.
> >    e.g. pkcs11=opensc-pkcs.so
>
> That way, they could be circumvented with LD_PRELOAD, which is quite bad in
> your security model.

all of those apps like openswan or wpa_supplicant will reveal all secrets
they have if called with a malicious LD_PRELOAD. you need to call them
as root and if you run anything as root with a bogus LD_PRELOAD you are
fucked anyway.

there is nothing wrong with my security model, init has sane paths,
init scripts have sane paths, login to root is required to have
sane paths, su kills LD_PRELOAD and friends and starts the root
shell with a proper path. same for LD_LIBRARY_PATH. no other
environment used, no issue here.

this is a well working  security model, proven in practice,
known by everone. if you want to bad mouth it, you should at
least provide some substantial reasoning.

> I already have several strong commitments from other vendors.

distributions adding symlinks is trivial. did mozilla agree
to change firefox and thunderbird? did kde agree to change
kmail and konquerer? what about gnome? what about any application
developer?

let me repeat what I wrote: show me three independend applications
with developers that want to agree on a standard and you can count
me in. I simply think your proposal is not good from a security
point of view, and not the best from an application developers
point of view. but if you can get those people to agree with you,
I will suggest to implement it in opensc too.


> I did not suggest to add it to PATH.

yes, that is the problem.

> And I also don´t see a need for it.

these days nobody thinks about systems where
the user is not root, it seems to me. how would a
user install a pkcs#11 module without being root
in your schema? the whole improvements you are aiming
at won't work anymore, right?

> GUI applications can also load them easily.
your proposal was that gui apps look in those
directories only to provide auto discovery, right?
so where is the improvement, if the only place
where you can add a file/symlink is not writeable
for a normal user?

> When the user loads it manually, the GetInfo function is called too.
> There is no difference, whether the library is found more easily or less
> easily by the user.

so your concept is to provide the pure filename to the user?
no meta data at all? no name / explanation / anything?

I think a concept that includes metadata could improve usability
a lot, and if the metadata comes from a resource file and not a
binary object, it is acceptable from a security point of view.

why do you want to promote a system that is not the best deal
is security, usability or both?

> There also isn´t a standard way to register drivers of a specific class
so you where writing a standard project, right?

and btw: there is already the mechanisms for csp, those are well known,
so if you insist to write a standard for pkcs#11 registering on windows,
I realy wonder why you want to something that is different from the
csp registry mechanisms. what is wrong with those? can't that be used
as a base for pkcs#11 style? could be easily used to provide metadata
and thus usability. and that is much easier for windows developer,
than moving a file around or adding a symlink. I guess most developers
will simply copy the file to that new directory, so old apps still
work and new ones too, but having several copies of the same file
is a sure warning sign, right?

your text doesn't even mention old applications on windows, does not
suggest any way how application developers on windows should provide
compatibility with new and old applications, and also it does not
provide any way to get metadata in a secure way, does not provide
a suggestion how the preference dialog or whatever might look or how
applications might behave.

if you want a minimal standard, that leaves all the hard questions
open: sure, it might be easy to get it ack'ed by everyone who doesn't
think about those problems. sorry, I do. and because of those I reject
your proposal. In my view it should either deal with those issues,
or we are better of without your proposed standard.

> I see most applications on Windows using CSP instead of PKCS#11 nowadays,
> because it´s a mess to use PKCS#11.

as far as I know a CSP based application does not need any change to
use a smart card based rsa key instead of a registry/whatever based one,
right? at least I was told that. if it is true, then CSP would be vastly
supperior to PKCS#11 wich is quite a low level api compared to CSP, if
I'm not mistaken.

> > wait till at least the authors of three independen applications
> > want a standard.
>
> I already have them.

could you post links to their postings to a public mailing lists?
will be an interesting read.

> Please do a usability study.
you don't know it is possible to register a pkcs#11 module in mozilla
without user interaction, do you? have you tried the software that
does?

> > Also here is an issue not covered so far:
> > the pkcs#11 module to be used - is that a global value or a per
application
> > value? is it a single value or a multi value?
>
> Please explain that question, I don´t understand it.

global versus per application:
does each application have a setting "this is my pkcs#11 module"
or is there one setting that all applications use? if you want
usability: why should a user need to specify the pkcs#11 module
in every application again?

but if we make it a global value: is there a way a user can have
different pkcs#11 modules assigned to different applications?
not an easy topic. you filesystem bases approach dodges that questions
and thus leaves application developers in the air.

how many years did it take to define a global "this is my prefered
web broweser" for unix and windows applications? many.
now you don't want to even think about the same problem with
pkcs#11 modules?

single or multi value:
do you want to have one value or a list that can hold several
modules? I wonder why anyone would want to have a list, but
as it is possible to load more than one pkcs#11 module (see
mozilla), it is a valid question.

again - your standard is short of addressing issues like that.

> Have you ever used SmartCards with Firefox before?

yes, thanks for asking, it is part of my normal test
cycle to test opensc with firefox or mozilla.
you will find a number of mails about issues with that
in the mailing list archive, if you want to dig.

> There is currently one big issue: Usability for end users.

so then why don't you address any of the advanced topics?

> If we can´t get PKCS#11 workable now, I am already thinking of porting
> CryptoAPI/CSP to Unix.

mac os x or windows style? I think the opengroup or someone like
that has open source code to do that. It is even on sourceforge,
as far as I know.

I don't think usability is magicaly created by moving a few files
around. I think the problems is a lot more complex. a good way
to start is asking how a preference dialog to select such a module
would look like. will the application show the filename only or
other information such as vendor, name, version, ...

from security point of view: do you get that info by looking at
a text file (save) or running code (unsafe or at least complex to
secure)?

usability will open up the question whether a user can select
the module once for all applications or needs to do that in each
application. is one module enought or are several needed.
what if a non root user installs software in his home?

thats why I mentioned kde and gnome: those projects have attracted
usability experts that can give valuable feedback on such topics.
and also they have experience in coding solutions such as this.

I don't think that replacing pkcs#11 with CSP will solve any of
those issues. but there are more issues with pkcs#11 I guess,
I'm not sure if all modules have the same idea how to show new
readers / cards, how to show cards with several pins, whether
or not to show keys if you are not logged in, and so on.

once usability issue we found with opensc: mozilla loads the
pkcs11 module, locks the card. if you are away from keyboard,
and your xscreensaver wants to authenticate you using your
smart card / token, how would it work around the lock by mozilla?
opensc fails. I guess other pkcs#11 modules will have the same
problem. csp might be a better design, maybe they thought about
issues such as this. don't know. but there is lots of additional
usability problems on the corner. moving files around does not
solve them. why develop a standard, without getting an overview
first? your document ends at the filesystem :(

if I want to assume worst case, your standard is even counter
productive, at least security wise. currently I can install
a pkcs#11 module as user and give it a try, and it won't
be able to damage the system outside of what a user can do.

but with your standard applications will require to use root
for installation, so they can add links to your directories
or copy files in there. security wise I have to assume that
it will be even harder to get pkcs#11 modules installed
without root permissions, and that is a drawback.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Justin Karneges
On Tuesday 20 September 2005 08:28 am, Andreas Jellinghaus wrote:
> > Take a look there:
> > http://wiki.cacert.org/wiki/Pkcs11TaskForce
>
> only one gui application listed.
> count me in once you find three applications, with independend
> code and their authors want such a standard.

Alright well you can count another now, I added my Psi project to the list.  
Although I should mention, it is technically the QCA "wrapper" library (used
by Psi) that has an interest in PKCS#11.  KDE may also use QCA in the future.  
More details about it here:
  http://delta.affinix.com/qca/

Yes, I'd prefer a nice drop-down box for selecting a smart card.  QCA v2.0
centralizes the management of public key sources (so-called KeyStores) for
this very reason.  The idea is that an application can obtain a list of
friendly names and types, for rendering in a GUI.  Click and go!

> if the standard causes apache to load a bunch of modules automaticaly
> it is a failure security wise, from my point of view.

Welcome to plugin systems, this is how they nearly always work.  Normal shared
libraries are insecure as well then, because they can be replaced.

Just don't make these files/directories writable by malicious users, and the
problem is solved. :)

-Justin
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Andreas Jellinghaus-2
Hi Justin,

so I wonder: do you want to present to the user a simple
list of file names, or do you want to present a box
whith more information about each module? maybe even
localized information in different languages?

the former is easy is files are put into some directory,
but I fear a list of cryptic names won't help the user much.

if you have text files as source however with metadata,
and you might even use a standard kde function to get
those, then it might be a lot nicer to display some detailed
information.

what is your choice? what do you prefer?

also do you think it is better to have a global setting for
all applications which pkcs#11 module to use, or should each
application have it's own prefernce menu and it's own setting
stored, which pkcs#11 module it uses?

do you think selecting one module is good enough, or should
the user be able to select a number of modules?


also I wonder: shouldn't a non root user be allowed to bring
his own smart card and use it with his own pkcs#11 module?
is the any reason root needs to approve which pkcs#11 module
users can use? (use for themself, of course they should not
be able to place them in some generic place that is automaticaly
used by everyone).

these are the basic questions I have. I think deciding on some
directory is a very small issue in the whole picture, and depending how
the rest is done, it might not be necessary, even an unneeded limitation
and uneeded change with concerns towards backward compatibility.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Justin Karneges
Hi Andreas,

> so I wonder: do you want to present to the user a simple
> list of file names, or do you want to present a box
> whith more information about each module? maybe even
> localized information in different languages?

I would not show the user a list of file names, but rather a list of actual
smart cards (probably using the friendly names queried from the cards).

> if you have text files as source however with metadata,
> and you might even use a standard kde function to get
> those, then it might be a lot nicer to display some detailed
> information.
>
> what is your choice? what do you prefer?

In either case, the data about the cards (and library locations) would have to
be gathered somehow, and ideally this would not require extra work of the
user.

> also do you think it is better to have a global setting for
> all applications which pkcs#11 module to use, or should each
> application have it's own prefernce menu and it's own setting
> stored, which pkcs#11 module it uses?
>
> do you think selecting one module is good enough, or should
> the user be able to select a number of modules?

IMO, the module is not so important as is a particular device.  A single
computer might make use of several cards, and so I don't think we need to
restrict ourselves into having just one global pkcs11 module.  With USB
tokens I think it is easy to imagine a situation where a computer is shared
by two people who each have different token vendors, and therefore two pkcs11
modules installed.

So I don't think there should be a single system-wide pkcs11 module.  I also
don't think there should be a single per-user module.  There should just be
any number of modules available, and the user would generally not be aware of
them (he would never explicitly select them).  All the user would care about
is whether or not his own card (device) is present, not which pkcs11 module
is servicing it.

With that in mind, I could imagine a single per-user _device_ setting, or even
a device+cert setting.  Then a user wouldn't have to go setup his Firefox,
and then his Kmail, etc.  They could share a global setting.  However, this
is a different problem to solve, I think, than the one of this thread.

> also I wonder: shouldn't a non root user be allowed to bring
> his own smart card and use it with his own pkcs#11 module?
> is the any reason root needs to approve which pkcs#11 module
> users can use? (use for themself, of course they should not
> be able to place them in some generic place that is automaticaly
> used by everyone).

Yes, this is a good point.  A user should probably be able to install his own
local modules.  Many other applications (Firefox included, I think) allow
per-user installed plugins that do not affect other users on the system.

-Justin
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Andreas Jellinghaus-2
Hi Justin,

On Wednesday 21 September 2005 00:46, Justin Karneges wrote:
> I would not show the user a list of file names, but rather a list of actual
> smart cards (probably using the friendly names queried from the cards).

so would you load all pkcs#11 modules and try all of them at the same time?

I forsee chaos, as all of them try to talk to the same readers and cards
via pcsc at the same time. sure this is going to work? or how would you
get that data.

how would you present readers only, i.e. if no card is available?
or empty slots (i.e. no usb reader attached, but virtual slots that
can be filled by hotplugging)?

> In either case, the data about the cards (and library locations)
> would have to be gathered somehow, and ideally this would not
> require extra work of the user.

yes. but it must be a rock solid system too. if several pkcs#11
modules fight over pcsc resources, that wouldn't be helpful, I guess?
So I wonder if it isn't better to show the modules and have the user
select them, rather than auto probing.

> IMO, the module is not so important as is a particular device.  A single
> computer might make use of several cards, and so I don't think we need to
> restrict ourselves into having just one global pkcs11 module.  With USB
> tokens I think it is easy to imagine a situation where a computer is shared
> by two people who each have different token vendors, and therefore two
> pkcs11 modules installed.

ok, so the question from my side is: will loading several pkcs#11 modules
cause trouble on the pcsc side? and is there a security issue or other
problems ahead, if you load several of those at the same time.

> So I don't think there should be a single system-wide pkcs11 module.  I also
> don't think there should be a single per-user module.  There should just be
> any number of modules available, and the user would generally not be aware
of
> them (he would never explicitly select them).  All the user would care about
> is whether or not his own card (device) is present, not which pkcs11 module
> is servicing it.

good point of view. I hope that is doable. but I'm not sure about how pkcs#11
modules behave pcsc wise, or if there are other problems.

also as developer I need to be able to specify the module, so I can test a new
version, or use the pkcs11-spy module to debug some problem. So even if the
user normaly doesn't see anything, there needs to be some dialog he can look
at, if he suspects trouble. And I'm pretty sure it should be possible to
disable a module, if he thinks that one is causing the trouble.

> With that in mind, I could imagine a single per-user _device_ setting, or
even
> a device+cert setting.  Then a user wouldn't have to go setup his Firefox,
> and then his Kmail, etc.  They could share a global setting.  However, this
> is a different problem to solve, I think, than the one of this thread.

device is hard to do. a smart card reader could be used with different cards,
which require different modules, so I don't see how assigning that device to
a module helps. also I guess pkcs#11 modules work differently: each module
tries to look at all pcsc readers it can find. At least OpenSC has no way
to restrict that, it was never requested, and I would wonder if anyone else
did.

> Yes, this is a good point.  A user should probably be able to install his
> own local modules.  Many other applications (Firefox included, I think)
> allow  per-user installed plugins that do not affect other users on the
> system.

that is one of the issues I have with the proposal: it talks about a fixed
directory, so the user has no way to get his module into that directory.
(if he could, he could install a trojan module and thus harm other users.)
so I think the proposal is to inflexible.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Ludovic Rousseau
In reply to this post by Philipp Gühring-2
Hello,

This discussion is a bit hot. I will try to calm it down by making
_technical_ proposals :-)

On 19/09/05, Philipp Gühring <[hidden email]> wrote:

> The biggest missing point in the PKCS#11 standard is the registration of
> PKCS#11 drivers in the system, so that applications can automatically find
> all available PKCS#11 drivers on a system.
>
> Our proposal is to use directories as registry for PKCS#11 drivers.
> Those directories only contain the drivers that adhere to the PKCS#11
> specification (lib*.so, *.DLL), please put all other additional material
> (Plugins, data, ...) somewhere else.
>
> Current directories:
>  Unix: /usr/lib/pkcs11/
>  Unix: /usr/lib64/pkcs11/
>  Solaris: /usr/lib/pkcs11/$ISA/
>         ($ISA is the architecture: /usr/lib/pkcs11/64/ , ... )
>  Windows: WINDOWS\SYSTEM32\pkcs11\*.dll
>
> Applications like Web Browsers, Email Clients, or cryptoframeworks should be
> able to automatically load all the drivers in those directories, and be able
> to use them, without the user having to specify any driver path anymore.

I think the idea of a directory is good. But I think /lib/pkcs11/ is
better than /usr/lib/pkcs11/ since /usr/lib/ may not be mounted yet
when needed (typically for a PAM module).

I strongly recommend that you (the PKCS#11 task force) provide a free
software implementation to use the scheme. The API should be:
int pkcs11_get_libs_number(int *filenames_size, int *descriptions_size)
int pkcs11_get_libs_desc(char *filenames[], char *descriptions[]);

- the return value is the number of registered PKCS#11. -1 in case of error.
- filenames_size is the size needed for filenames
- descriptions_size is the size needed for descriptions
memory allocations are made by the application, not by the API.

- filenames is an array of C-strings that will contain the filenames
of the PKCS#11 libs
- descriptions is an array of C-strings that will contain a
description of the PKCS#11 libs. You can get the description using
C_GetTokenInfo for example

This API is just a first proposal and can be changed.

These functions give the list of registered PKCS#11 libs. The
application may/should also offer the possibility to the user to enter
a pathname of his choice (for PKCS#11 libs that does not (yet) use the
scheme).

The API could also use a user defined library defined in PKCS11_LIB
(for example) environmental variable. So the user can do:
$ PKCS11_LIB=/home/joe/src/pkcs11/my_lib.so mozilla
to use a locally and user installed library.

I also propose to add /lib/pkcs11/default as a symlink to the default
PKCS#11 lib selected by the admin. The default lib could be the
default one proposed to the user.

Discussion:
- already running applications will continue to run as usual

- it does not bring new security issues. /lib/pcsc11/ is
write-protected so only the admin (or the package installation tool)
can add symlinks

- the user can use his own lib using PKCS11_LIB environment variable

- the files in /lib/pkcs11/ could even be ordered (alphabetically) and
presented in that order to the user (from most preferred lib to less
preferred lib). You (the admin) just need to add two digits in front
of the file names like we have in /etc/rc?.d/

- since an API is provided, the real implementation is subject to
changes without breaking the applications. The API could use a PATH,
configuration files, windows registry, etc. to provide the list of
registered libs.

- if only _one_ PKCS#11 lib is registered the application may use it
without asking the user. This should solve the usability problem. Note
that it is NOT an obligation. The application could ask for
confirmation first.

- you can implement this scheme even if some OpenSC developer do not
agree :-). It is just a matter of adding a symlink on the PKCS#11 lib
side.

- the symlink in /lib/pkcs11/ can be created by the packager
(distribution maker) without collaboration with the upstream author.

- if an application does not yet support the scheme, an (advanced)
user can have a look in /lib/pkcs11/ to know what filename he is
supposed to used and cut-n-paste it in the application dialog. So the
PKCS#11 lib could be installed anywhere in the system but still easy
to locate.


To conclude: if you want to see something implemented you have to
implement it yourself. That's why I propose to develop an API (just
one function) so that it is "easy" to integrate in applications.

Also feel free to provide patches for Mozilla, Konqueror, etc. to add
support of the scheme so that users and developers can use it and
discus real problems and not just flame on a mailing list.

I hope this mail is constructive.

Regards,

--
  Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Philipp Gühring-2
In reply to this post by Andreas Jellinghaus-2
Hi,

> so would you load all pkcs#11 modules and try all of them at the same time?

I would say one after the other, then it shouldn´t be a problem.

> yes. but it must be a rock solid system too. if several pkcs#11
> modules fight over pcsc resources, that wouldn't be helpful, I guess?

In my point of view, I have a couple of completely different systems that have
PKCS#11 drivers: SmartCards, USB Tokens, One-Wire devices, TPM´s, HSM´s.
All of them have completely different interfaces that do not interfere with
each other.
(But I don´t know yet what happens, when someone attaches several SmartCard
Readers with several SmartCards at once, but I think that´s the PKCS#11
drivers problem to handle those cases. That´s why my next task after the
driver registry is a testing lab to test all the PKCS#11 drivers which are
"in the wild" against those issues.)

> So I wonder if it isn't better to show the modules and have the user
> select them, rather than auto probing.

There are two things that can be done with the drivers: Query them for a
userfriendly name, and do some regression test, to verify that it works. (I
heard that one of the other toolkits (either Mozilla NSS or cryptlib as far
as I remember) already does that)

> > Yes, this is a good point.  A user should probably be able to install his
> > own local modules.  Many other applications (Firefox included, I think)
> > allow  per-user installed plugins that do not affect other users on the
> > system.

> that is one of the issues I have with the proposal: it talks about a fixed
> directory, so the user has no way to get his module into that directory.

The fixed directory is in /usr/lib/ , or a similar directory which can not be
written to by normal users and hopefully not by trojans.
That way the distributor and the system administrator can make sure, that only
secure modules are available there.

> (if he could, he could install a trojan module and thus harm other users.)
> so I think the proposal is to inflexible.

If the user wants to register his own modules, he can still do it, by manually
giving the path of the module, so we don´t loose any flexibility there.
The guideline just says that all drivers that come with the system, or are
installed by an installation system should be installed in that directory, so
that you can find it there.
The application can decide itself to allow loading of drivers that are
anywhere else by specifying a path (as it is now), or could also deny to load
it from somewhere else
The good thing with proposal is that the applications do not need to change
anything, if they do not want to (or they do not need the automatical
finding). If the application is not changed, it is just easier for the
user/administrator to find all the PKCS#11 modules on his own system, by
knowing where to look for them.

If I wrote the proposal misleading in that regard, please tell me so. (Or try
to rewrite it, and send it to me)

Best regards,
Philipp Gühring

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Andreas Jellinghaus-2
In reply to this post by Ludovic Rousseau
On Wednesday 21 September 2005 10:44, Ludovic Rousseau wrote:
> I think the idea of a directory is good. But I think /lib/pkcs11/ is
> better than /usr/lib/pkcs11/ since /usr/lib/ may not be mounted yet
> when needed (typically for a PAM module).

but then you need all dependend libraries in /lib, too.
I think that part is not worth the trouble. It would be
lots of libraries, I think.

> This API is just a first proposal and can be changed.

why a new api, if there is a generic api for such things?

for example kmymoney2 uses to discover plugins and load them:
    KTrader::OfferList offers = KTrader::self()->query("KMyMoneyPlugin");

And since the backend are standard *.desktop files I hope gnome
has an equivalent of this.

And with the *.desktop file approch you don't need to copy, move
or symlink any file, and you can put meta data in those text
files, like names and vendor and version, and you can localize
all these values? why settle for less?

> - the files in /lib/pkcs11/ could even be ordered (alphabetically) and
> presented in that order to the user (from most preferred lib to less
> preferred lib). You (the admin) just need to add two digits in front
> of the file names like we have in /etc/rc?.d/

so you want to show file names, not meta information?
that was not discussed in the proposal.

I wonder if filenames aren't cryptic.

> - if only _one_ PKCS#11 lib is registered the application may use it
> without asking the user. This should solve the usability problem. Note
> that it is NOT an obligation. The application could ask for
> confirmation first.

and if it crashes the application? if it doesn't work because hardware
is missing? wouldn't it be nice, if you could disable it? without
being root?

> - you can implement this scheme even if some OpenSC developer do not
> agree :-). It is just a matter of adding a symlink on the PKCS#11 lib
> side.

I wrote that I will agree. but I was waiting for application authors
who want to implement it, and so far only justin responded, and I'm
not sure if he has coded it yet. also I can't find his application,
but only QCA so far, which is middleware, not an application.

> - the symlink in /lib/pkcs11/ can be created by the packager
> (distribution maker) without collaboration with the upstream author.

sure. fine with me. distribution knows best what to do (or not).

> Also feel free to provide patches for Mozilla, Konqueror, etc. to add
> support of the scheme so that users and developers can use it and
> discus real problems and not just flame on a mailing list.
>
> I hope this mail is constructive.

well, once I saw how kde developers for example find all plugins
of a certain type (above statement), I wonder why they would like
an archaic interface that is clearly  inferior and offers no meta
information, and thus most likely results in either complex or insecure
code (to probe each pkcs#11 module and GetInfo) or not as much
usability as they could easily get (put name, vendor and version
in that desktop file. localize them.).

the basic resoning was usability, right? why write a standard
with low usability, if you can write one with high usability?

still disappointed. I won't be silent,
but I won't block that efford either.
small improvements in usability are better than none,
even if it is sad to see a chance for a much better improvement
missed.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PKCS#11 registry

Justin Karneges
On Wednesday 21 September 2005 01:52 pm, Andreas Jellinghaus wrote:
> I wrote that I will agree. but I was waiting for application authors
> who want to implement it, and so far only justin responded, and I'm
> not sure if he has coded it yet. also I can't find his application,
> but only QCA so far, which is middleware, not an application.

Just to answer these questions:

You can find Psi here: http://psi.affinix.com/

PKCS#11 is a recent feature of QCA.  The application or user must point the
QCA_PKCS11_LIB environment variable at an appropriate module file.

But you're right, I've not yet coded Psi to use QCA's smart card feature.

-Justin
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
12