Hello William, Thanks, I will consider you proposals this weekend.
Rapidly I would like to note that: I have an intention to change the format of the on-card MD help files (like for 'cmapfile'), to make it similar to the format that Gemalto is using. My intention is to not create/write them in MD itself, but in the pkcs15init part, with some corresponding opensc/pkcs15 configuration options. This pkcs15init part is already committed, but not MD. This is to say, that if currently now you are creating objects with MD, you will need to re-create them in the nearest future. Kind regards, Viktor. Le 02/12/2011 16:46, Hunter William a écrit : > Hi, > > I've attached a patch for some updates that I've made to Viktor's > secure-messaging branch. Sorry about the size and number of changes - I > didn't initially think that there would be so many. The commit details are > after this message. I've used the secure-messaging branch because it seems to > have the most up to date minidriver and IAS/ECC module. (I am working on an > IAS/ECC card) > > I now have both the PKCS#11 module and Minidriver working fairly well for > Document signing, Email signing and decryption, and client SSL certificate > verification. And also with PGP, although this is a very clunky interface. > This is all on a read-only IAS/ECC card. > > There may still be some threading/data issues, which Outlook seems to bring > to the surface quite easily, although the workarounds I have added seem to > have helped, and Outlook is now just very slow (which is probably normal!). > > Let me know if you have any questions about the changes. Most of them should > be fairly clean. One I forgot to mention in the commit log in the patch is a > workaround for Windows XP where CardDeleteContext may be called after DETACH > PROCESS, with bad results (pCardData becomes NULL at some point in the middle > of CardDeleteContext!). > > The one that might need the most thought is the generation of the GUID. The > way it was previously done failed on perfectly valid cards if the ID's were > too short. Plus, by just using a portion of the ID value, the GUID may no > longer be unique. However, what I do also has some issues (SHA1 on the ID's). > For one, there are issues with changing the GUID on existing keys, as they > will need to be reloaded into the Microsoft keystore. And it is probably also > not desirable to have the GUID change depending on whether the library was > compiled with openssl or not. But it seems clear that some sort of hash or > checksum is the right way to go. And with the minidriver still in beta, these > kind of changes should be expected by users. > > Regards, > Will > > ===================== > > Minidriver > ========== > Workaround some threading and data lifetime issues when card handle changes > and need to > re-associate card > > Workaround for Windows XP calling DllMain(Detach Process) before > CardDeleteContext > > Better generation of GUID if OpenSSL available > > Report PIN tries left/PIN blocked > > Corrected PKCS#1 padding handling in CardRSADecrypt > > Support SHA256 in CardSignData > > PKCS11 module > ============= > Allow use of Unwrap keys in C_DecryptInit > > CardMod reader module > ===================== > Support user specified DLL > > Tools > ===== > Fix issue where PC/SC system reported card present with zero > length ATR (when no card actually present) > > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
