[opensc-devel] Delete 'staging' branch of github OpenSC/OpenSC project
Hello, During considerable time already the master and staging branches have been closely synchronized. As for me we can close the 'staging' branch. It's initial role was to be a buffer for the new features, now this function is fulfilled by the 'master' itself and by the pull-requests branches. If no objections, I will remove the 'staging' branch. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of the server migration
Hello, On Thu, Dec 27, 2012 at 4:26 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: 2012/12/26 Viktor Tarasov viktor.tara...@gmail.com: On Wed, Dec 26, 2012 at 3:56 PM, Andreas Jellinghaus andr...@ionisiert.de * mailing lists: no idea what the current status is (i.e. this is a test mail). Do we have new lists? Subscribers migrated or invited? Does this old list still work, or should I shut it down? The mailing lists with the same names are created on SF. The request to import the 'OpenSC' archive (for a while only OpenSC) is pending. https://sourceforge.net/tracker/?func=detailatid=497423aid=3596976group_id=61487 Viktor, this request has been closed the same day you opened it. It looks like it is not the correct procedure. Sorry, the correct link is: https://sourceforge.net/p/forge/site-support/2051/ I just sent an email on each of the 3 lists to ask users to resubscribe to the lists at SF. * Trac/Wiki/ - any progress here? I remember so offerings and questions to migrate, but no status update since - maybe I missed it? We are waiting solution from Peter. I don't think we can count on Peter. I had a bad experience on the libusb project and waited after Peter for a new release during 2 years before participating to a forked project (libusbx). If something will no go as he expects, the alternative solution is to use the Wiki on github. Currently all wiki pages of OpenSC are migrated to github. https://github.com/OpenSC/OpenSC/wiki Sure, the github wiki is not the equivalent substitution to the WikiTrac, but an advantage is that there is no dependence on particular person to get it running. I do not like it at all but we may have lose all the bugs reported at opensc-project.org and start a new collection at github. If it is possible to do it automatically we may add a comment to every bug asking the bug reporter to report it again on github if the bug is still valid. Ok, I see. I will look around for a different solution. Probably migrate tracwiki to my platform . * opensc-project.org domain - registered to martin paljak, opensc.org reigstered to same unknown person - opensc.com for sale. any chance to move one of the domains to (whom?) someone? or live without them? I have no much experience, but my guess is if Peter will create a real wikitrac, he could use this domain for this service. If not, I can use this domain for the actual opensc.fr platform. Martin is busy with other project and real life. The best we can do is ask him to redirect opensc-project.org to opensc.org so a web site is still available. Currently my platform use the 'opensc.fr' domain name, but, it can be changed for 'opensc.org', if necessary. Anything else I missed? As said, I'd like to retire the server end of year, as it is a very old and unmaintained installation. Andreas, can you wait until mid-January before retiring the server so I have a chance to backup what I can? I am not at home now. Thanks -- 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] Status of the server migration
Hello, merry Christmas, On Wed, Dec 26, 2012 at 3:56 PM, Andreas Jellinghaus andr...@ionisiert.dewrote: But for those with time on their hands for open source project work: can someone summarize the current status of our server migration? * source code: now all in git on github, right? Does everyone have access who needs? What is the new system, people are asked to push patches to the mailing list and someone collects them? Or should people have their own repo, publish patches there and someone else pulls them? (more work, maybe not such a good idea) Or do we have an rietveld instance somewhere, so people can push changes there (how?) and they get compile-build-tested? All sources, OpenSC and sub-projects, are in github. The contributions are passing through the pull-requests. The pull requests from 'confirmed' contributors are automatically built on Ubuntu and Windows-Vista (other platforms are coming). For the other contributors the build of pull request has to be validated by one of 'admins' . 'Admins' can add contributor to the 'confirmed contributors' list. The 'admin' operations are accessible through the coded messages in comments to the pull-request. Admin can merge pull-request using the github interface, but, for the sake of linear git's history, it's preferable to pull the contributor's branch into the local branch, rebase it if necessary and push it 'ff-only' to the github's master. * mailing lists: no idea what the current status is (i.e. this is a test mail). Do we have new lists? Subscribers migrated or invited? Does this old list still work, or should I shut it down? The mailing lists with the same names are created on SF. The request to import the 'OpenSC' archive (for a while only OpenSC) is pending. https://sourceforge.net/tracker/?func=detailatid=497423aid=3596976group_id=61487 * Continuous build: is there a replacement system for the (jenkins?) system we have/had on the old server? https://opensc.fr/jenkins is currently working for OpenSC. Currently it builds the commits to 'master' and 'staging', 'releases' and 'pull-requests'. It still needs some efforts/support to build the packages on SuSE and debian, and to run automatic tests. There is no slaves to build for MAC. * Trac/Wiki/ - any progress here? I remember so offerings and questions to migrate, but no status update since - maybe I missed it? We are waiting solution from Peter. If something will no go as he expects, the alternative solution is to use the Wiki on github. Currently all wiki pages of OpenSC are migrated to github. https://github.com/OpenSC/OpenSC/wiki Sure, the github wiki is not the equivalent substitution to the WikiTrac, but an advantage is that there is no dependence on particular person to get it running. * opensc-project.org domain - registered to martin paljak, opensc.org reigstered to same unknown person - opensc.com for sale. any chance to move one of the domains to (whom?) someone? or live without them? I have no much experience, but my guess is if Peter will create a real wikitrac, he could use this domain for this service. If not, I can use this domain for the actual opensc.fr platform. Anything else I missed? As said, I'd like to retire the server end of year, as it is a very old and unmaintained installation. Regards, Andreas Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Windows minidriver reg file for the ePass2003
Hello, On Thu, Dec 20, 2012 at 12:20 PM, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: Can anyone help me set the correct value for the ePass2003 mini driver registry: http://download.gooze.eu/pki/opensc/windows/minidriver/exported-ePass2003.reg The content of the file is: ** Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards \OpenSC ePass2003 ECP] ATR=hex:3b,9f,95,81,31,fe,9f,00,66,46,53,05,01,00,11,71,df,00,00,03,6a,82,f8 ATRMask=hex,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff The length of ATRMask has to be the same as the lengths of ATR. Crypto Provider=Microsoft Base Smart Card Crypto Provider Smart Card Key Storage Provider=Microsoft Smart Card Key Storage Provider 8001=opensc-minidriver.dll opensc-tool --atr Using reader with a card: Feitian ePass2003 00 00 3b:9f:95:81:31:fe:9f:00:66:46:53:05:01:00:11:71:df:00:00:03:6a:82:f8 What is missing in my reg file to make the mini-driver work? Kind regards, Jean-Michel POURE -- GOOZE - http://www.gooze.eu High quality cryptographic tools for GNU/Linux, Mac OS X and Windows POURE SASU - 17 rue Saint Jacques - 95160 Montmorency - France Tel : +33 (0)9 72 13 53 90 - Mobile : +33 (0)6 51 99 37 90 Registry: FR 527 672 448 00018 - VAT: FR54527672448 CAcert root certificate: http://www.cacert.org/index.php?id=3 ID PGP/GPG: 084F2584 ___ 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] How to compile opensc in windows?
Le 12/12/2012 15:53, Rns Course a écrit : Hello I need to compile opensc-0.11.3. On this page: http://www.opensc-project.org/opensc/wiki/WindowsInstaller The command x86: SetEnv.cmd /x86 /Release and nmake /f win32\Makefile.msc LOC=-DASMV -DASMINF OBJA=inffas32.obj match686.obj zlib.lib is written, while there's not Makefile.msc file in the package. There is a Makefile.mak in it. Could you tell me how I should compile it on windows? Here below are the build commands from jenkins configuration, used for 'github commit' builds. win32: # cd C:\Program Files\Microsoft Visual Studio 10.0\VC\ # call vcvarsall.bat x86 # cd %WORKSPACE%\opensc-* # nmake /f Makefile.mak # cd win32 # nmake /f Makefile.mak OpenSC.msi win64: # call C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x64 /Release # cd %WORKSPACE%\opensc-* # nmake /f Makefile.mak BUILD_ON=WIN64 BUILD_FOR=WIN64 # cd win32 # nmake /f Makefile.mak BUILD_ON=WIN64 BUILD_FOR=WIN64 OpenSC.msi THX ___ 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] OpenSC Wiki in github
Hello, now the 'ListTagged' trac macros are expanded by the migration tool (thanks a lot to Nicolas Delon). 'SupportedHardware' page, the other ones that have used this macro, seems working properly. I think that's all that can be done with migration script -- the rest is manual. On Wed, Dec 12, 2012 at 10:58 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: 2012/12/11 Viktor Tarasov viktor.tara...@gmail.com: (Only wiki pages, not tickets.) I hope we can migrate the tickets using a tool and not only by hand. Without trac dedicated platform I guess that we have to look for using of the github's 'issues' system. I will look if it's possible to migrate there the trac tickets. As an extreme, desperate solution we can abandon the trac tickets and use the github 'issues'. The OpenSC Wiki pages in github are converted into 'textile' format. The rapid script used for this conversion, the archives with the dump of the OpenSC sub-project wiki pages and wiki attachments are also present in wiki repository. (Files are not accessible with GUI -- you need to clone repository. [2]) Using these files and archives the Wiki of the other OpenSC sub-projects can be also migrated to github. All the subprojects are in the OpenSC wiki. Maybe we should migrate their wiki pages to their own github wiki repository. But I don't know how easy that would be. It looks like the subprojects do not have many wiki pages. I will apply the resulted migration script to the sub-projects wiki also. I do not yet looked 'manually' through all the wiki pages to update existing, suppress obsolete or add new information. I will do it gradually and invite you as well to participate in this exciting activity, if you have will, possibility, time, etc... If you notice any 'systematic' conversion error, tell me please, I will change the conversion script and re-submit the pages . Some pages can be removed like [1] and [2] since they are about trac. Ok, thanks. Bye Kind regards, Viktor. [1] https://github.com/OpenSC/OpenSC/wiki/WikiFormatting [2] https://github.com/OpenSC/OpenSC/wiki/Using-HTML-in-Wiki-Text -- Dr. Ludovic Rousseau ___ 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
[opensc-devel] OpenSC Wiki in github
Hello, for a while we have no news about migration of tracwiki to the dedicated platform. Meanwhile, waiting for better solution, I migrated OpenSC wiki to github [1] . (Only wiki pages, not tickets.) The OpenSC Wiki pages in github are converted into 'textile' format. The rapid script used for this conversion, the archives with the dump of the OpenSC sub-project wiki pages and wiki attachments are also present in wiki repository. (Files are not accessible with GUI -- you need to clone repository. [2]) Using these files and archives the Wiki of the other OpenSC sub-projects can be also migrated to github. I do not yet looked 'manually' through all the wiki pages to update existing, suppress obsolete or add new information. I will do it gradually and invite you as well to participate in this exciting activity, if you have will, possibility, time, etc... If you notice any 'systematic' conversion error, tell me please, I will change the conversion script and re-submit the pages . Kind regards, Viktor. [1] https://github.com/OpenSC/OpenSC/wiki [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Wiki in github
Hello Andreas, On Tue, Dec 11, 2012 at 4:40 PM, Andreas Schwier andreas.schw...@cardcontact.de wrote: What do we want to do about the automatic list generation that is not working on GITHUB (e.g. SupportedHardware) ? Thanks, I do not noticed it. Do we copy the list as is from the old wiki ? For a while yes. My intention is to script the conversion as close as possible to existing wiki, and then 'gradually' update the resulted pages manually. Andreas Kind regards, Viktor. Am 11.12.2012 16:17, schrieb Viktor Tarasov: Hello, for a while we have no news about migration of tracwiki to the dedicated platform. Meanwhile, waiting for better solution, I migrated OpenSC wiki to github [1] . (Only wiki pages, not tickets.) The OpenSC Wiki pages in github are converted into 'textile' format. The rapid script used for this conversion, the archives with the dump of the OpenSC sub-project wiki pages and wiki attachments are also present in wiki repository. (Files are not accessible with GUI -- you need to clone repository. [2]) Using these files and archives the Wiki of the other OpenSC sub-projects can be also migrated to github. I do not yet looked 'manually' through all the wiki pages to update existing, suppress obsolete or add new information. I will do it gradually and invite you as well to participate in this exciting activity, if you have will, possibility, time, etc... If you notice any 'systematic' conversion error, tell me please, I will change the conversion script and re-submit the pages . Kind regards, Viktor. [1] https://github.com/OpenSC/OpenSC/wiki [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ 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] OpenSC Wiki in github
Hello, On Tue, Dec 11, 2012 at 5:08 PM, Toni Sjoblom - Aventra developm...@aventra.fi wrote: I tried to find the page about MyEID but it seems to be missing in GitHub wiki. Also several of the lists are missing/truncated (e.g. supported hardware, just a link to create a new page is shown). https://github.com/OpenSC/OpenSC/wiki/Aventra-MyEID-PKI-card The name of the migrated pages are constructed from the first h1 header of this page. This is because of the amazing feature of github wiki (or my own un-comprehension) to show as a page title the name of file and not the first h1 title. That's why the migration script changes the names and references. The conversion of the list of supported hardware is still to be scripted. ** ** Kind regards, Toni Kind wishes, Viktor. ** ** *From:* opensc-devel-boun...@lists.opensc-project.org [mailto: opensc-devel-boun...@lists.opensc-project.org] *On Behalf Of *Viktor Tarasov *Sent:* 11. joulukuuta 2012 17:18 *To:* OpenSC Development *Subject:* [opensc-devel] OpenSC Wiki in github ** ** Hello, ** ** for a while we have no news about migration of tracwiki to the dedicated platform. ** ** Meanwhile, waiting for better solution, I migrated OpenSC wiki to github [1] . (Only wiki pages, not tickets.) ** ** The OpenSC Wiki pages in github are converted into 'textile' format. ** ** The rapid script used for this conversion, the archives with the dump of the OpenSC sub-project wiki pages and wiki attachments are also present in wiki repository. (Files are not accessible with GUI -- you need to clone repository. [2]) Using these files and archives the Wiki of the other OpenSC sub-projects can be also migrated to github. ** ** I do not yet looked 'manually' through all the wiki pages to update existing, suppress obsolete or add new information. ** ** I will do it gradually and invite you as well to participate in this exciting activity, if you have will, possibility, time, etc... If you notice any 'systematic' conversion error, tell me please, I will change the conversion script and re-submit the pages . ** ** Kind regards, Viktor. ** ** ** ** [1] https://github.com/OpenSC/OpenSC/wiki [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN login broken in 0.13.0rc1
Hello, Le 10/12/2012 17:46, Lukas Wunner a écrit : I've issued pull request #111 which enhances pkcs15-gemsafeV1.c by two features: Build of the merged repository for pull request #111 fails on Windows (Vista). You can reach the compilation logs of the failed jenkins job using the link in description of your pull request. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] a few more trivial patches
Le 10/12/2012 17:10, Greg Troxel a écrit : Anthony Foiani anthony.foi...@gmail.com writes: Ludovic, greetings -- On Sun, Dec 9, 2012 at 7:19 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: 2012/12/8 Anthony Foiani anthony.foi...@gmail.com: Greetings -- I have two small patches which you might want to consider integrating. (And given that I can't get git to do what I want, you probably want to just cherry-pick these, as I suspect I've completely destroyed my repo history...) You should rebase your patches above OpenSC/OpenSC master. Ok, but pardon my git ignorance: I thought that one should never rebase a tree that will be published and pulled from? Or only if it's published and someone tries to *base a new tree* off of it? This is somewhat controversial, but from my experience in both open source and large private projects, the key issue is not to rebase branches that other people have made commits on top of, or merged into other branches. I find that it's helpful to rebase branches proposed for merging. The point for me is not so much to have them based off recent master to avoid a merge commit, but to produce the clean series of commits that would have appeared had there been no mistakes. Achieving the goal of not rebasing branches others have derived commits From can be accomplished by not rebasing published branches or having an understanding within the project that branches should not be cross-merged, so that rebasing them is still safe. Even if multitple people commit to a branch, with a little coordination this is not a big deal. I also vote for rebase of the feature branch before merging it to the master branch. If this procedure seems annoying, then use cherry-pick, especially when it's going about the minor changes. If no objections, I will rebase two last commits of the current 'master'. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Building github pull request
Hello, now the github pull requests (PR) to OpenSC/OpenSC are/can-be checked automatically for building on Ubuntu and Vista. At the moment this feature is installed to help the contributors to reveal the compilation errors on the platforms that they do not used to manage (mostly Windows). Some restrictions in permissions to run the build on the PR's merged repository are due to the implementation of jenkins plugin Github pull request builder [1]: - PRs from the github OpenSC organization members are built automatically, these members are 'admins'; - PRs from the users present in the CI internal 'whitelist' are built automatically; - for the PRs from the other contributors jenkins CI adds the PR comment Can one of the admins verify this patch? to attract the attention of 'admins'; - using the codified comments to PR, 'admins' can add user to the 'whitelist' or (re)run the test; Codified messages: - ok to test -- authorization to run the test on merged repository; - add to whitelist -- add user to whitelist; Examples: PR-#97 [2]: - pull request fails the build of merged repository on windows-32; - user 'mtausig' is added by 'admin' to internal CI 'whitelist', so that, the next PRs or updates of existing PRs from 'mtausig' will be built automatically. PR-#102 [3]: - successful built of the merged repository. If you consider that all these restrictions are too complicated, we will install the modified version of the jenkins plugin to unconditionally build all PRs. Kind regards, Viktor. [1] https://wiki.jenkins-ci.org/display/JENKINS/Github+pull+request+builder+plugin [2] https://github.com/OpenSC/OpenSC/pull/97 [3] https://github.com/OpenSC/OpenSC/pull/102https://github.com/OpenSC/OpenSC/pull/97 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.13.0
Hello, On Wed, Dec 5, 2012 at 6:23 PM, Greg Troxel g...@ir.bbn.com wrote: https://github.com/OpenSC/OpenSC/tags https://sourceforge.net/projects/opensc/files/OpenSC/ https://opensc.fr/jenkins/ The source used to be at: http://www.opensc-project.org/files/opensc/ Is that no longer the canonical location? The wiki at https://www.opensc-project.org/opensc still says the latest release is 0.12.2. We have to migrate the OpenSC project to the new hosting -- the existing platform will not be supported soon. For that reason we were looking for the appropriate solution. Current solution can/will be refined in a future. The wiki pages are outdated. Normally they have to be migrated onto the new hosting and then updated. We are conscious that hosting solution and migration procedure are not perfects, but we will try to do the best allowed by the available resources. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC 0.13.0
Hello, The next release is tagged on the github OpenSC/OpenSC project, thanks to all of you for your contributions. Tarball and MSI installers can be found on github, sourceforge or the CI server: https://github.com/OpenSC/OpenSC/tags https://sourceforge.net/projects/opensc/files/OpenSC/ https://opensc.fr/jenkins/ The packages for the other OSs will be added. The list, not complete, of the new features: * New card driver ePass2003. * OpenPGP card: greatly improved card driver and PKCS#15 emulation; implemented write (pkcs15init) mode; greatly enhanced documentation and tools. * ECDSA keys supported in 'read' and 'write' modes by internal PKCS#15 library, PKCS#11 and tools. * Minidriver in 'write' mode. * SM: secure messaging in GlobalPlatform-SP01 and CW14890 specifications; supported by ePass2003, IAS/ECC and AuthentIC cards; ACL and APDU modes to trigger secure messaging session; 'local' version of the external secure messaging module. * PKCS#15: support of 'secret-key' PKCS#15 objects support of 'authentication-object' PKCS#15 objects support of 'algReference' common key PKCS#15 attribute support of 'algReference' common key PKCS#15 attribute support of 'subjectName' common public key PKCS#15 attribute * PKCS#11: removed 'onepin' version of pkcs#11 module configuration options to expose slots for PINs and present on-card applications. support GOSTR3410 generate key mechanism support of EC key type * Support of PACE reader. * Remove libltdl reference. * ECDSA supported by MyEID card. * New card driver for the SmartCard-HSM, a light-weight hardware security module. * New useful commands in 'opensc-explorer' tool: 'find', 'put-data', ... * fixes SIGV issue related to the unsupported public key format * fixes for the number of documentation issues This release was pushed ahead by the number of new features and new card drivers eager for their place in the project, as well as by the necessity to restore the regular release process. You are heartily invited to comment/test/use this release. Also at this time we are migrating the OpenSC project to the new hosting. Currently: - the sources of OpenSC sources and its sub-projects are migrated to github (thanks to Ludovic); - mailing-list on sourceforge is ready to substitute the mailing-list on opensc-project.org (once more thanks to Ludovic); - Peter Stuge have to migrate the OpenSC trac wiki onto one of his platform ; - sourceforge will replace the file server hosted by opensc-project.org (currently the CI service sends the release and 'nightly' packages to both sourceforge and opensc-project); - CI service is currently running for OpenSC/OpenSC github project, but can be extended and include the other OpenSC sub-projects. Currently the github OpenSC/OpenSC contains two branches 'master' and 'staging', rigorously synchronized between each other. I guess that we can eliminate the 'staging' branch and use only the 'master' one. The OpenSC wiki pages are largely outdated; but I think it's reasonable to wait Peter to finish migration of existing trac before starting to update it. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN login broken in 0.13.0rc1
Hello, On Mon, Dec 3, 2012 at 9:06 AM, Lukas Wunner lu...@wunner.de wrote: I've got a GemSafeV1 card here which has 10 key containers. The native Gemalto Windows driver shows that there's a certificate in the third and fourth key container, all others are empty. OpenSC only sees the certificate in the third key container. Using a USB Sniffer I can see that the native Windows driver sends two kinds of select_file commands to the card: 00 a4 08 00 04 16 00 00 04 = This is the normal select_file command that is also sent by OpenSC. It selects the file at address 3f001604. Note that P1 = 08 (select from MF by path) and P2 = 00 (return FCI). 00 a4 08 0c 04 16 00 00 04 = This command is only sent by the native Windows driver, not by OpenSC. Note that P1 = 08 as before, but P2 = 0c. According to ISO 7816 part 4 section 6 table 59, that value is reserved for future use: http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11 According to ISO/IEC 7816-4:2005(E) Table 40 -- P2: 0 0 0 0 1 1 x x — No response data if Le field absent, or proprietary if Le field present In OpenSC the '0C' value for P2 is used when there is no need to return FCI data in 'SELECT' command: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L472 My guess is that the latter select_file command is used to access the fourth key container. I'm puzzled by P2 = 0c, is that a proprietary extension by Gemalto? How should OpenSC be extended to support these additional key containers? Right now apdu.p2 is hardwired to 0 in line 463 of src/libopensc/iso7816.c. What version of OpenSC are you referencing ? I propose you to use the master branch of the OpenSC/OpenSC github project. The P2 value in 'SELECT' card command have nothing to the number of detected key containers by gemsafeV1 card. As far as I see, gemsafeV1 card uses the PKCS#15 emulator. In this case the key containers (as well as certificates, public keys, ...) are hard-coded into the card's driver: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-gemsafeV1.c#L114 https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-gemsafeV1.c#L65 Also, I found out that this card has a somewhat peculiar PIN policy: ASCII, min length 4, max length 8, padded with 0x00. The hardwired values in line 84 of src/libopensc/pkcs15-gemsafeV1.c are: BCD, min length 6, max length 8, padded with 0xFF. The GemSafe-based code in pkcs15-pteid.c uses yet another variation: ASCII, min length 4, max length 8, padded with 0xFF. What is the preferred way to support the PIN policy of this card in OpenSC? One way would be to define a new card type (e.g. SC_CARD_TYPE_GEMSAFEV1_EPO). In OpenSC there is no common management of the PIN policy: format and manner to get/put PIN policy are too different from one card type to another. Specific PIN policy is/may-be implemented by the specific card driver. A more elegant solution would be if we could query the card for its PIN policy. Since the Gemalto Windows driver should work with any GemSafe card, it probably does exactly that. I can see with the USB Sniffer that right before sending the PIN, the Gemalto driver sends the following APDU: 80 ca 9f 7f 2d and gets the following back: 9f 7f 2a 42 50 32 72 12 91 61 81 07 00 91 38 01 03 c4 75 28 32 00 00 91 62 20 03 91 62 20 04 7c 00 01 00 01 01 00 00 00 00 00 00 00 00 90 00 Maybe the PIN policy is encoded in there? The APDU sent to the card is a get_data command with P1 = 9f, P2 = 7f. Lacking any documentation for these cards, I can't tell what the values in the response APDU mean. These data are the 'Card Production Life Cycle (CPLC)' data, there is no PIN Policy data. https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/types.h#L290 The ATR of this card is 3B:7D:96:00:00:80:31:80:65:B0:83:11:48:C8:83:00:90:00 and the product name is Classic TPC IS v2 (new name: IDClassic 300). Firmware version is 1.11. Thanks kind regards, Lukas Kind regards, Viktor. ___ 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] Status of engine-pkcs11.dll in OpenSC-0.13git for Windows
Hello, Le 28/11/2012 21:27, Jean-Michel Pouré - GOOZE a écrit : I have just realized that engine_pkcs11.dll does not seem to be part of OpenSC GIT installer for Windows: http://www.opensc-project.org/downloads/nightly/staging/win32/OpenSC-git20121128110936-win32.msi I could not find any engine_pkcs11.dll in System32 directory. Are there reasons for that? As far as I know, the engine-pkcs11 never was included into OpenSC MSI. Neither it has its own 'make MSI'. I would like to try building packages myself to learn more about Windows build system. Is the information given on http://www.opensc-project.org/opensc/wiki/NightlyBuilds up-to-date? This information need to be updated, but in the part that concerns compiling for/under Windows and the build of OpenSC MSI it should be correct. Kind regards, Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] TokenInfo Algorithm information for CardOS cards
Hello, I'm going to accept pull request 'Use Algorithm information from TokenInfo for computing signatures on CardOS cards' https://github.com/OpenSC/OpenSC/pull/97 I'm not owner of CardOS driver, do not use and do not know the CardOS card. The non-regression tests with the CardOS 4.3B card, initialized in OpenSC is the only thing that I could do. Tests concerns the signature in raw, pkcs1 and pkcs1sha1 modes. Please tell me if there are other tests that should be done before acceptance of this pull request. If there are no objections from the owners of CardOS driver, from the other users, I will integrate this request into the 'master' and 'staging' of the github OpenSC/OpenSC project (and in the future 0.13.0 version) Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Le 17/11/2012 17:40, Ludovic Rousseau a écrit : 2012/11/17 Ludovic Rousseau ludovic.rouss...@gmail.com: 2012/11/17 Andreas Jellinghaus andr...@ionisiert.de SF is sourceforge.net I guess? it still has the opensc project (that was used many, many years ago). Owners are juha and olaf - if you can reach them, you can re-activate it. I just sent a email to Olaf and Juha. I hope they still read the emails sent to their SF.net contact address. That was fast. Juha added me as admin. It would be best if other active people are also added as admin. Viktor, do you have a SourceForge account? Have created one: 'tarvik' BYe ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Hello Peter, Le 16/11/2012 21:42, Peter Stuge a écrit : Viktor Tarasov wrote: I propose to start migration the week 19-25.11 . I'll have more free time: - sources: all sources will migrate to github; - CI: CI server is currently hosted by 'opensc.fr' ; - download: on the same platform can be hosted the file server; - TRAC (wiki?): it seems that Peter Stuge proposed to do something with Trac. Peter, if you are here, can you take this part, or at least explain how it could be done, please? If no suggestions, Trac can also be hosted by 'opensc.fr' . Educating someone on how to do a migration is as I'm sure you know a whole lot more work than performing the migration. If there's desire I'm of course still happy to host a Trac, but please keep in mind that Trac is a lot less useful when source code is somewhere else. It seems that decision to move all sources to github is accepted. Do you mean that with sources on github it would be more useful to use the bug system and wiki on github, as Ludovic proposed, and not the Trac installed on someone's platform ? (I need some time to discover Trac's internals and how it interacts with SCM .) As far as I understood, in any case we have to start from sqlite dump of the current OpenSC Trac. Andreas, can you do it, please ? Please add my SSH key on the server and let me know, if you want me to look into moving Trac out. - mailling list: the same, if no other suggestions, I'm ready to install/migrate it to 'opensc.fr' platform. Would be nice if one of the experts explain what is the actions to follow for such migration. I don't like mailman too much. I've set it up, but I don't use it. I'd suggest using SF for the list(s?). Could you expand 'SF' or give the link, please? //Peter Kind regards, Viktor. ___ 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] openpgp.profile missing from win32 nightlies
Le 09/11/2012 22:19, Leonardo Brondani Schenkel a écrit : The latest nightlies from https://www.opensc-project.org/downloads/nightly/staging/win32/ do not come with openpgp.profile. Is it deliberate or a bug in the installer? Take last nightly from https://www.opensc-project.org/downloads/projects/opensc/ ___ 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] PIN login broken in 0.13.0rc1
Le 06/11/2012 15:54, Viktor Tarasov a écrit : Hello, On Tue, Nov 6, 2012 at 2:45 PM, Lukas Wunner lu...@wunner.de mailto:lu...@wunner.de wrote: when logging in to a GemSafeV1 card with 0.13.0rc1, opensc first retrieves the number of tries_left using C_GetTokenInfo() and then calls C_Login(). Both functions invoke sc_pin_cmd() to communicate with the card. It seems that somehow in-between the two invocations of sc_pin_cmd(), the sc_pkcs15_auth_info structure holding the PIN information is destroyed: $ OPENSC_DEBUG=9 pkcs11-tool --module opensc-pkcs11.so --test --login -p XXX [...] pkcs11-session.c:57:C_OpenSession: C_OpenSession(0x1) pkcs11-session.c:83:C_OpenSession: C_OpenSession handle: 0x6100f0 pkcs11-session.c:86:C_OpenSession: C_OpenSession() = CKR_OK framework-pkcs15.c:426:C_GetTokenInfo: C_GetTokenInfo(1) sec.c:157:sc_pin_cmd: called sec.c:204:sc_pin_cmd: returning with: -1408 (Not supported) -- data structure okay pkcs11-session.c:259:C_Login: C_Login(0x6100f0, 1) pkcs15-pin.c:293:sc_pkcs15_verify_pin: called pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(0x;len:8) pkcs15-pin.c:295:sc_pkcs15_verify_pin: Auth(type:0;method:0) pkcs15-pin.c:299:sc_pkcs15_verify_pin: PIN value validated card.c:315:sc_lock: called reader-pcsc.c:517:pcsc_lock: called card.c:610:sc_select_file: called; type=2, path=3f001604 card-gemsafeV1.c:184:gemsafe_select_file: called [...] card.c:636:sc_select_file: returning with: 0 (Success) sec.c:157:sc_pin_cmd: called sec.c:204:sc_pin_cmd: returning with: -1300 (Invalid arguments) -- data structure destroyed pkcs15-pin.c:367:sc_pkcs15_verify_pin: PIN cmd result -1300 [...] error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7) The final error message is caused by method:0. That value is assigned to data.pin_type in pkcs15-pin.c:sc_pkcs15_verify_pin(). A value of 0 means SC_AC_NONE. The correct value would be 1 which means SC_AC_CHV. There's a check in card-gemsafeV1.c:gemsafe_build_pin_apdu() for pin_type == SC_AC_CHV which returns SC_ERROR_INVALID_ARGUMENTS on failure. That's what causes the error message. If I hardwire data.pin_type = SC_AC_CHV in sc_pkcs15_verify_pin(), it still doesn't work: The card answers with CKR_PIN_INCORRECT even though the PIN is correct. Somehow the data structure holding the authentication info gets garbled. The curious thing is that upon the first invocation of sc_pin_cmd() (by C_GetTokenInfo()), the data structure seems to still be okay: The check for pin_type == SC_AC_CHV in gemsafe_build_pin_apdu() succeeds and the function just returns SC_ERROR_NOT_SUPPORTED because SC_PIN_CMD_GET_INFO is not implemented for GemSafeV1 cards. I'm at a loss here, if somebody has an idea what's going awry I'd be grateful to hear it. Try to apply the following: diff --git a/src/libopensc/pkcs15-gemsafeV1.c b/src/libopensc/pkcs15-gemsafeV1.c index c05578e..3e04d40 100644 --- a/src/libopensc/pkcs15-gemsafeV1.c +++ b/src/libopensc/pkcs15-gemsafeV1.c @@ -436,6 +436,7 @@ sc_pkcs15emu_add_pin(sc_pkcs15_card_t *p15card, info = calloc(1, sizeof(*info)); info-auth_type = SC_PKCS15_PIN_AUTH_TYPE_PIN; + info-auth_method = SC_AC_CHV; info-auth_id = *id; info-attrs.pin.min_length= min_length; info-attrs.pin.max_length= max_length; The patch has been applied to the Github OpenSC/OpenSC. Thanks, Lukas Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto: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] state of the project?
Hello, Le 11/11/2012 16:28, Andreas Jellinghaus a écrit : I wonder what we can or should do to improve the state of the project. It seems to me: * the last release was 0.12.2, released on 17.07.2011, not enough progress to create a release since. * that is a maintenance release, the last major version was opensc 0.12.0 in 22-Dec-2010. We are preparing 0.13.0 release on the base of the master/staging branch of Github OpenSC/OpenSC. Now it's at rc1. The candidates have been relatively well tested with some cards. The nightly builds and release candidates are on the OpenSC file server and in CI service. My intention is to publish the next major release during the last two weeks of November. There are still few regression issues with MacOS and old cards. I guess it's a good occasion to migrate the project. What is the procedure to follow when publishing a new major release ? * discussions about new server / some migration / some improvement etc. are similar old, no significant results yet While there have been some proposals, e.g. in the thread about the future of the server, there hasn't been any real discussion, no back and forth about the merrits of the different proposals, and no convergence on one option or decission by anyone. It seems to me the state of the project is defunct: while there are requests, proposals, options and offerings, we are not getting towards a decission or action it seems, as noone decides anything or gets people to agree or to do things. I haven't touched a smart card in over a year, so don't expect me to do anything - that wouldn't work. But if anyone is still concerned about the project, I think it is time you take action. Don't look for anyone else, it is you or noone. But many people offered help, if you want to drive the project forward. I propose to start migration the week 19-25.11 . I'll have more free time: - sources: all sources will migrate to github; - CI: CI server is currently hosted by 'opensc.fr' ; - download: on the same platform can be hosted the file server; - TRAC (wiki?): it seems that Peter Stuge proposed to do something with Trac. Peter, if you are here, can you take this part, or at least explain how it could be done, please? If no suggestions, Trac can also be hosted by 'opensc.fr' . - mailling list: the same, if no other suggestions, I'm ready to install/migrate it to 'opensc.fr' platform. Would be nice if one of the experts explain what is the actions to follow for such migration. Regards, Andreas Kind wishes, Viktor. ___ 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] PIN login broken in 0.13.0rc1
Hello, On Tue, Nov 6, 2012 at 2:45 PM, Lukas Wunner lu...@wunner.de wrote: when logging in to a GemSafeV1 card with 0.13.0rc1, opensc first retrieves the number of tries_left using C_GetTokenInfo() and then calls C_Login(). Both functions invoke sc_pin_cmd() to communicate with the card. It seems that somehow in-between the two invocations of sc_pin_cmd(), the sc_pkcs15_auth_info structure holding the PIN information is destroyed: $ OPENSC_DEBUG=9 pkcs11-tool --module opensc-pkcs11.so --test --login -p XXX [...] pkcs11-session.c:57:C_OpenSession: C_OpenSession(0x1) pkcs11-session.c:83:C_OpenSession: C_OpenSession handle: 0x6100f0 pkcs11-session.c:86:C_OpenSession: C_OpenSession() = CKR_OK framework-pkcs15.c:426:C_GetTokenInfo: C_GetTokenInfo(1) sec.c:157:sc_pin_cmd: called sec.c:204:sc_pin_cmd: returning with: -1408 (Not supported) -- data structure okay pkcs11-session.c:259:C_Login: C_Login(0x6100f0, 1) pkcs15-pin.c:293:sc_pkcs15_verify_pin: called pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(0x;len:8) pkcs15-pin.c:295:sc_pkcs15_verify_pin: Auth(type:0;method:0) pkcs15-pin.c:299:sc_pkcs15_verify_pin: PIN value validated card.c:315:sc_lock: called reader-pcsc.c:517:pcsc_lock: called card.c:610:sc_select_file: called; type=2, path=3f001604 card-gemsafeV1.c:184:gemsafe_select_file: called [...] card.c:636:sc_select_file: returning with: 0 (Success) sec.c:157:sc_pin_cmd: called sec.c:204:sc_pin_cmd: returning with: -1300 (Invalid arguments) -- data structure destroyed pkcs15-pin.c:367:sc_pkcs15_verify_pin: PIN cmd result -1300 [...] error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7) The final error message is caused by method:0. That value is assigned to data.pin_type in pkcs15-pin.c:sc_pkcs15_verify_pin(). A value of 0 means SC_AC_NONE. The correct value would be 1 which means SC_AC_CHV. There's a check in card-gemsafeV1.c:gemsafe_build_pin_apdu() for pin_type == SC_AC_CHV which returns SC_ERROR_INVALID_ARGUMENTS on failure. That's what causes the error message. If I hardwire data.pin_type = SC_AC_CHV in sc_pkcs15_verify_pin(), it still doesn't work: The card answers with CKR_PIN_INCORRECT even though the PIN is correct. Somehow the data structure holding the authentication info gets garbled. The curious thing is that upon the first invocation of sc_pin_cmd() (by C_GetTokenInfo()), the data structure seems to still be okay: The check for pin_type == SC_AC_CHV in gemsafe_build_pin_apdu() succeeds and the function just returns SC_ERROR_NOT_SUPPORTED because SC_PIN_CMD_GET_INFO is not implemented for GemSafeV1 cards. I'm at a loss here, if somebody has an idea what's going awry I'd be grateful to hear it. Try to apply the following: diff --git a/src/libopensc/pkcs15-gemsafeV1.c b/src/libopensc/pkcs15-gemsafeV1.c index c05578e..3e04d40 100644 --- a/src/libopensc/pkcs15-gemsafeV1.c +++ b/src/libopensc/pkcs15-gemsafeV1.c @@ -436,6 +436,7 @@ sc_pkcs15emu_add_pin(sc_pkcs15_card_t *p15card, info = calloc(1, sizeof(*info)); info-auth_type = SC_PKCS15_PIN_AUTH_TYPE_PIN; + info-auth_method = SC_AC_CHV; info-auth_id = *id; info-attrs.pin.min_length= min_length; info-attrs.pin.max_length= max_length; Thanks, Lukas Kind regards, Viktor. ___ 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] SC_MAX_CARD_DRIVERS and OpenSC 0.13
Hello, Le 02/11/2012 08:53, helpcrypto helpcrypto a écrit : Updating to any bigger magic number will do the trick, but maybe its better to consider removing SC_MAX_CARD_DRIVERS (hence having no limits), this, of course, depends on the usage. Can you say for what/where it is used? The SC_MAX_CARD_DRIVERS is increased from 32 to 48. This solution is not the best, but rapid and do not need a lot of tests and review. If someone have better proposals -- we will readily consider it. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN not sent to card before signing
Hello,
Le 19/10/2012 15:02, Mathias Tausig a écrit :
I am writing a PKCS#15 application for a (cardos v4.4) smartcard which
references an external signature application. The RSA key and the PIN are
stored in that external application, the PIN needs to be verified upon every
key usage.
To accomplish this, I have set the userConsent value in the
PrivateKeyDictionaryFile to 1.
Here is the content of the PrkDF (output from openssl):
0:d=0 hl=2 l= 67 cons: SEQUENCE
2:d=1 hl=2 l= 30 cons: SEQUENCE
4:d=2 hl=2 l= 18 prim: UTF8STRING:Signaturschlüssel
24:d=2 hl=2 l= 2 prim: BIT STRING
- 07 80 ..
28:d=2 hl=2 l= 1 prim: OCTET STRING
- 11.
31:d=2 hl=2 l= 1 prim: INTEGER :01
34:d=1 hl=2 l= 14 cons: SEQUENCE
36:d=2 hl=2 l= 1 prim: OCTET STRING :B
39:d=2 hl=2 l= 2 prim: BIT STRING
- 05.
0002 - SPACES/NULS
43:d=2 hl=2 l= 2 prim: BIT STRING
- 03 b8 ..
47:d=2 hl=2 l= 1 prim: INTEGER :02
50:d=1 hl=2 l= 17 cons: cont [ 1 ]
52:d=2 hl=2 l= 15 cons: SEQUENCE
54:d=3 hl=2 l= 6 cons:SEQUENCE
56:d=4 hl=2 l= 4 prim: OCTET STRING
- 3f 00 1f ff ?...
62:d=3 hl=2 l= 2 prim:INTEGER :0400
66:d=3 hl=2 l= 1 prim:INTEGER :14
69:d=0 hl=2 l= 0 prim: EOC
The problem is, that when I try to use the card with pkcs11-tool (either with
the --test option or with a --sign command), it doesn't verify the pin before
signing. Here is the relevant part of the APDU output:
Oct 19 14:40:20 off17 pcscd[4590]: 6755 APDU: 00 A4 08 00 02 1F FF
Oct 19 14:40:20 off17 pcscd[4590]: 00024106 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 1410 APDU: 00 20 00 81 06 31 32 33 34
35
36
Oct 19 14:40:20 off17 pcscd[4590]: 00048516 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 5039 APDU: 00 A4 08 00 02 50 15
Oct 19 14:40:20 off17 pcscd[4590]: 00024963 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 1737 APDU: 00 A4 08 00 02 1F FF
Oct 19 14:40:20 off17 pcscd[4590]: 00028271 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 0164 APDU: 00 22 01 B6 03 83 01 02
Oct 19 14:40:20 off17 pcscd[4590]: 00019795 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 0185 APDU: 00 2A 9E 9A 80 00 01 FF FF
FF
FF FF FF FF FF FF F
F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF F
F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF F
F FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02
1A 05 00 04 14 04 75 9
5 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80
Oct 19 14:40:20 off17 pcscd[4590]: 00039821 SW: 69 82
In the first two commands the signature DF (1fff) is entered and the PIN
verified, thant it switches back to the PKCS#15 DF without doing anything
there
(APDU#3). Than the signature DF is reentered and a signing command is tried
without prior authentication.
Is this a bug, is the userConsent field not heeded, or am I missing something?
Please confirm (or not) -- in your test you are not using the current OpenSC
pkcs#11 module
but only using the pkcs11-tool.
According to your logs, the application DF is selected between the PIN
verifying and 'sign' operation.
That's the behavior of the previous versions of OpenSC.
Could you tell us more about the application that generates the APDUs?
If it based on the older OpenSC version, try to change the 'lock_login'
configuration option.
cheers
Mathias
Kind regards,
Viktor.
___
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] github OpenSC organisation privileges
Hello, Le 07/10/2012 15:04, Ludovic Rousseau a écrit : I wanted to create a fork of martinpaljak / OpenSC.tokend under the OpenSC organisation but I can't. I do not have enough permissions. It would also be a good idea to more opensc-project.org subprojects uder the OpenSC github organisation. Martin, I guess you are the admin of the github OpenSC organisation. Can you update my privileges so I can create repositories under OpenSC? I guess Viktor is in the same situation. Yes, for example I would like to add the web-hook to trigger jenkins job on 'opensc.fr'. This can be done only with admin rights on OpenSC/OpenSC.git. Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Hello, New release candidate is tagged as '0.13.0rc1' -- commit 6b7d8af0 of github OpenSC/OpenSC.git. The tarball, MSI and SuSE RPM can be downloaded from http://www.opensc-project.org/downloads/projects/opensc/releases/ or directly from CI service https://opensc.fr/jenkins/ Here listed the changes since '0.13.0pre1' (only 'essential'): 40ff0e4e pkcs11: Fixed SIGV when deleting public key objects via PKCS#11 c91f0e84 entersafe: Disable RSA:512bits that modified in entersafe_generate_key and entersafe_store_key function 72786abe sc-hsm: Added write support for RSA and ECC keys, certificates and data objects a9393aa9 framework-pkcs15: Fixed a SIGV when key generation returned ERROR_NOT_SUPPORTED 1619a423 ecc: Adding more curves db3f5f5f framework-pkcs15: Fixed issued with uninitialized variable keysize f508b212 pkcs15: Add support to encode EC private key description 02fe6d47 pkcs11-tool: Fixed issue with ID increment failing on constant data 249b769a pkcs11: unlink 'pubkey' FW object when deleting related certificate ea40e7fe Use AM_CPPFLAGS instead of INCLUDES 3656b478 Use AX_PTHREAD instead of ACX_PTHREAD d525ca97 libopensc: OID with only zeros in array do not valid Thanks for your participation. There are still few issues inherited from pre1: - building MAC OS X packages (waiting for someone who know/can/will to bring more details on this problem); - ePass2003 signing problem -- seems to be related with pkcs11 engine ... - ... and as a consequence -- need to be tested with engine; - still to be tested smartcard logon. Kind regards, Viktor. Le 26/09/2012 11:12, Viktor Tarasov a écrit : Hello Andreas. On Tue, Sep 25, 2012 at 8:07 PM, Andreas Schwier andreas.schw...@cardcontact.de mailto:andreas.schw...@cardcontact.de wrote: we are testing on Windows XP SP3, Debian Lenny and a current Ubuntu version. Our focus is on PKCS#11 and integration with Firefox, Thunderbird and XCA. We already tested minidriver with IE and Outlook, but we do short regression tests with each new build. Ok, thanks. We've set up automated tests using our Smart Card Shell, which interfaces with PKCS#11 using opensc-java. This way we test key generation of all kinds (RSA/EC), certificates issuance and storing as well as data element reading/writing. We also have a quick regression test using a script with various pkcs11-tool commands. We've also done tests using the IAIK PKCS#11 wrapper that worked well. Your automated tests are triggered-by/pulled-from your-branch/opensc-opensc github ? Do you see any interest in connecting your automated tests to the common OpenSC CI service ? https://opensc.fr/jenkins/ So far we're quite confident that the current code base is stable. We have three things left on our list, but they are not pressing: 1. Adding support to have domain parameter at the PKCS#11 interface for EC public keys after on card generation (i.e. serialize/ deserialize public keys as spki) 2. Adding support for explicit domain parameter in EC_PARAMS 3. Fast-track C_Initialize and C_SetPIN into the card-driver (The SmartCard-HSM uses a PKCS#11 like token initialization) Given the fact, that these changes touch core code, we would schedule this topics for the .14 release. Andreas Am 25.09.2012 17:04, schrieb Viktor Tarasov: Hi Andreas, On Tue, Sep 25, 2012 at 9:14 AM, Andreas Schwier andreas.schw...@cardcontact.de mailto:andreas.schw...@cardcontact.de mailto:andreas.schw...@cardcontact.de mailto:andreas.schw...@cardcontact.de wrote: we've completed the development of write support for the SmartCard-HSM and are in the middle of testing and bug-fixing. Fine, what part of the common OpenSC libraries are involved into your tests (pkcs11, minidriver, pkcs15, ...) ? What are the OSs? The code is based on the latest version in OpenSC/staging and changes mostly apply to our own code. Is there a chance to get write support into the upcomin release ? If yes, I would prepare a pull request against the CardContact/staging branch. Ok, you can make pull request to 'staging' or 'master' of OpenSC/OpenSC -- two branches are kept syncronized. Andreas Kind wishes, Viktor. Am 17.09.2012 22:00, schrieb Viktor Tarasov: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare
Re: [opensc-devel] Testing
Hello Andreas, On Tue, Oct 2, 2012 at 7:53 PM, Andreas Schwier (ML) andreas.schwier...@cardcontact.de wrote: we've tested the nightly build (OpenSC-git20121002092635-win32.msi) that includes write support for the SmartCard-HSM and found no issues. We've tested with our own PKCS#11 test suite, integration with Firefox 15.0.1 and Thunderbird 15.0.1 on Windows XP SP3. Will there be a new release candidate ? Ok, I will create the tag for release candidate. Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ 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] new server hoster and adminstrator for opensc-project.org required
Hello Andreas, On Tue, Oct 2, 2012 at 11:13 PM, Andreas Jellinghaus andr...@ionisiert.dewrote: So, have you agreed on something? I read different opinions, offers, comments, but nothing that points out coming to some consent. What is your preference? Since I'm not really active, I don't want to decide this. I checked googlegroups and code.google.com, worst case I can figure out how to copy/move things there. I will look into code.google.com, but beside this, one of the solution could be to : - move the sources of the projects to github; - use my CI service for nightly builds; - install on the same platform file server for release tarbals, RPMs, MSIs, etc; - move onto the same platform wiki, trac and mailing lists. If there will not be other suggestions, and if the study of the googlegroups or similar will not bring other solution, we could start the migration. Regards, Andreas Kind regards, Viktor. ___ 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] Testing
I do not have MAC and cannot do the tests myself. If it's a regression, and if you have an access to MAC platform, you could try to determine the commit that introduced this problem. I do not see other way to resolve it . I propose to tag the 'rc1' and wait during certain time for more details or for somebody who is capable to resolve it . Kind regards, Viktor. On Wed, Oct 3, 2012 at 10:14 AM, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: Le mercredi 03 octobre 2012 à 09:17 +0200, Viktor Tarasov a écrit : Ok, I will create the tag for release candidate. Please have a look at this Mac OS X package issue. I don't understand why the package build fails at final stage. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ 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] SIGV when deleting certificate but not related public key
On Thu, Sep 27, 2012 at 11:30 AM, Peter Stuge pe...@stuge.se wrote:
Andreas Schwier wrote:
I will first need to write a small test in C to reproduce the problem.
Right now we test from Java, which makes debugging a real nightmare.
Maybe you can reproduce it using some of the existing command line
tools?
It can be reproduced, using command
# pkcs11-tool --module ./build/lib/opensc-pkcs11.so --slot-index 0 -l
--pin 1234 --delete-object --type cert --id object-id
and patched pkcs11-tool:
diff --git a/src/tools/pkcs11-tool.c b/src/tools/pkcs11-tool.c
index f23948b..30074d8 100644
--- a/src/tools/pkcs11-tool.c
+++ b/src/tools/pkcs11-tool.c
@@ -824,6 +824,9 @@ int main(int argc, char * argv[])
util_fatal(You should specify at least one of the
object ID, object label,
application label or application ID\n);
delete_object(session);
+
+ printf(Now list public keys ...\n);
+ list_objects(session, CKO_PUBLIC_KEY);
}
if (do_set_id) {
I will look for the solution.
//Peter
___
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] SIGV when deleting certificate but not related public key
On Thu, Sep 27, 2012 at 1:13 PM, Andreas Schwier
andreas.schw...@cardcontact.de wrote:
Just tried the same.
There is also a SIGV if you try to delete the public key alone.
Apparently the public key object in the framework has no related object
in the pkcs15 layer.
Public key PKCS#11 object is created from certificate if there is no
corresponding PKCS#15 public key object.
https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/framework-pkcs15.c#L544
As we see, the deletion of the 'parent' cert object has not been
sufficiently tested.
Andreas
Am 27.09.2012 13:04, schrieb Viktor Tarasov:
On Thu, Sep 27, 2012 at 11:30 AM, Peter Stuge pe...@stuge.se
mailto:pe...@stuge.se wrote:
Andreas Schwier wrote:
I will first need to write a small test in C to reproduce the
problem.
Right now we test from Java, which makes debugging a real
nightmare.
Maybe you can reproduce it using some of the existing command line
tools?
It can be reproduced, using command
# pkcs11-tool --module ./build/lib/opensc-pkcs11.so --slot-index 0 -l
--pin 1234 --delete-object --type cert --id object-id
and patched pkcs11-tool:
diff --git a/src/tools/pkcs11-tool.c b/src/tools/pkcs11-tool.c
index f23948b..30074d8 100644
--- a/src/tools/pkcs11-tool.c
+++ b/src/tools/pkcs11-tool.c
@@ -824,6 +824,9 @@ int main(int argc, char * argv[])
util_fatal(You should specify at least one
of the
object ID, object label,
application label or application ID\n);
delete_object(session);
+
+ printf(Now list public keys ...\n);
+ list_objects(session, CKO_PUBLIC_KEY);
}
if (do_set_id) {
I will look for the solution.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
mailto: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
--
-CardContact Software System Consulting
|.## ##.| Andreas Schwier
|# #| Schülerweg 38
|# #| 32429 Minden, Germany
|'## ##'| Phone +49 571 56149
-http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org
___
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] new release?
Hello Andreas. On Tue, Sep 25, 2012 at 8:07 PM, Andreas Schwier andreas.schw...@cardcontact.de wrote: we are testing on Windows XP SP3, Debian Lenny and a current Ubuntu version. Our focus is on PKCS#11 and integration with Firefox, Thunderbird and XCA. We already tested minidriver with IE and Outlook, but we do short regression tests with each new build. Ok, thanks. We've set up automated tests using our Smart Card Shell, which interfaces with PKCS#11 using opensc-java. This way we test key generation of all kinds (RSA/EC), certificates issuance and storing as well as data element reading/writing. We also have a quick regression test using a script with various pkcs11-tool commands. We've also done tests using the IAIK PKCS#11 wrapper that worked well. Your automated tests are triggered-by/pulled-from your-branch/opensc-opensc github ? Do you see any interest in connecting your automated tests to the common OpenSC CI service ? https://opensc.fr/jenkins/ So far we're quite confident that the current code base is stable. We have three things left on our list, but they are not pressing: 1. Adding support to have domain parameter at the PKCS#11 interface for EC public keys after on card generation (i.e. serialize/ deserialize public keys as spki) 2. Adding support for explicit domain parameter in EC_PARAMS 3. Fast-track C_Initialize and C_SetPIN into the card-driver (The SmartCard-HSM uses a PKCS#11 like token initialization) Given the fact, that these changes touch core code, we would schedule this topics for the .14 release. Andreas Am 25.09.2012 17:04, schrieb Viktor Tarasov: Hi Andreas, On Tue, Sep 25, 2012 at 9:14 AM, Andreas Schwier andreas.schw...@cardcontact.de mailto:andreas.schw...@cardcontact.de wrote: we've completed the development of write support for the SmartCard-HSM and are in the middle of testing and bug-fixing. Fine, what part of the common OpenSC libraries are involved into your tests (pkcs11, minidriver, pkcs15, ...) ? What are the OSs? The code is based on the latest version in OpenSC/staging and changes mostly apply to our own code. Is there a chance to get write support into the upcomin release ? If yes, I would prepare a pull request against the CardContact/staging branch. Ok, you can make pull request to 'staging' or 'master' of OpenSC/OpenSC -- two branches are kept syncronized. Andreas Kind wishes, Viktor. Am 17.09.2012 22:00, schrieb Viktor Tarasov: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org http://opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be connected. It would be nice if you could look/test the tarball or packages of the release 0.13.0pre1. Your remarks, proposals, contributions are heartily welcome. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto:opensc-devel@lists.opensc-project.org http
Re: [opensc-devel] Strange issue in framework-pkcs15.c / pkcs15_gen_keypair
Hi, On Tue, Sep 25, 2012 at 4:39 PM, Andreas Schwier andreas.schw...@cardcontact.de wrote: Hi Douglas, the same problem exists for RSA keys. If you specify an invalid key size, the code tries to generate invalid objects. Our fix ist at https://github.com/CardContact/OpenSC/commit/a9682fd704dca5abc028b32e5ec577aa1c12ee78 Thanks for patch and testing. It was a bug. It appeared in 9a63e03e when support of the soft-generated keys was removed from pkcs15-init and pkcs11. Andreas Kind regards, Viktor. Am 25.09.2012 16:31, schrieb Douglas E. Engert: On 9/25/2012 5:01 AM, Andreas Schwier (ML) wrote: Dear all, we've come a across a strange issue in OpenSC. When we try to generate a key pair with parameters not supported by the card, then the framework code still tries to allocate private/public key objects rather than returning an error code. The questionable code is in line 2675 of framework-pkcs15.c / pkcs15_gen_keypair. Is that an intended behaviour or a plain bug ? Same problem as before. No one has had a PKCS#15 card that supports ECC. The original ECC code added to OpenSC was for client use only, and used the PIV card. For testing the piv-tool could tell the card to generate a key pair, but that was not via and PKCS standards. Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ 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] new release?
Hi Andreas, On Tue, Sep 25, 2012 at 9:14 AM, Andreas Schwier andreas.schw...@cardcontact.de wrote: we've completed the development of write support for the SmartCard-HSM and are in the middle of testing and bug-fixing. Fine, what part of the common OpenSC libraries are involved into your tests (pkcs11, minidriver, pkcs15, ...) ? What are the OSs? The code is based on the latest version in OpenSC/staging and changes mostly apply to our own code. Is there a chance to get write support into the upcomin release ? If yes, I would prepare a pull request against the CardContact/staging branch. Ok, you can make pull request to 'staging' or 'master' of OpenSC/OpenSC -- two branches are kept syncronized. Andreas Kind wishes, Viktor. Am 17.09.2012 22:00, schrieb Viktor Tarasov: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be connected. It would be nice if you could look/test the tarball or packages of the release 0.13.0pre1. Your remarks, proposals, contributions are heartily welcome. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ 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] new release?
On Wed, Sep 19, 2012 at 11:54 PM, Douglas E. Engert deeng...@anl.govwrote: I have been testing 0.13.0-pre1 from tarball listed below. Builds on Solaris. works with MIT Kerberos PKINIT and pam_krb5 to login to AD as the KDC. Can sign Email using thunderbird 13.0.1. The pkcs11-tool -derive using ECDH works using a PIV test card from NIST and a card I created. (i.e. using the key frome a card and the cert from the other card, will produce the same secret key.) Ok, thanks for the testing. In 0.13.0-pre1 there is the bug that concerns the using of non-initialized OID data. My non-regression tests were done with the current (*d525ca97e3*) 'master' version: For the OpenSC installed on Linux from tarball the following tests of the where done using the pkcs15 and pkcs11 tools, with the cards 'CardOS v4.3B', 'SetCOS 4.4.1 B', 'Athena', 'Aventra' and 'Feitian': - erase card (pkcs15-init -E); - initialize (ex. pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin 99 --puk 88); - generate RSA 1024/2048 (depending on card); - import PKCS#12 with user and CA certificates; - get public key from imported or generated key; - sign data using pkcs15-crypt and pkcs11-tool and verify it with openssl; - decrypt the data encypted by openssl; Using Firefox 12.0 and Thunderbird 15.0.1, on Vista, with IAS/ECC card and OpenSC installed from MSI: - generate key and sign certificate request; - import certificate; - authenticate to access protected web page. - import PKCS#12; - sign mail; - decrypt mail. As for me, still to test are minidriver (IE and outlook), smartcard logon (windows) and SM (for the cards that support it). Do you have other suggestions for the non-regression tests? Kind regards, Viktor. On 9/17/2012 3:00 PM, Viktor Tarasov wrote: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be connected. It would be nice if you could look/test the tarball or packages of the release 0.13.0pre1. Your remarks, proposals, contributions are heartily welcome. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ 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] new release?
Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be connected. It would be nice if you could look/test the tarball or packages of the release 0.13.0pre1. Your remarks, proposals, contributions are heartily welcome. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required
Hello, On Thu, Sep 13, 2012 at 12:00 AM, Martin Paljak mar...@martinpaljak.netwrote: Hello, On Wed, Sep 12, 2012 at 11:03 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: Hi, opensc-project.org needs a new home: someone with a (real or virtual) server and the interest in setting it up from scratch and keeping it running and maintaining that server, installation and service for the project. someone who is able to win the trust of the community as new server administrator. The current installation is terribly old. It is based on ubuntu hardy and I think that is nearing the end of its supported livetime or even is unsupported now, thus it is urgently required to rebuild the server. Over the years we had several approaches and various people offered to take over running the server, but so far none of those worked out in the end, noone followed up after the initial discussion. To give this new efford more motivation here is some presure: running a server without maintenance and security updates is not a good idea. Thus I will shut down the current installation at the last end of this year. Any motivated linux administrator can setup a simple server with apache and a few copies of trac, plus postfix and a few mailing lists in a few hours or a day, with maybe a bit more time for fine tuning and migration of the content. This shouldn't be a big deal, thus there should be enough time to find someone interested in doing so and migrating opensc and related projects of the outdated installation. I've had a barebones machine sitting in idle (except for being a ssh gateway for irc...) for almost a year, but for (past) reasons not worth mentioning, I've failed to focus sufficiently on non-real-life matters like OpenSC for a while. This might be a good chance to a) scope the services required for opensc-project.org and b) implement it on a clean machine with some systematic sysadmin approach. But for sustainable results, the scope should be seriously minimal and limited... I have a will to participate but not much of sysadmin experience. So, in the absence of other solution, with some assistance I could do this work. Currently I have an access to platform where are only running jenkins master behind apache. This platform is largely under-used and can host additional services. Martin Kind regards, Viktor. ___ 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] new release?
Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. For the future (after this release), I think (and it was already suggested here) that we don't really need two branches in github. We could use the unique 'master' branch, tag it as needed by release process, and to manage all proposals as pull requests to 'master'. For a while there is no packages (tarbals, MSIs, ...) labeled by tag name, only the packages automatically built on 'staging' branch and labeled by git version. I will create the release dedicated jenkins jobs and will put thus prepared packages onto the 'usual' places. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch for pkcs15init/pkcs15-lib
Hello, Le 31/08/2012 16:59, Andreas Schwier (ML) a écrit : while we are working on write support for the SmartCard-HSM we've come across some issues in pkcs15-lib. The issues are mostly related to the isolation between the pkcs15 framework and the emulation layer. We've authored a patch for the issues. Because we can not oversee the impact of our patch for other cards, we would like to ask card driver writers for a review. The patch can be found at [1]. Thanks for patch, slightly modified version applied in https://github.com/OpenSC/OpenSC/commit/ee94020919d41ee35c49bf290fe59a12ed453dfe . The change of the patch takes care of the 'delete_object' card handlers that do not support all object types -- the common framework resume the control if handler returns 'NOT-SUPPORTED'. Thanks, Andreas [1] https://github.com/CardContact/OpenSC/commit/b3b9bde068c6ebd96469b71235a76ce4c719a490 Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Bugs and releases
Hello Douglas. Le 16/08/2012 20:01, Douglas E. Engert a écrit : Viktor, Thanks for going through all OpenSC bug reports the last few days. Its been a long time since that has been done. Do you have a time estimate when you will be done, and when we can have a 0.13.0 release candidate? Vaguely it could be the weekend -- one more week to look over the current tickets and for the tests. I have no experience in the release preparation and do not clearly imagine the criterion that can be used to declare the release candidate ready. Would be nice to hear your point of view on this and other release related questions. Thanks. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Hello, Le 22/07/2012 17:44, Viktor Tarasov a écrit : I would like to start preparation of the new release based on the 'staging' branch of GitHub OpenSC . Your suggestions proposals are heartily welcome. As far as I see all 'essential' proposals, that have be committed into the 'staging' branch of OpenSC git repository hosted in opensc-project.org (git://www.opensc-project.org/OpenSC.git), are present in github OpenSC. Unfortunately there is no access to the code review service (gerrit) of opensc-project.org and it's not currently possible to pick-up the 'interesting' requests. So, if anybody interested to see these proposals in the next release, please, do pull request to 'staging' branch of GitHub OpenSC (git://github.com/OpenSC/OpenSC.git) . If anyone has more or less significant proposals, especially the ones that touch the common framework, please, create the pull requests for github OpenSC.git/staging until the next weekend . Don't worry if you will not arrive until this term -- I hope to make automatic the essential part of release process and so, to make releases more frequents. The next weekend I hope to start the advanced non-regression tests of the current 'staging' and to tag the candidate for release. Look also if something essential is missing in the current 'NEWS' of 'staging'. Sorry, 'NEWS' do not reflects in details all the contributions that have been made during the last year -- they are too numerous. 'Codereview' service of opensc-project.org is still not accessible and so there is no possibility to pick-up the 'useful' proposals that have been made there. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Prompt for SO PIN in Firefox
Hello, Le 21/07/2012 06:37, Nguyễn Hồng Quân a écrit : I want to generate key in Firefox with my OpenPGP card. The OpenPGP card need Admin PIN (SO PIN) to do that. However, I didn't see dialog box to ask for this PIN, so the generation fails. So, is there a way to ask for SO PIN via PKCS#11? If yes, how should the code of card support be changed? I have no solution, PIN callbacks is not supported by PKCS#11 framework (in the manner as it's supported by pkcs15-init tool). PKCS#11 framework do not create slot for SoPIN. In theory, with PKCS#11 you could generate the key. If SoPIN is presented by emulator as a 'normal' second PIN (without 'so-pin' flag), and if the PKCS#11 module is configured to create slot for every present PIN (default configuration), you could open session to corresponding slot and generate the key. But to use this key (I guess that in your case SoPIN do not give the right to use new key) you have to open session with the second, normal 'UserPIN' slot. So it's probably not usable in Firefox. Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Hello, I would like to start preparation of the new release based on the 'staging' branch of GitHub OpenSC . Your suggestions proposals are heartily welcome. As far as I see all 'essential' proposals, that have be committed into the 'staging' branch of OpenSC git repository hosted in opensc-project.org (git://www.opensc-project.org/OpenSC.git), are present in github OpenSC. Unfortunately there is no access to the code review service (gerrit) of opensc-project.org and it's not currently possible to pick-up the 'interesting' requests. So, if anybody interested to see these proposals in the next release, please, do pull request to 'staging' branch of GitHub OpenSC (git://github.com/OpenSC/OpenSC.git) . Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS#15 Emulator
Hello, Le 04/07/2012 03:16, Galoh Haron a écrit : I guess i need to clarify the question on pkcs#15 emulator again. 1) I have created pkcs15-thecard.c and work on sc_pks15emu-thecard_init_ex 2) With some code's modification, the command of opensc-tool -i, opensc-tool -a opensc -s work. 3) Any other steps missing for the emulator to work or perhaps a tiny miny write up for developers to work on the emulator ? I would start from implementing the card driver with the basic 'sc_card_operations' handlers and testing all the stuff with the opensc-explorer . Then make a list of the pre-existing objects (PINs, Pub/Priv keys, certs, data) that you wish to see exposed with the libopensc/pkcs15 API as the PKCS#15 objects. After that take as example some existing emulator to see how to prepare data before calling the 'sc_pkcs15emu_add_**' functions and host to register your 'init_ex' procedure in pkcs15-syn.c . Then your can start the testing with the pkcs15-* tools, and finally minidriver. I am trying to get the minidriver to work with the pkcs#15 emulator. Thank you. Kind regards, Viktor. On Mon, Jul 2, 2012 at 10:11 PM, Galoh Haron grha...@gmail.com mailto:grha...@gmail.com wrote: Hello, I am trying to emulate a non pkcs#15 smart card with no support for MF selection. How to test the emulation works? Because when i tried to run command pkcs15-tool -r 00, i received Certificate read failed: Invalid ASN.1 object Based on the log, 2012-07-02 22:06:20.293 [pkcs15-tool] reader-pcsc.c:176:pcsc_internal_transmit: called 2012-07-02 22:06:20.340 Incoming APDU data [ 17 bytes] = 84 E4 6C BA 08 7C 97 35 05 07 F1 DA 37 4E B2 90 ..l..|.57N.. 00 . == 2012-07-02 22:06:20.340 [pkcs15-tool] card.c:330:sc_unlock: called 2012-07-02 22:06:20.340 [pkcs15-tool] card-mykad.c:506:mykad_check_sw: called 2012-07-02 22:06:20.340 certificate size is 1035 2012-07-02 22:06:20.340 called, left=1031, depth 0 2012-07-02 22:06:20.340 Looking for 'tbsCertificate', tag 0x110 2012-07-02 22:06:20.340 decoding 'tbsCertificate' 2012-07-02 22:06:20.340 called, left=880, depth 1 2012-07-02 22:06:20.340 Looking for 'version', tag 0x2100, OPTIONAL 2012-07-02 22:06:20.340 decoding 'version' 2012-07-02 22:06:20.340 called, left=3, depth 2 2012-07-02 22:06:20.340 Looking for 'version', tag 0x2 2012-07-02 22:06:20.340 decoding 'version' 2012-07-02 22:06:20.340 decoding 'version' returned 2 2012-07-02 22:06:20.340 [pkcs15-tool] asn1.c:1394:asn1_decode: returning with: 0 (Success) 2012-07-02 22:06:20.340 Looking for 'serialNumber', tag 0x2 2012-07-02 22:06:20.340 decoding 'serialNumber' 2012-07-02 22:06:20.340 Looking for 'signature', tag 0x110 2012-07-02 22:06:20.340 decoding 'signature' 2012-07-02 22:06:20.340 Looking for 'issuer', tag 0x110 2012-07-02 22:06:20.340 decoding 'issuer' 2012-07-02 22:06:20.340 Looking for 'validity', tag 0x110 2012-07-02 22:06:20.340 decoding 'validity' 2012-07-02 22:06:20.340 Looking for 'subject', tag 0x110 2012-07-02 22:06:20.340 decoding 'subject' 2012-07-02 22:06:20.340 Looking for 'subjectPublicKeyInfo', tag 0x110 2012-07-02 22:06:20.340 decoding 'subjectPublicKeyInfo' 2012-07-02 22:06:20.340 sc_pkcs15_pubkey_from_spki 013C1CEF:157 2012-07-02 22:06:20.340 called, left=157, depth 0 2012-07-02 22:06:20.340 Looking for 'algorithm', tag 0x110 2012-07-02 22:06:20.340 decoding 'algorithm' 2012-07-02 22:06:20.340 called, left=13, depth 1 2012-07-02 22:06:20.340 Looking for 'algorithm', tag 0x6 2012-07-02 22:06:20.340 decoding 'algorithm' 2012-07-02 22:06:20.340 Looking for 'nullParam', tag 0x5, OPTIONAL 2012-07-02 22:06:20.340 decoding 'nullParam' 2012-07-02 22:06:20.340 [pkcs15-tool] asn1.c:1394:asn1_decode: returning with: 0 (Success) 2012-07-02 22:06:20.340 Looking for 'subjectPublicKey', tag 0x3 2012-07-02 22:06:20.340 decoding 'subjectPublicKey' 2012-07-02 22:06:20.340 [pkcs15-tool] asn1.c:1394:asn1_decode: returning with: 0 (Success) 2012-07-02 22:06:20.340 DEE pk_alg.algorithm=0 2012-07-02 22:06:20.340 called, left=138, depth 0 2012-07-02 22:06:20.340 Looking for 'publicKeyCoefficients', tag 0x110, OPTIONAL 2012-07-02 22:06:20.340 decoding 'publicKeyCoefficients' 2012-07-02 22:06:20.340 called, left=135, depth 1 2012-07-02 22:06:20.340 Looking for 'modulus', tag 0x2 2012-07-02 22:06:20.340 decoding 'modulus' 2012-07-02 22:06:20.340 Looking for 'exponent', tag 0x2 2012-07-02 22:06:20.340 decoding 'exponent' 2012-07-02 22:06:20.340 [pkcs15-tool]
Re: [opensc-devel] Questions on SM implementation
Hello, Le 04/07/2012 00:06, Frank Morgner a écrit : In OpenSC, the caller allocates memory if needed, afaik. Is there a specific reason why sc_single_sm_transmit breaks with this approach when getting the SM APDU? Difficult to divine what you mean. Is it card specific 'free-sm-apdu' called inside sc_single_sm_transmit() ? Memory for SM-APDUs is allocated by card specific 'get-apdu()', so it's quite natural that it's freed by card specific 'free-apdu()' . Allocation of sm-apdu and especially it's freeing are card specific and could be more then simple call to malloc() and free() -- let it be the card specific. 1. In struct sm_secure_channel, what is the difference between the keyset and the session? The GP/CWA structures of keysets and sessions all hold cryptographic keys. Session keys are the result of mutual authentication and are calculated by both sides (IFD and ICC) that share (or trust) some common secret. Keyset are static symmetric key(s), shared by both sides, and that are used to calculate session keys in the case of symmetric authentication scheme. In GP and CWA the keysets have a different look: three parts in GP, two parts in CWA. GP keysets can be presented to application as direct values, or as a 'master' key that needs to be 'diversified'. So the key set is the basis for a SM key agreement, where the derived keys are put into session, right? 2. Which roles play host_challenge and card_challenge in struct sm_secure_channel? AFAIK, an SM channel does not depend on a nonce. What do you mean 'SM channel'? ICC and IFD challenges are used by both sides to calculate session keys. Both sides exchange these values during the authentication negotiation. This is card specific and does not globally apply to SM. I know cards which use longer nonces and different key agreements. I think sm_secure_channel.session would be the right place to put it. This and previous are not card specific but SM type (GP, CWA) and authentication scheme (symmetric, asymmetric) specific. But you have a reason -- challenges and keysets can be moved inside the session typed data. 3. Have you thought about unifying struct sm_module_operations and struct sm_card_operations? The operations open/initialize, get_sm_apdu/get_apdus, close/finalize essentially seem to do the same. The difference is in prototypes, in data types, in 'context'. Caller and executor of the sm_card_operation handlers share a lot of common data via the 'sc_card' data, including the common SM session. The data of the only one APDU is exchanged. The module is 'session-less' -- every handle call needs all necessary data to re-calculate session key, restore SM context, etc. Module can return chained data of multiple APDUs . 1. Sessions: sm_ctx is always present in sc_card_t, when sm_card_operation.get_sm_apdu is called. The session information is available in both cases. Module handlers have not access to the 'sc_card' data, and I prefer to not change it. 2. APDU chains: Why not handle multiple APDUs with subsequent calls to sm_card_operations.get_sm_apdu (an error code could indicate if more APDUs must be transmitted)? It could be, I don't see the advantage. Note also that module handles use not the 'sc_apdu' but the 'sc_remote_data' data type . Look at card-authentic.c:2349 where you are actually already converting a call from sm_card_operation to sm_module_operations. Is there a case where this conversion can't be done? For this card only the 'APDU-TRANSMIT' SM mode is implemented. It uses only one 'remote-command' (APDU_TRANSMIT) type. Such conversion is possible only in this case. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Questions on SM implementation
Hello, Le 30/06/2012 00:25, Frank Morgner a écrit : I have some more questions on the SM implementations of OpenSC, that I could not find a quick answer in the source code: 1. In struct sm_secure_channel, what is the difference between the keyset and the session? The GP/CWA structures of keysets and sessions all hold cryptographic keys. Session keys are the result of mutual authentication and are calculated by both sides (IFD and ICC) that share (or trust) some common secret. Keyset are static symmetric key(s), shared by both sides, and that are used to calculate session keys in the case of symmetric authentication scheme. In GP and CWA the keysets have a different look: three parts in GP, two parts in CWA. GP keysets can be presented to application as direct values, or as a 'master' key that needs to be 'diversified'. 2. Which roles play host_challenge and card_challenge in struct sm_secure_channel? AFAIK, an SM channel does not depend on a nonce. What do you mean 'SM channel'? ICC and IFD challenges are used by both sides to calculate session keys. Both sides exchange these values during the authentication negotiation. 3. Have you thought about unifying struct sm_module_operations and struct sm_card_operations? The operations open/initialize, get_sm_apdu/get_apdus, close/finalize essentially seem to do the same. The difference is in prototypes, in data types, in 'context'. Caller and executor of the sm_card_operation handlers share a lot of common data via the 'sc_card' data, including the common SM session. The data of the only one APDU is exchanged. The module is 'session-less' -- every handle call needs all necessary data to re-calculate session key, restore SM context, etc. Module can return chained data of multiple APDUs . Kind regards, Viktor. ___ 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] PIV: signature output format
On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert deeng...@anl.gov wrote:
Just back from vacation...
On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
Hi Douglas,
I'm trying to get signature with the PIV card and verify it with the
'openssl pkeyutl'.
I use EC key #04 CARD AUTH Key.
It fails because of the 'raw' output format of the signature produced by
OpenSC.
OpenSSL expects the signature as a ASN1 sequence of two integers.
I've seen in card-piv.c your comments:
https://github.com/OpenSC/**OpenSC/blob/staging/src/**
libopensc/card-piv.c#L2023https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
/* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
* Which may have leading 00 to force positive
* TODO: -DEE should check if PKCS15 want the same
It seems that PKCS#15 really wants it.
* But PKCS11 just wants 2* filed_length in bytes
Can you explain more? Why it wants 'raw' data?
PKCS#11 v2.30: says:
6.3.1 EC Signatures
For the purposes of these mechanisms, an ECDSA signature is an octet
string of even
length which is at most two times nLen octets, where nLen is the length
in octets of the
base point order n. The signature octets correspond to the concatenation
of the ECDSA
values r and s, both represented as an octet string of equal length of
at most nLen with the
most significant byte first. If r and s have different octet length, the
shorter of both must
be padded with leading zero octets such that both have the same octet
length.
PKCS#11 2.20 in Section 12.3.1 says the same as above.
PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a fixed
size of nLen=20.
So PKCS#11 is not returning ASN1 but just the concatenation of r and s.
Ok, thanks.
* So we have to strip out the integers
* if present and pad on left if too short.
*/
I would propose to keep the ASN1 encoded data at the PKCS#15 level,
and, if needed, to convert it to the 'raw' format by dedicated procedure
in the pkcs15 framework of pkcs11.
Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
If it needs to be ASN1, then yes the conversion could be done in the
framework.
Ok, there is no signature in ASN.1 in pkcs#15, but there some practical
reasons.
The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
OpenSSL, for which the pkcs15-tool have to provide data in a suitable
format, needs also the ASN.1 encoding.
So, my suggestion is to keep the encoding returned by the card at the
pkcs#15 level,
and change it to the 'raw' mode on the pkcs#11 side.
Finally, I have no preference, if you prefer to keep it like it is now,
we'll be living with.
Kind regards,
Viktor.
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SC_ERROR_SECURITY_STATUS_NOT_SATISFIED
Hello, On Thu, Jun 21, 2012 at 10:36 AM, Galoh Haron grha...@gmail.com wrote: Recently we need to upgrade our non pkcs15 card to be compiled to the new version of opensc. Reason we want to support minidriver. (Signing on IE) We encouter error of SC_ERROR_SECURITY_STATUS_NOT_SATISFIED. We realize that when sending certain apdu command the card required pin validation/relogin. Previously opensc 0.11.4 supports pin revalidation. But there is a the new opensc deprecates the pkcs11 pin revalidation/relogin function @ http://www.opensc-project.org/opensc/changeset/95a5ab065401968c7f300ee4bd8d391d96279013/OpenSC/src/pkcs11/framework-pkcs15.c#file0 Since the card does not support pkcs15. Any idea/patch on how to implement pin cache/revalidation on pkcs11 and with the new opensc ? For the crypto operations the PIN re-validation has been implemented at the pkcs15 level. Your card is not natively pkcs#15, but, afaiu, it has to use pkcs#15 emulator and so, re-validation has to work for you also. If you will not receive other answers, you can test the latest MSIs built for 'staging' branch. ( https://opensc.fr/jenkins/ ) Here I could give you more details. What card are you using? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] PIV: signature output format
Hi Douglas,
I'm trying to get signature with the PIV card and verify it with the 'openssl
pkeyutl'.
I use EC key #04 CARD AUTH Key.
It fails because of the 'raw' output format of the signature produced by OpenSC.
OpenSSL expects the signature as a ASN1 sequence of two integers.
I've seen in card-piv.c your comments:
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
/* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
* Which may have leading 00 to force positive
* TODO: -DEE should check if PKCS15 want the same
It seems that PKCS#15 really wants it.
* But PKCS11 just wants 2* filed_length in bytes
Can you explain more? Why it wants 'raw' data?
* So we have to strip out the integers
* if present and pad on left if too short.
*/
I would propose to keep the ASN1 encoded data at the PKCS#15 level,
and, if needed, to convert it to the 'raw' format by dedicated procedure in the
pkcs15 framework of pkcs11.
Kind regards,
Viktor.
--
Viktor Tarasov viktor.tara...@opentrust.com
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Does pkcs15init allow to overwrite existing key?
Hello, On Wed, Jun 20, 2012 at 5:19 AM, Quan Nguyen quanngu...@mbm.vn wrote: I'm trying to implementing key import support for OpenPGP. I've almost done at the driver level and I'm continuing in pkcs15init, but face a problem: It seems that the pkcs15-init tool does not allow to overwrite existing key. When I provide key ID to import, it always reject if the ID has existed. Is there a reason why the pkcs15-init do so? The reason is to protect from overwriting the existing objects. Can the behavior be changed? Or there is another way to make pkcs15-init to overwrite? Overwrite not, for the native cards the method is to delete existing object and then create a new one with the same ID. My command to test: pkcs15-init --store-private-key quan-key.pem --auth-id 3 --verify-pin --extractable --id 4 -- Regards, Quân ___ 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] OpenSC staging branch
Hello, Le 14/06/2012 23:55, Frank Morgner a écrit : However, sm.h still requires you to know cwa structures and gp structures. This is typically what you would want to abstract with a SM layer. Look at opensc.h and cards.h, which offer a similar abstraction to the smart card driver. If you add a smart card driver to opensc, you only have to add sc_get_yourcard_driver to card.h and add it to internal_card_drivers in ctx.c. Effectively, you have to add only two lines to OpenSC's core files and your card driver is integrated. Now think about what you would have to change when adding a new SM implementation with your architecture. The difference between libopensc and SM is that there is only one ISO specification for the cards, and there are at least two SM specifications -- GlobalPlatform and CWA . I don't get your argument. libopensc doesn't force you to base your card driver on the iso7816 driver you are free to implement the call back functions as you want. This is absolutely compatible with non-7816 cards -- simply change the call back functions as needed. To be clear on the terminology: CWA'SM extends ISO 7816-4's SM. *Please* look at both documents and search for the differences regarding SM. You will find out that CWA is more specific in that it allows only one specific configuration of ISO 7816. Also, it requires the usage of Triple DES and Retail MAC. Thus, the two SM standards are ISO and GP. I do not separate ISO and CWA -- for me it one entity. I'm talking about difference between GP and ISOCWA version of SM. Now imagine, you have a SM driver for ISO 7816. And you have built into the ISO 7816 SM driver call back functions for doing the crypto operations. Then CWA is perfectly compatible with the ISO 7816 driver with call back functions for DES and Retail MAC. That's what I am proposing. In the SM of actual 'staging' the essential part (in libopensc) is the SM related call back handlers for the card driver and external SM module. And also the general and type specific SM data. What you are proposing (afaiu) is the further stage -- optimizing and structuring of SM crypto library and APIs that have to be used by SM handlers and module . In the current SM framework I do not see contradictions or excluded possibilities. In sm.h the SM data types include the sub-types specific for the SM specification, in the same manner as pkcs15-key data type includes the data types specific to the different key types -- RSA, DSA, GOST, ... If that's the case, using an abstraction layer for the crypto operations can be useful here, too. I do not understand what you are looking for: there is the generic level of crypto data types and operations, there is level of data and operations that is a key type specific . The same in SM: generic SM data types that has 'parameter' member where are the SM type specific data to be placed. 2. There are at least two methods to hook into SM, using a SM module and implementing SM at the driver level. This conceptually introduces duplication. It is sure to be followed with code duplication. Both should be unified: Each card driver has a SM driver, which provides wrapping and unwrapping SM. A SM driver can then also be a SM module with external key sets. Was it a question? Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and 'ACL' mode. I don't understand ACL mode, because it isn't used anywhere. (This, by the way, begs the question why it is defined...) The two hooks I see is via module or via implementation by the card driver. I am advocating for merging sm_module_operations and sm_card_operations. ACL mode is used when decision to-use or not-to-use SM for the next operation is derived by the ACL for this operation. Example is the iasecc card driver. Hmm, SM_MODE_ACL isn't used anywhere... Duplication can happen due to fact that each card driver implement SM as it wants, and can include into card specific part entire SM crypto library. Code duplication is bad. It leads to error duplication and other problems. Once more, the card drivers are relatively free inside their card-specific part. My humble opinion is that during the period of implementing of the common SM framework, we could tolerate some code duplication. Although every driver in every card is free to do whatever it wants, you might want to give it some possibilities for simplifications. So let's *design* a flexible SM framework instead of saying you are free to do whatever you want. CWA, epass2003, nPA, OpenPGP, DNie (afaik) are all based on ISO 7816 SM. Abstraction layers will help to find a common and robust code base between those cards. Agree, but let's start from definition of (the most) generic SM types and SM related handlers . The abstraction of SM related crypto can be the next stage. I do not contest that duplication can happen, but: - it should not be obstacle to the implementation; -
Re: [opensc-devel] OpenSC Server Maintenance
Hello, Le 11/06/2012 21:39, Alon Bar-Lev a écrit : Hello Andreas, GitHub is a great place... Already there, just need to migrate the wiki. The question is where Gerrit will be (if is used). And if there is a need to migrate the bugs as well... which may be difficult. Currently the most advanced OpenSC source code is in github. (By the way, who is the owner of github OpenSC project ?) OpenSC/OpenSC github project is connected to the alternative CI server (https://opensc.fr/jenkins/ https://opensc.fr/jenkins/computer/) This CI service is connected to the Jean-Michel's build/test farm. Also there are installed and tested CodeReview service (https://opensc.fr/gerrit/ https://opensc.fr/jenkins/computer/). What else do we need? Wiki, mailing list, file-server, ... Alon. On Mon, Jun 11, 2012 at 10:31 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: Hi everyone, the software running opensc-project.org is getting very, very old. I didn't upgrade it when Martin had plans to rebuild the server on real hardware somewhere, but that didn't happen for years now, and the installation is getting older and older. Is anyone interested in working on this - building a new server somewhere? Or what is your suggestion to migrate the project to some hosting plattform? code.google.com, sourceforge, savannah, ...? It not urgent, but I wouldn't be supprised if things break, as the server gets little attention. Thus the better someone steps up to maintain it, the better. Regards, Andreas ___ 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Server Maintenance
Le 12/06/2012 16:49, Ludovic Rousseau a écrit : Currently the most advanced OpenSC source code is in github. (By the way, who is the owner of github OpenSC project ?) Martin Paljak created the OpenSC organization at github. https://github.com/OpenSC And then Martin created the OpenSC repository for this organization. https://github.com/OpenSC/OpenSC I don't know what owner means in this case. The OpenSC organization has 3 members: Martin, you and me. As a member I cannot add 'hooks' to trigger jenkins's build by commit to github project. Only 'owner' can do it. I do not yet looked how to trigger jenkins build on github pull-requests, but I guess it will also need the 'owner's participation. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] openpg-tool manual
Le 11/06/2012 22:55, Jean-Michel Pouré - GOOZE a écrit : Dear Peter, We will soon release Debian based packages for OpenSC staging. It appears that a short manual for openpg-tool is missing. Or maybe I did not find it. Do you plan to publish a short manual? The man pages for openpgp-tool have been recently added and are installed by 'make install' procedure. Have you checked you debian packaging sources? Kind regards, Kind wishes, Viktor. ___ 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] OpenSC staging branch
Le 10/06/2012 14:21, Frank Morgner a écrit : Uh, I think I am a bit late on this discussion... But I wanted to add a general concern that there are some conceptual problems with the SM branch (and the recently included patches in staging). 1. Global SM configuration is mixed with a configuration at the driver level. For example, look at [3]. It includes CWA, IAS/ECC data types which should be realized at the card driver level (or maybe some SM driver). In [3] there is no IAS/ECC types. There are data types related to the two more-or-less different SM implementations: GlobalPlatform and CWA. It's not card specific. 2. There are at least two methods to hook into SM, using a SM module and implementing SM at the driver level. This conceptually introduces duplication. It is sure to be followed with code duplication. Both should be unified: Each card driver has a SM driver, which provides wrapping and unwrapping SM. A SM driver can then also be a SM module with external key sets. Was it a question? Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and 'ACL' mode. Duplication can happen due to fact that each card driver implement SM as it wants, and can include into card specific part entire SM crypto library. I do not contest that duplication can happen, but: - it should not be obstacle to the implementation; - please point out exactly, where in code you see duplication. 3. As stated earlier, I am advocating for an additional abstraction between encoding and encryption. Thus, a SM driver would only implement encoding, offering an other abstraction to the crypto. Not implementing this abstraction has led to code duplication [1]. And reinventing the wheel will continue, when all ISO-7816-like cards [2, for example] (or modules) offer their own implementation of: - TLV-encoding/decoding of cryptogram (with padding content indicator), mac and le (depending on the APDU case) - ISO padding of APDU header and data As stated ealier, every card driver (at least at the beginning) can do roughly what it wants inside it's card specific part. We have only started to introduce the common SM framework, and for a while, we will not blame the card driver if it includes it's own SM related crypto procedures (... and thus duplicates the code. Is that the code duplication that you are talking about? 4. General problems with code quality: - A lot of dead code pieces (#if 0) You mean the SM part or entire code base of OpenSC. - Usage of global switches instead of switches in the card context What do you mean? - No or wrong documentation of the SM stuff - directory sm should be renamed to sm-modules ... These issues, I think, disqualify the SM branch to be included in OpenSC's trunk. The biggest problem, I think is the coexistance of two independant SM hooks. You simply cannot cover all SM use cases with one low level SM wrapping method. But understand you quite well -- you know/use only this one. In general I dislike the concept of a SM module, because all OpenSC initialization magic is lost, when only the APDU buffer is passed to the module. If a module is only used for external keysets, then it should do only encrypting/decrypting/authenticating instead of handling the whole smart card stuff. External module do not handle all the smart card staff, but it has to do part of it. Example: when importing, the RSA key has to be presented by a sequence of 5-7 APDUs, which could be different for the different cards. So, external module has to be able to compose the plain APDUs . Then, what you get is OpenSC that handles smart card stuff, including SM encoding and a crypto layer with loadable modules. Sorry, do not understood. [1] http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015121.html [2] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-epass2003.c [3] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h ___ 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] OpenSC staging branch
Le 10/06/2012 22:39, Frank Morgner a écrit : On Sunday, June 10 at 03:39PM, Viktor Tarasov wrote: Le 10/06/2012 14:21, Frank Morgner a écrit : Uh, I think I am a bit late on this discussion... But I wanted to add a general concern that there are some conceptual problems with the SM branch (and the recently included patches in staging). 1. Global SM configuration is mixed with a configuration at the driver level. For example, look at [3]. It includes CWA, IAS/ECC data types which should be realized at the card driver level (or maybe some SM driver). In [3] there is no IAS/ECC types. There are data types related to the two more-or-less different SM implementations: GlobalPlatform and CWA. It's not card specific. Well, well... I copied CWA, IAS/ECC data types from https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h:133. If there are no IAS/ECC types, it shows how wrong the documentation is. (By the way, there *is* some function called `iasecc_sm_external_authentication`, line 342) You are perfectly right, the documentation is not perfect -- will be working on it. Do you see something card-specific in the data types? The name of function can be easily changed, and will be changed. Thanks to point it out. However, sm.h still requires you to know cwa structures and gp structures. This is typically what you would want to abstract with a SM layer. Look at opensc.h and cards.h, which offer a similar abstraction to the smart card driver. If you add a smart card driver to opensc, you only have to add sc_get_yourcard_driver to card.h and add it to internal_card_drivers in ctx.c. Effectively, you have to add only two lines to OpenSC's core files and your card driver is integrated. Now think about what you would have to change when adding a new SM implementation with your architecture. The difference between libopensc and SM is that there is only one ISO specification for the cards, and there are at least two SM specifications -- GlobalPlatform and CWA . In sm.h the SM data types include the sub-types specific for the SM specification, in the same manner as pkcs15-key data type includes the data types specific to the different key types -- RSA, DSA, GOST, ... 2. There are at least two methods to hook into SM, using a SM module and implementing SM at the driver level. This conceptually introduces duplication. It is sure to be followed with code duplication. Both should be unified: Each card driver has a SM driver, which provides wrapping and unwrapping SM. A SM driver can then also be a SM module with external key sets. Was it a question? Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and 'ACL' mode. I don't understand ACL mode, because it isn't used anywhere. (This, by the way, begs the question why it is defined...) The two hooks I see is via module or via implementation by the card driver. I am advocating for merging sm_module_operations and sm_card_operations. ACL mode is used when decision to-use or not-to-use SM for the next operation is derived by the ACL for this operation. Example is the iasecc card driver. Duplication can happen due to fact that each card driver implement SM as it wants, and can include into card specific part entire SM crypto library. Code duplication is bad. It leads to error duplication and other problems. Once more, the card drivers are relatively free inside their card-specific part. My humble opinion is that during the period of implementing of the common SM framework, we could tolerate some code duplication. I do not contest that duplication can happen, but: - it should not be obstacle to the implementation; - please point out exactly, where in code you see duplication. - CWA implements SM according to ISO 7816 ([4], p67) and so does epass3000. Once more, card driver can do what it want if this do not hurts the common part, or until the moment when the common SM framework will be installed. - About two years ago I have pointed at some places where bit padding is implemented multiple times (with different implementations) -- this still holds today. Sorry, I will not be looking for where two years ago you pointed these places, please, point them here and now . If this bit padding takes more then few lines in codes, we will certainly create some dedicated procedure. 3. As stated earlier, I am advocating for an additional abstraction between encoding and encryption. Thus, a SM driver would only implement encoding, offering an other abstraction to the crypto. Not implementing this abstraction has led to code duplication [1]. And reinventing the wheel will continue, when all ISO-7816-like cards [2, for example] (or modules) offer their own implementation of: - TLV-encoding/decoding of cryptogram (with padding content indicator), mac and le (depending on the APDU case) - ISO padding of APDU header and data
Re: [opensc-devel] OpenSC staging branch
Le 04/06/2012 19:22, Jean-Michel Pouré - GOOZE a écrit : Dear all, There seems to be a lot of development in OpenSC staging branch: https://github.com/OpenSC/OpenSC/commits/staging?page=1 What is the required way to make a commit? Fork and make a pull request? Can you confirm we are back to GIThub normal process? Currently we are gathering pending proposals in the 'staging' branch of OpenSC/OpenSC github project. This branch is connected to CI service (https://opensc.fr/jenkins). Currently the right the way for proposals is fork - change - pull-request. For a while the review of proposals is slightly simplified. One reason is the stagnation of proposal admission process during the preceding period -- a lot of proposals were waiting in purgatory for a long time. Next reason is that the pull requests in github are not yet connected to CI service and so the only way to compile/test proposal on different platforms is to be included to 'staging'. I will try to connect the github pull requests to jenkins. If no, probably we should return to the using of gerrit. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GetInvolved wiki page
Le 05/06/2012 09:38, Ludovic Rousseau a écrit : Hello, 2012/6/5 Jean-Michel Pouré - GOOZE jmpo...@gooze.eu: But my question is: * Are we still using gerrit? * Is gerrit synced? After hearing the community answers, I will rewrite this later today. As far as I understand the situation: 1- github and gerrit has diverged too much and need to be resync manually 2- a lot of work has been invested in the staging branch on github and should not be lost 3- the idea is to start gerrit with a new clean copy of what is on github Start with clean copy is not complicated -- clone bare github repository somewhere in Gerrit's review directory. We can re-visit the old gerrit proposals and cherry-pick the 'usefull' ones into the new gerrit's project. The problem now is to find manpower (and expertise) to implement point 3. I was ready to do it, but as you know, have no sufficient rights on gerrit and jenkins connected to opensc-project.org . Currently I prefer the alternatives jenkins (and gerrit) connected to the github 'staging'. This allows to gather pending proposals into 'staging' and in the nearest future to prepare the next (major) release of OpenSC. It also allows the build of packages on multiple platforms and automated testing. Once gerrit is usable again the github repository should be read only to avoid a new divergence. I agree, if the alternatives jenkins and gerrit will be used, or current access rules to jenkins and gerrit on opensc-project.org will be changed. I do not volunteer for point 3. I was expecting Martin to do it but he may not have enough free time these days. The main problem of OpenSC is a lack of trusted manpower. Andreas (previous leader) left the project. Martin has limited free time. I do not use OpenSC much myself but try to help as much as I can. Viktor is working fine merging github pull requests. ... Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] EF(DIR) and sc_pkcs15_bind_internal
Le 02/06/2012 14:10, Martin Paljak a écrit : Hello, On Fri, Jun 1, 2012 at 9:45 PM, Douglas E. Engert deeng...@anl.gov wrote: An example might be a PIV card application has the ATR may contain the default application on the card. Thus it could be possible that a card has both a default application that is not PKCS#15 and the card could also be a PKCS#15 card. I don't now understand what you want to imply. Should the logic be tuned further? What I'm trying to do is to create a card application that would require minimal or even no changes at all to OpenSC to be recognized as a PKCS#15 card. But adhering to standards, I believe that the first check should be trying to select the PKCS#15 application by AID, if EF(DIR) is not present. There is also EF.ATR, where the (default) application ID could be encoded. I have no ISO-7816-5, but according to 'ISO-7816-4 2005' ch.8.2.2 'Application selection' there are following application selection methods: - implicit application selection. For this method an application ID or initial application selection command has to be present in historical bytes of ATR. If there is no such data in historical bytes, then application identifier has to be looked for in EF.ATR. - selection using the SELECT-DF-NAME command with the AID found in historical bytes or in EF.ATR - selection using composed data from EF.DIR and EF.ATR. Parsing of EF.ATR content is already present in the common part of OpenSC. As I've not found a reference to 5015 either (except that it has been used by other applications for PKCS#15 DF in the wild), this might also reply to the question of why the file ID-s are as they currently ar. Afaiu, the '5015' (P15) is nowhere in the standards. It's used by OpenSC convention and also by other card producers (Oberthur AuthentIC 3.2). The best description of the issue is of course a patch, which solves the problem as I see it. Will send it on Monday. Best, Martin Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] ECDH in 'staging' of github OpenSC/OpenSC
Hi Douglas, ECDH support, that you have tested in SM branch, has been committed into the 'staging' branch of github OpenSC/OpenSC. https://github.com/OpenSC/OpenSC/tree/staging I've made only basic (list on-card objects) tests with PIV card. More substantial tests will be performed later, when the rest of pending proposals will find their place in 'staging'. If you are using Windows environment you can try one of MSIs from https://opensc.fr/jenkins/view/OpenSC-staging/ Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] FOSS development
On Sun, May 27, 2012 at 11:59 PM, Peter Stuge pe...@stuge.se wrote: Jean-Michel Pouré - GOOZE wrote: What I suggest is that OpenSC should be hosted on GIThub with write access to core developers (at least 5/6 people). Insisting on changing some hosting situation that has been set up is nothing but obnoxious protesting and spitting on the already established hosting. Peter, probably it useless, but may I bring once more to your attention the fact that github is set into the center for Development Policy by Martin himself. Look onto the diagram in https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy . Centering development around github.com brings no benefits whatsoever over opensc-project.org. The latter allows the project to do nice integration and customization of all tools. Github not so much. What integration do you mean? On opensc-project.org the tarball, MSI and DMG are built. No RPMs, DEB, no automated tests, ... 'Customization of all tools' -- what tools do you mean ? Effectively, it would be nice to build and publish Linux packages, connect automated tests, include other OpenSC sub-projects, ... But who will do all this on opensc-project.org? Martin have no time, no one else can/allowed to do something. Beside the necessity of the perfect commits, can you propose something else? Kind regards, Viktor. //Peter ___ 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] new release?
Le 25/05/2012 18:09, Douglas E. Engert a écrit : On 5/25/2012 6:04 AM, Martin Paljak wrote: Hello, On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engertdeeng...@anl.gov wrote: The SM branch has pulled in many other changes (including my C_Derive changes) that I would like to see in the next release. If the SM branch is not going to be the bases for the next release, then we need to look at what change in the SM branch can be pulled in to the release. Martin, I would like to hear your comments. Obviously Viktor and others have had way more time in their hands to work on OpenSC than me :) Also obvious is that the most active branch is supposed to be merged as the basis for next release, which was more or less the idea of Git in the first place. As the recovery option, the sync problem between Gerrit and github needs to be cleared. Too much integration is probably not a good idea, two-way syncing between github pull request and Gerrit has brought no obvious benefits... The most straightforward approach would probably be forcing the github tree into opensc-project.org and clearing Gerrit... Before, I propose to gather into the github staging all pending proposals. After use this branch as the base for the next release: test this branch as far as possible, firstly using the automated packaging and tests, then extended manual tests with number of cards. For the future use the github OpenSC as the main repository for development and packaging. Connected to CI service, GitHub gives similar possibilities to analyze and validate proposals as Gerrit do. (I do not yet tried to connect github pull request to Jenkins, but I think it's possible.) By the way, Martin, will it be possible to add to the github OpenSC/OpenSC the web-hook with URL of my jenkins service? I need it for the 'staging' of OpenSC/OpenSC, where I would like to use trigger by commit and also to try the build of pull requests. Martin Sounds reasonable, but how do we avoid these types of problems in the future? No two-way syncing, with Gerrit or GitHub as the master? Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
On Mon, May 21, 2012 at 3:48 AM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: Hi Peter, On 05/21/2012 04:35 AM, Peter Koch wrote: Here are my own impressions - if they are wrong, please correct me: 1: OpenPGP cards do NOT have a filesystem like other smart cards. Instead of storing informations in EFs which are located in DFs an OpenPGP card stores information in Data Objects. Here my conclusion is: Without EFs and DFs and in particular without commands to create EFs and DFs pkcs15-init does not make any sense. Yes, but the pkcs15-init binding for OpenPGP card will implement only a small part: importing certificate, generate keys. It won't create DF EFs. The reason why I need pkcs15-init binding is that I want it possible to import certificate via PKCS#11 interface (using Firefox). While researching how to achieve it, I tried with the pkcs11-tool and found that doing import certificate needs the pkcs15-init binding. I will appreciate if someone point me another way to do, avoiding pkcs15-init. No other way if you are going to use the pkcs11 framework of OpenSC. The pkcs11 framework uses pkcs15init API. 2: The current driver emulates SELECT and READ BINARY APDUs by reading from the corresponding Data Objects. I believe this was done in order to emulate a (read only) PKCS#15 file layout. If that was true - is there any hope to extend this emulation? Yes, but it seems that this emulated file layout does not match the PKCS#15 very well, leading to the problem which I described in this topic http://www.opensc-project.org/pipermail/opensc-devel/2012-May/018018.html Card specific emulator do not emulates the file system but exposes the pkcs15 objects with their attributes. These attributes genarally contain some 'path'. This 'path' can-be/is treated by the card specific libopensc driver. To resume, in the card specific pkcs15 emulator you can assign some attribute value, that will have some meaning in your card specific libopensc driver, that in its turn will perform a card specific low level operation. In that manner the card specific implementation of 'file system' is hidden from pkcs15 level. 3: What features are missing in the current implementation and what bugs should be fixed? What's new in my own branch: - Write support for normal DOs (the Extended Header List DO - 4D - is not supported yet. This DO is used for key import). - Expose certificate (stored in the 7F21 DO) to PKCS#11 app. Things I want to do next is to support key import and certificate import. Beside the absence of pkcs15init support, afais, the openpgp libopensc driver have no support for any operation that could change the card's content: write, update, delete, generate, import, ... -- Regards, Quân ___ 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] OpenPGP card / Cryptostick - current status???
On Mon, May 21, 2012 at 1:22 PM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: Hi Viktor, On 05/21/2012 05:10 PM, Viktor Tarasov wrote: 2: The current driver emulates SELECT and READ BINARY APDUs by reading from the corresponding Data Objects. I believe this was done in order to emulate a (read only) PKCS#15 file layout. If that was true - is there any hope to extend this emulation? Yes, but it seems that this emulated file layout does not match the PKCS#15 very well, leading to the problem which I described in this topic http://www.opensc-project.org/pipermail/opensc-devel/2012-May/018018.html Card specific emulator do not emulates the file system but exposes the pkcs15 objects with their attributes. These attributes genarally contain some 'path'. This 'path' can-be/is treated by the card specific libopensc driver. I think this is right for pkcs15 binding in libopensc folder, but not for pkcs15init binding in pkcs15init folder. For example, here is how I expose the certificate object, located at path 3F007F21, to pkcs15: sc_format_path(3F007F21, cert_info.path); strlcpy(cert_obj.label, Cardholder certificate, sizeof(cert_obj.label)); r = sc_pkcs15emu_add_x509_cert(p15card, cert_obj, cert_info); However, when come to pkcs15init, the path is read from the pkcs15.profile, then openpgp.profile, and it is 3F0050157F21 instead 3F007F21 (the additional 5015 comes from pkcs15.profile). I have not found a way to intervene the path reading to change 3F0050157F21 to 3F007F21 (what the lower driver needs) yet. 5015 comes from your pkcs15init profile https://github.com/hongquan/OpenSC-OpenPGP/commit/9b2ea7689b461c31b7ffda736d2c9dc332491562#L1R59 where your crypto objects are put inside the 'DF PKCS15-AppDF'. Path for this DF is not defined in openpgp profile, so, it takes it from the upper profile -- pkcs15.profile. https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/pkcs15init/pkcs15.profile#L135 Never tried it myself, but you can try the openpgp profile without 'PKCS15-AppDF'. Beside the absence of pkcs15init support, afais, the openpgp libopensc driver have no support for any operation that could change the card's content: write, update, delete, generate, import, ... At low level, the OpenPG card uses PUT DATA command instead of UPDATE BINARY to write content. I implemented that put_data function for OpenPGP driver in my github repository ( https://github.com/hongquan/OpenSC-OpenPGP/commits/openpgp). If you are going to use the common pkcs15 and pkcs15init framework , you have to fill at least the 'write' hadle with the meanigfull actions . https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/libopensc/card-openpgp.c#L827 Inside this handle the 'PUT DATA' or else can be used -- it's doesn't matter. -- Regards, Quân Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS15init profile to omit a part of path
Hello Nguyễn, Le 18/05/2012 11:59, Nguyễn Hồng Quân a écrit : I need a help to create pkcs15init profile structure so that I can change/rewrite the canonical path. In general, the path to a file AABB in PKCS15 is as: 3F005015AABB, in which 3F00 is the MF, 5015 is the PKCS15-AppDF's file-id. Now, because the virtual file system of my OpenPGP card (which is non-pkcs15) is constructed as: MF (3F00) | +-- File_1 (AABB) | +-- File_2 (AACC) | +--- Directory (DDCC) | +-- File_3 (CCEE) the real path to the file is 3F00AABB. How would I define the profile file to omit the PKCS15-AppDF, i.e. the 5015, in the path? In OpenSC the pkcs15-init part is used mostly by cards that can natively support the on-card PKCS#15 file system. The only exception is the Oberthur's card, that has producer specific on-card file system and data encoding. In the OpenSC this card uses the emulator in its 'pkcs15-libopensc' part (like the openpgp card), and uses extended pkcs15init API to implement the emulator of 'pkcs15-init' part . The 'emulator' extension of the pkcs15init API consists in the 'emu_*' sc_pkcs15init_operations handlers (src/libopensc/pkcs15-init.h). You can look into oberthur.profile and src/pkcs15init/pkcs15-oberthur.c with the card's pkcs15init handlers. No look too close into the src/pkcs15init/pkcs15-oberthur-awp.c. This file contains the implementing of the producer specific data encoding/decoding. Unfortunately there is no more or less full documentation on the profiles, other then the comments in profile files itself or in the sources. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS15init profile to omit a part of path
Hi Peter, Le 20/05/2012 19:19, Peter Marschall a écrit : This is not directly related to your question, but more general: You wrote about implementing write support for OpenPGP cards. Is there a chance to see the code you already have? maybe e.g. on github ;-) You can look onto 'secure-messaging' branch of my OpenSC github project, forked from OpenSC/OpenSC. https://github.com/viktorTarasov/OpenSC-SM/tree/secure-messaging In my Jenkins (https://opensc.fr/jenkins/) this branch is continuously built on multiple platforms; packages are created for win32, win64, debian, suse, mac (package for SuSE is published onto the OpenSuSE build platform); some (at the moment rudimentary) automatic tests are executed with the real card; coverity scan performed. CI service is still under development. There is some CI support for OpenSC/OpenSC/staging also. Now I gradually start the merging of this branch into 'staging' of OpenSC/OpenSC. I hope to merge all. After that the CI service will be concentrated on OpenSC staging and master. In that way I hope to revive release process of OpenSC. Best Peter Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] flex.profile missing and PIN-EIntry broken
Hello, On Sun, May 6, 2012 at 11:20 AM, Peter Koch p...@opensc-project.org wrote: I just tried to erase my old Cryptoflex card an recreate a PKCS#15-structure under Windows. First problem was: flex.profile was missing - here's the relevant debug output from pkcs15-init -Cvvv 2012-05-06 10:57:54.577 Trying profile file C:\Programme\OpenSC Project\OpenSC\profiles\pkcs15.profile 2012-05-06 10:57:54.577 profile C:\Programme\OpenSC Project\OpenSC\profiles\pkcs15.profile loaded ok 2012-05-06 10:57:54.577 [pkcs15-init] profile.c:380:sc_profile_load: returning with: 0 (Success) 2012-05-06 10:57:54.587 [pkcs15-init] profile.c:327:sc_profile_load: called 2012-05-06 10:57:54.587 Using profile directory 'C:\Programme\OpenSC Project\OpenSC\profiles'. 2012-05-06 10:57:54.587 Trying profile file C:\Programme\OpenSC Project\OpenSC\profiles\flex.profile 2012-05-06 10:57:54.598 profile C:\Programme\OpenSC Project\OpenSC\profiles\flex.profile loaded ok 2012-05-06 10:57:54.598 [pkcs15-init] profile.c:373:sc_profile_load: returning with: -1201 (File not found) 2012-05-06 10:57:54.598 Failed to load profile 'flex': File not found 2012-05-06 10:57:54.608 [pkcs15-init] pkcs15-lib.c:374:sc_pkcs15init_bind: Load profile error: -1201 (File not found) Couldn't bind to the card: File not found So I copied flex.profile (and some other profiles which were also missing) into the profiles-directory. Next problem: pkcs15-init -C tells me it cannot read the PIN: C:\Programme\OpenSC Project\OpenSC\toolspkcs15-init -C Using reader with a card: SCM Microsystems Inc. SPRx32 USB Smart Card Reader 0 Failed to read PIN: Not supported Failed to create PKCS #15 meta structure: Generic PKCS#15 initialization error Debug-output does not help but there seems to be a ticket and a fix. Is this ticket #402: http://www.opensc-project.org/opensc/ticket/402 ? Are you expecting to use PIN-pad reader with the pkcs15-init tool ? Have you tried with the non-pinpad reader ? What package, version are you using ? 'For-me-it-works with CryptoFlex-16k, non-pinpad reader and latest MSI (32bits) of the OpenSC 'secure-messaging' branch. With PIN-pad the 'pkcs15-init -C' prompts to enter SOPIN at the command line. Not sure that it's a bug, not sure that pkcs15-init *has* to work with pin-pad. PinPad (Gemalto's PC PinPad reader) works properly when trying to verify PIN in opensc-explorer. Peter Kind regards, Viktor. Kind regards, Viktor. ___ 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] flex.profile missing and PIN-EIntry broken
Little addition. On Wed, May 9, 2012 at 5:45 PM, Viktor Tarasov viktor.tara...@gmail.comwrote: 'For-me-it-works with CryptoFlex-16k, non-pinpad reader and latest MSI (32bits) of the OpenSC 'secure-messaging' branch. ... beside the missing flex.profile problem. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fix a crash when trying to list objects via opensc-pkcs11
Hello Nguyễn,
Le 07/05/2012 10:42, Nguyễn Hồng Quân a écrit :
I've updated the openpgp-card.c and the select_file() now returns right
error Data object not found.
However, in the final list, the missing pub key still be listed (see the
attached log).
Is anything wrong with the PKCS15 common part?
This card is not natively PKCS#15 card, and emulator is used to expose the
pkcs#15 objects.
If you definitively need to deal with the non-initialized card, imho,
you have to review it's emulator part (libopensc/pkcs15-openpgp.c) .
Thanks,
Kind regards,
Viktor.
On 05/05/2012 07:29 PM, Viktor Tarasov wrote:
Le 05/05/2012 07:14, Nguyễn Hồng Quân a écrit :
Thanks Viktor,
I found the defect at the function pgp_get_blob() in card-openpgp.c.
There are lines:
if (child-id == id) {
(void) pgp_read_blob(card, child);
*ret = child;
return SC_SUCCESS;
The problem is either:
1. The child blob does not exist, but there still exists its ID.
2. The result of pgp_read_blob(card, child) is not checked.
This function is called by file_select and because it returns SUCCESS,
it makes file_select SUCCESS although the blob does not exist.
I think fixing 1 is better. What do you think? (Or the ID is
pre-defined?)
I'm new (and this driver was not written by me), so I'm grateful to
receive your guidance.
First of all,
I do not know openpgp card and do not have this card to make the tests.
Afaiu, the 'child' and it's 'ID' are the openpgp specific features that do
not have any relation to the 7816 standards.
They has to be hidden from the common OpenSC library part by the openpgp
card's driver.
The authors of openpgp driver could explain better,
by from my point of view,
if the blob cannot be read, pgp_select() has to return 'file-not-found' or
other error.
In any case with such openpgp internal errors there is no possibility to
return a valid FCP/FCI and valid file length.
Looking onto the code I suppose that the FCP returned by
pgp_select(public-key) belongs in fact to MF (or intermediate DF).
That's for, in my previous mail, I asked you
what are the 'type' and 'ef-structure' of the sc_file data returned by
'successful' pgp_select() ?
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fix a crash when trying to list objects via opensc-pkcs11
Le 05/05/2012 07:14, Nguyễn Hồng Quân a écrit :
Thanks Viktor,
I found the defect at the function pgp_get_blob() in card-openpgp.c.
There are lines:
if (child-id == id) {
(void) pgp_read_blob(card, child);
*ret = child;
return SC_SUCCESS;
The problem is either:
1. The child blob does not exist, but there still exists its ID.
2. The result of pgp_read_blob(card, child) is not checked.
This function is called by file_select and because it returns SUCCESS,
it makes file_select SUCCESS although the blob does not exist.
I think fixing 1 is better. What do you think? (Or the ID is
pre-defined?)
I'm new (and this driver was not written by me), so I'm grateful to
receive your guidance.
First of all,
I do not know openpgp card and do not have this card to make the tests.
Afaiu, the 'child' and it's 'ID' are the openpgp specific features that do not
have any relation to the 7816 standards.
They has to be hidden from the common OpenSC library part by the openpgp card's
driver.
The authors of openpgp driver could explain better,
by from my point of view,
if the blob cannot be read, pgp_select() has to return 'file-not-found' or
other error.
In any case with such openpgp internal errors there is no possibility to return
a valid FCP/FCI and valid file length.
Looking onto the code I suppose that the FCP returned by pgp_select(public-key)
belongs in fact to MF (or intermediate DF).
That's for, in my previous mail, I asked you
what are the 'type' and 'ef-structure' of the sc_file data returned by
'successful' pgp_select() ?
On Fri 04 May 2012 08:18:58 PM ICT, Viktor Tarasov wrote:
Hello Nguyễn,
On Fri, May 4, 2012 at 12:04 PM, Nguyễn Hồng Quân quanngu...@mbm.vn
mailto:quanngu...@mbm.vn wrote:
The case in this log is that the card is not initialised. It contains
no key. That is the reason why
the blob read failed, the file length is zero, the read binary
returned
zero and final, a key with zero length modulus.
I think what behavior for this case is conventional. When the card
contains no key, should OpenSC:
- return error
- see it normal and notify: No key
- see it normal and notify: Valid key with zero attributes (modulus
length if pubkey).
It's not going about the key files
but about the openpgp specific select_file() method.
Without longly looking into specifications, let us postulate -- valid
'selectable' EF should have length more then zero.
With this rule, your select_file(EF) procedure should not return
SUCCESS if it cannot get valid FCP and file length.
By the way,
what are the 'type' and 'ef_structure' of the sc_file data returned by
this 'select' ?
To resume,
as for me it should be case 'return error'.
--
Regards,
Quân
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fix a crash when trying to list objects via opensc-pkcs11
Hello Nguyễn, On Fri, May 4, 2012 at 12:04 PM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: The case in this log is that the card is not initialised. It contains no key. That is the reason why the blob read failed, the file length is zero, the read binary returned zero and final, a key with zero length modulus. I think what behavior for this case is conventional. When the card contains no key, should OpenSC: - return error - see it normal and notify: No key - see it normal and notify: Valid key with zero attributes (modulus length if pubkey). It's not going about the key files but about the openpgp specific select_file() method. Without longly looking into specifications, let us postulate -- valid 'selectable' EF should have length more then zero. With this rule, your select_file(EF) procedure should not return SUCCESS if it cannot get valid FCP and file length. By the way, what are the 'type' and 'ef_structure' of the sc_file data returned by this 'select' ? To resume, as for me it should be case 'return error'. I'm new to OpenSC and I have no other card (but my CryptoStick) to test, I don't know what behavior the team agreed for this case. Can you let me know? Observing the situation when the private key does not exist, it seems that the 3rd behavior is being adopted: $ pkcs11-tool --module=/usr/lib/opensc-pkcs11.so -O -l Using slot 1 with a present token (0x1) Logging in to OpenPGP Card (Signature PIN). Please enter User PIN: Private Key Object; RSA label: Signature key ID: 01 Usage: sign Segmentation fault On Thu 03 May 2012 07:32:38 PM ICT, Viktor Tarasov wrote: On Thu, May 3, 2012 at 12:38 PM, Nguyễn Hồng Quân quanngu...@mbm.vn mailto:quanngu...@mbm.vn wrote: Hi, I would like to resend the gzipped log file: Effectively, there is an insufficient control of the pkcs15/11 object validity in the common part. In more details I will look during the weekend, but, I guess that you have to review the openpgp card driver (card-openpgp.c) . According to logs, it tries to read the file blob inside the pgp_select(), fails, but nevertheless the pgp_select returns SUCCESS . Is it wanted behavior? The returned selected file has zero length, binary read of zero bytes returns SUCCESS (with zero length it do not even try to access the card). and finally there is a valid public key object with zero length modulus. On Thu 03 May 2012 05:35:53 PM ICT, Nguyễn Hồng Quân wrote: Hi, Here is the log (debug level 8) On Thu 03 May 2012 03:36:07 PM ICT, Nguyễn Hồng Quân wrote: Hello every one, I've just committed a patch to fix a crash of opensc-pkcs11 when I tested with CryptoStick. Please review: https://github.com/OpenSC/OpenSC/pull/31 -- Regards, Quân -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto:opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
On Thu, May 3, 2012 at 12:35 AM, Peter Stuge pe...@stuge.se wrote: Viktor Tarasov wrote: I still propose to merge the SM branch into the github:OpenSC-staging and prepare it as candidate for release . It should not be difficult, recently both branches has been synchronized. The difficulty lies not in making something that builds, the difficulty lies in understanding every single changed line of code. There hasn't been very much review. You've already told this months ago. Something has been changed? Have you something else to propose, taking into account the available human resources ? Reviewer, the one that can review something more than 'trailing whitespaces', needs some motivation. This motivation is stimulated by responsiveness of the project to his aspirations. There was unusual period of absence of dialogue in the OpenSC project, so, I suggest the unusual means to restore the normal dialogue. //Peter ___ 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] Fix a crash when trying to list objects via opensc-pkcs11
On Thu, May 3, 2012 at 12:38 PM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: Hi, I would like to resend the gzipped log file: Effectively, there is an insufficient control of the pkcs15/11 object validity in the common part. In more details I will look during the weekend, but, I guess that you have to review the openpgp card driver (card-openpgp.c) . According to logs, it tries to read the file blob inside the pgp_select(), fails, but nevertheless the pgp_select returns SUCCESS . Is it wanted behavior? The returned selected file has zero length, binary read of zero bytes returns SUCCESS (with zero length it do not even try to access the card). and finally there is a valid public key object with zero length modulus. On Thu 03 May 2012 05:35:53 PM ICT, Nguyễn Hồng Quân wrote: Hi, Here is the log (debug level 8) On Thu 03 May 2012 03:36:07 PM ICT, Nguyễn Hồng Quân wrote: Hello every one, I've just committed a patch to fix a crash of opensc-pkcs11 when I tested with CryptoStick. Please review: https://github.com/OpenSC/OpenSC/pull/31 -- Regards, Quân -- Regards, Quân ___ 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] new release?
On Wed, May 2, 2012 at 4:31 PM, Douglas E. Engert deeng...@anl.gov wrote: On 5/2/2012 8:22 AM, Jean-Michel Pouré - GOOZE wrote: Le mardi 01 mai 2012 à 21:00 +0300, Kalev Lember a écrit : What I am looking for is an official release, something that Linux distributions could pick up. A snapshot of another development branch wouldn't really help me here, but I appreciate the suggestion. At some point, the SM branch will deprecate other branches: * This is where most development is done. * We have a complete approach of a quality circle, starting with frequent updates and ending with package releases and automatic testing. OpenSC hackers are encouraged to switch to SM branch. That still does not answer the questions: What will be in the next Official release and when? Will SM be in it? The SM branch has pulled in many other changes (including my C_Derive changes) that I would like to see in the next release. If the SM branch is not going to be the bases for the next release, then we need to look at what change in the SM branch can be pulled in to the release. Martin, I would like to hear your comments. Also do I. I still propose to merge the SM branch into the github:OpenSC-staging and prepare it as candidate for release . It should not be difficult, recently both branches has been synchronized. One more argument is that the alternative CI server should soon be ready for the automatic packaging and later for the automatic testing. It could be useful when preparing new release. Kind regards, Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] How to deal with the gerrit backlog in an effective way?
On Tue, Apr 3, 2012 at 8:36 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Le 3 avril 2012 00:30, Viktor Tarasov viktor.tara...@gmail.com a écrit : Le 02/04/2012 10:01, Ludovic Rousseau a écrit : Le 2 avril 2012 09:56, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : I don't think there is. Here is the address of the secure messaging branch: https://github.com/viktorTarasov/OpenSC-SM/tree/secure-messaging We are using it, as it includes most fixes. Binaries are published in: http://www.opensc-project.org/downloads/nightly/sm/ Why not use Opensc-SM for OpenSC developing branch? The solution is very simple. 1. rebase the SM branch over the OpenSC version in gerrit/staging 2. submit the changes to gerrit 3. review the changes on gerrit (they should be OK) 4. someone (Martin/Viktor/me) will accept the changes in gerrit and they will be merged You do not need extra power for that. It is just normal developer work. How the 'staging', that you are working on, is related to the 'staging' branch of the OpenSC.git from github ? Looking onto the git workflow ( https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy) I do not quite understand the place of 'staging' on the opensc-project.org . The official repository should be on opensc-project.org. github should be a mirror. So, the presented schema of the git workflow is invalid, and you are going to redesign it, isn't it? But gerrit was not working (or I did not know how to use it) so I merged pull request on github, that was a mistake. Then the two repositories diverged in incompatible ways. Maybe OpenSC on github should be deleted and recreated as a copy of opensc-project.org repository. Why to not do the same with the opensc-project.org repository and to recreate it as a copy of github ? This way looks more respective to the number of people who have forked the github OpenSC.git project. It's the opensc-project.org repository could be the mirror of the github's one -- the main development base. Or maybe we can achieve the same result in a soft way and make the 2 repos to converge again. Maybe. If someone will have the time and motivation. Bye Kind regards, Viktor. -- Dr. Ludovic Rousseau ___ 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] How to deal with the gerrit backlog in an effective way?
Le 02/04/2012 10:01, Ludovic Rousseau a écrit : Le 2 avril 2012 09:56, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : I don't think there is. Here is the address of the secure messaging branch: https://github.com/viktorTarasov/OpenSC-SM/tree/secure-messaging We are using it, as it includes most fixes. Binaries are published in: http://www.opensc-project.org/downloads/nightly/sm/ Why not use Opensc-SM for OpenSC developing branch? The solution is very simple. 1. rebase the SM branch over the OpenSC version in gerrit/staging 2. submit the changes to gerrit 3. review the changes on gerrit (they should be OK) 4. someone (Martin/Viktor/me) will accept the changes in gerrit and they will be merged You do not need extra power for that. It is just normal developer work. How the 'staging', that you are working on, is related to the 'staging' branch of the OpenSC.git from github ? Looking onto the git workflow (https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy) I do not quite understand the place of 'staging' on the opensc-project.org . Bye Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Hello, On Wed, Mar 28, 2012 at 11:05 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Gerrit has more than 200 patches still waiting the the backlog. Many of them can't be merge since they do not 'fast-forward' and must be rebased by hand. Since the git commits were created without a Change-Id: we have 3 options (I think): 1. edit each commit message to add the missing Change-Id: and resubmit a rebased patch 2. reject all the patches rebase all the patches resubmit them as new gerrit entries 3. reject all the patches ask for new submission 4. Big part of the patches in backlog comes from SM branch. This branch was recently merged with the public 'staging'. So, my proposition is to: 4a. cherry-pick proposals from 'your staging' that are not related to SM and not yet present in 'public staging' ; 4b. switch the 'public staging' to 'SM' and use it as a principal development base and base for releases; 4c. reset official gerrit to the 'staging' at this moment; 4d. re-submit previously cherry-picked proposals. I did option 1 for some patches. It is very borring and time consuming. Without help (man power) I do plan for option 3. I do not know if a creating a french OpenSC association to deal with the project governance will help here. But people with some free time can surely help move OpenSC. 'French OpenSC association' ? I saw it has been mentioned in the mailing thread but do not understood what for ? The process is simple. Select a patch and go to its oldest unmerged ancestor. Then do: # a. create a merge branch git branch merge # b. go inside local merge branch git checkout merge # c. get cherry-pick a patch from gerrit git fetch ... # d. add Change-Id: git rebase -i HEAD~1 # e. push git push gerrit HEAD:refs/for/staging # f. go inside staging git checkout staging # g. resync git pull The real command for step c. is given at the gerrit interface for a given patch. Example with https://www.opensc-project.org/codereview/#/c/45/ The command is git fetch https://www.opensc-project.org/codereview/p/OpenSC refs/changes/45/45/1 git cherry-pick FETCH_HEAD In step d. the missing Change-Id: line must be added in the commit message. In the git rebase in interactive mode replace pick by reword Then add the Change-Id: given by gerrit. In this case Change-Id: Ifc3b467d8a299897bb7417c8dfd09873f24e46f6 as the last line of the commit message. You can loop on steps c, d, e, c, d, e, ... Any volunteer? -- Dr. Ludovic Rousseau ___ 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] removing libltdl?
Le 24/03/2012 21:55, Magosányi, Árpád a écrit : Could someone tell me what happened with this change in gerrit? I see the messages but do not understand. It has been merged into OpenSC/OpenSC 'staging' https://github.com/OpenSC/OpenSC/commit/df8715849d462e617025427ad96a7708bad24445 On 03/24/2012 07:01 PM, Alon Bar-Lev wrote: On Sat, Mar 24, 2012 at 1:19 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Le 24 mars 2012 12:05, Magosányi, Árpád m4g...@gmail.com a écrit : I guess you might want to discuss the pros and cons of removing libltdl dependency. There is a heap of changesets about it in gerrit. I do not remember why libltdl was needed in the first place. Alon, do you know/remember why libltdl was added? Is it related to OpenSC on Mac OS X 10.5 for PowerPC? I found a reference in [1]. Bye, [1] https://www.opensc-project.org/opensc/changeset/53c3c486af54a60e4ea09bdd7ce936a3b538f420/OpenSC Because at that time it was simpler to port to Windows using libtool. As I wrote in the origin post, currently there are almost none libtool usage. In Gentoo tree OpenSC was the last. I don't know any reason why it should be used. I should have removed it long ago. I already fixed the libp11 in similar manner, there I still can commit. Alon. ___ 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le 17/03/2012 19:13, Jean-Michel Pouré - GOOZE a écrit : Le vendredi 16 mars 2012 à 23:36 +0100, Ludovic Rousseau a écrit : I finally succeeded in rebasing and approving some patched in the backlog. I still do not understand everything. I subscribed to the OpenSC project on gerrit so I should receive a email for any submitted patch. I also added Viktor Tarasov as a member of the Integrators group. Viktor, you should be able to approve patches now. Thanks a lot for your work and adding Viktor in the group. Thanks. Gerrit still has replication problem -- 'staging' of OpenSC/OpenSC.git do not updated by merges of Gerrit's repository. Certainly, gerrit is nice tool to play with, but, without replication it looses much of it's utility. More important, from my point of view, is jenkins. Somebody has to administrate jenkins to extend the existing jobs, create the new ones and include the build of Linux packages in continuous manner. Anybody can do it? I do not have such rights. That's why I still propose to temporarily use the alternatives jenkins gerrit. Both were tested with 'staging' of OpenSC and 'secure-messaging' of OpenSC-SM on Debian, Win32 and Win64. With the graceful cooperation of Jean-Michel this jenkins should include the MacOS and other slaves and to build the linux packages. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Managing the queue line of a compilation farm
Le 16/03/2012 19:29, Jean-Michel Pouré - GOOZE a écrit : For example, in https://opensc.fr/jenkins/ the build on two windows platform depend-on and triggered-by the build on debian. To build under Debian packages, we probably need: https://launchpad.net/jenkins.pbuilder.plugin pbuilder is the Debian chrooted package builder. If you allow us, we may trigger pbuilder on our farm using SSH. The problem with pbuilder is that it runs under root account (or sudo which is the same). So we will probably need to install a fresh server with all Debian and Ubuntu chroots. Builds will auto-sign packages. Priority should be set to zero, just like in Debian backports. Ok. I am guite disapointed by OpenSC-SM naming under Windows. From a user point of view, it should be more explicit and include a readable naming space, like for example name-year-date-32x.msi. Even if this means a single build everyday. You should not be disappointed - the naming policy is open for suggestions. The current one is just the rapid 'working' solution. Can we proceed with Debian stuff? We can cope with all GNU/Linux builds under all platforms including x32, x64 and ARM, providing signed packages and APT/RPMs repositories. Excellent, I will prepare the guidelines for the procedure. Thanks. Kind regards, Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le 17/03/2012 22:03, Peter Stuge a écrit : Viktor Tarasov wrote: I still propose to temporarily use the alternatives jenkins gerrit. It's IMO really stupid to fork anything, regardless if it is code or infrastructure. You are amazedly brief. Could you explain here how can we 'move forward', preferably without appealing to the absent persons and to the non-working services? //Peter ___ 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] OpenSC and gerrit
Le 17/03/2012 22:32, Peter Stuge a écrit : Viktor Tarasov wrote: Could you explain here how can we 'move forward', preferably without appealing to the absent persons and to the non-working services? No, a move forward idea is broken from the start. Be specific. What is it that does not currently work and which is critical for developing perfect commits? I posit nothing. Probably you have not read my mail. - replication in gerrit do not working. Should we manually push the perfect commits from gerrit's repo to staging? (In the github's pull requests the commits are also perfects, almost perfect.) - nobody from the active persons has an admin access to jenkins -- no possibility to extend the current jobs, create the new ones and to build linux packages in continuous manner. For these two points there is no visibility on when they could be resolved. This situation is lasting for months. Personally I would prefer to develop the OpenSC's card middleware, but in the current situation do not see the possibility. That's why I'm spending my time to get knowledge of jenkins and gerrit and to install an alternative way of 'moving forward'. //Peter Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Managing the queue line of a compilation farm
On Fri, Mar 16, 2012 at 2:47 PM, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: Le vendredi 16 mars 2012 à 12:56 +0100, Ludovic Rousseau a écrit : Do you know the OpenSUSE build service [1]? I checked OBS but it does not support all architectures. The reason is simple: OpenSUSE wants to convince that SuSE is the best. Simple old story. But you are right: SuSE job management software seems to be free, so I will test it. From http://popcon.debian.org/ it seems that i386, AMD64 and ARM are the GNU/Linux widely used platforms. We ordered a couple of ARM boards with 1G onboard today. This will allow to provide Debian ARM and Android based systems. If you needs more platforms, let me know. GOOZE really wants to contribute to OpenSC and help. At present, the compilation farm is running, but we don't have a queue management system. If you know one, any generic and opensource solution, let us know. What solution for job queue management is using OpenSC? Not sure that I understand the term 'queue management' but in jenkins you can create a chain of dependent builds/tests/etc, transfer the artifacts from one build to another, ... For example, in https://opensc.fr/jenkins/ the build on two windows platform depend-on and triggered-by the build on debian. In your list you mention Windows: 32 and 64 msi. Will it be cross-compilation? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] gerrit and merge process: Submitted, Merge Pending state
On Tue, Mar 13, 2012 at 6:59 PM, Peter Stuge pe...@stuge.se wrote: Peter Stuge wrote: I made an attempt to kick change 1 loose. Ok, so that worked. It would work fine to repeat this for each change, even if it is a bit labour intensive at least now, to clear the backlog. I've done it also for change 2 now. As you may recall, approving and submitting the change can be done also via ssh: ssh -P 8882 www.opensc-project.org gerrit review $commithash \ --code-review +2 -s I really like this interface to gerrit when patches need no comment but are good to go as-is. The way our Gerrit has been configured it enforces linear submission of commits to the repository, ie. everything must be submitted to the git repo in the same order changes were pushed to gerrit by contributors. This is in itself not a bad thing since it forces contributors to pay attention to changes in the codebase and what commits goes into the repository, but it does slightly raise the bar for less experienced git users. It's not really difficult, but it's one more thing to keep track of; make sure that your commit has the correct parent before you push. From practical experience with gerrit in several projects I tend to prefer the cherry-pick strategy when submitting changes. This means that stuff can be included into the git repository in a different order than was pushed to gerrit. It also means that humans need to pay more attention to not submitting changes in the wrong order when they are interdependent. The current config makes it impossible to do something wrong, but can in some cases create extra work for rebase and review. The cherry-pick merge strategy makes it very easy to do something wrong, but can save extra work with rebasing and reviewing+submitting of updated patch sets. The current config has strong arguments, even if it brings slightly more inconvenience. I actually favor not changing the config, even if we will have to rebase each and every change. Commit 51630a844e8e95e7108cb1966c5f3e21b93a463b is the last common commit for OpenSC/OpenSC.git(staging) and gerrit's repo. (By the way, this commit where not submitted to OpenSC.git by gerrit -- there is no Change-Id in comments) Two last commits merged into the gerrit's repo are not replicated into OpenSC/OpenSC.git. Something wrong with replication configuration? GitHub refuses not ff merges? Have you an access to the gerrit's logs? I would propose to start from zero: - merge the OpenSC-SM branch into OpenSC-staging (or simply switch to -- recently the OpenSC-staging was merged into OpenSC-SM). - pick from the current gerrit's changesets the useful proposals and apply them to this branch. - re-install the Gerit's OpenSC project with the updated github repository. - limit direct commits to github's OpenSC-staging (or replicate these changes to the gerrit's repo on the regular base) - update the list of the Jenkins admins, or install an alternative Jenkins (like this one https://opensc.fr/jenkins/, https://opensc.fr/gerrit/https://opensc.fr/jenkins/-- still under construction), dedicated to the OpenSC-staging and OpenSC-master. It's needed to implement the glaring lack of an actual jenkins -- the build of OpenSC linux packages. //Peter Kind wishes, Viktor. ___ 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] PKCS15 Deauthenticate Function
On Fri, Feb 24, 2012 at 2:04 PM, evalues evalues evalues...@gmail.comwrote:
If I use this command I get the next response: SW1 = 6D and SW2 = 00, and
its meaning is that Instruction code not supported or invalid. There is
anything wrong? Can you explain to my how is the process to deauthenticate.
1. Initialized with OpenSC, this card has both PINs locals -- SoPIN and
UserPIN.
They are defined in the first level DF (5015).
So, in your APDU data the 'level' has to be '1'.
2. The CLA of the APDU has to be 0x80, as for proprietary command:
Your code has to be like this:
sc_format_apdu(card, apdu, SC_APDU_CASE_3_SHORT, 0x28, 0x01, 0x00);
apdu.cla = 0x80;
apdu.le = 0;
...
For me works the manual test with generic variant of 'Athena ASEPCOS'
(reset SoPIN):
OpenSC [3F00/5015] apdu 80:28:01:00:04:00:01:00:01
Thank you
Kind regards,
Viktor.
On Thu, Feb 23, 2012 at 4:00 PM, evalues evalues evalues...@gmail.comwrote:
The code would be as shown bellow:
sc_apdu_t apdu;
const u8 mf_buf[4] = {0x00, 0x00, 0x00, 0x01};
sc_format_apdu(card, apdu, SC_APDU_CASE_3_SHORT, 0x28, 0x01, 0x00);
apdu.le = 0;
apdu.lc = 4;
apdu.data= mf_buf;
apdu.datalen = 4;
apdu.resplen = 0;
r = sc_transmit_apdu(card, apdu);
Thank you.
On Fri, Feb 17, 2012 at 10:37 AM, Viktor Tarasov
viktor.tara...@gmail.com wrote:
On Wed, Feb 8, 2012 at 6:04 PM, evalues evalues evalues...@gmail.comwrote:
Hello,
thanks for your answer. I'm working with Athena smartcard and I have
seen that in the file card-asepcos.c, the function of logout is not
implemented. I have seen in the file card-starcos.c that it have this
function, and I have seen that the function is to send a certain APDU to
the smartcard. I want know if it is possible to do the logout function for
athena smartcard and the APDU that I should use.
Athena card has a proprietary APDU to reset the PIN's 'verified' flag:
Asepcos cards have a Clear Security Status command - it is encoded as
following:
80 28 01 00 Lc data
Where data is 4 bytes: 00, level, MSByte of pin's FID, LSByte of
pin's FID
level is the directory depth of the pin's location - e.g., 0 for a pin
in the MF, 1 for a pin in a DF under the MF, etc.
For example, to clear the status of the pin with FID=1 under the MF, use
the following apdu:
80 28 01 00 04 00 00 00 01
Thank you.
Kind regards,
Viktor.
On Sun, Jan 29, 2012 at 8:08 PM, Viktor Tarasov
viktor.tara...@gmail.com wrote:
Hello,
Le 25/01/2012 11:45, evalues evalues a écrit :
Hello,
I need know if at Opensc (opensc.dll version 0.12.1.0) there is a
pkcs15-function that allows me to deauthenticate on a smart card. For
example, I was looking the source code of this opensc version, and I found
that in the file minidriver.c there is a
function (CardAuthenticatePin) that uses the function
sc_pkcs15_verify_pin for check if the PIN is correct, and if so
authenticate the user on the smartcard. Besides, I was looking the
function
CaredDeauthenticate, but I did not find a pkcs15-funtion for
deauthenticate, does it exist? If it exist, what is?
Not all the cards natively support the 'deauthenticate' function.
There is no such function in the OpenSC pkcs15 API.
In libopensc API there is the sc_logout() one, that calls the card
specific 'logout' handler, if this last one is implemented.
Also, I want know if there is an API of pkcs15-function.
Thank you.
Kind regards,
Viktor.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Le 17/02/2012 17:52, Peter Stuge a écrit : Jean-Michel Pouré - GOOZE wrote: * OpenSC used to have a very flexible approach. OpenSC is NOT kernel.org with thousands of developers and no need for hierarchy. OpenSC is smaller, but I do not agree that there is no need for any kind of hierarchy. Now, please understand that this is not about power hierarchy as in politics, but it is about technical experience with the code and with the problem domain. I am personally familiar with the smart card domain but I haven't spent much time with the OpenSC codebase and therefore I absolutely do not want some patch I create to be included without being reviewed first. The review is criticial. Especially in a codebase like OpenSC, to which I might indeed delegate my legal authority, I want the review to be merciless. Nobody doubts that review in critical. But what shall we do now, how can we 'move forward', if the review/acceptance process is stopped at the Gerrit level and the only person that is capable and has authority to do something is absent for a long time already ? ... * Setting-up a compilation farm is no reason for closing write access to historical developers of OpenSC. I agree, but I don't think one has anything to do with the other, even if they happened at the same time. I guess that anyone who had write access to the repository earlier can get it again if they just send a public ssh key and their prefered username. I agree, compilation farm is extremely useful. But it has to be adapted/configured in accordance with the available human and other resources. There has to be no definitive obstacle for 'moving forward', otherwise this 'compilation farm' stuff loose it's sense of being. We demand more freedom and transparency or this can only lead to endless flamewars. Let's focus on a concrete problem. Have you created a patch which has been peer reviewed and is well understood, but has been rejected by Martin and Ludovic? If yes, let's try to find a solution. If no, you can't really demand more freedom and transparency, because you haven't exercised the freedom to create perfect patches yet. I did review the epass2003 commits when their availability was announced, and I've looked at the entersafe github account again just now. Here is some feedback: There are three branches; ePass2003_1, epass2003 and ep2k3. These names are non-descript. Commit 902e637c is quite long with over 2k lines added for the card driver. That seems much to me. It's infeasible for me as careful programmer but OpenSC internals newbie to review this code. My gut feeling is that much of the code could be factored out. The commits are not very well described in the commit messages. The commits include unrelated changes. The commits include whitespace changes mixed with actual code changes. The following commit undoes some of the unrelated changes in the previous one. This is what was immediately obvious to me just by looking at one and a half commits in one of the branches. The things I point out above are all things which do not belong in a perfect patch, and do not beling in the OpenSC codebase that I want to use. All these things, and probably more!, must be obvious to any other programmer who has looked at the commits. I do not believe that I have some special vision and only I can see these things. It seems to me that the commits have been created without self-review, which is of course the very first thing to do before proposing any change for inclusion. Probably you have a reason -- 'whitespace', 'commit messages', 'undoes unrelated changes', ... But from my point of view: - commit history do not needs to be perfect for the new driver, before it's commited into one of the official branches; - personally, I'm ready to correct myself the limited number of the coding style ot other issues when merging newbie commits, but to not make the 'ping-pong' last for ages; - historically, afais, driver authors where relatively free in coding style, implementation particularities, etc. in the part that concerns it's 'own space' . (It's the module approach, that Nikos Mavrogiannopoulos talking about in his mail in this thread.) Certainly, the 'newbies' have to be 'educated' in the 'right' direction, but the process could not be so rigorous and finally to not block the 'moving forward'. ... //Peter Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Le 19/02/2012 11:23, Peter Stuge a écrit : Viktor Tarasov wrote: Nobody doubts that review in critical. But what shall we do now, how can we 'move forward', if the review/acceptance process is stopped at the Gerrit level and the only person that is capable and has authority to do something is absent for a long time already ? I suggest to iterate over proposed patches until they are perfect. Iterate with who? There is nobody on the other side of the wire. For months the only person that is capable to do/answer something is absent. That way, those who can submit commits in Gerrit (this is the Gerrit term for including a commit into the main repository) will need to spend close to zero time on doing so. Their job becomes so easy that it is a no-op. Then it also gets done quickly and frequently. This must be the goal. I'm completely agree with you, and admire the beauty of your abstract considerations, but what have we do here now, in our current situation -- Jenkins is dead, Gerrit is in mute coma. ... - personally, I'm ready to correct myself the limited number of the coding style ot other issues when merging newbie commits, but to not make the 'ping-pong' last for ages; This is a trade-off. It's fine to do this once or twice for a new developer. It's however quite hopeless when the developer whose work you review consistently makes the same mistakes that you have corrected and possibly even pointed out several times before. It is a waste of time for humans to do such work. Believe me, I have other interesting things to do. But for months I'm looking the way to help to 'move OpenSC forward' and but had no answers -- there is no activity on the other side. Decision to pull the ECDH, the ePass2003 into SM branch is my isolated desperate attempt to 'move forward'. Static analysis of commits, e.g. using checkpatch.pl from Linux possibly with som modifications, can and must be automated. Gerrit is the perfect place to do it. Please, come back to earth -- Gerrit is not actually functional. - historically, afais, driver authors where relatively free in coding style, implementation particularities, etc. in the part that concerns it's 'own space' . I find this problematic since it leads to low reusability. Even just visual style differences are not really helpful. A uniform codebase is more coherent and easier to deal with for everyone involved. The coding style rules do not have to be very many, but having project wide rules is a good thing. Completely on you side. But that's the current state of art. To change something we need more resources. Certainly, the 'newbies' have to be 'educated' in the 'right' direction, but the process could not be so rigorous and finally to not block the 'moving forward'. Until newbies can demonstrate that they have learned the right things they are by definition not moving forward. ... //Peter Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Le 19/02/2012 10:50, Peter Stuge a écrit : Jean-Michel Pouré - GOOZE wrote: 1) The ePass2003 code was reviewed by Viktor and included in his branch. You probably did not know, did not compile, did not test and therefore Viktor's work is ignored. This is appropriate in my opinion, because I do not think that the commits are ready for inclusion in the main OpenSC repository, regardless of the fact that Viktor has included them in his. He needs and deserves write access to OpenSC main GIT to speed up development. I disagree, if he considers the epass2003 commits I looked at to be of acceptable quality. The ePass2003 commit has been re-factored before creating the SM+ePass2003 branch, to make it compatible with the general SM framework and to correct some of the coding style issues. https://github.com/viktorTarasov/OpenSC/commits/include-ePass2003 The reasons is that we need more new features, more beta testers. You disregard the topic of code quality, which I think that is unacceptable in particular for a security related project. Just to remind, the overwhelming part of the ePass2003 commit is concentrated in it's own new module (card driver) . Locking a project to a small number of developers is not good. There is no locking. Please get that idea out of your mind. Everyone can create commits. But as I have tried to give several examples of, obviously not every commit should automatically be included in the main repository - which is in principle what you advocate. IMHO, the way OpenSC used to be organized one year ago was superior, because there was a central repository with all new features. More beta features, more testers, larger market and superior quality. More code = more bugs. This is no longer the case and each developers works in his corner. If that is the case, it is so because the active developers do not communicate with each other. As you've mentioned, communicating is important. Committing to the main repository is never the start of communication, it is what concludes communication. The only collaborative work is what you call peer review. I'm not sure how much review actually happens. So my opinion would be to allow each developer to commit changes to the main GITHUB staging (developing) branch after discussion. Like it used to be the case using SVN. Replace branch with repository and I see no problem. But sharing a sandbox is significantly less convenient than each developer having their own repository/ies, while also exchanging commits with each other. It is perfectly fine for each developer to have one or even more repositories. Please understand that this is the nature of git, and actually the nature of development work. One person has focus on one thing at a time, in their corner. After they finish, it is of course important to do show and tell, get review comments, rework the code, and repeat until consensus. And make sure OpenSC is not only owned by one or two people. This cannot ever happen, we don't agree with this privatization. Who are we ? I don't care if OpenSC has just one committer, as long as code quality is a high, if not the highest, priority. The organization should be like: * 4/5 committers * 10/20 code contributors and developers * 100 beta testers The problem with this organizational diagram is that neither you nor anyone else can magically generate competent developers with lots of spare time. People contribute what they can when they can. You can of course hire developers, but if your recruitment process is strict, so as to find only really competent developers, you will discover quickly that they are quite rare. //Peter ___ 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] PKCS15 Deauthenticate Function
On Wed, Feb 8, 2012 at 6:04 PM, evalues evalues evalues...@gmail.comwrote: Hello, thanks for your answer. I'm working with Athena smartcard and I have seen that in the file card-asepcos.c, the function of logout is not implemented. I have seen in the file card-starcos.c that it have this function, and I have seen that the function is to send a certain APDU to the smartcard. I want know if it is possible to do the logout function for athena smartcard and the APDU that I should use. Athena card has a proprietary APDU to reset the PIN's 'verified' flag: Asepcos cards have a Clear Security Status command - it is encoded as following: 80 28 01 00 Lc data Where data is 4 bytes: 00, level, MSByte of pin's FID, LSByte of pin's FID level is the directory depth of the pin's location - e.g., 0 for a pin in the MF, 1 for a pin in a DF under the MF, etc. For example, to clear the status of the pin with FID=1 under the MF, use the following apdu: 80 28 01 00 04 00 00 00 01 Thank you. Kind regards, Viktor. On Sun, Jan 29, 2012 at 8:08 PM, Viktor Tarasov viktor.tara...@gmail.comwrote: Hello, Le 25/01/2012 11:45, evalues evalues a écrit : Hello, I need know if at Opensc (opensc.dll version 0.12.1.0) there is a pkcs15-function that allows me to deauthenticate on a smart card. For example, I was looking the source code of this opensc version, and I found that in the file minidriver.c there is a function (CardAuthenticatePin) that uses the function sc_pkcs15_verify_pin for check if the PIN is correct, and if so authenticate the user on the smartcard. Besides, I was looking the function CaredDeauthenticate, but I did not find a pkcs15-funtion for deauthenticate, does it exist? If it exist, what is? Not all the cards natively support the 'deauthenticate' function. There is no such function in the OpenSC pkcs15 API. In libopensc API there is the sc_logout() one, that calls the card specific 'logout' handler, if this last one is implemented. Also, I want know if there is an API of pkcs15-function. Thank you. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Le 16/02/2012 22:53, Douglas E. Engert a écrit : On 2/15/2012 5:39 AM, Jean-Michel Pouré - GOOZE wrote: Dear all, I just got in contact with Stef Walter, who is integrating libp11-glue into Gnome and Gnome keyring. He outlines that libp11-glue needs this patch: PKCS#11 module shouldn't fail if mlock doesn't work http://www.opensc-project.org/opensc/ticket/389 This patch and other waiting patches raise the question of OpenSC guidance and the need to have more commiters to OpenSC main GIT. Martin, would you agree to add Viktor as a major OpenSC GIT member with power to apply patches to main GIT trunk? I don't want to be paranoid, but we need a more flexible approach rather than just Martin and Ludovic applying and reviewing patches. We discussed that at FOSDEM in a small audience, but I would like to discuss that issue in public and have your own opinion. Who would like OpenSC GITHUB to be REALLY in control of the community? Martin and Ludovic, could you agree to open your group to other members of the community? The question is not so much who is on the commiter list, but do commits get made when needed, and who decides a commit is ready and should be made. There are minor fixes, like 389 that is 4 months old with an additional fix 2 months ago, and looks like it needs to be made, as well as major changes such as the SM, ePass2003, and the ECDH modifications. Personally, I am quite interested in getting the ECDH in to the next release with or without the SM code and am willing to rebase the modifications as needed. I believe the ECDH has been ready for months. Viktor pulled the ECDH modifications into his SM on October 4, 2011 and he also pulled in the ePass2003 on January 29. The way forward is not necessarily more commiters, but a plan for the next release and some action. As I understand the current policy, the patch acceptance policy is resumed in: - fixes for crying bugs go to 'master'; - little fixes, evident limited patch goes to 'staged'; - more consequent proposals pass to Gerrit and here waits for approval to be applied to 'staged'. Current problem is that the process is stagnated on the Gerrit level. For some obscure reasons Martin do not participates in Gerrit review/acceptance procedures, as well as Ludovic. Nobody else have sufficient authority to do it. Martin has pushed to Gerrit part of SM branch. What are the intentions for the rests? What about next release? What should be included into? How can be tested the compatibility of different proposals? Personally I do not look for additional rights, as Douglas, I'm interested in some action and ready to help to move the things forward. And so, would like to have this possibility. Also Jenkins is dead for some time already. What shall we do? Wait? Mount temporary service of limited volume -- at least for OpenSC/'staged' and few other branches ? So can we consider adding ePass2003, SM, and ECDH to the next release as these are already being tested together. If giving Viktor commit authority would speed up the inclusion of both small and larger modifications, it would be OK with me. If we can get these included without giving him commit authority, that would be OK with me too. But we need action. Community, please advice and discuss this issue. Kind regards, Jean-Michel ___ 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] PKCS15 Deauthenticate Function
Hello, Le 25/01/2012 11:45, evalues evalues a écrit : Hello, I need know if at Opensc (opensc.dll version 0.12.1.0) there is a pkcs15-function that allows me to deauthenticate on a smart card. For example, I was looking the source code of this opensc version, and I found that in the file minidriver.c there is a function (CardAuthenticatePin) that uses the function sc_pkcs15_verify_pin for check if the PIN is correct, and if so authenticate the user on the smartcard. Besides, I was looking the function CaredDeauthenticate, but I did not find a pkcs15-funtion for deauthenticate, does it exist? If it exist, what is? Not all the cards natively support the 'deauthenticate' function. There is no such function in the OpenSC pkcs15 API. In libopensc API there is the sc_logout() one, that calls the card specific 'logout' handler, if this last one is implemented. Also, I want know if there is an API of pkcs15-function. Thank you. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Call for review of the ePass2003 driver
Hello Jean-Michel. On Fri, Dec 16, 2011 at 6:35 PM, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: Dear Friends, Just a quick note that the ePass2003 is now available from GOOZE: http://www.gooze.eu/epass-2003 ... We would be happy to hear from you and integrate the epass2003 driver into OpenSC core source code. I started the merge of ePass2003 support into my SM branche: https://github.com/viktorTarasov/OpenSC/tree/include-ePass2003 For a while I've tested it with opensc-explorer and with importing of PKCS#12. I invite you to look into. Will you agree with the changes of SM API ? https://github.com/viktorTarasov/OpenSC/commit/1922e1bf38344f5e4491601a783047655c34faf7 https://github.com/viktorTarasov/OpenSC/commit/24776a365156a47e7754a3207334eb2a517d20e3 There are still some cosmetic changes to be made, like using of short logs form, coding style, ... Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OFF: defunct opensc-user
Hello, Le 21/01/2012 13:30, Gergely Buday a écrit : I wanted to ask questions on opensc-user but the mailing list page said that it was inactive. Should I post my questions here? Ask your question here. - Gergely Kind regards, Viktor. ___ 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] proving a key is on a smart card
On Thu, Jan 19, 2012 at 7:25 PM, Frank Cusack fr...@linetwo.net wrote: On Thu, Jan 19, 2012 at 2:27 AM, Viktor Tarasov viktor.tara...@gmail.comwrote: On Thu, Jan 19, 2012 at 9:52 AM, Frank Cusack fr...@linetwo.net wrote: On Wed, Jan 18, 2012 at 11:57 PM, Viktor Tarasov viktor.tara...@gmail.com wrote: On Thu, Jan 19, 2012 at 8:30 AM, Frank Cusack fr...@linetwo.netwrote: On Wed, Jan 18, 2012 at 11:04 PM, Christian Hohnstaedt christ...@hohnstaedt.de wrote: On Wed, Jan 18, 2012 at 04:20:05PM -0800, Frank Cusack wrote: In a CSR, how is it proven that the key resides on a smart card (and is not exportable)? In my understanding, the CSR is signed by the private key of the (to be) cert itself. Thus that signature only proves that the requester actually possesses the private half, not that the private key resides on a smart card. Looking at the cryptoflex command set, I don't see anything there that would add something to the CSR asserting that the key was generated on-card. Same for ISO 7816-8, but I could easily be missing something. You're probably missing the fact that noone stops the owner of a software key to add the same information to the CSR. Not if there's an APDU that adds that information as part of the operation, and the key used in that operation cannot be used except for CSR generation. If the generate/import key operations are protected by secure-messaging, then the 'ticket' will be included into the successful APDU's response. This 'ticket' can be checked by caller to be sure that key was really injected/generated by card. You're missing the point. Of course the caller can know if the key was really generated on card, but the CA cannot know that. Secure messaging can be established in asymmetric mode, using the CA certificate trusted by card. I don't think that's enough? It doesn't matter if the card trusts the CA, it's that the CA has to trust the card. Difficult to do more with the common cards. Possible solution could be organisational : - OpCA dedicated only for mutual authentication between the cards and enrollment/other entities; - OpCA certificate is not widely published and is only known by the upper actors. (like symmetric keys for symmetric SM.) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Getting an OpenSC initialized CardOS card to work in Windows 7 x64
Le 12/01/2012 15:00, LinuxChuck a écrit : Are there any event logs or debug logs I should try to gather to determine the cause of this error? Look for the file c:\tmp\md.log . This path is hard encoded into the MSI that I've sent you. Set also the debug settings in opensc.conf -- debug = 8; and debug_file = c:\...;. Thanks Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC GIT organization members
Hello, Le 09/01/2012 14:02, Ludovic Rousseau a écrit : Le 9 janvier 2012 13:51, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : Le dimanche 08 janvier 2012 à 14:51 +0100, Jean-Michel Pouré - GOOZE a écrit : Now, from OpenSC main page on GITHUB [1] it is written that organization members are Martin and Ludovic. Does it mean that only Martin and Ludovic can accept and commit changes to main tree? To be more precise, could Alon and Viktor and make other candidates also become official members of the OpenSC organization [1] on GIT hub: https://github.com/OpenSC This is quite ridiculous to believe that OpenSC could belong to two developers only: Martin and Ludovic. What is your opinion? Can we discuss that? I am new to gerrit and github. So I am not sure what to do and try to be cautious. I see the Pull request from entersafe at [1]. I also see two comments from ViktorTarasov. Do entersafe plan to update the code as suggested by Viktor? It seems that only Martin can enlighten situation. Le 08/12/2011 20:32, Martin Paljak a écrit : * Github.com pull requests are automagically sent to Gerrit (polled every 5 minutes). This is a convenience method to get pull requests to a central location [1] [2], direct pushing to Gerrit's refs/for/staging should be preferred. So, direct pushing to Gerrit is preferred. Afaiu, Martin have selectively pushed part of SM branch to the Gerrit's 'staging' from his own local repository, where he had merged SM branch into OpenSC branch. My attempt to push the rest from my own local branch was unsuccessful. Suppose I do not have sufficient permissions. Would be nice if Martin, or other administrator, push to Gerrit the rest of SM branch or delegate to someone else the wider permissions . From my point of view, the actual validation system is certainly nice and attractive, but not in relation with the available resources to do the necessary work. The validation process is inactive during certain time already. There are two Gerrit administrators -- one of them is off-line, second is new to Gerrit . I agree with Jean-Michel -- Gerrit has to be more reactive and, if necessary, more people be involved into the validation process. For me it's not clear, with such stagnated Gerrit, how can we 'move forward', check/test compatibility of the different proposals and finally prepare common OpenSC 'staging' to test. Bye [1] https://github.com/OpenSC/OpenSC/pull/12 Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC GIT organization members
Hello, Le 09/01/2012 14:02, Ludovic Rousseau a écrit : Le 9 janvier 2012 13:51, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : Le dimanche 08 janvier 2012 à 14:51 +0100, Jean-Michel Pouré - GOOZE a écrit : Now, from OpenSC main page on GITHUB [1] it is written that organization members are Martin and Ludovic. Does it mean that only Martin and Ludovic can accept and commit changes to main tree? To be more precise, could Alon and Viktor and make other candidates also become official members of the OpenSC organization [1] on GIT hub: https://github.com/OpenSC This is quite ridiculous to believe that OpenSC could belong to two developers only: Martin and Ludovic. What is your opinion? Can we discuss that? I am new to gerrit and github. So I am not sure what to do and try to be cautious. I see the Pull request from entersafe at [1]. I also see two comments from ViktorTarasov. Do entersafe plan to update the code as suggested by Viktor? It seems that only Martin can enlighten situation. Le 08/12/2011 20:32, Martin Paljak a écrit : * Github.com pull requests are automagically sent to Gerrit (polled every 5 minutes). This is a convenience method to get pull requests to a central location [1] [2], direct pushing to Gerrit's refs/for/staging should be preferred. So, direct pushing to Gerrit is preferred. Afaiu, Martin have selectively pushed part of SM branch to the Gerrit's 'staging' from his own local repository, where he had merged SM branch into OpenSC branch. My attempt to push the rest from my own local branch was unsuccessful. Suppose I do not have sufficient permissions. Would be nice if Martin, or other administrator, push to Gerrit the rest of SM branch or delegate to someone else the wider permissions . From my point of view, the actual validation system is certainly nice and attractive, but not in relation with the available resources to do the necessary work. The validation process is inactive during certain time already. There are two Gerrit administrators -- one of them is off-line, second is new to Gerrit . I agree with Jean-Michel -- Gerrit has to be more reactive and, if necessary, more people be involved into the validation process. For me it's not clear, with such stagnated Gerrit, how can we 'move forward', check/test compatibility of the different proposals and finally prepare common OpenSC 'staging' to test. Bye [1] https://github.com/OpenSC/OpenSC/pull/12 Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch: AT_SIGNATURE/AT_KEYEXCHANGE issues with minidriver
Le 04/01/2012 17:07, Viktor Tarasov a écrit : Le 04/01/2012 16:38, Hunter William a écrit : Secondly, I can't see the purpose of allowing one key to be available both as an AT_SIGNATURE and as an AT_KEYEXCHANGE key. In fact, in my testing, if this is done, only signatures work, decryption fails. I encountered the same problem with the double key usage: CryptGetUserKey(..., AT_KEYEXCHANGE, ...) returns the key handle, but the following CryptDecrypt(...) returns NTE_BAD_KEY; Big temptation to suggest the bug of CSP, but the 'certutil -SCinfo' seems working properly. Anyway, I rolled it back to you original idea. https://github.com/viktorTarasov/OpenSC/commit/4c532adf52f4b2e5d199b91c69ac174ae93226ca Thanks, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch: parsing prKDF - linking PIN to Private Key
Le 04/01/2012 15:30, Viktor Tarasov a écrit : Le 04/01/2012 11:30, Hunter William a écrit : My first suggestion is to set authId when parsing the contents of PrKDF. Ok, for now that should work fine, although longer term a better solution may be needed. Note that the AuthID may also be specified in terms of a security environment, which makes things a lot more complicated... It's probably best not to worry about that for now. (Would have to go from the AuthReference - SE info - PIN reference - EF.AOD - AuthID - it's a bit circular!) Agree -- not to worry for a while. Take also into consideration that for OpenSC pkcs#15 framework, as the base library for pkcs#11 and minidriver, it's only important the protection by 'PIN' authentication object . Other types (SM, Auth.Extern) are not used by pkcs#15 and upper levels (parsed, but not used). As it currently implemented, these types of protections are resolved at the libopensc level. I'll try and make the change for the parsing of the PrKDF. Fine. Cheers, Will Kind wishes, Viktor. As discussed (see above), attached is a patch which sets the authID for a private key from the accessControlRules in the case where authID is not present, but a corresponding accessControlRule is. Fine, thanks, I will apply it. Applied with some cosmetic changes, thanks. https://github.com/viktorTarasov/OpenSC/commit/593159abbf4e0ba0692d1c1d40ae090c7fa3db32 In theory a better longer term solution is necessary (there may be different PIN's per key operation), but in practice it may never be. Cheers, Will ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
