RE: PKCS#11

Hi Bob,

I just saw now your last answer (my previous message was not aware of it...)

>Marco:
>
>Unfortunately, you happen to be using the least tested of our CTILs.  I am
>very surprised the CTIL even writes to the card, I did not expect this.  I
>am not the author of the PKCS11 interface, I will have to take time to
>investigate the logic you outline below.  Do you know if it is necessary to
>write the PIN to the card in order to perform signature operations?

I guess not. But even if yes, I imagine the object should be removed from 
the
card before the end of the run. And I did not find any call to
C_DestroyObject in the code. Another possibility is that C_CreateObject, in 
the
PKCS11 implementations you used, does not physically write on the card. But 
I
would find this strange.

>This would be a PKCS11 interface question, the CTIL only does what is 
>necessary
>based on the undercarriage crypto library (in this case PKCS11).  I am 
>aware
>that the original author had problems with the various PKCS11 libraries in
>attempting to match certificates with private keys.  The logic you have 
>been
>investigating attempts various approaches based on the PKCS11 object data
>structures to match them; I believe there are now 3 different techniques 
>for
>the various supported libraries (due to the authors of the PKCS11 libs, 
>each
>interpreted the specifications differently; this is not under our control).
>
>After looking at your previous e-mail, I see that you are integrating a new
>PKCS11 library.

Yes, I am integrating a new PKCS11 library, that is not mentioned between 
the
ones you support.

>Architecturally, I am surprised our logic writes an object
>to the card for the PIN.  Even if this is necessary, it would seem it 
>should
>be deleted at the end.  If you can indicate to me that this is not 
>necessary
>for proper PKCS11 operation, then I will investigate re-arranging the 
>PKCS11
>library to not perform this operation and keep track of this information
>internally (or at the least, delete the object at the end).  The "..."
>characters on the object name imply that something is different in your
>incarnation that we expected for the naming (a string).  I will have to
>investigate further.

I think the wrong label written on the card is a minor problem.

>In the mean-time, you might consider keeping the created object handle in
>the PKCS11 CTIL class memory, and if not NULL destroying it at the end; we
>do call the destructors on the CTILs.  I would override the name to be a
>constant string as you suggest.  This should get you operational in a short
>amount of time.  Please let me know if this works, we can attempt to
>implement this in the other libraries and re-test.  The logic that writes 
>to
>the card may have been necessary for a particular PKCS11 library we have
>tested with, update testing will indicate this.  If this is the case, we
>will #ifdef the write logic for that particular library if possible 
>(perhaps
>by input PKCS11 library file name).
>
>After viewing the referenced code, it would appear that the "m_hPinObject"
>object is not destroyed.  You should be able to destroy this object upon
>CSM_Pkcs11 destruction (or the inheriting class) and fix your problem.
>Please let me know.  I agree that your returned name should be "Data object
>for Pin", since this is hardcoded in the logic.  Could your library be
>losing track of this string?  Or perhaps not tracking it properly if our
>logic does not close the session?  Further testing will show; please let me
>know if this works, I will update the baseline.
>
>There were not relevant changes to the SFL R1.10 version.
>
>Bob Colestock
>VDA.

For the moment I simply commented the call to CSM_Pkcs11::SetPin.
Starting next week I'll be able to work on your suggestions.

Thanks

Bye

Marco
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.