PKCS#11 was meant to be a common set of C bindings to the card and socket services,
for each token. It was never intended to be an abstraction layer for cards/readers.
>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.
It was not supposed to. In the original application-side driver (in TIPEM/BSAFE), its corresponding interface was a set of abstract virtual functions, that you had to subclass to suit the device's actual behaviour.
So, your applications subclass knowledge would exploit their knowledge of the card/socket services actual behaviour, which were one per PCMCIA controller on the pentium bus. Microsoft essentially did the same in its CryptoAPI, where each smartcard has its own driver which knows how the card really sequences the flow of TPDUs, once SCardTrasmit starts the transmission via common C/dll bindings to the common transfer code.
> >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?
I agree. If we need to implement CryptoAPI on UNIX, then lets do so, not PKCS#11 C bindings. But why bother, why not just use Intel's framework, which comes on all platforms?
> > > 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.Hmm. PKCS#11 v2. Retrofit CryptoApi into C bindings designed for a different purpose.
For DoD DMS procurements, an NSA contractor did write a resource manager for socket services in line with the original design concept for PKCS#11 v1. The resource manager coordinated access to (a) multiple slots (abtracted from the hardware enumeration) (b) inter-slot communication (for escrow and secure card backup controlled by card state), and (c) CHV support to the card application (to access key filll devices (aka authenticated eeprom), trusted keypads etc.)
>-- >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
MSN Toolbar provides one-click access to Hotmail from any Web page � FREE download!
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
