RE: PKCS#11

Hi Bob, thanks a lot for your explanations. I worked on them and now I am 
doing some progresses in the PKCS11 field.  Since our PKCS11 library does 
not support hashing algorithms, I am using sm_pkcs11Free3DLLd. In this way, 
the hashing algorithms are provided by Crypto++. From a very first analysis 
it looks like I can sign and verify signatures. I still have some (not 
reproducible...!) problems in accessing the certificates on the cards. I am 
investigating them.

In order to point to the certificate files, are .cer, .der, .crt formats ok? 
Or do I need the .out format?

Concerning your offer to include our PKCS11 library in the list of supported 
library, thanks but at present we cannot give out our PKCS11.

bye

Marco

>Marco:
>
>You do not need to use the address book at all.  The address book is only
>present for alias name lookup of recipient certificates.  For use outside
>our UDF test environment, I suggest you simply specify encrypt recipients 
>by
>pointing directly to the certificate files, not using the address book
>logic.
>
>As to signing, it only uses the address book to get issuer certificates for
>DSA, if the params are not present.  If this is the case, you need to load
>all issuer certificates into the address book (just some unique alias name,
>DN name and a pointer to the file, usually under the "./certs" directory).
>
>For signing from the card, be sure to properly identify the signing SLOT on
>your card, that contains a valid signing private key
>(CSM_CSInst::SetUseThis() AND CSM_CSInst::SetApplicable()).  Your "" config
>file needs a keyword "Login1=" to identify the appropriate signing SLOT on
>your card.  Since this is unique to the CTIL, and you are using a new
>un-tested PKCS11 (we have had to make modifications to the CTIL in order to
>accommodate different PKCS11 libraries, see the readme file(s), yours will
>probably not work directly), the ID mechanism may need some work.  Not all
>PKCS11 libraries are created equal, none follow the specifications exactly
>and the specification is ambiguous in many places (especially when an
>application attempts to align certificates with private keys for 
>ID!@#$#$%).
>Please read the project readme files in the PKCS11 directories, they may
>help debug your PKCS11 library.  As to the IDs we use (All CTILS will 
>accept
>the proper DN string, be careful of upper/lower case letters, the other
>formats are internal IDs, usually a computer SOCKET and SLOT number):
>
>Login1=mstrpkcs.dll-01-11
>Login1=C=US@O=MISSI TEST@OU=MISSI TEST DOD@CN=Test User 1
>Login1=pk2priv.dll-00-01   # Login in GemPlus smart Card
>Login1=dkck232n.dll-02-01	# Login in DataKey smart Card
>Login1=Spex32.dll-02-01	# Login in DataKey smart Card
>
>See the following config files for our examples:
>
>./sm_pkcs11/SignedData/02_SignedGemPlus.cfg
>./sm_pkcs11/SignedData/03_SignedDataKey.cfg
>./sm_pkcs11/SignedData/01_SignedMaestro.cfg
>
>One final note:  the "sm_pkcs11Free3DLLd" project is quite new, combining
>several CTILs, please let me know if you encounter problems, it has been
>minimally tested.
>
>Good luck and welcome to the hardest part of this security world.  If you
>get too frustrated, we can help, but I will need to get a copy of your
>software, the card (properly configured with signer/encyrptor), some
>documentation.  If this is a commercial package, we may be able to add it 
>to
>our list of supported PKCS11 libraries (no promises on timeliness of our
>response, yet).  In any case, we can help.  We have hardware setup and
>configured for smart-cards, GemPlus, and PCMCIA which seem to be the most
>popular PKCS11 hardware tokens.
>
>Bob Colestock
>VDA
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.