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", <or
replace with your favorite crypto library>); 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
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. It is a good
practice not to re-implement a known protocol or format if you can use one that
exists (and has been tested) that's why many applications choose OpenSSL for
SSL/TLS for example. So maybe the "PKCS#11 directory" [3] is the best solution
I've seen this far.
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.
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 ;)
Just some food for thought when you improve gnome-keyring and related GNOME
matters.
[1] http://fedoraproject.org/wiki/FedoraCryptoConsolidation
[2] http://delta.affinix.com/qca/
[3] http://wiki.cacert.org/Pkcs11TaskForce
[4]
http://ludovicrousseau.blogspot.com/2010/04/free-software-tokend-above-pkcs11-for.html
--
Martin Paljak
@martinpaljak.net
+3725156495
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
