Re: [opensc-devel] Spec for specifying PKCS#11 modules to load
On 7/17/2010 5:16 PM, Stef Walter wrote: > Is there a spec around for specifying to applications which PKCS#11 > modules to load and how to initialize them? > > I'm thinking something along the lines of PAM conf files, where you can > specify which PAM modules different applications load. > > We're working hard on PKCS#11 support in GNOME, and rather than coming > up with something like this on our own, perhaps someone has already > given this some thought? Main problem with pure PKCS#11 is an applicaiton loads only one pkcs11 lib. NSS can load multiple pkcs11 libs, Google for NSS PKCS#11 Then there is the Solaris PKCS#11 Cryptographic Framework library. From the man page: " The libpkcs11 library implements the RSA Security Inc. PKCS#11 Cryptographic Token Interface (Cryptoki), v2.20 specification by using plug-ins to provide the slots. Each plug-in, which also implements RSA PKCS#11 v2.20, represents one or more slots." http://docs.sun.com/source/817-6972-10/5_pkcs11_int.html I presume you are involved with: http://live.gnome.org/GnomeKeyring/ToDo > > Cheers, > > Stef > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Spec for specifying PKCS#11 modules to load
Hello,
A huge backlog of e-mails to go through, but here's a thought on the subject:
On Jul 18, 2010, at 9:41 PM, Stef Walter wrote:
> On 2010-07-18 13:34, Anders Rundgren wrote:
>> On 2010-07-18 18:49, Stef Walter wrote:
>>
>>>
>>> The missing piece is a common standard for specifying which PKCS#11
>>> modules for an application to load.
>>
>> This is not what Microsoft and Apple offers.
>>
>> They offer a directory of providers. If apps want to
>> discriminate against certain providers they can do that
>> based on provider name, capabilities, or through user selection.
>> If there is a need for local provider config, it is a part of the
>> application.
>>
>> I don't say that what you asking for is wrong, but it seems
>> that you want to architect it in another way than MSFT
>> and APPL did.
>
> Yes that's correct. We're architecting it in a more flexible way, one
> that allows diversity of crypto libraries and can be adapted to varying
> security needs.
I support what Anders Rundgren wrote above.
The problem with PKCS#11 is that even if there are rudimentary certificate
management facilities (CKA_TRUSTED and CKA_CERTIFICATE_CATEGORY), it is not
meant to be anything else than an interface for cryptographic hardware or
software algorithm implementations. Much like OpenSSL can't really be used for
anything except crypto algorithms and basic hardware key access (via engines).
Last time I checked the "store" interface was not really there. And if an
application has decided to live on OpenSSL, it will be a huge job to port it to
something else. Or to provide an alternative fork. but that's only one piece of
the puzzle.
What Apple and Microsoft provide (and what the "NSS effort" [1] IMHO tries to
mimic) is a central database for setting trust on various certificates. And a
central mechanism/API for operating with keys, either software or hardware
based, that automagically propagate to higher API-s. Something that Apple (with
CDSA/Keychain) and Microsoft (with CryptoAPI with certificate manager) provide.
The way I understand it, "the system" consists of several pieces:
personalization/enrollment/generation procedures (the difficult and sensitive
part); algorithm implementations ("I need SHA1, I link against OpenSSL", ); hardware access (PKCS#11 is meant
for this and CryptoAPI, CDSA include support for it); certificate management or
basically PKI elements which mean working with certificates and trust; and
finally, application integration, which puts it all together and for example
provides rendered web pages over SSL with client side certificates and keys
from a smart card to a web server that keeps its keys in a HSM.
I don't think that I would care much for pluggability of SHA256 or RSA2048
*software* implementations if I had an existing codebase to manage - the
"GnuTLS vs PKCS#11 vs OpenSSL" debate does not make much sense for applications
currently based on one of those specs/projects. The "NSS effort" makes it
pretty simple, you either use NSS and are part of the movement or you use
whatever else is available and are left on your own. The Linux "paradox of
choice": it is so good to be able to choose from so many possibilities, that it
becomes bad that there's so many implementations to choose from. For example, I
use GNOME on Linux but for long used k3b for writing disks.. Because it just
used to be the easiest to use application :) Do you want to promote
gnome-keyring (if that's the component you're working with) to something like
OpenSSL (what *GNOME applications* will rely on when they need SHA1 or crypt
with AES, instead of using OpenSSL) or something like CDSA/Keychain is, that is
will be used when you use the function that conceptually translates to
OpenURL() with a https URL in a GNOME application?
I don't use KDE, but QCA [2] seems like an effort that tries to become the
CryptoAPI of KDE, which means it provides higher level API-s for applications
to use. Do you want to implement a part of "the system" or provide a hybrid
implementation, that QCA seems to try to do?
Different application scenarios ("enterprise VPN with strict policies" vs "home
user with a smart card and wifi box with web administration") have different
requirements which need different approaches on configurability and
flexibility. That's no simple task.
>From end user application perspective (which is also the smart card
>perspective) the need to access to keys on a card is universal, but the PKI
>parts (which includes trust roots and certificate trust settings) have
>sometimes good arguments to be application specific. Sometimes you want a
>globally accepted root certificate, sometimes not. Of course, a central
>implementation makes it easy to patch (and exploit!) bugs in peer certificate
>validation checks.
If you remove basic requirement of having to work smoothly with hardware based
keys, the center of gravity is still in the application. It *has* to include
t
Re: [opensc-devel] Spec for specifying PKCS#11 modules to load
On Tue, 2010-07-20 at 18:16 +0300, Martin Paljak wrote: > > If you plan to provide higher level GNOME API-s, my suggestion would > be NOT to piggyback on PKCS#11. You may end up abusing it. If the > specification tells that pReserved should be NULL, it really should be > NULL. There are PKCS#11 providers with additional functions to support > specific key activation authentication. The end result is something > that's pkcs11-ish but is not PKCS#11. Yes, there can be many > interpretations of a specification but it is best to KISS. Best for > interoperability and best for developers, who don't need to guess but > have explicit API-s and explicit conformance. If you need to work with > PKCS#11, work with it like the PKCS#11 Tokend [4] does: just create a > provider for your framework that can be used to pump in PKCS#11 based > keys. And PKCS#11 won't provide for anything else but key access. If > application will anyway need to use GNOME API-s, you can forget as > much as you want about PKCS#11. If PKCS#11 is a concept that the > developer should know, pkcs11-help > er or libp11 can be used to help them. +1 Maybe the API shoud be able to manage a smartcard, i.e. erase, initialize, set pin, transfer certificates, etc ... So you can build a nice management interface in Seahorse. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Italian CNS integration (without SM)
Hello, here's a patch for Italian CNS support against the current trunk, this time without secure messaging. The plan is to reach a consensus on this version, then add Secure Messaging, building on Viktor's work. There shouldn't be any thorny issues to deal with. The two outstanding discussion points, IMHO, are: - in card-cardos.c, I changed the logic around line 820, because I think that the previous handling of outlen was downright wrong – am I missing something fundamental? - I kept the "Give random" function in iso7816.c. It doesn't really belong to ISO 7816, but it does belong to ETSI TS 101 206-3, and it is shared by many cards. What do you think about this? Should I confine it to card-itacns.c, or is it OK to keep it there, os other (and future) drivers could benefit from it? Any feedback is extremely welcome! Thanks, -- Emanuele itacns-r4518-20100719.patch.gz Description: GNU Zip compressed data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Spec for specifying PKCS#11 modules to load
On 07/20/2010 10:16 AM, Martin Paljak wrote: > Hello, > > A huge backlog of e-mails to go through, but here's a thought on the > subject: Thanks for responding. > The Linux "paradox of choice": it > is so good to be able to choose from so many possibilities, that it > becomes bad that there's so many implementations to choose from. For > example, I use GNOME on Linux but for long used k3b for writing > disks.. Because it just used to be the easiest to use application :) > Do you want to promote gnome-keyring (if that's the component you're > working with) to something like OpenSSL (what *GNOME applications* > will rely on when they need SHA1 or crypt with AES, instead of using > OpenSSL) or something like CDSA/Keychain is, that is will be used > when you use the function that conceptually translates to OpenURL() > with a https URL in a GNOME application? Gnome Keyring is not going to turn into something like OpenSSL. Here's the 50,000 foot main goals of Gnome Keyring: 1. To be a place to store passwords. 2. To be a common place to store keys and certificates. 3. To contain crypto related UI widgets for a consistent experience. Point 2 above is where PKCS#11 comes into the picture. Crypto libraries like NSS can access keys and certificates in Gnome Keyring. We're not trying to be a crypto library like NSS. We're not trying to store 'policy' or 'trust' information. In fact I'll be talking about our implementation in a presentation at the upcoming GUADEC. > From end user application perspective (which is also the smart card > perspective) the need to access to keys on a card is universal, but > the PKI parts (which includes trust roots and certificate trust > settings) have sometimes good arguments to be application specific. > Sometimes you want a globally accepted root certificate, sometimes > not. Of course, a central implementation makes it easy to patch (and > exploit!) bugs in peer certificate validation checks. > > If you remove basic requirement of having to work smoothly with > hardware based keys, the center of gravity is still in the > application. It *has* to include the logic that uses well known > protocols to give assisting information to the user about the > trustability of the given situation, or it has to implement its own > protocol with the building blocks provided as algorithms. I strongly agree here. When it comes to deciding policy and trust, the application must take the central role. Each application has vastly different requirements. The model of OpenSSH is vastly different from a web browser, yet both use the same key store and the same types of keys. In the future I believe there will be more inovation in the areas of trust to solve some of the problematic areas today. So to summarize, in Gnome Keyring we make no trust decisions. As part of the key store we do make CA certificates available to the crypto libraries and applications, and these are marked as such. > So maybe the > "PKCS#11 directory" [3] is the best solution I've seen this far. That's certainly a good start. > If you plan to provide higher level GNOME API-s, my suggestion would > be NOT to piggyback on PKCS#11. You may end up abusing it. If the > specification tells that pReserved should be NULL, it really should > be NULL. FWIW, NSS abuses pReserved to no end. In Gnome Keyring we extend PKCS#11 a bit but remain very conformant to the spec. > Yes, there can be > many interpretations of a specification but it is best to KISS. Best > for interoperability and best for developers, who don't need to guess > but have explicit API-s and explicit conformance. That's definitely the goal. Flexibility, transparency and usability are high up on the list. > Last but not least, I'm personally somewhat religious about "trust" > and how the term is used (and abused) by many vendors. Even if there > can be two people who agree on what the term means for them, it is > essentially a very personal decision. I've seen warning about things > not being "trusted" or seen green and assuring "trusted" signs when > my internal decision about the actual case has been 100% opposite. > Technical validity or a boolean answer of "1" for a certificate chain > validation is not the same as trust. It will depend on your business > sector as well, if you work in the CA business or military sector you > probably would think differently ;) Thanks! Much appreciated. And if you feel at any point like you'd like to get involved, please join in. Cheers, Stef ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
