Feedback to the PKCS11 proposal
by Andreas Jellinghaus, one of the OpenSC developers.
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
- 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.
(as posted on the opensc-devel list in response to the proposal)