Bonjour, On Thu, 22 Apr 2004, Christian Schneider wrote:
> From the start I had the feeling that something is wrong with the way > how pkcs#11 has to be configured in > clients like mozilla. PKCS#11 defines an API, but the definition lacks some points, which makes your idea below impractical. > What do you think about the idea to write one pkcs#11 library that is > delivered with he os and always installed in a certain spot or at least > where it will be found as a library and always with the same name. > > This library is only a wrapper to the real pkcs#11 libraries you have. The problem is that the PKCS#11 API clearly defines the functions, but not so exactly the behaviour of the library+token with some object flags combinations. I use several PKCS#11 libraries here (and even several PKCS#11 major versions: 1 and 2) for some different tokens (smartcards, PCMCIA crypto cards, PCI crypto cards, I won't provide the manufacturers' names), and I can't write a one-for-all code, because the behaviour is not the same for all. For example, when Netscape/Mozilla asks for an RSA key generation on a token, the C_GenerateKeyPair() call is followed by a C_DestroyObject() call to destroy the public key part, assuming that everything can be done with the private key part. That's wrong on 2 different tokens+libraries I use. On the PCMCIA card, you can't retrieve the modulus and public exponent if your object handle is an RSAPrivate one, you have to do it on the RSAPublic correspondent object. On the PCI card, a Private key can't exist without the corresponding Public key, and vice-versa. PKCS#11 doesn't prevent these behaviours. Other differences exists. > In a config file you define what real pkcs#11 libraries you use and > where they are. The wrapper then unifies all those libraries and shows > all slots and tokens together. Since all tokens won't have the same capabilities, it would be difficult to unify all of them. PKCS#11 authentication scheme is not robust at all, that's why a lot of vendors provide their own scheme, either by providing additional functions in the same library file, or by using off-band mecanisms (for example a smartcard reader with a screen+keypad attached to a crypto card, to enter smartcards to activate the token whenever a C_Login() function call is performed). How should a one-for-all PKCS#11 library interact with all these *non standard* schemes? > The advantage would be that the user does not have to configure each > client but only one system config file. You could even provide a system > like in pcsc-lite where a manufacturer driver only needs to be installed > inside a driver directory to be found. And there's at least one main disadvantage/difficulty: PKCS#11v2 defines a behaviour to adopt if several software accesses the library (by opening several sessions). If all your software uses the 'merged' PKCS#11 library, you'll loose some concurrency benefits. If you allow other software to use the vendors PKCS#11 while other software is still using the 'merged' one, you're allowing more concurrency, but since you'll have to provide guards in your 'merged' library, these guards will surely badly interact with the vendors ones. -- Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5 ----- All wiyht. Rho sritched mg kegtops awound? _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
