[opensc-devel] Multiple ACLs
Hi, actually pkcs15init takes into account the possibility of multiple ACLs for one operation. Is it really used? Multiple ACLs appear as linked list associated to operation, for example, when loading generic profile 'pkcs15' and then the card specific one. Authentication of an operation in pkcs15init requests to validate all the PINs from the associated list (if there are no 'NONE' or ''NEVER' in the same list). As for me, the expected behavior in this situation has to be 'overwrite the generic settings with the card specific one'. Multiple ACLs concern only the files instantiated from profile. In libopensc all(?) card specific FCP encoders use only the first acl from the list. So, I propose to abandon multiple ACLs, because it complicates the creation of a new objects for the OpenSC PKCS#11 module. Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] itacns driver in WIndows
Hi, current trunk cannot be compiled with Visual Studio that do not supports the declaration of the variables inside the block after the first instruction. Actually it's the case in 'card-itacns' and 'pkcs15-itacns'. Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
Aventra development wrote: Hi, I don’t have any objections on the change you proposed Andre. I have also prepared and attached to this message a patch, please review and commit. It adds the following features to the MyEID driver (based on trunk) includes also some fixes on whitespace: - Card initialization and finalization (activation) - Key generation (thanks to Viktor, however now I have some problem with pcsc transmit failing after some time while the card is generating the key) - PIN change and unblock (code added to MyEID driver, but it does not work with pkcs15-tool (does nothing), There is little 'copy&past' issue in your patch. It's corrected in r4682. pkcs11-tool works, but pkcs#11 module does not when using Firefox). Other problems with firefox is that certificate enrollment does not work when using the pkcs#11 module, e.g. when using this site: pkitest.gdm.de/starsign Actually in MyEID profile some operations that should be executed during the card enrollment are protected by SOPIN. It's rather difficult to supply SOPIN for PKCS#11 module inside the User session. Here is patch with the working version of MyEID profile. Not all changes in this patch are justified, but it can be tuned later. There is also the problem of 'Multiple ACLs' http://www.opensc-project.org/pipermail/opensc-devel/2010-September/014803.html Here is also the patch that allows (in a temporary manner) to pass-by the problem of 'Multiple ACLs'. With these two patchs I can import pkcs12 with Firefox in Windows. PIN change/unblock with pkcs15-tool also 'working for me'. Omnikey CardMan 3121 has been used in my tests. Anyway it's a step forward. If somebody is able to help with the Firefox problem or knows why the pkcs15-tool does not work, feel free to edit the code or send some information to me so we will get also these working. Kind regards, Toni Kind wishes, Viktor. -Original Message- From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- boun...@lists.opensc-project.org] On Behalf Of Andre Zepezauer Sent: 31. elokuuta 2010 21:02 To: Viktor TARASOV Cc: 'OpenSC-devel' Subject: Re: [opensc-devel] Problem with 2K keys and MyEID On Tue, 2010-08-31 at 18:40 +0200, Viktor TARASOV wrote: Andre Zepezauer wrote: On Mon, 2010-08-30 at 15:19 +0200, Viktor TARASOV wrote: Aventra development wrote: The 1K key generation works nicely, but we are having a problem generating a 2K key using OpenSC 0.11.13 and our own MyEID card. OpenSC correctly finds a new file id and creates the file, and after that it tries to store the key to that file. The issue is that the created file’s size is only 1024 bytes, so the card will answer with 67 00 (Wrong length). Some code in OpenSC decides to create the wrong sized file, but I have not been able to find it. Now I’m curious that, does other cards work when generating (or just loading) 2048 byte keys? For me, to generate the 2048 bits key on the Aventra card, the following path was needed to be applied to the OpenSC trunk. If no objection, I'll commit this patch to trunk. Hello Viktor, I would write the check for supported modulus length a bit more generic. But it's functional the same like yours, because myeid supports only 1024 and 2048 bit (at least the driver does). Therefore it doesn't matter a lot. #include "internal.h" pkcs15init/pkcs15-myeid.c:513 /* check that the card supports the requested modulus length */ if (_sc_card_find_rsa_alg(p15card->card, keybits) == NULL) SC_TEST_RET(ctx, LEVEL, ERROR, MSG); Agree, it's much better. I hope that Toni (maintainer of myEID driver) have no objections. On the other hand it would be fine to give a good example, because someone may want to copy+paste your code. See copy+paste in the card drivers [1]. The same check also occurs in line 427, 514, 574, 637. And interestingly _always_ some lines below there is the following conditional assignment: if (file->size < 1024) file->size = 1024; Will you prepare the patch? Haven't the required hardware, therefore testing isn't possible to me. But if someone would send me some pieces of these cards, I could do it myself the next time. Regards Andre Kind wishes, Viktor. [1]http://www.opensc-project.org/pipermail/opensc-devel/2010- August/014615.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov Index: src/pkcs15init/profile.c === --- src/pkcs15init/profile.c(révision 4692) +++ src/pkcs15init/profile.c(copie de travail) @@ -1355,7 +1355,7 @@ if (map_str2int(cur, oper, &op, fileOpNames))
Re: [opensc-devel] [opensc-commits] svn opensc changed[4692] pkcs11: #250: refresh PIN counters and associated token flags on every call to C_GetTokenInfo
webmas...@opensc-project.org wrote: > Revision: 4692 > Author: martin > Date: 2010-09-05 16:53:08 + (Sun, 05 Sep 2010) > > Log Message: > --- > pkcs11: #250: refresh PIN counters and associated token flags on every call > to C_GetTokenInfo > > Modified: trunk/src/pkcs11/framework-pkcs15.c > +CK_RV C_GetTokenInfo(CK_SLOT_ID slotID, CK_TOKEN_INFO_PTR pInfo) > > Modified: trunk/src/pkcs11/pkcs11-global.c > -CK_RV C_GetTokenInfo(CK_SLOT_ID slotID, CK_TOKEN_INFO_PTR pInfo) > I do not agree with this change. Why to spoil the old house, when we are not yet ready to build a new one? Certainly, inside the opensc-pkcs11, like in the stomach, all in one place, but I guess that somebody can be sensible to the order of arrival. In this changes the common 'C_' function is defined inside the 'framework-pkcs15' when 'framework-pkcs15init' is still there. With the same logic we can start to define the common libopensc functions inside the card drivers. Why not? At the end of course all this stuff will be inside the same library. IMHO, first of all the re-design of frameworks has to be done in atomic manner, then the upper changes. Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] itacns driver in WIndows
Will take care of that today or tomorrow, thanks for pointing this out! Best regards, Emanuele On Mon, Sep 6, 2010 at 09:18, Viktor TARASOV wrote: > Hi, > > current trunk cannot be compiled with Visual Studio > that do not supports the declaration of the variables > inside the block after the first instruction. > > Actually it's the case in 'card-itacns' and 'pkcs15-itacns'. > > Kind wishes, > Viktor. > > -- > Viktor Tarasov > > ___ > 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
Re: [opensc-devel] Logical Channels
Andre Zepezauer wrote: > Every modern Java card and in particular GlobalPlatform is capable of > doing so, if the applet implements javacard.framework.MultiSelectable. > Once I've tried to use it with the card that declares this possibility in its specification, but, in reality it was not (properly) implemented. I guess that such a case is not the unique one. Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
Viktor TARASOV wrote: > Aventra development wrote: >> - PIN change and unblock (code added to MyEID driver, but it does not >> work with pkcs15-tool (does nothing), > There is little 'copy&past' issue in your patch. > It's corrected in r4682. Sorry, it's in r4693. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4692] pkcs11: #250: refresh PIN counters and associated token flags on every call to C_GetTokenInfo
Hello, On Sep 6, 2010, at 11:27 AM, Viktor TARASOV wrote: > webmas...@opensc-project.org wrote: >> Modified: trunk/src/pkcs11/framework-pkcs15.c >> +CK_RV C_GetTokenInfo(CK_SLOT_ID slotID, CK_TOKEN_INFO_PTR pInfo) >> >> Modified: trunk/src/pkcs11/pkcs11-global.c >> -CK_RV C_GetTokenInfo(CK_SLOT_ID slotID, CK_TOKEN_INFO_PTR pInfo) >> > > I do not agree with this change. > Why to spoil the old house, when we are not yet ready to build a new one? There are five options to deal with the legacy when implementing this feature: a) include pkcs15 specific headers in pkcs11-global.c. Would be a "violation" for the rest of those "global" functions as they currently are. But could be "right" in the long run, as the PKCS#11 module should be enritely built upon PKCS#15 layer of libopensc (be it R/O or initialization code) b) move C_GetTokenInfo to framework-pkcs15.c. Is a violation for the rest of framework-pkcs15.c and maybe insults pkcs15-global.c, but simple. c) create a new "global-pkcs15.c" or "pkcs15-token.c" style file with C_GetTokenInfo, that talks directly to libopensc, bypassing the "framework" glue in the PKCS#11 module, maybe shifting some other "global but PKCS#15-ish" stuff there. d) extend the "framework-framework" code inside PKCS#15 to define a update_token function or something similar? e) omit the change because it "does not fit in the file hierarchy" f) something else ? The only other option for me could be a). I chose b). Would a) be better or do you have other suggestions? > Certainly, inside the opensc-pkcs11, like in the stomach, all in one place, > but I guess that somebody can be sensible to the order of arrival. > > In this changes the common 'C_' function is defined inside > the 'framework-pkcs15' when 'framework-pkcs15init' is still there. It is still the same way common (or global) as before, as the framework-framework creators did not foresee the need for dynamic token state updates, so this abstraction is missing. > With the same logic we can start to define the common libopensc > functions inside the card drivers. > Why not? At the end of course all this stuff will be inside the same > library. Yes. Many cards do (re-) implement libopensc functions in card drivers. I don't approve it either. But the card driver folder is in a much better shape (and way better defined) than the PKCS#11 implementation, IMHO. > IMHO, first of all the re-design of frameworks has to be done in atomic > manner, > then the upper changes. Sure. I hope it does not make it more complicated to pick out and change the C_* functions. I would suggest deleting the whole framework-framework thing in PKCS#11 and hardwire specific functions to specific libopensc sc_pkcs15_* and sc_pkcs15init_* calls. -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release / PIN not asked
Am Donnerstag 02 September 2010 schrieb Martin Paljak: > > Please provide opensc-debug.log for TCOS2 for the failing transaction with > 0.12.0. If possible, also the successful log with 0.11.X might help. The logs are http://www.uni-giessen.de/~g013/opensc/report-bug.txt http://www.uni-giessen.de/~g013/opensc/opensc-debug.0.11.13-1.log http://www.uni-giessen.de/~g013/opensc/opensc-debug.0.12.0-svn-r4647.log Version 0.12 does not ask for the PIN, 0.11.13 does. Sorry for the late answer. Johannes ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
Hello, On Sep 6, 2010, at 11:02 AM, Viktor TARASOV wrote: > Aventra development wrote: >> - PIN change and unblock (code added to MyEID driver, but it does not work >> with pkcs15-tool (does nothing), > There is little 'copy&past' issue in your patch. > It's corrected in r4682. The included patch does it even better in less (almost no) code, at least pin change and unblock seem to work without problems. The card_state handling should also be fixed, but I don't know what the initial value for it should be, thus the FIXME. myeid.patch Description: Binary data -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release / PIN not asked
Hello, On Sep 6, 2010, at 2:05 PM, Johannes Becker wrote: > Am Donnerstag 02 September 2010 schrieb Martin Paljak: > >> >> Please provide opensc-debug.log for TCOS2 for the failing transaction with >> 0.12.0. If possible, also the successful log with 0.11.X might help. > > The logs are > http://www.uni-giessen.de/~g013/opensc/report-bug.txt > http://www.uni-giessen.de/~g013/opensc/opensc-debug.0.11.13-1.log > http://www.uni-giessen.de/~g013/opensc/opensc-debug.0.12.0-svn-r4647.log > > Version 0.12 does not ask for the PIN, 0.11.13 does. With which application are you using opensc-pkcs11.so? The application is never calling C_Login. What is the output of pkcs11-tool -L ? Does it include for your slot: token flags: rng, readonly, ***login required***, PIN initialized, token initialized ? -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4692] pkcs11: #250: refresh PIN counters and associated token flags on every call to C_GetTokenInfo
Martin Paljak wrote: > Hello, > > On Sep 6, 2010, at 11:27 AM, Viktor TARASOV wrote: > >> webmas...@opensc-project.org wrote: >> >>> Modified: trunk/src/pkcs11/framework-pkcs15.c >>> +CK_RV C_GetTokenInfo(CK_SLOT_ID slotID, CK_TOKEN_INFO_PTR pInfo) >>> >>> Modified: trunk/src/pkcs11/pkcs11-global.c >>> -CK_RV C_GetTokenInfo(CK_SLOT_ID slotID, CK_TOKEN_INFO_PTR pInfo) >>> >>> >> I do not agree with this change. >> Why to spoil the old house, when we are not yet ready to build a new one? >> > There are five options to deal with the legacy when implementing this feature: > > a) include pkcs15 specific headers in pkcs11-global.c. Would be a "violation" > for the rest of those "global" functions as they currently are. But could be > "right" in the long run, as the PKCS#11 module should be enritely built upon > PKCS#15 layer of libopensc (be it R/O or initialization code) > b) move C_GetTokenInfo to framework-pkcs15.c. Is a violation for the rest of > framework-pkcs15.c and maybe insults pkcs15-global.c, but simple. > c) create a new "global-pkcs15.c" or "pkcs15-token.c" style file with > C_GetTokenInfo, that talks directly to libopensc, bypassing the "framework" > glue in the PKCS#11 module, maybe shifting some other "global but > PKCS#15-ish" stuff there. > d) extend the "framework-framework" code inside PKCS#15 to define a > update_token function or something similar? > e) omit the change because it "does not fit in the file hierarchy" > f) something else ? > > The only other option for me could be a). I chose b). Would a) be better or > do you have other suggestions? > As for me, firstly the frame-less pkcs11 should be commited and after that the needed functionality implemented. Meanwhile (as a rapid answer) extend the 'framework'. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release
more fun with the upcoming 0.12.0 release: - the only way I know how to initialize an Aladdin eToken PRO 32K with opensc is by using the openct driver; is there another way? - once I initialize an Aladdin eToken using opensc I can generate 2048 bit keys, add and delete objects etc. Everything works, however ... : - why must I *always* specify the SO-PIN when writing objects to the eToken? - there is tiny glitch when re-initializing the card: #initialize > ./pkcs15-init -C -T -P -a 01 Using reader with a card: Aladdin eToken PRO 64k New Security Officer PIN (Optional - press return for no PIN). Please enter Security Officer PIN: [SO-PIN] Please type again to verify: [SO-PIN] Unblock Code for New User PIN (Optional - press return for no PIN). Please enter User unblocking PIN (PUK): New User PIN. Please enter User PIN: [PIN] Please type again to verify: [PIN] Unblock Code for New User PIN (Optional - press return for no PIN). Please enter User unblocking PIN (PUK): # write an object > ./pkcs15-init --store-certificate ~/.globus/usercert.pem --auth-id 01 --id 123456 --format pem Using reader with a card: Aladdin eToken PRO 64k User PIN required. Please enter User PIN: [PIN] Security officer PIN [Security Officer PIN] required. Please enter Security officer PIN [Security Officer PIN]: [SO-PIN] # now erase the card > ./pkcs15-init -E Using reader with a card: Aladdin eToken PRO 64k PIN [Security Officer PIN] required. Please enter PIN [Security Officer PIN]: [SO-PIN] Unspecified PIN [reference 3] required. Please enter Unspecified PIN [reference 3]: [PIN] The unspecified pin 'reference 3' is actually the user pin ... other than that (and other than that I still need a bleeding-edge pcsc version for the Feitian cards to work correctly) this version looks great! share and enjoy, JJK / Jan Just Keijser ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release
2010/9/6 Jan Just Keijser : > more fun with the upcoming 0.12.0 release: > > - the only way I know how to initialize an Aladdin eToken PRO 32K with > opensc is by using the openct driver; is there another way? Follow [1]. Maybe the token is CCID compliant. Bye [1] http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release
Hi Ludovic, Ludovic Rousseau wrote: > 2010/9/6 Jan Just Keijser : > >> more fun with the upcoming 0.12.0 release: >> >> - the only way I know how to initialize an Aladdin eToken PRO 32K with >> opensc is by using the openct driver; is there another way? >> > > Follow [1]. Maybe the token is CCID compliant. > > Bye > > [1] http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant > > Thanks for the quick response. I had the ccid driver installed yet opensc/pcsc-lite did not recognize it - I guess this means the Aladdin eToken PRO is (also) *NOT* CCID compliant. Time to update the wiki? cheers, JJK / Jan Just Keijser ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with 2K keys and MyEID
Martin Paljak wrote: > Hello, > > On Sep 6, 2010, at 11:02 AM, Viktor TARASOV wrote: > > >> Aventra development wrote: >> >>> - PIN change and unblock (code added to MyEID driver, but it does not work >>> with pkcs15-tool (does nothing), >>> >> There is little 'copy&past' issue in your patch. >> It's corrected in r4682. >> > The included patch does it even better in less (almost no) code, at least pin > change and unblock seem to work without problems. > The card_state handling should also be fixed, but I don't know what the > initial value for it should be, thus the FIXME. > In fact, it's better. Let's wait Tony to test and approve. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SC_SEC_ENV_KEY_REF_ASYMMETRIC
Hello Andre, On Aug 20, 2010, at 2:02 AM, Andre Zepezauer wrote: > Hello Martin, > > according to your last post, here are my first suggestions for an > improvement: > > 1. Fix the SC_SEC_ENV_KEY_REF_ASYMMETRIC magic > See how this flag is used and where it is set! Do you have a patch for this? > The first point is the most easy one, if the affected drivers are > maintained and the one and only supported algorithm is RSA. OpenSC supports only RSA in real life. DSA support is not existing, AFAIK. GOST support is .. under verification. > My suggestion is to rename this flag to SC_SEC_ENV_KEY_ASYMMETRIC. BTW it's > very amusing that two wrong assumptions lead to a correct result. > Now what do you think? Are this the kind of improvements you would like > to see in opensc? Yes, please. The algref-patch.txt could be next to go after this fix. Bye, -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4692] pkcs11: #250: refresh PIN counters and associated token flags on every call to C_GetTokenInfo
Hello, On Sep 6, 2010, at 3:36 PM, Viktor TARASOV wrote: >> There are five options to deal with the legacy when implementing this >> feature: >> >> a) include pkcs15 specific headers in pkcs11-global.c. Would be a >> "violation" for the rest of those "global" functions as they currently are. >> But could be "right" in the long run, as the PKCS#11 module should be >> enritely built upon PKCS#15 layer of libopensc (be it R/O or initialization >> code) >> b) move C_GetTokenInfo to framework-pkcs15.c. Is a violation for the rest of >> framework-pkcs15.c and maybe insults pkcs15-global.c, but simple. >> c) create a new "global-pkcs15.c" or "pkcs15-token.c" style file with >> C_GetTokenInfo, that talks directly to libopensc, bypassing the "framework" >> glue in the PKCS#11 module, maybe shifting some other "global but >> PKCS#15-ish" stuff there. >> d) extend the "framework-framework" code inside PKCS#15 to define a >> update_token function or something similar? >> e) omit the change because it "does not fit in the file hierarchy" >> f) something else ? >> >> The only other option for me could be a). I chose b). Would a) be better or >> do you have other suggestions? >> > > As for me, firstly the frame-less pkcs11 should be commited and after > that the needed functionality implemented. > Meanwhile (as a rapid answer) extend the 'framework'. Sorry, that would be like beating a dead badger with a sausage - "fun" but pointless. If you look at the code closely, you see that framework-pkcs15init.c is mostly garbage, with only a single goal of reacting to C_InitToken. Which, I assume, does not work very well anyway. The rest of pkcs15init (one of the two "frameworks") functions return (incorrectly) CKR_CRYPTOKI_NOT_INITIALIZED and framework-pkcs15.c has #ifdef USE_PKCS15_INIT defines that implement calls to pkcs15init functionality, that SHOULD be in framework-pkcs15init.c instead. The "framework framework" is thus an extra, not necessary indirection layer that serves no purpose. In one word: useless. But cleaning it out is more work than implementing one function more-or-less like it should be in the future. The file where it eventually ends up inside src/pkcs11 does not really matter. Once the cleanup is done, it will be clear. -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4692] pkcs11: #250: refresh PIN counters and associated token flags on every call to C_GetTokenInfo
Martin Paljak wrote: > Hello, > On Sep 6, 2010, at 3:36 PM, Viktor TARASOV wrote: > >>> There are five options to deal with the legacy when implementing this >>> feature: >>> >>> a) include pkcs15 specific headers in pkcs11-global.c. Would be a >>> "violation" for the rest of those "global" functions as they currently are. >>> But could be "right" in the long run, as the PKCS#11 module should be >>> enritely built upon PKCS#15 layer of libopensc (be it R/O or initialization >>> code) >>> b) move C_GetTokenInfo to framework-pkcs15.c. Is a violation for the rest >>> of framework-pkcs15.c and maybe insults pkcs15-global.c, but simple. >>> c) create a new "global-pkcs15.c" or "pkcs15-token.c" style file with >>> C_GetTokenInfo, that talks directly to libopensc, bypassing the "framework" >>> glue in the PKCS#11 module, maybe shifting some other "global but >>> PKCS#15-ish" stuff there. >>> d) extend the "framework-framework" code inside PKCS#15 to define a >>> update_token function or something similar? >>> e) omit the change because it "does not fit in the file hierarchy" >>> f) something else ? >>> >>> The only other option for me could be a). I chose b). Would a) be better or >>> do you have other suggestions? >>> >>> >> As for me, firstly the frame-less pkcs11 should be commited and after >> that the needed functionality implemented. >> Meanwhile (as a rapid answer) extend the 'framework'. >> > > Sorry, that would be like beating a dead badger with a sausage - "fun" but > pointless. > Sorry, I'm not sufficiently intelligent to perceive your joke. > If you look at the code closely, you see that framework-pkcs15init.c is > mostly garbage, with only a single goal of reacting to C_InitToken. Which, I > assume, does not work very well anyway. > The rest of pkcs15init (one of the two "frameworks") functions return > (incorrectly) CKR_CRYPTOKI_NOT_INITIALIZED and framework-pkcs15.c has #ifdef > USE_PKCS15_INIT defines that implement calls to pkcs15init functionality, > that SHOULD be in framework-pkcs15init.c instead. > The "framework framework" is thus an extra, not necessary indirection layer > that serves no purpose. In one word: useless. > Agree, so, go ahead, get rid of frameworks. Long time ago this task was already mentioned. Finally it's not so complicated, isn't it? > But cleaning it out is more work than implementing one function more-or-less > like it should be in the future. The file where it eventually ends up inside > src/pkcs11 does not really matter. Once the cleanup is done, it will be > clear. > I've got already know how much time it takes to implement the good intentions in OpenSC. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for testing of the upcoming 0.12.0 release
2010/9/6 Jan Just Keijser : > Thanks for the quick response. I had the ccid driver installed yet > opensc/pcsc-lite did not recognize it - I guess this means the Aladdin > eToken PRO is (also) *NOT* CCID compliant. Time to update the wiki? Please, do not guess. Just follow the procedure as described in [1]. [1] http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
