From evalues.es at gmail.com Wed Feb 8 17:04:18 2012 From: evalues.es at gmail.com (evalues evalues) Date: Wed, 8 Feb 2012 18:04:18 +0100 Subject: [opensc-devel] PKCS15 Deauthenticate Function In-Reply-To: <4F259920.4070308@googlemail.com> References: <4F259920.4070308@googlemail.com> Message-ID: 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. Thank you. On Sun, Jan 29, 2012 at 8:08 PM, Viktor Tarasov 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120208/fcfd6c07/attachment.html From jmpoure at gooze.eu Wed Feb 15 11:39:01 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Wed, 15 Feb 2012 12:39:01 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion Message-ID: <1329305941.3393.44.camel@acer> 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? Community, please advice and discuss this issue. Kind regards, Jean-Michel -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120215/6849332d/attachment.bin From deengert at anl.gov Thu Feb 16 21:53:04 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 16 Feb 2012 15:53:04 -0600 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <1329305941.3393.44.camel@acer> References: <1329305941.3393.44.camel@acer> Message-ID: <4F3D7AC0.1030405@anl.gov> 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. 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 at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From alon.barlev at gmail.com Thu Feb 16 22:04:46 2012 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 17 Feb 2012 00:04:46 +0200 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F3D7AC0.1030405@anl.gov> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> Message-ID: Hello, On Thu, Feb 16, 2012 at 11:53 PM, Douglas E. Engert wrote: > The way forward is not necessarily more commiters, but a plan > for the next release and some action. Well, once there was maintainer for each subject, so if maintainer of (in this case) ePass2003 decides to put a specific implementation it should be OK. If another one is working on SM and it effects only specific drivers, why not? For example, I don't think I need to beg to include the removal of the libltdl dependency should be trivial even if I got this only 99%. This project loses its flexibility, this is not an advantage. You can decide which feature goes to which milestone, and cooperate with people within different branches. Alon. From peter at stuge.se Fri Feb 17 01:07:49 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 17 Feb 2012 02:07:49 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> Message-ID: <20120217010749.12454.qmail@stuge.se> Alon Bar-Lev wrote: > This project loses its flexibility, this is not an advantage. I disagree. I find that Git allows all the flexibility developers could ask for. The cry for more committers is misguided. With Git, anyone and everyone is a committer. If commits exist but are not being included in the main repository then it is most likely because they need more work. The effort required to include a perfect patch is next to zero. The question is if a project will insist on perfect patches (e.g. Linux) or if anyone should be allowed to commit anything to the main repo. Inkscape apparently did the latter, and it resulted in a massive janitorial workload to clean up the horrible mess that had been created. No fun. Consider also that addition of commits without review will quite likely introduce bugs which would have been discovered by peers. I think this fact alone is reason enough for OpenSC to not include a single line which hasn't been reviewed rather thoroughly. The review process could even be formalized and made into a strict requirement before writes to the main repo are possible. I understand that Gooze and others have strong interest in inclusion of changes into OpenSC. The only way to make that happen is what Douglas described; put in the work, and create perfect patches. Write access to some repository is not the issue. The whole world already has Git write access. If someone needs help with publishing a repository then feel free to let me know. If you have prepared a patch which you think is perfect but noone is responding then give it a thorough review yourself, and try again. Also try discussing the change, explaining it in an email can be a great way to produce a better commit message, which is very important for anyone who is doing review. Note that review does not mean to browse through the change and say "looks ok", but it means to understand the effects of every changed line. This can require a lot of context and/or research. You can help by that commit be included by doing review. You doing review is infinitely more important than you having write access to some repository. //Peter From jmpoure at gooze.eu Fri Feb 17 09:37:05 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Fri, 17 Feb 2012 10:37:05 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120217010749.12454.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> Message-ID: <1329471425.3883.15.camel@acer> Le vendredi 17 f?vrier 2012 ? 02:07 +0100, Peter Stuge a ?crit : > The cry for more committers is misguided. With Git, anyone and > everyone is a committer. If commits exist but are not being included > in the main repository then it is most likely because they need more > work. The effort required to include a perfect patch is next to zero. The question here is flexibility: * OpenSC used to have a very flexible approach. OpenSC is NOT kernel.org with thousands of developers and no need for hierarchy. * Setting-up a compilation farm is no reason for closing write access to historical developers of OpenSC. * Discussions are the base of Free Software. Once discussions have occurred, there should be several people with write access. You have to trust people. No need to lock write access to the main GIT. From my point of view, OpenSC is becoming a semi-private project with two people in charge: Ludovic and Martin. Personally, I don't want OpenSC to be organized the same way as libccid. We demand more freedom and transparency or this can only lead to endless flamewars. Keep in mind that before doing business, I have been a politician fighting during 4 years for more freedom. Now I am retired, but if need be, we will create a charity for OpenSC and organize a duly elected board. I am not talking about a fork, which will never happen, but about elections. Kind regards, -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120217/569f4160/attachment.bin From viktor.tarasov at gmail.com Fri Feb 17 09:37:26 2012 From: viktor.tarasov at gmail.com (Viktor Tarasov) Date: Fri, 17 Feb 2012 10:37:26 +0100 Subject: [opensc-devel] PKCS15 Deauthenticate Function In-Reply-To: References: <4F259920.4070308@googlemail.com> Message-ID: On Wed, Feb 8, 2012 at 6:04 PM, evalues evalues wrote: > 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 > Where is 4 bytes: 00, , , > 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 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120217/db094eca/attachment-0001.htm From peter at stuge.se Fri Feb 17 16:52:19 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 17 Feb 2012 17:52:19 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <1329471425.3883.15.camel@acer> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> Message-ID: <20120217165219.23449.qmail@stuge.se> Jean-Michel Pour? - GOOZE wrote: > > With Git, anyone and everyone is a committer. > > The question here is flexibility: What flexibility is needed? My point is that everyone can easily create perfect patches, and given perfect patches which have been peer reviewed there is no need for flexibility as in lots of people with write access to the main repository. Even just one person can easily handle that effort, like Linus shows in the much larger kernel project. > * 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. Don't make the mistake of believing that only people with write access can do review. It is quite the opposite. I have been trying to make this point many times before, but it seems difficult for many to grasp that all peer review is helpful and important for the codebase, regardless of who is doing it. Everyone who cares about a software can and should help with review. A side effect of doing review is of course that knowledge about the codebase increases in the community. After having done some amount of review, people might even get write access, because they have demonstrated that they can be trusted. This is demonstrated by finding difficult-to-spot problems in others' patches. It is not demonstrated by quickly giving every patch a thumbs-up. Some say that it feels pointless to do review for someone who does not have write access. I disagree with this, and I think this is a very dangerous, almost complacent, attitude. If you do not believe that your review is worth anything to those with write access, why should you yourself have write access? This becomes a negative spiral where in the end a project has no resources to do review, simply because people do not have enough self-esteem to believe that the review they can contribute matters. I don't know what the answer is. I've tried time and time again to convince people that doing review is helpful and important and a significant contribution to any project, but it often doesn't really stick. > * 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. > * Discussions are the base of Free Software. Once discussions have > occurred, there should be several people with write access. You > have to trust people. No need to lock write access to the main GIT. I disagree about having to trust people out of the blue. Generally, people write really shitty software, and the poor way that a lot of open source software works is all the proof we need. I love open source, not neccessarily because it is technically superior, but because it allows *me* to fix things which are broken. I believe that open source is as good as it is primarily thanks to the practise of peer review. The purpose of more write access as far as I can see is to have faster, ie. less well reviewed and thus less well understood, changes in the main repo. I do not agree at all with that goal. > From my point of view, OpenSC is becoming a semi-private project > with two people in charge: Ludovic and Martin. Personally, I don't > want OpenSC to be organized the same way as libccid. I find both Martin and Ludovic to be quite reasonable people. I've never had any problem discussing any issue with them, actually quite the opposite. If there are perfect patches (well reviewed, well understood) then I am convinced that they would race each other to add those patches into the repository. I have no experience from libccid development, but I'm happy with it as a user, so Ludovic must be doing something right. > 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. > Keep in mind that before doing business, I have been a politician > fighting during 4 years for more freedom. I did not know - that is quite commendable! Thank you for working on making the world a better place! Keep in mind that open source is not a democracy. > Now I am retired, but if need be, we will create a charity for > OpenSC and organize a duly elected board. I am not talking about > a fork, which will never happen, but about elections. But elections do not increase code quality. I think software quality is more important than flat democracy. The meritocracy that is open source *is* a hierarchy. I don't think this is bad. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120217/c7c2f7f8/attachment.pgp From jmpoure at gooze.eu Fri Feb 17 21:58:47 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Fri, 17 Feb 2012 22:58:47 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120217165219.23449.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> Message-ID: <1329515927.4197.28.camel@acer> Dear Peter, Thank you for your time. In organization theory, there is no perfect solution. There are several ways to achieve success. Let us take two examples to see how OpenSC can be improved: 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. He needs and deserves write access to OpenSC main GIT to speed up development. The reasons is that we need more new features, more beta testers. 2) Take the example of Alon developments around PKCS#11. A lot of them were ignored by OpenSSH. The reason is that when a small number of people have a grasp on a project, strange things sometimes happen. I would not like this to happen with OpenSC. Locking a project to a small number of developers is not good. 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. This is no longer the case and each developers works in his corner. The only collaborative work is what you call "peer review". 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. And make sure OpenSC is not only owned by one or two people. This cannot ever happen, we don't agree with this privatization. The organization should be like: * 4/5 committers * 10/20 code contributors and developers * 100 beta testers Kind regards, Jean-Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120217/b2588210/attachment.bin From nmav at gnutls.org Fri Feb 17 22:56:12 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 17 Feb 2012 23:56:12 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <1329515927.4197.28.camel@acer> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <1329515927.4197.28.camel@acer> Message-ID: <4F3EDB0C.3070107@gnutls.org> On 02/17/2012 10:58 PM, Jean-Michel Pour? - GOOZE wrote: > Let us take two examples to see how OpenSC can be improved: 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. He needs and deserves write access to > OpenSC main GIT to speed up development. The reasons is that we need > more new features, more beta testers. [disclaimer I'm not experienced with opensc internals and comment might be wrong] This sounds pretty similar to the situation in hardware drivers which often evolve faster than the linux kernel's pace. It might be better to have a module approach for such development so that cutting edge drivers can be used with opensc without recompilation or waiting for a new opensc release. I don't know though, whether the size of the projectjustifies something like that. > 2) Take the example of Alon developments around PKCS#11. A lot of > them were ignored by OpenSSH. The reason is that when a small number > of people have a grasp on a project, strange things sometimes happen. > I would not like this to happen with OpenSC. Locking a project to a > small number of developers is not good. In cases it might be good. We rejected Alon's PKCS #11 patches on gnutls as well. You can say it was the wrong decision or so, but in the end of day the few developers responsible for the project will have to maintain it. If it is code they cannot maintain, or does not agree with the longer term plans of the project maybe the feature should be postponed. regards, Nikos From viktor.tarasov at gmail.com Sat Feb 18 03:59:34 2012 From: viktor.tarasov at gmail.com (Viktor Tarasov) Date: Sat, 18 Feb 2012 04:59:34 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F3D7AC0.1030405@anl.gov> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> Message-ID: <4F3F2226.8010603@googlemail.com> 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 at lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel From ludovic.rousseau at gmail.com Sat Feb 18 18:03:20 2012 From: ludovic.rousseau at gmail.com (Ludovic Rousseau) Date: Sat, 18 Feb 2012 19:03:20 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F3F2226.8010603@googlemail.com> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <4F3F2226.8010603@googlemail.com> Message-ID: Le 18 f?vrier 2012 04:59, Viktor Tarasov a ?crit : > 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. I don't know why only Martin and myself are integrators on Gerrit. I reviewed some patches but don't know what to do next. It looks like the patches are not moved to github/staging. Maybe a configuration problem? Note: this is my first use of Gerrit. > 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. Exact. I did not noticed. > What shall we do? > Wait? Mount temporary service of limited volume -- at least for OpenSC/'staged' and few other branches ? Martin, what do you plan to do? Regards, -- ?Dr. Ludovic Rousseau From jmpoure at gooze.eu Sun Feb 19 08:36:23 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Sun, 19 Feb 2012 09:36:23 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F3F2226.8010603@googlemail.com> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <4F3F2226.8010603@googlemail.com> Message-ID: <1329640583.4534.2.camel@acer> Dear all, > 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'. This seems relevant and superior to the previous SVN process. > 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. From Gerrit webpage: "Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer." YES, this is what is needed. -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/18b49a69/attachment.bin From peter at stuge.se Sun Feb 19 09:50:39 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 10:50:39 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <1329515927.4197.28.camel@acer> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <1329515927.4197.28.camel@acer> Message-ID: <20120219095039.20102.qmail@stuge.se> 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 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. > 2) Take the example of Alon developments around PKCS#11. A lot of them > were ignored by OpenSSH. The reason is that when a small number of > people have a grasp on a project, strange things sometimes happen. What? The reason is that, as you may know, OpenSSH is developed in the OpenBSD project, and their plans for PKCS#11 did not align with Alon's plans for OpenSSH PKCS#11 outside OpenBSD. > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/5c8ff530/attachment.pgp From viktor.tarasov at gmail.com Sun Feb 19 10:01:08 2012 From: viktor.tarasov at gmail.com (Viktor Tarasov) Date: Sun, 19 Feb 2012 11:01:08 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120217165219.23449.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> Message-ID: <4F40C864.7090708@googlemail.com> 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. From peter at stuge.se Sun Feb 19 10:23:37 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 11:23:37 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F40C864.7090708@googlemail.com> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> Message-ID: <20120219102337.22688.qmail@stuge.se> 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. 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. > 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; Work in progress will always exist. Beta testing of work in progress is good and important, and Git makes this extremely easy. Anyone in the world can publish their work in progress. Proposing a commit for inclusion in the main repo is something quite different. Whenever something is pushed to Gerrit it must indeed be perfect, or it is just some lazy or sloppy developer wasting the time of others. I think we are all busy and want to avoid wasted time. > - 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. 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. > - 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. > 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 From anders.rundgren at telia.com Sun Feb 19 10:41:44 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Sun, 19 Feb 2012 11:41:44 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120219102337.22688.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> Message-ID: <4F40D1E8.7080006@telia.com> IMO the core problem with OpenSC is a that all cards seem to require a tweak, profile or similar. For government IDs which are driven by politics rather than reason there is no problem to solve; the governments simply have to pay the price for demanding "uniqueness". For non-government tokens like the excellent Feitian Epass2003 I would consider another approach: Updating the firmware to emulate PIV so that we can put the middleware aside once and for all. That is, HW vendors should qualify their products against middleware rather than running never-ending projects that only creates frustration and exuberant costs. Anders From peter at stuge.se Sun Feb 19 10:46:46 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 11:46:46 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F40D1E8.7080006@telia.com> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D1E8.7080006@telia.com> Message-ID: <20120219104646.24362.qmail@stuge.se> Anders Rundgren wrote: > For non-government tokens like the excellent Feitian Epass2003 > I would consider another approach: Updating the firmware to > emulate PIV so that we can put the middleware aside once and > for all. I agree completely that all the legacy involved in tokens and cards is horrendous waste of engineering resources, time and life. I'm excited about the gnuk project, it's a nice platform to play with the PKCS#11 over USB idea, which I refuse to give up on before having attempted to implement it and failed. :) //Peter From jmpoure at gooze.eu Sun Feb 19 10:50:13 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Sun, 19 Feb 2012 11:50:13 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120219102337.22688.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> Message-ID: <1329648613.3601.5.camel@acer> > Until newbies can demonstrate that they have learned the right things > they are by definition not moving forward. Come-on, we are not in a class-room or in an administration. We all agree that Gerrit is the solution. So let's make it work and open accounts for recognized developers to make sure simple patches are committed. If this is not done within a reasonable time frame, I will create a Charity under French law open to everyone and we will have elections. Kind regards, -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/f55f4312/attachment.bin From viktor.tarasov at gmail.com Sun Feb 19 11:14:57 2012 From: viktor.tarasov at gmail.com (Viktor Tarasov) Date: Sun, 19 Feb 2012 12:14:57 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120219102337.22688.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> Message-ID: <4F40D9B1.1070507@googlemail.com> 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. From viktor.tarasov at gmail.com Sun Feb 19 11:18:16 2012 From: viktor.tarasov at gmail.com (Viktor Tarasov) Date: Sun, 19 Feb 2012 12:18:16 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120219095039.20102.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <1329515927.4197.28.camel@acer> <20120219095039.20102.qmail@stuge.se> Message-ID: <4F40DA78.1050203@googlemail.com> 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 at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel From peter at stuge.se Sun Feb 19 11:27:45 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 12:27:45 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <1329648613.3601.5.camel@acer> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <1329648613.3601.5.camel@acer> Message-ID: <20120219112745.27288.qmail@stuge.se> Jean-Michel Pour? - GOOZE wrote: > > Until newbies can demonstrate that they have learned the right things > > they are by definition not moving forward. > > Come-on, we are not in a class-room or in an administration. We are also not in a democracy. We are in a security related open source project. > We all agree that Gerrit is the solution. So let's make it work and > open accounts for recognized developers to make sure simple patches > are committed. Everyone can register an account, which then allows to push commits into Gerrit, and to comment on and perform +1/-1 review of other commits. An OpenID is neccessary. If someone does not have an OpenID and would like me to provide one, feel free to send me your prefered username, md5(yourpassword) and your full name and email address, and I will create an identity for you on my OpenID provider. You then add two tags to any web page that you control, and the URL of that web page is your OpenID identifier. Note that many sites such as SourceForge, Google, Yahoo, etc. already have OpenID providers, so if you have an account there you can look around to find your OpenID identifier, which you then use to register with Gerrit. > If this is not done within a reasonable time frame, I will create a > Charity under French law open to everyone and we will have elections. Create as many charities as you like, I don't think it will make any difference. Working on code is unrelated to holding elections. I suggest that those who want to contribute to OpenSC start flooding Gerrit with perfect patches that are so obviously perfect and that are approved by so many contributors that they require nearly zero attention from Martin and Ludovic, and thus can be submitted (again, the Gerrit term for including in the main repo) very quickly. The only alternative to that is IMO for those who want to do development with a different goal and/or a different method than Martin and Ludovic to create a fork. Actually this is already what happens when using Git. Every repository is already a fork. Forking isn't neccessarily bad, but keep in mind that you will have to work very hard to be able to replace the de-facto standard. It will be significantly easier to focus on working with the existing project, on the terms of the existing project. Whenever a fork is created, it is important to decide right at the start what the purpose will be. If the purpose is to get changes back into the original codebase then it is obviously critical to follow the procedures and practises of that codebase, otherwise the effort will be wasted, since the forked codebase is unmergeable. Maybe someone wants to spend time fixing it up. This is very painful, and a complete waste of time. The alternative is to go full steam ahead and decide to never look back. Only with this attitude does it really make sense to fork. You already indicated that you don't really want to fork, so I guess your choice is made. This is all politics. Let's disregard the politics. That leaves code. It is impossible to argue against a perfect patch. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/a6b9bcbb/attachment.pgp From jmpoure at gooze.eu Sun Feb 19 11:50:34 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Sun, 19 Feb 2012 12:50:34 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120219112745.27288.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <1329648613.3601.5.camel@acer> <20120219112745.27288.qmail@stuge.se> Message-ID: <1329652234.3601.21.camel@acer> > We are also not in a democracy. We are in a security related open > source project. Don't get me wrong. This is an organization issue. I am not talking about forking OpenSC, this would be stupid. The website, teams and tools should remain. But we need a simplier and more effective approach. Remember that under European law, all contributors hold a copyright on OpenSC code. The leader is not the copyright holder. When nothing happens in a project, we have the right to change leadership. Holding elections will allow to decide how to organize the project. IMHO, a reasonable timeframe to fix organization issues should be around one month. We are today 19th February 2012. If within a month all these issues are not fixed, I will incorporate a Charity with other OpenSC members and call for elections of a board. Kind regards, -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/bd4adaa8/attachment.bin From peter at stuge.se Sun Feb 19 12:06:45 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 13:06:45 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F40D9B1.1070507@googlemail.com> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> Message-ID: <20120219120645.30071.qmail@stuge.se> 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. Martin is not the only person who you can talk to about code. Try asking the mailing list, and if that fails it is always possible to do self-review and iterate locally. > > 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. Jenkins may have a problem, but Gerrit looks like it is functioning fine, at least now. It is trying to merge commits which have been pushed, reviewed and submitted for merge, but where the commits have been pushed with dependencies, and where the dependencies have not yet been reviewed and submitted for merge. Here is where perfect patches make all the difference. The dependency looks wrong, and if there was no dependency, the commit would already have been included in the repository. Granted, Gerrit was introduced recently and will take a little getting used to, for people to learn the ins and outs. But in the end it is an incredibly helpful tool. > Believe me, I have other interesting things to do. Yes, I believe you. :) > 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. I think everyone is on the same side. > Decision to pull the ECDH, the ePass2003 into SM branch is my > isolated desperate attempt to 'move forward'. :) Well, maybe nothing desperate is neccessary. Ludovic can submit commits in Gerrit to the main repository, so work on making the commits in Gerrit trivial for him to submit. I believe he will do it quickly. One very nice thing about Gerrit is that anyone can push an improved version of anyone else's work. In order to not make a mess, it is important to preserve the Change-Id inside the commit message, but everything else can change, both the rest of the commit message and the contents and the history of the commit. So for example: https://www.opensc-project.org/codereview/#change,7 has status Submitted, Merge Pending Ludovic has approved and submitted this change. Gerrit tries to include it, but a dependency is missing. Change 7 has one dependency: https://www.opensc-project.org/codereview/#change,6 which has been verified by Jenkins, but not reviewed and submitted by Ludovic. This change has no further dependencies. There are two ways to move forward on change 7: 1. Ludovic can review and submit change 6 for merge, which will then also make change 7 get included in the repository. 2. Anyone with a Gerrit account can fetch the commit in change 7 according to the download instructions, and cherry-pick it onto a new branch of the main repository, and then push that branch to Gerrit. This will make the change no longer have a dependency. Dependencies are created when a branch with several commits is pushed to Gerrit. Gerrit prefers that any branch being pushed is strictly for logically related commits. Gerrit prefers very many different branches, rather than only few. Fortunately, branches are fast and easy with git! After someone has done 2. above Ludovic will have to review and submit the updated change 7 for merge. So it seems more efficient to convince Ludovic to review and submit change 6, and then change 7 will automatically go in right after it. Repeat for all open and later added :) changes. > > 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. It looks good to me? https://www.opensc-project.org/codereview/ I've just registered and signed in. It works for Ludovic as well, and I'm sure he will submit commits as long as they need no further work. I don't really see a problem. > >> - 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. Yes of course. And perhaps it is not highest priority to work on style cleanup. On the other hand, doing that might be a way for everyone to contribute very simple changes and get comfortable with the tools, and trivial things like how to create nice looking commit messages and so on, the technicalities. Remember to install the Gerrit commit-hook locally in all clones of the repository, so that a Change-Id is generated locally when you commit. Avoid pushing anything to Gerrit which doesn't have a Change-Id, in order to reduce issues you may have if and when you start reworking either a patch you yourself created, or a patch from someone else. If no commit-hook is installed locally, Gerrit will generate a Change-Id on push. If two different versions of the same commit are pushed, Gerrit will generate two distinct Change-Id, and thus they will appear to be different changes, when in fact they are only different versions of one and the same change. Running the commit-hook locally avoids this problem, because the Change-Id is only generated the first time that the commit is created. The commit-hook will not replace an existing Change-Id. //Peter From jmpoure at gooze.eu Sun Feb 19 12:32:19 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Sun, 19 Feb 2012 13:32:19 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120219120645.30071.qmail@stuge.se> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> Message-ID: <1329654739.3601.30.camel@acer> Le dimanche 19 f?vrier 2012 ? 13:06 +0100, Peter Stuge a ?crit : > Jenkins may have a problem, but Gerrit looks like it is functioning > fine, at least now. It is trying to merge commits which have been > pushed, reviewed and submitted for merge, but where the commits have > been pushed with dependencies, and where the dependencies have not > yet been reviewed and submitted for merge. I created an account on Gerrit and looked at this URL: https://www.opensc-project.org/codereview/#q,status:open,n,z Some issues are marked 18 February 2012 with "Jenkins" user. So it seems we have GITHUB, Jenkins and Gerrit ... All this seems complicated. Please advise: 1) How to push a patch from GITHUB to OpenSC staging directory. In two or three sentences. 2) Explain who is responsible of reviewing and you are going to extend the review team. > Anders Rundgren wrote: > > For non-government tokens like the excellent Feitian Epass2003 > > I would consider another approach: Updating the firmware to > > emulate PIV so that we can put the middleware aside once and > > for all. > I agree completely that all the legacy involved in tokens and cards > is horrendous waste of engineering resources, time and life. What??? Are suggesting that we should upgrade the ePass2003 firmware? This is ridiculous. If you don't have time and resources, open the review team to the historical OpenSC developers, like Viktor and others. Kind regards, -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/cc466db7/attachment.bin From peter at stuge.se Sun Feb 19 12:45:53 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 13:45:53 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <1329652234.3601.21.camel@acer> References: <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <1329648613.3601.5.camel@acer> <20120219112745.27288.qmail@stuge.se> <1329652234.3601.21.camel@acer> Message-ID: <20120219124553.997.qmail@stuge.se> Jean-Michel Pour? - GOOZE wrote: > > We are also not in a democracy. We are in a security related open > > source project. > > Don't get me wrong. This is an organization issue. I am not talking > about forking OpenSC, this would be stupid. Not neccessarily - if there is critical mass I think it is the only reasonable course. > The website, teams and tools should remain. But we need a simplier > and more effective approach. The tools (git and Gerrit) are as simple and effective as they can be. They are truly state of the art. That's the tools part. As for workflow, that will only be simple and effective when there is agreement on what is desired in the codebase. I consider it prudent to focus on quality, in particular for security related projects. That means that changes are not included on a whim or just because they are proposed. It means that development will be much slower than would be the case with a focus other than quality, e.g. a focus on rapid introduction of new features. > Remember that under European law, all contributors hold a copyright > on OpenSC code. The leader is not the copyright holder. When > nothing happens in a project, we have the right to change > leadership. Everyone has copyright, but actually that is not the key; the license already guarantees freedom for the code. "Leadership" is not related to the copyright, and since the codebase has a free license, actually "change leadership" is nothing other than starting a new project. > Holding elections will allow to decide how to organize the project. No, not really. Holding elections may allow to decide how to organize a different project using the same codebase from the same copyright holders under the same or a compatible license. A fork. > IMHO, a reasonable timeframe to fix organization issues should be > around one month. We are today 19th February 2012. If within a > month all these issues are not fixed, I will incorporate a Charity > with other OpenSC members and call for elections of a board. I don't think you should wait. If you can find enough people to participate in the fork then as I said I think you should do it with determination; if there is hesitation then the fork is doomed to fail already before it has begun. I for one will stay at opensc-project.org and hope that it will never hold elections. What little I might be able to contribute I'd prefer to contribute to code. It's strange that democracy and bureacracy are proposed to move a software project forward, and that perfect commits isn't seen as a perhaps more effective path. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/3ca32c1e/attachment.pgp From peter at stuge.se Sun Feb 19 13:28:06 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 14:28:06 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <1329654739.3601.30.camel@acer> References: <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> Message-ID: <20120219132806.3979.qmail@stuge.se> Jean-Michel Pour? - GOOZE wrote: > I created an account on Gerrit and looked at this URL: > https://www.opensc-project.org/codereview/#q,status:open,n,z > > Some issues are marked 18 February 2012 with "Jenkins" user. > So it seems we have GITHUB, Jenkins and Gerrit ... > > All this seems complicated. It's not so bad. I'll try to explain! GitHub stores the project output. This is where the current repository is published for the world to use, test, and base work on. Gerrit receives input. All proposed commits arrive here. It looks like there may be two ways for commits to arrive: 1. A developer creates an account and does git push directly to Gerrit 2. A developer signals the OpenSC repository on GitHub that they want to propose some change. Maybe this is done with a GitHub pull request. Note: I am not sure about this 2. I'm guessing based on the "GitHub" owner seen for many of the proposed changes. The Owner column on https://www.opensc-project.org/codereview/#q,status:open,n,z is the name of the person who uploaded the commit into Gerrit. Whenever Gerrit receives a change, it asks Jenkins to verify that the change at least does not break the build, but Jenkins can also do some further testing, such as checking the formatting and whatever technical checks are desired for proposed changes. Only Jenkins can set the Verified flag for commits in Gerrit, and nothing can go out to GitHub from Gerrit without Jenkins approving. > Please advise: > 1) How to push a patch from GITHUB to OpenSC staging directory. > In two or three sentences. I would do: One-time setup: a. Create Gerrit account and add username and public SSH key b. git clone from github which has the patch c. cd into cloned dir d. Install commit-msg hook scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git f. git config remote.gerrit.push HEAD:refs/for/master For each patch: 1. Make the current branch equal to OpenSC GitHub + the patch (git rebase) 2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD 3. git push gerrit In case multiple commits belong together in the same logical change or that they depend on each other, then the current branch should have all these commits following the last commit of OpenSC GitHub. > 2) Explain who is responsible of reviewing and you are going to > extend the review team. Everyone is responsible for reviewing. All registered users can review all proposed changes, comment on each changed line, comment on the change as a whole, and give a score of +1, 0 or -1. Martin and Ludovic can in addition "submit" changes, ie. move them from Gerrit to the OpenSC GitHub. Obviously the job for Martin and Ludovic becomes much much easier if there are many others who have already given +1 score for a change. I am also just a user in Gerrit, like you and others, so I can't extend permissions for anyone, but I don't think doing that is very important. Focus on the code and everything else will fall into place. > > > For non-government tokens like the excellent Feitian Epass2003 > > > I would consider another approach: Updating the firmware to > > > emulate PIV so that we can put the middleware aside once and > > > for all. > > > > I agree completely that all the legacy involved in tokens and cards > > is horrendous waste of engineering resources, time and life. > > What??? Are suggesting that we should upgrade the ePass2003 firmware? > This is ridiculous. Converging on a single implementation would perhaps not be such a bad idea, but I would personally prefer something without any legacy, ie. not even CCID. > If you don't have time and resources, open the review team to the > historical OpenSC developers, like Viktor and others. The whole world can do review. The more people that help with this, the less effort it is for Martin and Ludovic. The more people who help with review, the more people will be able to join Martin and Ludovic in submitting changes from Gerrit to the OpenSC GitHub. As I already wrote, I think that everyone who could commit before Gerrit was set up just need to mention their Gerrit username to Martin in order to also be able to submit changes from Gerrit to OpenSC GitHub. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/9e602c9c/attachment-0001.pgp From peter at stuge.se Sun Feb 19 13:30:38 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 14:30:38 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120219132806.3979.qmail@stuge.se> References: <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> Message-ID: <20120219133038.4174.qmail@stuge.se> Peter Stuge wrote: > > Please advise: > > 1) How to push a patch from GITHUB to OpenSC staging directory. > > In two or three sentences. > > I would do: > > One-time setup: > a. Create Gerrit account and add username and public SSH key > b. git clone from github which has the patch > c. cd into cloned dir > d. Install commit-msg hook > scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ > e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git > f. git config remote.gerrit.push HEAD:refs/for/master > > For each patch: > 1. Make the current branch equal to OpenSC GitHub + the patch (git rebase) > 2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD > 3. git push gerrit > > In case multiple commits belong together in the same logical change > or that they depend on each other, then the current branch should > have all these commits following the last commit of OpenSC GitHub. This is my prefered way. I just found confirmation of my guess that a pull request sent to OpenSC GitHub will also arrive into Gerrit. So if already using GitHub then that is probably the easiest way. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120219/74852668/attachment.pgp From anders.rundgren at telia.com Sun Feb 19 14:05:21 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Sun, 19 Feb 2012 15:05:21 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <1329654739.3601.30.camel@acer> References: <1329305941.3393.44.camel@acer> <4F3D7AC0.1030405@anl.gov> <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> Message-ID: <4F4101A1.3020004@telia.com> On 2012-02-19 13:32, Jean-Michel Pour? - GOOZE wrote: >> Anders Rundgren wrote: >>> For non-government tokens like the excellent Feitian Epass2003 >>> I would consider another approach: Updating the firmware to >>> emulate PIV so that we can put the middleware aside once and >>> for all. >> I agree completely that all the legacy involved in tokens and cards >> is horrendous waste of engineering resources, time and life. > > What??? Are suggesting that we should upgrade the ePass2003 firmware? > This is ridiculous. Dear Jean-Michel, It depends what your interest is. My clients which include banks and government agencies are only interested in *using* tokens with as little "fuzz" as possible. In spite of my role as a consultant I think they are right. You didn't hear my presentation at FOSDEM 2012 but it was about creating a token with a standard API so that you would as a customer be able to just plug it in. This is though a much more ambitious project than reflashing ePass2003 to emulate PIV. Why PIV? Due to Europe's limited success creating an interoperable card standard, it seems that NIST's PIV would be good choice. Since some 98% of our client platforms nowadays are defined by only three giant US corporations, US standards will always be better supported. Cheers, Anders From peter at stuge.se Sun Feb 19 18:11:56 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Feb 2012 19:11:56 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F4101A1.3020004@telia.com> References: <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> Message-ID: <20120219181157.17817.qmail@stuge.se> Anders Rundgren wrote: > You didn't hear my presentation at FOSDEM 2012 but it was about > creating a token with a standard API so that you would as a > customer be able to just plug it in. This is an advantage of USB P11. In Windows 8 and later there doesn't even have to be a driver installed, since WinUSB comes with the operating system already and can be loaded automatically if the device follows some Microsoft-invented USB extensions. Only one PKCS#11 DLL is neccessary, and nothing more. > it seems that NIST's PIV would be good choice It would be a much better candidate if there was not such a thick layer of components involved which serve little to no purpose. In principle I do not argue strongly against PIV, I generally agree with your observations. But it would be nice to try to do even better. :) //Peter From anders.rundgren at telia.com Mon Feb 20 09:50:27 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Mon, 20 Feb 2012 10:50:27 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <20120219181157.17817.qmail@stuge.se> References: <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> Message-ID: <4F421763.8030907@telia.com> On 2012-02-19 19:11, Peter Stuge wrote: > Anders Rundgren wrote: >> You didn't hear my presentation at FOSDEM 2012 but it was about >> creating a token with a standard API so that you would as a >> customer be able to just plug it in. > > This is an advantage of USB P11. In Windows 8 and later there doesn't > even have to be a driver installed, since WinUSB comes with the > operating system already and can be loaded automatically if the > device follows some Microsoft-invented USB extensions. Only one > PKCS#11 DLL is neccessary, and nothing more. I don't know what USB P11 is, can you send me a pointer? Although PKCS #11 is good it is not particularly popular on Windows. It is essentially only Mozilla who insists on not supporting the native Windows crypto system. SUN/Oracle have managed to do 3(!) major Java releases (5,6,7) without PKCS #11 support for Win-64. They have though added support for Crypto-API. The total confusion on the *NIX side regarding crypto subsystem haven't been particularly beneficial for PKCS #11 either. Regarding my token-project it has no direct ties to PKCS #11; it is closer to the NXP GP-chip which is powering Google's Wallet. The reason for this is that PKCS #11 doesn't have a interface supporting secure remote provisioning, something which absolutely necessary in the mobile phone world. I have stretched this notion to include connected tokens as well with a hope reaching the critical mass needed for establishing a de-facto standard. > >> it seems that NIST's PIV would be good choice > > It would be a much better candidate if there was not such a thick > layer of components involved which serve little to no purpose. If you talk about the actual card standard I have no idea what you are referring to. It looks quite simple to me. If you OTOH refer to the OpenSC implementation, this is something that PIV isn't responsible for. Anyway, I know that the PIV vendors verify their cards against Microsoft's driver and that is IMO the way to go. > > In principle I do not argue strongly against PIV, I generally agree > with your observations. > > But it would be nice to try to do even better. :) That is what my project is all about but that is hardly an alternative for Feitian at this stage. Anders > > > //Peter > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > From peter at stuge.se Mon Feb 20 20:40:11 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Feb 2012 21:40:11 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F421763.8030907@telia.com> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> Message-ID: <20120220204011.8977.qmail@stuge.se> Anders Rundgren wrote: > I don't know what USB P11 is, can you send me a pointer? It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. > Although PKCS #11 is good it is not particularly popular on Windows. > It is essentially only Mozilla who insists on not supporting the > native Windows crypto system. SUN/Oracle have managed to do 3(!) > major Java releases (5,6,7) without PKCS #11 support for Win-64. > They have though added support for Crypto-API. The same USB device could support Crypto-API primitives too. > Regarding my token-project it has no direct ties to PKCS #11; it is > closer to the NXP GP-chip which is powering Google's Wallet. > > The reason for this is that PKCS #11 doesn't have a interface > supporting secure remote provisioning, something which absolutely > necessary in the mobile phone world. Provisioning is indeed outside PKCS#11 and could be done in some other, also convenient, way. USB is really easy to use. > I have stretched this notion to include connected tokens as well > with a hope reaching the critical mass needed for establishing a > de-facto standard. I fear that you are ahead of your time. :\ Adam Dunkels implemented the internet of things many years ago, but I don't even have IPv6. Things are changing, but still slowly. > >> it seems that NIST's PIV would be good choice > > > > It would be a much better candidate if there was not such a thick > > layer of components involved which serve little to no purpose. > > If you talk about the actual card standard I have no idea what > you are referring to. It looks quite simple to me. If you OTOH > refer to the OpenSC implementation, this is something that PIV > isn't responsible for. Actually neither, I refer to the entire stack of software required for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. > Anyway, I know that the PIV vendors verify their cards against > Microsoft's driver and that is IMO the way to go. If there's a superior alternative Microsoft may well catch up at some point. They did with USB. > > But it would be nice to try to do even better. :) > > That is what my project is all about but that is hardly an > alternative for Feitian at this stage. Also agree. I'm also not suggesting Feitian to pick up on my idea. If they do that's perfectly fine and totally awesome, but I'm keeping the idea alive only because *I* think it is good and would like to try it out. //Peter From deengert at anl.gov Mon Feb 20 21:08:42 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 20 Feb 2012 15:08:42 -0600 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120219133038.4174.qmail@stuge.se> References: <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> Message-ID: <4F42B65A.9000201@anl.gov> [Ludovic, Please see below.] On 2/19/2012 7:30 AM, Peter Stuge wrote: > Peter Stuge wrote: >>> Please advise: >>> 1) How to push a patch from GITHUB to OpenSC staging directory. >>> In two or three sentences. >> >> I would do: >> >> One-time setup: >> a. Create Gerrit account and add username and public SSH key >> b. git clone from github which has the patch >> c. cd into cloned dir >> d. Install commit-msg hook >> scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ >> e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git >> f. git config remote.gerrit.push HEAD:refs/for/master >> >> For each patch: >> 1. Make the current branch equal to OpenSC GitHub + the patch (git rebase) >> 2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD >> 3. git push gerrit >> >> In case multiple commits belong together in the same logical change >> or that they depend on each other, then the current branch should >> have all these commits following the last commit of OpenSC GitHub. > > This is my prefered way. I just found confirmation of my guess that a > pull request sent to OpenSC GitHub will also arrive into Gerrit. So > if already using GitHub then that is probably the easiest way. I am new to Gerrit too, but it looks like if 2 code reviews give a +1, the code will be advanced. See: https://www.opensc-project.org/codereview/ I can use my Google OpenID to Sign In, and today did a code review on: Change I51630a84: Cleanup PKCS15 PIV Card PIN flags This is a change I submitted in December, and Victor gave it a +1 So today I gave it a +1, (As I am the only PIV developer I figure I can review my own code) "Looks good to me, but someone else must approve" But this does not look like it is the same as "Looks good to me, approved" https://www.opensc-project.org/codereview/#admin,group,7 says Ludovic and Martin are the two members of the Integrators group. I might assume Ludovic and Martin are in the Administrator group, but I can not see that. https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy says: "Git write access is granted to those who GetInvolved with OpenSC development and ..." This would imply that there is no intent to keep write access controlled, but it might be controlled today based on the Gerrit access control. Ludovic, Can you verify if you are in the Gerrit Administrator's group? and are any of the other people listed on the "GetInvolved" page listed as integrators, or admins? > > > //Peter > > > > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From peter at stuge.se Mon Feb 20 21:31:08 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Feb 2012 22:31:08 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F42B65A.9000201@anl.gov> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> <4F42B65A.9000201@anl.gov> Message-ID: <20120220213108.12919.qmail@stuge.se> Douglas E. Engert wrote: > I am new to Gerrit too, All right! I'm by no means an expert, but I have been using it in several projects for a while, where I also helped with issues during the migration, so please feel free to ask any questions. > but it looks like if 2 code reviews give a +1, the code will be > advanced. > > See: https://www.opensc-project.org/codereview/ Need Code Review +2 means that one "+2" review is neccessary. 2x +1 is not equivalent. > I can use my Google OpenID to Sign In, and today did a code review > on: Change I51630a84: Cleanup PKCS15 PIV Card PIN flags Thanks! Although since it is your patch it is perhaps a bit redundant, since you have likely reviewed your patch locally before sending it anyway. > This is a change I submitted in December, and Victor gave it a +1 > So today I gave it a +1, (As I am the only PIV developer I figure I > can review my own code) I expect every developer to review their own code locally, already before pushing to Gerrit. The fact that you're the PIV expert is inconvenient to formalize a set of rules for, so it's something integrators will simply have to keep in the back of their head, as they look at individual changes. > "Looks good to me, but someone else must approve" > But this does not look like it is the same as "Looks good to me, approved" Indeed, the latter is a "+2" code review. > https://www.opensc-project.org/codereview/#admin,group,7 > says Ludovic and Martin are the two members of the Integrators group. Right, this means that they are able to "submit" or integrate changes from Gerrit into the OpenSC repository on GitHub, by selecting +2 Looks good to me, approved during review, and clicking the "Publish and Submit" button, which is available in the web interface. Ludovic: Keep in mind that selecting +2 and clicking "Publish Comments" is *not* sufficient to integrate that change. Gerrit is a young tool still. :) I personally strongly prefer the SSH interface. If I was an integrator, I could have included your change with the command: ssh -p 8882 www.opensc-project.org gerrit review 51630a844e8e95e7108cb1966c5f3e21b93a463b --code-review +2 -s The hash after the review command is the patch set commit hash. Combination of Change-Id and patch set number should also work, i.e. ssh -p 8882 www.opensc-project.org gerrit review I51630a84,1 --code-review +2 -s although I haven't had success with this anywhere yet. (May be due to old an buggy versions of Gerrit!) > https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy > says: > "Git write access is granted to those who GetInvolved with OpenSC > development and ..." > This would imply that there is no intent to keep write access controlled, > but it might be controlled today based on the Gerrit access control. Gerrit behaves just like a Git repository, and for those more comfortable with GitHub it's also possible to fork OpenSC there and work from that. "Git write access" is almost nonsensical because Git allows everyone to write everywhere. > Ludovic, > Can you verify if you are in the Gerrit Administrator's group? > and are any of the other people listed on the "GetInvolved" page > listed as integrators, or admins? Integrators is only Martin and Ludovic, hence those are the ones who can currently include Gerrit changes into OpenSC on GitHub. Now for the third time, I'm sure that everyone who used to have repository write access will also quickly be added to the Integrator group if they mention their account name or ID and someone in the Administrators group is around. If only Martin is admin, then I guess there's a bit of a wait state, but that's not really such a big deal, because it doesn't block further work in any way. //Peter From anders.rundgren at telia.com Mon Feb 20 21:41:28 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Mon, 20 Feb 2012 22:41:28 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <20120220204011.8977.qmail@stuge.se> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> Message-ID: <4F42BE08.20208@telia.com> On 2012-02-20 21:40, Peter Stuge wrote: > Anders Rundgren wrote: >> I don't know what USB P11 is, can you send me a pointer? > > It's my old idea of implementing PKCS#11 directly over USB. Issues > have been pointed out, and they would have to be solved of course. Maybe you would like to have an STM32F215-based token? 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES It may happen this year. Anders > > >> Although PKCS #11 is good it is not particularly popular on Windows. >> It is essentially only Mozilla who insists on not supporting the >> native Windows crypto system. SUN/Oracle have managed to do 3(!) >> major Java releases (5,6,7) without PKCS #11 support for Win-64. >> They have though added support for Crypto-API. > > The same USB device could support Crypto-API primitives too. > > >> Regarding my token-project it has no direct ties to PKCS #11; it is >> closer to the NXP GP-chip which is powering Google's Wallet. >> >> The reason for this is that PKCS #11 doesn't have a interface >> supporting secure remote provisioning, something which absolutely >> necessary in the mobile phone world. > > Provisioning is indeed outside PKCS#11 and could be done in some > other, also convenient, way. USB is really easy to use. > > >> I have stretched this notion to include connected tokens as well >> with a hope reaching the critical mass needed for establishing a >> de-facto standard. > > I fear that you are ahead of your time. :\ Adam Dunkels implemented > the internet of things many years ago, but I don't even have IPv6. > Things are changing, but still slowly. > > >>>> it seems that NIST's PIV would be good choice >>> >>> It would be a much better candidate if there was not such a thick >>> layer of components involved which serve little to no purpose. >> >> If you talk about the actual card standard I have no idea what >> you are referring to. It looks quite simple to me. If you OTOH >> refer to the OpenSC implementation, this is something that PIV >> isn't responsible for. > > Actually neither, I refer to the entire stack of software required > for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. > > >> Anyway, I know that the PIV vendors verify their cards against >> Microsoft's driver and that is IMO the way to go. > > If there's a superior alternative Microsoft may well catch up at some > point. They did with USB. > > >>> But it would be nice to try to do even better. :) >> >> That is what my project is all about but that is hardly an >> alternative for Feitian at this stage. > > Also agree. I'm also not suggesting Feitian to pick up on my idea. If > they do that's perfectly fine and totally awesome, but I'm keeping > the idea alive only because *I* think it is good and would like to > try it out. > > > //Peter > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > From deengert at anl.gov Mon Feb 20 22:22:18 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 20 Feb 2012 16:22:18 -0600 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F42BE08.20208@telia.com> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <4F42BE08.20208@telia.com> Message-ID: <4F42C79A.4060805@anl.gov> On 2/20/2012 3:41 PM, Anders Rundgren wrote: > On 2012-02-20 21:40, Peter Stuge wrote: >> Anders Rundgren wrote: >>> I don't know what USB P11 is, can you send me a pointer? >> >> It's my old idea of implementing PKCS#11 directly over USB. Issues >> have been pointed out, and they would have to be solved of course. > > Maybe you would like to have an STM32F215-based token? > 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES > It may happen this year. > > Anders I have not tried this, but check out this token too: http://www.goldkey.com/usb-smart-card-with-piv.html Built-in PIV Support Basic functionality and support for PIV cards and tokens already exists in Microsoft Windows?, Mac OS? X, and many Linux? distributions. It does not say what what the Linux support is, but I bet it is OpenSC. > >> >> >>> Although PKCS #11 is good it is not particularly popular on Windows. >>> It is essentially only Mozilla who insists on not supporting the >>> native Windows crypto system. SUN/Oracle have managed to do 3(!) >>> major Java releases (5,6,7) without PKCS #11 support for Win-64. >>> They have though added support for Crypto-API. >> >> The same USB device could support Crypto-API primitives too. >> >> >>> Regarding my token-project it has no direct ties to PKCS #11; it is >>> closer to the NXP GP-chip which is powering Google's Wallet. >>> >>> The reason for this is that PKCS #11 doesn't have a interface >>> supporting secure remote provisioning, something which absolutely >>> necessary in the mobile phone world. >> >> Provisioning is indeed outside PKCS#11 and could be done in some >> other, also convenient, way. USB is really easy to use. >> >> >>> I have stretched this notion to include connected tokens as well >>> with a hope reaching the critical mass needed for establishing a >>> de-facto standard. >> >> I fear that you are ahead of your time. :\ Adam Dunkels implemented >> the internet of things many years ago, but I don't even have IPv6. >> Things are changing, but still slowly. >> >> >>>>> it seems that NIST's PIV would be good choice >>>> >>>> It would be a much better candidate if there was not such a thick >>>> layer of components involved which serve little to no purpose. >>> >>> If you talk about the actual card standard I have no idea what >>> you are referring to. It looks quite simple to me. If you OTOH >>> refer to the OpenSC implementation, this is something that PIV >>> isn't responsible for. >> >> Actually neither, I refer to the entire stack of software required >> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >> >> >>> Anyway, I know that the PIV vendors verify their cards against >>> Microsoft's driver and that is IMO the way to go. >> >> If there's a superior alternative Microsoft may well catch up at some >> point. They did with USB. >> >> >>>> But it would be nice to try to do even better. :) >>> >>> That is what my project is all about but that is hardly an >>> alternative for Feitian at this stage. >> >> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >> they do that's perfectly fine and totally awesome, but I'm keeping >> the idea alive only because *I* think it is good and would like to >> try it out. >> >> >> //Peter >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel at lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel >> > > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jmpoure at gooze.eu Mon Feb 20 22:23:45 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Mon, 20 Feb 2012 23:23:45 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <20120220204011.8977.qmail@stuge.se> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> Message-ID: <1329776625.10135.43.camel@acer> Dear Peter, > It's my old idea of implementing PKCS#11 directly over USB. Issues > have been pointed out, and they would have to be solved of course. Feitian offers two ranges of products: CCID (ePass2003 and other products) and HID over USB (ePass2001 and other products). At Gooze, we have HID over USB products in stock (around 100 unused tokens) but we did not released them as they were incompatible with OpenSC. Under Windows, it seems that HID over USB range of products can be used without drivers, just over USB. Under Linux, a small proprietary USB framework is needed. If this is what you mean, you may be interested in testing these HID products. Just write me a private email and I can send you one of these tokens. IMHO, CCID is superior as it is really plug-and-play under all systems. Of course, CCID is needed, but it could be installed under all systems by default. The last versions of libccid with udev really rocks. Pure plug-and-play never exists, you always need an underlying library. libccid is that library. I agree PIN provisioning is really an issue. But if you think of Android, there could be an application available from Android store to do this job. What we need is: * Cheap hardware available worldwide, with onlines sales. * A common framework under all systems, this is OpenSC. * Compatibility with all systems, including Linux, Mac, Windows and Android. * A growing user base. * A growing developer base. A common strategy is to be able to answer "Yes" to all questions and needs. With OpenSC, you can say YES to "Windows", "Mac", "Linux" and soon "Android". You can say YES and ship tokens to most countries. Remember crypto is a restricted market and you need authorizations to be able to ship. From my point of view, I would be more in favor of an Android phone acting as a CCID device overs some secure wireless link over OpenSC. GOOZE will soon release crypto chips for Android and this will become one of our target project. We have the demo chips in stock. As usual, we will offer free crypto chips for Android to hackers requesting it. The only reason why Apple removed smartcard support is that (in my opinion) it may be working secretly on a new iPhone replacing smartcards and offering secure payment. The target for new OpenSC developments should be smart phones. We may discuss that in a few weeks after governance issues in OpenSC are improved. All we need is to move forward. Kind regards, -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120220/2f931a28/attachment-0001.bin From peter at stuge.se Mon Feb 20 22:36:13 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Feb 2012 23:36:13 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F42BE08.20208@telia.com> References: <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <4F42BE08.20208@telia.com> Message-ID: <20120220223613.19128.qmail@stuge.se> Anders Rundgren wrote: > > It's my old idea of implementing PKCS#11 directly over USB. Issues > > have been pointed out, and they would have to be solved of course. > > Maybe you would like to have an STM32F215-based token? > 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES > It may happen this year. That's nice, although I'm not crazy about stm32. I tend toward NXP LPC. But so far, the closest to what I want and which is available is Gnuk: http://www.fsij.org/gnuk/ ..which also uses stm32. The development situation for stm32 in particular for USB is not amazing it seems. I haven't looked very deep in the datasheets yet. Gnuk implements CCID and so on in order to be interoperable with software stacks (in particular GnuPG) *today* but like you I'm focusing less on the right now and more on the right way for the future. :) The nice part about Gnuk is that it has all the primitives in place, even if it is only a slow software implementation, so I would really only have to focus on the protocol/API, which actually is exactly what I want. :) //Peter From peter at stuge.se Mon Feb 20 22:40:58 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Feb 2012 23:40:58 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F42C79A.4060805@anl.gov> References: <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <4F42BE08.20208@telia.com> <4F42C79A.4060805@anl.gov> Message-ID: <20120220224058.19435.qmail@stuge.se> Douglas E. Engert wrote: > I have not tried this, but check out this token too: > > http://www.goldkey.com/usb-smart-card-with-piv.html > > Built-in PIV Support > Basic functionality and support for PIV cards and tokens already > exists in Microsoft Windows?, Mac OS? X, and many Linux? distributions. > > It does not say what what the Linux support is, but I bet it is OpenSC. I like the mechanical design very much, but not really the other aspects of the product; closed, they favor key escrow, and talk about their "Master Token" products raises some question marks which I believe will never be answered by the company. //Peter From jmpoure at gooze.eu Mon Feb 20 22:48:06 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Mon, 20 Feb 2012 23:48:06 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120220213108.12919.qmail@stuge.se> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> <4F42B65A.9000201@anl.gov> <20120220213108.12919.qmail@stuge.se> Message-ID: <1329778086.10135.62.camel@acer> Le lundi 20 f?vrier 2012 ? 22:31 +0100, Peter Stuge a ?crit : > Integrators is only Martin and Ludovic, hence those are the ones who > can currently include Gerrit changes into OpenSC on GitHub. > > Now for the third time, I'm sure that everyone who used to have > repository write access will also quickly be added to the Integrator > group if they mention their account name or ID and someone in the > Administrators group is around. If only Martin is admin, then I guess > there's a bit of a wait state, but that's not really such a big deal, > because it doesn't block further work in any way. This is where I don't quite agree. The notion of trust is more interesting than the notion of code purity. If you trust a small group of 5/6 main developers to have discussions before writing +2, this is fairly enough. I am worried that some people might ALWAYS argue that a code is not pure-enough and this leads to endless flame wars. Free software is a collaborative process where we improve the code base, just like in ISO-9001 (release software, describe bug, fix bug, improve). This is a circular process. Collaborative commits means more bugs. But also more beta-testers, more beta testers and more users and in the end a better project. This is life. Let me take an image: if you ask you wife to have surgery for a perfect body before marriage, you won't go very far. On the converse, I am in favor of a collaborative approach based on trust. Kind regards, -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120220/addc2217/attachment.bin From peter at stuge.se Mon Feb 20 22:58:26 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Feb 2012 23:58:26 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <1329776625.10135.43.camel@acer> References: <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <1329776625.10135.43.camel@acer> Message-ID: <20120220225826.20798.qmail@stuge.se> Hi! Jean-Michel Pour? - GOOZE wrote: > > It's my old idea of implementing PKCS#11 directly over USB. Issues > > have been pointed out, and they would have to be solved of course. > > Feitian offers two ranges of products: CCID (ePass2003 and other > products) and HID over USB (ePass2001 and other products). Don't get me started on HID. :) The libusb FAQ http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass tries to give an overview of the considerations for using HID. Executive summary is that it's a bad idea if you want to run on anything but Windows, and even there it may not be a very good idea because you have to re-implement some features which USB otherwise offers your protocol design for free. > At Gooze, we have HID over USB products in stock (around 100 unused > tokens) but we did not released them as they were incompatible with > OpenSC. > > Under Windows, it seems that HID over USB range of products can be > used without drivers, just over USB. Do you know how it is used by CryptoAPI and/or PKCS#11 applications? > Under Linux, a small proprietary USB framework is needed. Proprietary? You know that I think that's the wrong approach. :) The FAQ page mentions HIDAPI which can be used to communicate with HID class devices in some cases, but if portability is a concern, it should be clear from the FAQ page that using HID is not the best choice anyway. > If this is what you mean, Sorry, no, it's not. What I have in mind is to implement the actual PKCS#11 API directly over USB, as far as that is possible. Again, issues have been pointed out with doing this, but I still think it's worth a shot. > IMHO, CCID is superior as it is really plug-and-play under all > systems. So much software is running which is completely unneccessary. I agree that CCID has sufficient usability, but it is by far not the best that can be done. > Pure plug-and-play never exists, It does, actually. At least in Windows and Linux pure plug-and-play would be possible with my USB P11 idea, but I believe also in other systems. As always with PKCS#11 it would be neccessary to point applications to the correct PKCS#11-provider file (.dll or .so) but still I find the idea worth exploring. > What we need is: > * Cheap hardware available worldwide, with onlines sales. Yes, and the logistics of this can be tricky, but as you know with some volume it can indeed be done. And if the solution is good enough I think the volume will come. > * A common framework under all systems, this is OpenSC. I'd be much happier without any framework at all actually. > * Compatibility with all systems, including Linux, Mac, Windows and > Android. Yes, the portability is important. iOS would also be nice, but well that may be pushing one's luck. :p > From my point of view, I would be more in favor of an Android phone > acting as a CCID device overs some secure wireless link over OpenSC. As you probably know, anything wireless is a quite significant attack vector. No "secure" transactions there please. But with a cable maybe. However, Android devices so far do not have a strong history of local IO either coming in or going out. :\ This can change along with market demands of course, but it raises the barrier for development. > GOOZE will soon release crypto chips for Android What kind of chips? How do they connect? > The only reason why Apple removed smartcard support is that (in my > opinion) it may be working secretly on a new iPhone replacing > smartcards and offering secure payment. Yes, I think this is a common belief, and I don't think it's wrong. > The target for new OpenSC developments should be smart phones. Much of OpenSC doesn't really apply in smartphones, but I agree that smartphones may be very relevant security devices. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120220/240daa2f/attachment.pgp From jmpoure at gooze.eu Mon Feb 20 23:26:47 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Tue, 21 Feb 2012 00:26:47 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <20120220225826.20798.qmail@stuge.se> References: <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <1329776625.10135.43.camel@acer> <20120220225826.20798.qmail@stuge.se> Message-ID: <1329780407.12158.4.camel@acer> Dear Peter, > http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass I wron't discuss as I don't know if improving HID for GNU/Linux is really time consuming. > Do you know how it is used by CryptoAPI and/or PKCS#11 applications? CSP and PKCS#11. Just contact me privately and I can ship you a free HID token for testing. As you are the "wizard" of libusb, you may be able to judge and maybe find a solution to communicate with the tokens. I have your address in Berlin, is this still the same? Kind regards, -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120221/a233d7e4/attachment-0001.bin From peter at stuge.se Mon Feb 20 23:44:43 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 21 Feb 2012 00:44:43 +0100 Subject: [opensc-devel] USB token firmware In-Reply-To: <1329780407.12158.4.camel@acer> References: <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <1329776625.10135.43.camel@acer> <20120220225826.20798.qmail@stuge.se> <1329780407.12158.4.camel@acer> Message-ID: <20120220234443.25626.qmail@stuge.se> Jean-Michel Pour? - GOOZE wrote: > > http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass > > I wron't discuss as I don't know if improving HID for GNU/Linux is > really time consuming. Hopefully you read the page anyway to find out about the considerations for HID. It may still be relevant even if the HID token is a little older. The HIDAPI library created by Alan Ott is as easy to use as it gets for HID class devices with Linux. The Linux kernel since a long time offers an API which can be used without any drivers and also without libusb, but the API has limited capabilities, and depending on the device they may not be sufficient. Then it will be neccessary to use libusb instead, and udev must be configured to allow the user to disable the kernel HID class driver. I believe HIDAPI now supports not only using libusb but also the kernel API. > > Do you know how it is used by CryptoAPI and/or PKCS#11 applications? > CSP and PKCS#11. OK! Yes, then the idea is similar to mine, except I do not like to use HID in order to reduce portability issues. HID has advantages for Windows but is more complicated everywhere else. (It can even be impossible on Mac OS X. Apple changed the policy for replacing the kernel HID driver in 10.6.) > Just contact me privately and I can ship you a free HID token for > testing. As you are the "wizard" of libusb, you may be able to judge > and maybe find a solution to communicate with the tokens. No need for token, but thanks for the offer! :) The code that already supports the device is instead what I would look at. Is it available online? //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120221/01ce10e2/attachment.pgp From jmpoure at gooze.eu Tue Feb 21 00:04:27 2012 From: jmpoure at gooze.eu (Jean-Michel =?ISO-8859-1?Q?Pour=E9?= - GOOZE) Date: Tue, 21 Feb 2012 01:04:27 +0100 Subject: [opensc-devel] USB token firmware In-Reply-To: <20120220234443.25626.qmail@stuge.se> References: <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <1329776625.10135.43.camel@acer> <20120220225826.20798.qmail@stuge.se> <1329780407.12158.4.camel@acer> <20120220234443.25626.qmail@stuge.se> Message-ID: <1329782667.13024.8.camel@acer> Le mardi 21 f?vrier 2012 ? 00:44 +0100, Peter Stuge a ?crit : > No need for token, but thanks for the offer! :) The code that already > supports the device is instead what I would look at. Is it available > online? Sorry, it is not publicly available. I am confused about this discussion, because at first you ask us to flash the ePass2003 with another firmware, then we tell you that Feitian HID tokens are already available and you are not interested because ... kernel driver is not perfect under Linux. At GOOZE, we stick to CCID. Good luck with your project. I hope that we will be able to collaborate more on OpenSC main branch without being too picky on solutions. Kind regards, -- Jean-Michel Pour? - Gooze - http://www.gooze.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6022 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120221/94fe1e85/attachment.bin From peter at stuge.se Tue Feb 21 00:42:42 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 21 Feb 2012 01:42:42 +0100 Subject: [opensc-devel] USB token firmware In-Reply-To: <1329782667.13024.8.camel@acer> References: <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <1329776625.10135.43.camel@acer> <20120220225826.20798.qmail@stuge.se> <1329780407.12158.4.camel@acer> <20120220234443.25626.qmail@stuge.se> <1329782667.13024.8.camel@acer> Message-ID: <20120221004242.30274.qmail@stuge.se> Jean-Michel Pour? - GOOZE wrote: > > No need for token, but thanks for the offer! :) The code that already > > supports the device is instead what I would look at. Is it available > > online? > > Sorry, it is not publicly available. You mentioned that one component is the small proprietary HID code for Linux and that part is of course not available, but it seemed like the other parts might be? Or did I misunderstand? Can you say more about the software on Linux for that token? > I am confused about this discussion, because at first you ask us to > flash the ePass2003 with another firmware, Oh, no that was Anders' suggestion. Maybe that's the confusion. I agree with him that as far as existing card/token standards go, PIV is indeed likely to be well and widely supported, but I don't have any opinion on changing the ePass2003 firmware. > then we tell you that Feitian HID tokens are already available and > you are not interested because ... kernel driver is not perfect > under Linux. I'm not interested in having yet another token laying around. :) But I am however interested in the protocol! And I would look at the Linux software situation for that HID token and I would maybe also be able to find improvements. I just don't need the token to do that. > At GOOZE, we stick to CCID. I think this is smart, especially if the Feitian HID token is an older product and no new HID token is planned. > Good luck with your project. Thanks! The idea was always only about a protocol optimized for security, usability and portability, and it still needs r&d, so please don't get the impression that I am trying to make someone else use it before I have shown that it works. > I hope that we will be able to collaborate more on OpenSC main > branch without being too picky on solutions. Don't worry, as you know I'm not a significant contributor. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120221/9cf1d8da/attachment.pgp From peter at stuge.se Tue Feb 21 00:51:37 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 21 Feb 2012 01:51:37 +0100 Subject: [opensc-devel] USB token firmware In-Reply-To: <20120221004242.30274.qmail@stuge.se> References: <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <1329776625.10135.43.camel@acer> <20120220225826.20798.qmail@stuge.se> <1329780407.12158.4.camel@acer> <20120220234443.25626.qmail@stuge.se> <1329782667.13024.8.camel@acer> <20120221004242.30274.qmail@stuge.se> Message-ID: <20120221005137.30943.qmail@stuge.se> Peter Stuge wrote: > You mentioned that one component is the small proprietary HID code > for Linux and that part is of course not available, but it seemed > like the other parts might be? Or did I misunderstand? I think I did. I read your email again to check. > Can you say more about the software on Linux for that token? From your email it seems that the software for Linux may be completely proprietary. In that case it is of course difficult for me to make any suggestions. Is there any protocol documentation? //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120221/1ff010fc/attachment.pgp From anders.rundgren at telia.com Tue Feb 21 07:51:20 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Tue, 21 Feb 2012 08:51:20 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <1329776625.10135.43.camel@acer> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <1329776625.10135.43.camel@acer> Message-ID: <4F434CF8.6050609@telia.com> On 2012-02-20 23:23, Jean-Michel Pour? - GOOZE wrote: > IMHO, CCID is superior as it is really plug-and-play under all systems. > Of course, CCID is needed, but it could be installed under all systems > by default. The last versions of libccid with udev really rocks. Pure > plug-and-play never exists, you always need an underlying library. > libccid is that library. Jean-Michel, I'm not following you here. CCID (as I understand it) only defines an USB communication protocol/class, not how for example how to do an RSA signature. When I look into my W7 installation I note that when I attach my ePass2003 token to it, there is a driver from "EnterSafe". That doesn't look particularly universal to me. In addition, in order to do something useful with the token I had to install a specific ePass2003 management program. It worked great BTW! Don't get me wrong but from a *customer perspective* it would have been much better if all this software was a part of a platform's "smart card support". My guess is that the smart card industry can't do that which is one of the motivations behind my SKS/KeyGen2 project. Upgrading ePass2003 to PIV is an intermediary step. I believe the management part unfortunately is largely undefined in PIV but maybe somebody else know better? Douglas? Cheers, Anders From ludovic.rousseau at gmail.com Tue Feb 21 08:13:26 2012 From: ludovic.rousseau at gmail.com (Ludovic Rousseau) Date: Tue, 21 Feb 2012 09:13:26 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F42B65A.9000201@anl.gov> References: <20120217010749.12454.qmail@stuge.se> <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> <4F42B65A.9000201@anl.gov> Message-ID: Le 20 f?vrier 2012 22:08, Douglas E. Engert a ?crit : > Ludovic, > ?Can you verify if you are in the Gerrit Administrator's group? > and are any of the other people listed on the "GetInvolved" page > listed as integrators, or admins? I only see 2 groups in the admin section: - Integrators: Martin and myself - Release Managers: Martin only It looks like I can add new member(s) to the Integrators group. Bye, -- ?Dr. Ludovic Rousseau From ludovic.rousseau at gmail.com Tue Feb 21 08:34:47 2012 From: ludovic.rousseau at gmail.com (Ludovic Rousseau) Date: Tue, 21 Feb 2012 09:34:47 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <20120220213108.12919.qmail@stuge.se> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> <4F42B65A.9000201@anl.gov> <20120220213108.12919.qmail@stuge.se> Message-ID: Le 20 f?vrier 2012 22:31, Peter Stuge a ?crit : > Douglas E. Engert wrote: >> I am new to Gerrit too, > > All right! I'm by no means an expert, but I have been using it in > several projects for a while, where I also helped with issues during > the migration, so please feel free to ask any questions. > > >> but it looks like if 2 code reviews give a +1, the code will be >> advanced. >> >> See: https://www.opensc-project.org/codereview/ > > Need Code Review +2 means that one "+2" review is neccessary. 2x +1 > is not equivalent. OK. Using +2 (instead of +1) now shows some progress. Example with https://www.opensc-project.org/codereview/#change,44 If I click on "Submit Patch Set 1" I now get the error: "Submit Failed Project policy requires all submissions to be a fast-forward. Please rebase the change locally and upload again for review." What should I do now? It looks like gerrit worked for another patch: https://www.opensc-project.org/codereview/#change,2 The status is "Submitted, Merge Pending" Do I have to do something? Who will do the merge? Thanks -- ?Dr. Ludovic Rousseau From deengert at anl.gov Tue Feb 21 11:43:20 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 21 Feb 2012 05:43:20 -0600 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> <4F42B65A.9000201@anl.gov> <20120220213108.12919.qmail@stuge.se> Message-ID: <4F438358.7030403@anl.gov> On 2/21/2012 2:34 AM, Ludovic Rousseau wrote: > Le 20 f?vrier 2012 22:31, Peter Stuge a ?crit : >> Douglas E. Engert wrote: >>> I am new to Gerrit too, >> >> All right! I'm by no means an expert, but I have been using it in >> several projects for a while, where I also helped with issues during >> the migration, so please feel free to ask any questions. >> >> >>> but it looks like if 2 code reviews give a +1, the code will be >>> advanced. >>> >>> See: https://www.opensc-project.org/codereview/ >> >> Need Code Review +2 means that one "+2" review is neccessary. 2x +1 >> is not equivalent. > > OK. > Using +2 (instead of +1) now shows some progress. > > Example with https://www.opensc-project.org/codereview/#change,44 > If I click on "Submit Patch Set 1" I now get the error: > "Submit Failed > Project policy requires all submissions to be a fast-forward. > > Please rebase the change locally and upload again for review." > > What should I do now? I think I have to rebase the code, and do another pull request? > > It looks like gerrit worked for another patch: > https://www.opensc-project.org/codereview/#change,2 > The status is "Submitted, Merge Pending" > Do I have to do something? > Who will do the merge? > > Thanks > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From anders.rundgren at telia.com Tue Feb 21 12:01:56 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Tue, 21 Feb 2012 13:01:56 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F42C79A.4060805@anl.gov> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <4F42BE08.20208@telia.com> <4F42C79A.4060805@anl.gov> Message-ID: <4F4387B4.90801@telia.com> On 2012-02-20 23:22, Douglas E. Engert wrote: > > > On 2/20/2012 3:41 PM, Anders Rundgren wrote: >> On 2012-02-20 21:40, Peter Stuge wrote: >>> Anders Rundgren wrote: >>>> I don't know what USB P11 is, can you send me a pointer? >>> >>> It's my old idea of implementing PKCS#11 directly over USB. Issues >>> have been pointed out, and they would have to be solved of course. >> >> Maybe you would like to have an STM32F215-based token? >> 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES >> It may happen this year. >> >> Anders > > I have not tried this, but check out this token too: > > http://www.goldkey.com/usb-smart-card-with-piv.html > > Built-in PIV Support > Basic functionality and support for PIV cards and tokens already > exists in Microsoft Windows?, Mac OS? X, and many Linux? distributions. > > It does not say what what the Linux support is, but I bet it is OpenSC. Douglas, I believe you have misunderstood my intentions. The idea with my project is not finding a suitable PIV token but creating a new standard for cryptographic modules. However, I may have to hijack some of PIV stack in order to not get swamped by contra-productive middleware development. My FOSDEM 2012 presentation: http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf Anders > > > >> >>> >>> >>>> Although PKCS #11 is good it is not particularly popular on Windows. >>>> It is essentially only Mozilla who insists on not supporting the >>>> native Windows crypto system. SUN/Oracle have managed to do 3(!) >>>> major Java releases (5,6,7) without PKCS #11 support for Win-64. >>>> They have though added support for Crypto-API. >>> >>> The same USB device could support Crypto-API primitives too. >>> >>> >>>> Regarding my token-project it has no direct ties to PKCS #11; it is >>>> closer to the NXP GP-chip which is powering Google's Wallet. >>>> >>>> The reason for this is that PKCS #11 doesn't have a interface >>>> supporting secure remote provisioning, something which absolutely >>>> necessary in the mobile phone world. >>> >>> Provisioning is indeed outside PKCS#11 and could be done in some >>> other, also convenient, way. USB is really easy to use. >>> >>> >>>> I have stretched this notion to include connected tokens as well >>>> with a hope reaching the critical mass needed for establishing a >>>> de-facto standard. >>> >>> I fear that you are ahead of your time. :\ Adam Dunkels implemented >>> the internet of things many years ago, but I don't even have IPv6. >>> Things are changing, but still slowly. >>> >>> >>>>>> it seems that NIST's PIV would be good choice >>>>> >>>>> It would be a much better candidate if there was not such a thick >>>>> layer of components involved which serve little to no purpose. >>>> >>>> If you talk about the actual card standard I have no idea what >>>> you are referring to. It looks quite simple to me. If you OTOH >>>> refer to the OpenSC implementation, this is something that PIV >>>> isn't responsible for. >>> >>> Actually neither, I refer to the entire stack of software required >>> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >>> >>> >>>> Anyway, I know that the PIV vendors verify their cards against >>>> Microsoft's driver and that is IMO the way to go. >>> >>> If there's a superior alternative Microsoft may well catch up at some >>> point. They did with USB. >>> >>> >>>>> But it would be nice to try to do even better. :) >>>> >>>> That is what my project is all about but that is hardly an >>>> alternative for Feitian at this stage. >>> >>> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >>> they do that's perfectly fine and totally awesome, but I'm keeping >>> the idea alive only because *I* think it is good and would like to >>> try it out. >>> >>> >>> //Peter >>> _______________________________________________ >>> opensc-devel mailing list >>> opensc-devel at lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >> >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel at lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel >> >> > From deengert at anl.gov Tue Feb 21 14:46:54 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 21 Feb 2012 08:46:54 -0600 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F434CF8.6050609@telia.com> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <1329776625.10135.43.camel@acer> <4F434CF8.6050609@telia.com> Message-ID: <4F43AE5E.6000406@anl.gov> On 2/21/2012 1:51 AM, Anders Rundgren wrote: > On 2012-02-20 23:23, Jean-Michel Pour? - GOOZE wrote: > >> IMHO, CCID is superior as it is really plug-and-play under all systems. >> Of course, CCID is needed, but it could be installed under all systems >> by default. The last versions of libccid with udev really rocks. Pure >> plug-and-play never exists, you always need an underlying library. >> libccid is that library. > > Jean-Michel, > > I'm not following you here. CCID (as I understand it) only defines > an USB communication protocol/class, not how for example how to do > an RSA signature. When I look into my W7 installation I note that > when I attach my ePass2003 token to it, there is a driver from > "EnterSafe". That doesn't look particularly universal to me. > > In addition, in order to do something useful with the token I had to > install a specific ePass2003 management program. It worked great BTW! > > Don't get me wrong but from a *customer perspective* it would > have been much better if all this software was a part of a platform's > "smart card support". My guess is that the smart card industry can't > do that which is one of the motivations behind my SKS/KeyGen2 project. > > Upgrading ePass2003 to PIV is an intermediary step. I believe the > management part unfortunately is largely undefined in PIV but maybe > somebody else know better? Douglas? That is correct. As I understand it, the intent was to let the card vendors define this for theirs cards and allow them to market card management systems, giving them some competitive advantage for their cards. At least the end user card interface would be the same. But 800-73 does define "put data" and "generate key", which allows for some testing. It does not define a load key or any finalize commands which would be needed by a production card management system. > > > > Cheers, > Anders > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert at anl.gov Tue Feb 21 15:17:01 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 21 Feb 2012 09:17:01 -0600 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F4387B4.90801@telia.com> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <4F42BE08.20208@telia.com> <4F42C79A.4060805@anl.gov> <4F4387B4.90801@telia.com> Message-ID: <4F43B56D.8000505@anl.gov> On 2/21/2012 6:01 AM, Anders Rundgren wrote: > On 2012-02-20 23:22, Douglas E. Engert wrote: >> >> >> On 2/20/2012 3:41 PM, Anders Rundgren wrote: >>> On 2012-02-20 21:40, Peter Stuge wrote: >>>> Anders Rundgren wrote: >>>>> I don't know what USB P11 is, can you send me a pointer? >>>> >>>> It's my old idea of implementing PKCS#11 directly over USB. Issues >>>> have been pointed out, and they would have to be solved of course. >>> >>> Maybe you would like to have an STM32F215-based token? >>> 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES >>> It may happen this year. >>> >>> Anders >> >> I have not tried this, but check out this token too: >> >> http://www.goldkey.com/usb-smart-card-with-piv.html >> >> Built-in PIV Support >> Basic functionality and support for PIV cards and tokens already >> exists in Microsoft Windows?, Mac OS? X, and many Linux? distributions. >> >> It does not say what what the Linux support is, but I bet it is OpenSC. > > Douglas, > I believe you have misunderstood my intentions. The idea with my > project is not finding a suitable PIV token but creating a new standard > for cryptographic modules. However, I may have to hijack some of PIV > stack in order to not get swamped by contra-productive middleware > development. OK. Note the PIV standards really define an application, and it could be extended or an additional application on the card could be used to do what you propose. > > My FOSDEM 2012 presentation: > http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf The current PIV ECDH operations only return the ECDH keying material, and do not save it on the token. This is what the ECDH mods I want to get into OpenSC are all about. The mods return the raw keying material as a PKCS#11 symmetric key Session Object to the caller who could then use this with software based ECDH Key Agreement. Pushing the ECDH Key Agreement to the token for use by the token looks very interesting. > > Anders > >> >> >> >>> >>>> >>>> >>>>> Although PKCS #11 is good it is not particularly popular on Windows. >>>>> It is essentially only Mozilla who insists on not supporting the >>>>> native Windows crypto system. SUN/Oracle have managed to do 3(!) >>>>> major Java releases (5,6,7) without PKCS #11 support for Win-64. >>>>> They have though added support for Crypto-API. >>>> >>>> The same USB device could support Crypto-API primitives too. >>>> >>>> >>>>> Regarding my token-project it has no direct ties to PKCS #11; it is >>>>> closer to the NXP GP-chip which is powering Google's Wallet. >>>>> >>>>> The reason for this is that PKCS #11 doesn't have a interface >>>>> supporting secure remote provisioning, something which absolutely >>>>> necessary in the mobile phone world. >>>> >>>> Provisioning is indeed outside PKCS#11 and could be done in some >>>> other, also convenient, way. USB is really easy to use. >>>> >>>> >>>>> I have stretched this notion to include connected tokens as well >>>>> with a hope reaching the critical mass needed for establishing a >>>>> de-facto standard. >>>> >>>> I fear that you are ahead of your time. :\ Adam Dunkels implemented >>>> the internet of things many years ago, but I don't even have IPv6. >>>> Things are changing, but still slowly. >>>> >>>> >>>>>>> it seems that NIST's PIV would be good choice >>>>>> >>>>>> It would be a much better candidate if there was not such a thick >>>>>> layer of components involved which serve little to no purpose. >>>>> >>>>> If you talk about the actual card standard I have no idea what >>>>> you are referring to. It looks quite simple to me. If you OTOH >>>>> refer to the OpenSC implementation, this is something that PIV >>>>> isn't responsible for. >>>> >>>> Actually neither, I refer to the entire stack of software required >>>> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >>>> >>>> >>>>> Anyway, I know that the PIV vendors verify their cards against >>>>> Microsoft's driver and that is IMO the way to go. >>>> >>>> If there's a superior alternative Microsoft may well catch up at some >>>> point. They did with USB. >>>> >>>> >>>>>> But it would be nice to try to do even better. :) >>>>> >>>>> That is what my project is all about but that is hardly an >>>>> alternative for Feitian at this stage. >>>> >>>> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >>>> they do that's perfectly fine and totally awesome, but I'm keeping >>>> the idea alive only because *I* think it is good and would like to >>>> try it out. >>>> >>>> >>>> //Peter >>>> _______________________________________________ >>>> opensc-devel mailing list >>>> opensc-devel at lists.opensc-project.org >>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>> >>> >>> _______________________________________________ >>> opensc-devel mailing list >>> opensc-devel at lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >>> >> > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From anders.rundgren at telia.com Tue Feb 21 15:53:54 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Tue, 21 Feb 2012 16:53:54 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F43B56D.8000505@anl.gov> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <4F42BE08.20208@telia.com> <4F42C79A.4060805@anl.gov> <4F4387B4.90801@telia.com> <4F43B56D.8000505@anl.gov> Message-ID: <4F43BE12.9050608@telia.com> On 2012-02-21 16:17, Douglas E. Engert wrote: > > > On 2/21/2012 6:01 AM, Anders Rundgren wrote: >> On 2012-02-20 23:22, Douglas E. Engert wrote: >>> >>> >>> On 2/20/2012 3:41 PM, Anders Rundgren wrote: >>>> On 2012-02-20 21:40, Peter Stuge wrote: >>>>> Anders Rundgren wrote: >>>>>> I don't know what USB P11 is, can you send me a pointer? >>>>> >>>>> It's my old idea of implementing PKCS#11 directly over USB. Issues >>>>> have been pointed out, and they would have to be solved of course. >>>> >>>> Maybe you would like to have an STM32F215-based token? >>>> 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES >>>> It may happen this year. >>>> >>>> Anders >>> >>> I have not tried this, but check out this token too: >>> >>> http://www.goldkey.com/usb-smart-card-with-piv.html >>> >>> Built-in PIV Support >>> Basic functionality and support for PIV cards and tokens already >>> exists in Microsoft Windows?, Mac OS? X, and many Linux? distributions. >>> >>> It does not say what what the Linux support is, but I bet it is OpenSC. >> >> Douglas, >> I believe you have misunderstood my intentions. The idea with my >> project is not finding a suitable PIV token but creating a new standard >> for cryptographic modules. However, I may have to hijack some of PIV >> stack in order to not get swamped by contra-productive middleware >> development. > > OK. Note the PIV standards really define an application, and it could > be extended or an additional application on the card could be used > to do what you propose. That's correct and may very well be what I end-up with :-) > >> >> My FOSDEM 2012 presentation: >> http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf > > The current PIV ECDH operations only return the ECDH keying material, > and do not save it on the token. This is what the ECDH mods I want to get > into OpenSC are all about. The mods return the raw keying material as a > PKCS#11 symmetric key Session Object to the caller who could then use > this with software based ECDH Key Agreement. > > Pushing the ECDH Key Agreement to the token for use by the token > looks very interesting. I'm not sure I understand what you are trying to do here. The PIV specification doesn't (AFAIK...) allow you to store the result of an operation on the card. I could imagine that "super-operations" like HMACSHA256 (ID-to-ECDH-priv-key-on-token, Other-party's-ECDH pubkey, KDF-Algorithm, KDF-Data, "Argument Data") could be interesting but that looks like a new token method to me. Anders > > >> >> Anders >> >>> >>> >>> >>>> >>>>> >>>>> >>>>>> Although PKCS #11 is good it is not particularly popular on Windows. >>>>>> It is essentially only Mozilla who insists on not supporting the >>>>>> native Windows crypto system. SUN/Oracle have managed to do 3(!) >>>>>> major Java releases (5,6,7) without PKCS #11 support for Win-64. >>>>>> They have though added support for Crypto-API. >>>>> >>>>> The same USB device could support Crypto-API primitives too. >>>>> >>>>> >>>>>> Regarding my token-project it has no direct ties to PKCS #11; it is >>>>>> closer to the NXP GP-chip which is powering Google's Wallet. >>>>>> >>>>>> The reason for this is that PKCS #11 doesn't have a interface >>>>>> supporting secure remote provisioning, something which absolutely >>>>>> necessary in the mobile phone world. >>>>> >>>>> Provisioning is indeed outside PKCS#11 and could be done in some >>>>> other, also convenient, way. USB is really easy to use. >>>>> >>>>> >>>>>> I have stretched this notion to include connected tokens as well >>>>>> with a hope reaching the critical mass needed for establishing a >>>>>> de-facto standard. >>>>> >>>>> I fear that you are ahead of your time. :\ Adam Dunkels implemented >>>>> the internet of things many years ago, but I don't even have IPv6. >>>>> Things are changing, but still slowly. >>>>> >>>>> >>>>>>>> it seems that NIST's PIV would be good choice >>>>>>> >>>>>>> It would be a much better candidate if there was not such a thick >>>>>>> layer of components involved which serve little to no purpose. >>>>>> >>>>>> If you talk about the actual card standard I have no idea what >>>>>> you are referring to. It looks quite simple to me. If you OTOH >>>>>> refer to the OpenSC implementation, this is something that PIV >>>>>> isn't responsible for. >>>>> >>>>> Actually neither, I refer to the entire stack of software required >>>>> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >>>>> >>>>> >>>>>> Anyway, I know that the PIV vendors verify their cards against >>>>>> Microsoft's driver and that is IMO the way to go. >>>>> >>>>> If there's a superior alternative Microsoft may well catch up at some >>>>> point. They did with USB. >>>>> >>>>> >>>>>>> But it would be nice to try to do even better. :) >>>>>> >>>>>> That is what my project is all about but that is hardly an >>>>>> alternative for Feitian at this stage. >>>>> >>>>> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >>>>> they do that's perfectly fine and totally awesome, but I'm keeping >>>>> the idea alive only because *I* think it is good and would like to >>>>> try it out. >>>>> >>>>> >>>>> //Peter >>>>> _______________________________________________ >>>>> opensc-devel mailing list >>>>> opensc-devel at lists.opensc-project.org >>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>>> >>>> >>>> _______________________________________________ >>>> opensc-devel mailing list >>>> opensc-devel at lists.opensc-project.org >>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>> >>>> >>> >> >> > From deengert at anl.gov Tue Feb 21 17:16:42 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 21 Feb 2012 11:16:42 -0600 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F43BE12.9050608@telia.com> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <4F42BE08.20208@telia.com> <4F42C79A.4060805@anl.gov> <4F4387B4.90801@telia.com> <4F43B56D.8000505@anl.gov> <4F43BE12.9050608@telia.com> Message-ID: <4F43D17A.5020103@anl.gov> On 2/21/2012 9:53 AM, Anders Rundgren wrote: > On 2012-02-21 16:17, Douglas E. Engert wrote: >> >> >> On 2/21/2012 6:01 AM, Anders Rundgren wrote: >>> On 2012-02-20 23:22, Douglas E. Engert wrote: >>>> >>>> >>>> On 2/20/2012 3:41 PM, Anders Rundgren wrote: >>>>> On 2012-02-20 21:40, Peter Stuge wrote: >>>>>> Anders Rundgren wrote: >>>>>>> I don't know what USB P11 is, can you send me a pointer? >>>>>> >>>>>> It's my old idea of implementing PKCS#11 directly over USB. Issues >>>>>> have been pointed out, and they would have to be solved of course. >>>>> >>>>> Maybe you would like to have an STM32F215-based token? >>>>> 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES >>>>> It may happen this year. >>>>> >>>>> Anders >>>> >>>> I have not tried this, but check out this token too: >>>> >>>> http://www.goldkey.com/usb-smart-card-with-piv.html >>>> >>>> Built-in PIV Support >>>> Basic functionality and support for PIV cards and tokens already >>>> exists in Microsoft Windows?, Mac OS? X, and many Linux? distributions. >>>> >>>> It does not say what what the Linux support is, but I bet it is OpenSC. >>> >>> Douglas, >>> I believe you have misunderstood my intentions. The idea with my >>> project is not finding a suitable PIV token but creating a new standard >>> for cryptographic modules. However, I may have to hijack some of PIV >>> stack in order to not get swamped by contra-productive middleware >>> development. >> >> OK. Note the PIV standards really define an application, and it could >> be extended or an additional application on the card could be used >> to do what you propose. > > That's correct and may very well be what I end-up with :-) > >> >>> >>> My FOSDEM 2012 presentation: >>> http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf >> >> The current PIV ECDH operations only return the ECDH keying material, >> and do not save it on the token. This is what the ECDH mods I want to get >> into OpenSC are all about. The mods return the raw keying material as a >> PKCS#11 symmetric key Session Object to the caller who could then use >> this with software based ECDH Key Agreement. The above allows for example Thunderbird to use ECDH for encrypted email, with most if the work done in software, as the derived key is not stored on the token. >> >> Pushing the ECDH Key Agreement to the token for use by the token >> looks very interesting. > I meant based on your slides it looks like that is what you would like to do as a new operation. > I'm not sure I understand what you are trying to do here. The PIV > specification doesn't (AFAIK...) allow you to store the result of an > operation on the card. Correct. > I could imagine that "super-operations" like > > HMACSHA256 (ID-to-ECDH-priv-key-on-token, > Other-party's-ECDH pubkey, > KDF-Algorithm, > KDF-Data, > "Argument Data") > > could be interesting but that looks like a new token method to me. Based on you slides, this sounds like a version of NIST 800-56A Section 6.1.1.2. with all the operations done on the token, and the key (Z) stored on the token for use by other operations. > > Anders > > > >> >> >>> >>> Anders >>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> >>>>>>> Although PKCS #11 is good it is not particularly popular on Windows. >>>>>>> It is essentially only Mozilla who insists on not supporting the >>>>>>> native Windows crypto system. SUN/Oracle have managed to do 3(!) >>>>>>> major Java releases (5,6,7) without PKCS #11 support for Win-64. >>>>>>> They have though added support for Crypto-API. >>>>>> >>>>>> The same USB device could support Crypto-API primitives too. >>>>>> >>>>>> >>>>>>> Regarding my token-project it has no direct ties to PKCS #11; it is >>>>>>> closer to the NXP GP-chip which is powering Google's Wallet. >>>>>>> >>>>>>> The reason for this is that PKCS #11 doesn't have a interface >>>>>>> supporting secure remote provisioning, something which absolutely >>>>>>> necessary in the mobile phone world. >>>>>> >>>>>> Provisioning is indeed outside PKCS#11 and could be done in some >>>>>> other, also convenient, way. USB is really easy to use. >>>>>> >>>>>> >>>>>>> I have stretched this notion to include connected tokens as well >>>>>>> with a hope reaching the critical mass needed for establishing a >>>>>>> de-facto standard. >>>>>> >>>>>> I fear that you are ahead of your time. :\ Adam Dunkels implemented >>>>>> the internet of things many years ago, but I don't even have IPv6. >>>>>> Things are changing, but still slowly. >>>>>> >>>>>> >>>>>>>>> it seems that NIST's PIV would be good choice >>>>>>>> >>>>>>>> It would be a much better candidate if there was not such a thick >>>>>>>> layer of components involved which serve little to no purpose. >>>>>>> >>>>>>> If you talk about the actual card standard I have no idea what >>>>>>> you are referring to. It looks quite simple to me. If you OTOH >>>>>>> refer to the OpenSC implementation, this is something that PIV >>>>>>> isn't responsible for. >>>>>> >>>>>> Actually neither, I refer to the entire stack of software required >>>>>> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >>>>>> >>>>>> >>>>>>> Anyway, I know that the PIV vendors verify their cards against >>>>>>> Microsoft's driver and that is IMO the way to go. >>>>>> >>>>>> If there's a superior alternative Microsoft may well catch up at some >>>>>> point. They did with USB. >>>>>> >>>>>> >>>>>>>> But it would be nice to try to do even better. :) >>>>>>> >>>>>>> That is what my project is all about but that is hardly an >>>>>>> alternative for Feitian at this stage. >>>>>> >>>>>> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >>>>>> they do that's perfectly fine and totally awesome, but I'm keeping >>>>>> the idea alive only because *I* think it is good and would like to >>>>>> try it out. >>>>>> >>>>>> >>>>>> //Peter >>>>>> _______________________________________________ >>>>>> opensc-devel mailing list >>>>>> opensc-devel at lists.opensc-project.org >>>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>>>> >>>>> >>>>> _______________________________________________ >>>>> opensc-devel mailing list >>>>> opensc-devel at lists.opensc-project.org >>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>>> >>>>> >>>> >>> >>> >> > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From anders.rundgren at telia.com Tue Feb 21 17:40:21 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Tue, 21 Feb 2012 18:40:21 +0100 Subject: [opensc-devel] Upgrading aPass2003 Firmware to PIV In-Reply-To: <4F43D17A.5020103@anl.gov> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <4F4101A1.3020004@telia.com> <20120219181157.17817.qmail@stuge.se> <4F421763.8030907@telia.com> <20120220204011.8977.qmail@stuge.se> <4F42BE08.20208@telia.com> <4F42C79A.4060805@anl.gov> <4F4387B4.90801@telia.com> <4F43B56D.8000505@anl.gov> <4F43BE12.9050608@telia.com> <4F43D17A.5020103@anl.gov> Message-ID: <4F43D705.4020407@telia.com> On 2012-02-21 18:16, Douglas E. Engert wrote: > >>> Pushing the ECDH Key Agreement to the token for use by the token >>> looks very interesting. >> > > I meant based on your slides it looks like that is what you would like > to do as a new operation. > >> I'm not sure I understand what you are trying to do here. The PIV >> specification doesn't (AFAIK...) allow you to store the result of an >> operation on the card. > > Correct. > >> I could imagine that "super-operations" like >> >> HMACSHA256 (ID-to-ECDH-priv-key-on-token, >> Other-party's-ECDH pubkey, >> KDF-Algorithm, >> KDF-Data, >> "Argument Data") >> >> could be interesting but that looks like a new token method to me. > > Based on you slides, this sounds like a version of NIST 800-56A > Section 6.1.1.2. with all the operations done on the token, > and the key (Z) stored on the token for use by other operations. You are right. My scheme does indeed store a ECDH Z-result in the token. However, this is a token management/provisioning key, rather than a "user key". For user-keys I currently have no ambitions beyond what PIV supports. I have "played" with the idea of creating a "secure stack-machine" for performing arbitrary cryptographic operations on result-data but I couldn't figure out how this would work without introducing vulnerabilities. :-( Anders > >> >> Anders >> >> >> >>> >>> >>>> >>>> Anders >>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> Although PKCS #11 is good it is not particularly popular on Windows. >>>>>>>> It is essentially only Mozilla who insists on not supporting the >>>>>>>> native Windows crypto system. SUN/Oracle have managed to do 3(!) >>>>>>>> major Java releases (5,6,7) without PKCS #11 support for Win-64. >>>>>>>> They have though added support for Crypto-API. >>>>>>> >>>>>>> The same USB device could support Crypto-API primitives too. >>>>>>> >>>>>>> >>>>>>>> Regarding my token-project it has no direct ties to PKCS #11; it is >>>>>>>> closer to the NXP GP-chip which is powering Google's Wallet. >>>>>>>> >>>>>>>> The reason for this is that PKCS #11 doesn't have a interface >>>>>>>> supporting secure remote provisioning, something which absolutely >>>>>>>> necessary in the mobile phone world. >>>>>>> >>>>>>> Provisioning is indeed outside PKCS#11 and could be done in some >>>>>>> other, also convenient, way. USB is really easy to use. >>>>>>> >>>>>>> >>>>>>>> I have stretched this notion to include connected tokens as well >>>>>>>> with a hope reaching the critical mass needed for establishing a >>>>>>>> de-facto standard. >>>>>>> >>>>>>> I fear that you are ahead of your time. :\ Adam Dunkels implemented >>>>>>> the internet of things many years ago, but I don't even have IPv6. >>>>>>> Things are changing, but still slowly. >>>>>>> >>>>>>> >>>>>>>>>> it seems that NIST's PIV would be good choice >>>>>>>>> >>>>>>>>> It would be a much better candidate if there was not such a thick >>>>>>>>> layer of components involved which serve little to no purpose. >>>>>>>> >>>>>>>> If you talk about the actual card standard I have no idea what >>>>>>>> you are referring to. It looks quite simple to me. If you OTOH >>>>>>>> refer to the OpenSC implementation, this is something that PIV >>>>>>>> isn't responsible for. >>>>>>> >>>>>>> Actually neither, I refer to the entire stack of software required >>>>>>> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >>>>>>> >>>>>>> >>>>>>>> Anyway, I know that the PIV vendors verify their cards against >>>>>>>> Microsoft's driver and that is IMO the way to go. >>>>>>> >>>>>>> If there's a superior alternative Microsoft may well catch up at some >>>>>>> point. They did with USB. >>>>>>> >>>>>>> >>>>>>>>> But it would be nice to try to do even better. :) >>>>>>>> >>>>>>>> That is what my project is all about but that is hardly an >>>>>>>> alternative for Feitian at this stage. >>>>>>> >>>>>>> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >>>>>>> they do that's perfectly fine and totally awesome, but I'm keeping >>>>>>> the idea alive only because *I* think it is good and would like to >>>>>>> try it out. >>>>>>> >>>>>>> >>>>>>> //Peter >>>>>>> _______________________________________________ >>>>>>> opensc-devel mailing list >>>>>>> opensc-devel at lists.opensc-project.org >>>>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> opensc-devel mailing list >>>>>> opensc-devel at lists.opensc-project.org >>>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From deengert at anl.gov Tue Feb 21 20:21:00 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 21 Feb 2012 14:21:00 -0600 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F438358.7030403@anl.gov> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> <4F42B65A.9000201@anl.gov> <20120220213108.12919.qmail@stuge.se> <4F438358.7030403@anl.gov> Message-ID: <4F43FCAC.5080407@anl.gov> Ludovic, change,44 below is Vicktor's, not mine. I should not have said "I think I have to rebase the code, and do another pull request?" I was hopping you would try a +2 on: https://www.opensc-project.org/codereview/#change,237 Its parent is: 6f8dcc9172277799011d88fdbe2fabfcf3a89774 Make the Mac OS X package builder script more resilient. which is the gerrit staging branch, so it should not need to be rebased. On 2/21/2012 5:43 AM, Douglas E. Engert wrote: > > > On 2/21/2012 2:34 AM, Ludovic Rousseau wrote: >> Le 20 f?vrier 2012 22:31, Peter Stuge a ?crit : >>> Douglas E. Engert wrote: >>>> I am new to Gerrit too, >>> >>> All right! I'm by no means an expert, but I have been using it in >>> several projects for a while, where I also helped with issues during >>> the migration, so please feel free to ask any questions. >>> >>> >>>> but it looks like if 2 code reviews give a +1, the code will be >>>> advanced. >>>> >>>> See: https://www.opensc-project.org/codereview/ >>> >>> Need Code Review +2 means that one "+2" review is neccessary. 2x +1 >>> is not equivalent. >> >> OK. >> Using +2 (instead of +1) now shows some progress. >> >> Example with https://www.opensc-project.org/codereview/#change,44 >> If I click on "Submit Patch Set 1" I now get the error: >> "Submit Failed >> Project policy requires all submissions to be a fast-forward. >> >> Please rebase the change locally and upload again for review." >> >> What should I do now? > > I think I have to rebase the code, and do another pull request? > >> >> It looks like gerrit worked for another patch: >> https://www.opensc-project.org/codereview/#change,2 >> The status is "Submitted, Merge Pending" >> Do I have to do something? >> Who will do the merge? >> >> Thanks >> > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From peter at stuge.se Wed Feb 22 00:39:24 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 22 Feb 2012 01:39:24 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F43FCAC.5080407@anl.gov> References: <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> <4F42B65A.9000201@anl.gov> <20120220213108.12919.qmail@stuge.se> <4F438358.7030403@anl.gov> <4F43FCAC.5080407@anl.gov> Message-ID: <20120222003925.16065.qmail@stuge.se> Douglas E. Engert wrote: > change,44 below is Vicktor's, not mine. I should not have said > "I think I have to rebase the code, and do another pull request?" You can also do it! //Peter From ludovic.rousseau at gmail.com Wed Feb 22 19:17:58 2012 From: ludovic.rousseau at gmail.com (Ludovic Rousseau) Date: Wed, 22 Feb 2012 20:17:58 +0100 Subject: [opensc-devel] OpenSC write access to main trunk, discussion In-Reply-To: <4F43FCAC.5080407@anl.gov> References: <1329471425.3883.15.camel@acer> <20120217165219.23449.qmail@stuge.se> <4F40C864.7090708@googlemail.com> <20120219102337.22688.qmail@stuge.se> <4F40D9B1.1070507@googlemail.com> <20120219120645.30071.qmail@stuge.se> <1329654739.3601.30.camel@acer> <20120219132806.3979.qmail@stuge.se> <20120219133038.4174.qmail@stuge.se> <4F42B65A.9000201@anl.gov> <20120220213108.12919.qmail@stuge.se> <4F438358.7030403@anl.gov> <4F43FCAC.5080407@anl.gov> Message-ID: Le 21 f?vrier 2012 21:21, Douglas E. Engert a ?crit : > Ludovic, > ?change,44 below is Vicktor's, not mine. I should not have said > ?"I think I have to rebase the code, and do another pull request?" > > I was hopping you would try a +2 on: > ?https://www.opensc-project.org/codereview/#change,237 Done. > Its parent is: > > 6f8dcc9172277799011d88fdbe2fabfcf3a89774 Make the Mac OS X package builder script more resilient. > which is the gerrit staging branch, so it should not need to be rebased. > > > > On 2/21/2012 5:43 AM, Douglas E. Engert wrote: >> >> >> On 2/21/2012 2:34 AM, Ludovic Rousseau wrote: >>> Le 20 f?vrier 2012 22:31, Peter Stuge ? a ?crit : >>>> Douglas E. Engert wrote: >>>>> I am new to Gerrit too, >>>> >>>> All right! I'm by no means an expert, but I have been using it in >>>> several projects for a while, where I also helped with issues during >>>> the migration, so please feel free to ask any questions. >>>> >>>> >>>>> but it looks like if 2 code reviews give a +1, the code will be >>>>> advanced. >>>>> >>>>> See: https://www.opensc-project.org/codereview/ >>>> >>>> Need Code Review +2 means that one "+2" review is neccessary. 2x +1 >>>> is not equivalent. >>> >>> OK. >>> Using +2 (instead of +1) now shows some progress. >>> >>> Example with https://www.opensc-project.org/codereview/#change,44 >>> If I click on "Submit Patch Set 1" I now get the error: >>> "Submit Failed >>> Project policy requires all submissions to be a fast-forward. >>> >>> Please rebase the change locally and upload again for review." >>> >>> What should I do now? >> >> I think I have to rebase the code, and do another pull request? >> >>> >>> It looks like gerrit worked for another patch: >>> https://www.opensc-project.org/codereview/#change,2 >>> The status is "Submitted, Merge Pending" >>> Do I have to do something? >>> Who will do the merge? >>> >>> Thanks >>> >> > > -- > > ?Douglas E. Engert ? > ?Argonne National Laboratory > ?9700 South Cass Avenue > ?Argonne, Illinois ?60439 > ?(630) 252-5444 > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- ?Dr. Ludovic Rousseau From evalues.es at gmail.com Thu Feb 23 15:00:34 2012 From: evalues.es at gmail.com (evalues evalues) Date: Thu, 23 Feb 2012 16:00:34 +0100 Subject: [opensc-devel] PKCS15 Deauthenticate Function In-Reply-To: References: <4F259920.4070308@googlemail.com> Message-ID: 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 wrote: > > > On Wed, Feb 8, 2012 at 6:04 PM, evalues evalues wrote: > >> 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 > > Where is 4 bytes: 00, , , > > 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 > > 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. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120223/ab805d9c/attachment.htm From deengert at anl.gov Thu Feb 23 22:15:21 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 23 Feb 2012 16:15:21 -0600 Subject: [opensc-devel] MacOS 10.8 Mountain Lion and OpenSC Message-ID: <4F46BA79.3010509@anl.gov> Is anyone planing on looking at OpenSC and Mac OS 10.8? especially in light of: http://lists.apple.com/archives/fed-talk/2011/Jul/msg00099.html and http://www.macworld.com/article/165417/2012/02/apple_readies_mac_os_x_mountain_lion_update.html -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From ludovic.rousseau at gmail.com Fri Feb 24 07:31:04 2012 From: ludovic.rousseau at gmail.com (Ludovic Rousseau) Date: Fri, 24 Feb 2012 08:31:04 +0100 Subject: [opensc-devel] MacOS 10.8 Mountain Lion and OpenSC In-Reply-To: <4F46BA79.3010509@anl.gov> References: <4F46BA79.3010509@anl.gov> Message-ID: Le 23 f?vrier 2012 23:15, Douglas E. Engert a ?crit : > Is anyone planing on looking at OpenSC and Mac OS 10.8? I do not expect problem with OpenSC on 10.8. PC/SC is still present. > especially in light of: > http://lists.apple.com/archives/fed-talk/2011/Jul/msg00099.html > > and > http://www.macworld.com/article/165417/2012/02/apple_readies_mac_os_x_mountain_lion_update.html See also http://lists.macosforge.org/pipermail/smartcardservices-dev/2012-February/000045.html Bye, -- ?Dr. Ludovic Rousseau From evalues.es at gmail.com Fri Feb 24 13:04:56 2012 From: evalues.es at gmail.com (evalues evalues) Date: Fri, 24 Feb 2012 14:04:56 +0100 Subject: [opensc-devel] PKCS15 Deauthenticate Function In-Reply-To: References: <4F259920.4070308@googlemail.com> Message-ID: 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. Thank you On Thu, Feb 23, 2012 at 4:00 PM, evalues evalues wrote: > 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 > wrote: > >> >> >> On Wed, Feb 8, 2012 at 6:04 PM, evalues evalues wrote: >> >>> 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 >> > Where is 4 bytes: 00, , , >> > 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.tarasov at 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. >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120224/1efe2952/attachment.htm From viktor.tarasov at gmail.com Fri Feb 24 14:19:11 2012 From: viktor.tarasov at gmail.com (Viktor Tarasov) Date: Fri, 24 Feb 2012 15:19:11 +0100 Subject: [opensc-devel] PKCS15 Deauthenticate Function In-Reply-To: References: <4F259920.4070308@googlemail.com> Message-ID: On Fri, Feb 24, 2012 at 2:04 PM, evalues evalues wrote: > 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 wrote: > >> 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.tarasov at gmail.com> wrote: >> >>> >>> >>> On Wed, Feb 8, 2012 at 6:04 PM, evalues evalues wrote: >>> >>>> 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 >>> > Where is 4 bytes: 00, , , >>> > 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.tarasov at 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. >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opensc-project.org/pipermail/opensc-devel/attachments/20120224/63462f29/attachment.htm From martin at martinpaljak.net Fri Feb 24 23:00:07 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Sat, 25 Feb 2012 01:00:07 +0200 Subject: [opensc-devel] MacOS 10.8 Mountain Lion and OpenSC In-Reply-To: <4F46BA79.3010509@anl.gov> References: <4F46BA79.3010509@anl.gov> Message-ID: Hello, On Fri, Feb 24, 2012 at 00:15, Douglas E. Engert wrote: > Is anyone planing on looking at OpenSC and Mac OS 10.8? > > especially in light of: > http://lists.apple.com/archives/fed-talk/2011/Jul/msg00099.html > > and > http://www.macworld.com/article/165417/2012/02/apple_readies_mac_os_x_mountain_lion_update.html Regarding PKCS#11, I doubt there's much happening (I *heard* that the pcsc-lite version is still the same, but I'm not interested in trying out Apple betas). But regarding OpenSC.tokend, given previous experience with it and the lack of (public or NDA) documentation from Apple regarding the topic, definitely not before 10.8 has been demod on stage and actual *retail* copy is available. If anything, there might be a few things to keep in mind: - possible requirement to have signed binaries (and installer?) for OpenSC.tokend, if still supported - possible requirement to play together/through the appstore... - tokend/cdsa totally deprecated and a new replacement surfaces (which would render OpenSC.tokend useless on 10.8 anyway...) Martin From awalls at md.metrocast.net Mon Feb 27 00:15:45 2012 From: awalls at md.metrocast.net (Andy Walls) Date: Sun, 26 Feb 2012 19:15:45 -0500 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: References: Message-ID: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> Anthony Foiani wrote: >Greetings! > >I found your message from last fall on the OpenSC devel list: > >http://www.opensc-project.org/pipermail/opensc-devel/2011-October/017307.html > >Have you been able to make any progress with this token? > >I'm in a similar situation, if not more extreme: I would like to >support >this on an embedded non-x86 target (PowerPC32). So I get to deal with >big >vs. little endian, on top of everything else. > >Anyway. If you've made any progress, I'd be very interested to hear >about >it. > >Best regards, >Anthony Foiani I added basic support for the embedded "card reader" but did nothing for the actual embedded "smart card". I got very busy and didn't have time to pursue it. I will post a patch to the list in a day or so. Regards, Andy From anthony.foiani at gmail.com Mon Feb 27 00:54:03 2012 From: anthony.foiani at gmail.com (Anthony Foiani) Date: Sun, 26 Feb 2012 17:54:03 -0700 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> Message-ID: Andy -- On Sun, Feb 26, 2012 at 5:15 PM, Andy Walls wrote: > > I added basic support for the embedded "card reader" but did nothing for the actual embedded "smart card". ?I got very busy and didn't have time to pursue it. Understood.? Thanks for the update! > I will post a patch to the list in a day or so. Great, thank you! I did find someone else who seems to have made some progress: http://blog.go-lan.net/openct-ikey-4000-driver/ Although it looks like the iKey4000 comes in two flavors, one that is CCID-compliant, and one that isn't? 04B9:1206 - no CCID, not supported 04B9:1400 - CCID, supported by libccid? (This is from http://wiki.debian.org/Smartcards ) There also seems to be one commercial outfit that offers such a driver, but I wasn't able to read their web page very well (I don't speak Czech, and the Google translate version is only somewhat helpful): http://www.dignita.cz/produkty/linux-driver-pro-ikey4000 Anyway. Thanks again for any help you can offer. Best regards, Anthony Foiani From ludovic.rousseau at gmail.com Mon Feb 27 07:49:47 2012 From: ludovic.rousseau at gmail.com (Ludovic Rousseau) Date: Mon, 27 Feb 2012 08:49:47 +0100 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> Message-ID: Le 27 f?vrier 2012 01:54, Anthony Foiani a ?crit : > Although it looks like the iKey4000 comes in two flavors, one that is > CCID-compliant, and one that isn't? > > 04B9:1206 - no CCID, not supported > 04B9:1400 - CCID, supported by libccid? > > (This is from http://wiki.debian.org/Smartcards ) The second one is listed in the "Should work but untested by me" CCID list http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400 So it should work out of the box with my CCID driver. Bye -- ?Dr. Ludovic Rousseau From anthony.foiani at gmail.com Mon Feb 27 17:46:23 2012 From: anthony.foiani at gmail.com (Anthony Foiani) Date: Mon, 27 Feb 2012 10:46:23 -0700 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> Message-ID: Ludovic -- On Mon, Feb 27, 2012 at 12:49 AM, Ludovic Rousseau wrote: > The second one [04B9:1400] is listed in the "Should work but untested by me" CCID list > http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400 > > So it should work out of the box with my CCID driver. That's fantastic. Now to see if there's an easy way to tell the difference between these two types of iKey4000... Thanks again! Best regards, Anthony Foiani From awalls at md.metrocast.net Mon Feb 27 18:15:42 2012 From: awalls at md.metrocast.net (Andy Walls) Date: Mon, 27 Feb 2012 13:15:42 -0500 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> Message-ID: Anthony Foiani wrote: >Ludovic -- > >On Mon, Feb 27, 2012 at 12:49 AM, Ludovic Rousseau > wrote: >> The second one [04B9:1400] is listed in the "Should work but untested >by me" CCID list >> http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400 >> >> So it should work out of the box with my CCID driver. > >That's fantastic. > >Now to see if there's an easy way to tell the difference between these >two types of iKey4000... > >Thanks again! > >Best regards, >Anthony Foiani The output of lsusb -v should tell you, IIRC. If it is the CCID variant, lsusb should be able to tell you it is CCID. Regards, Andy From ludovic.rousseau at gmail.com Mon Feb 27 18:15:43 2012 From: ludovic.rousseau at gmail.com (Ludovic Rousseau) Date: Mon, 27 Feb 2012 19:15:43 +0100 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> Message-ID: Le 27 f?vrier 2012 18:46, Anthony Foiani a ?crit : > Ludovic -- > > On Mon, Feb 27, 2012 at 12:49 AM, Ludovic Rousseau > wrote: >> The second one [04B9:1400] is listed in the "Should work but untested by me" CCID list >> http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400 >> >> So it should work out of the box with my CCID driver. > > That's fantastic. Thanks :-) > Now to see if there's an easy way to tell the difference between these > two types of iKey4000... You can use the "lsusb" command on GNU/Linux to display the USB Vendor ID and Product ID. But you need to _have_ the device first. So not really helpful if you want to by one, unless you are allowed to bring it back and get your money. Bye -- ?Dr. Ludovic Rousseau From anthony.foiani at gmail.com Mon Feb 27 19:23:22 2012 From: anthony.foiani at gmail.com (Anthony Foiani) Date: Mon, 27 Feb 2012 12:23:22 -0700 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> Message-ID: Andy, Ludovic -- On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau wrote: > Le 27 f?vrier 2012 18:46, Anthony Foiani a ?crit : >> Now to see if there's an easy way to tell the difference between these >> two types of iKey4000... > > You can use the "lsusb" command on GNU/Linux to display the USB Vendor > ID and Product ID. > But you need to _have_ the device first. So not really helpful if you > want to by one, unless you are allowed to bring it back and get your > money. The situation is actually a bit worse. I'm working with an organization that has already standardized on the iKey4000 and has already issued them and integrated them into other parts of their infrastructure. I do have a handful of samples, but if both types are already out in the field, then I need a solution that can accomodate both. :( I read that SafeNet was open to providing the necessary documentation under NDA; that might be one route. Someone else also mentioned that they have been able to communicate with an iKey4000, but it's not clear which variety they are using. Thanks very much for the help so far; I'll see what else I can find out. Best regards, Anthony Foiani From akroehnert at go-lan.net Mon Feb 27 19:54:58 2012 From: akroehnert at go-lan.net (Andreas Kroehnert) Date: Mon, 27 Feb 2012 20:54:58 +0100 (CET) Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: Message-ID: <9c317e78-69e7-47c7-bf99-23d3f264312a@ahmshere> Hi Anthony, I think its more beneficial to respond to this list, rather than just your comment you left on the blog. The little OpenCT patch I've done was originally done for the "standard" ikey 4000 (04b9:1206). But should also work for the "non-standard" one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000) Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid. While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected. It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now. So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card. I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days. Kind Regards Andreas From anthony.foiani at gmail.com Mon Feb 27 20:33:04 2012 From: anthony.foiani at gmail.com (Anthony Foiani) Date: Mon, 27 Feb 2012 13:33:04 -0700 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: <9c317e78-69e7-47c7-bf99-23d3f264312a@ahmshere> References: <9c317e78-69e7-47c7-bf99-23d3f264312a@ahmshere> Message-ID: Andreas, greetings -- On Mon, Feb 27, 2012 at 12:54 PM, Andreas Kroehnert wrote: > Hi Anthony, > > I think its more beneficial to respond to this list, rather than just your comment you left on the blog. Of course. Thank you for replying so quickly and so thoroughly! > The little OpenCT patch I've done was originally done for the "standard" ikey 4000 (04b9:1206). But should also work for the "non-standard" one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000) Yes, it's a mess. It seems that SafeNet has sold a few different combinations of reader+smartcard all under the "iKey4000" name. Their NDA requirements might even be driven by the variety of suppliers... I just went through and checked my 6 samples: they're all 0x1206 variants. > Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid. > > While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected. > > It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now. Hm. Maybe these are enough hints for me to do some digging on my own. I won't be able to look at it in detail for a few weeks yet; I was sending out emails to try to get a sense of where the community stands regarding support for this token. > So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card. Right. I'm looking forward to seeing your code, when you get the opportunity to rebuild that RAID... > I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days. Ouch, sorry to hear about that. That never happens at a convenient time, does it... Thanks once again for your help! Best regards, Anthony Foiani From deengert at anl.gov Mon Feb 27 21:55:33 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 27 Feb 2012 15:55:33 -0600 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: <9c317e78-69e7-47c7-bf99-23d3f264312a@ahmshere> References: <9c317e78-69e7-47c7-bf99-23d3f264312a@ahmshere> Message-ID: <4F4BFBD5.2080609@anl.gov> On 2/27/2012 1:54 PM, Andreas Kroehnert wrote: > Hi Anthony, > > I think its more beneficial to respond to this list, rather than just your comment you left on the blog. > > The little OpenCT patch I've done was originally done for the "standard" ikey 4000 (04b9:1206). But should also work for the "non-standard" one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000) > > Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid. > > While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected. > > It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now. PIV? Really? If so it should respond to the NIST 800-73 part 2 SELECT Card Command with the AID of the PIV application. You can try this opensc-tool command to see if it responds with a PIV application on the device: opensc-tool -s 00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00 What does it return? If their goal is to have this device as a PIV and usable on Windows, I would expect to be CCID as well. > > So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card. > > I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days. > > Kind Regards > Andreas > > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert at anl.gov Mon Feb 27 22:28:30 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 27 Feb 2012 16:28:30 -0600 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: <4F4BFBD5.2080609@anl.gov> References: <9c317e78-69e7-47c7-bf99-23d3f264312a@ahmshere> <4F4BFBD5.2080609@anl.gov> Message-ID: <4F4C038E.5050000@anl.gov> This document found by Google, and located at NIST, has some interesting information: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp943.pdf It looks like it defines many of the additional provisioning commands (But does not list the actual APDUs for these) that would allow the iKey400 to act like a PIV card after it had been provisioned. On 2/27/2012 3:55 PM, Douglas E. Engert wrote: > > > On 2/27/2012 1:54 PM, Andreas Kroehnert wrote: >> Hi Anthony, >> >> I think its more beneficial to respond to this list, rather than just your comment you left on the blog. >> >> The little OpenCT patch I've done was originally done for the "standard" ikey 4000 (04b9:1206). But should also work for the "non-standard" one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000) >> >> Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid. >> >> While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected. >> >> It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now. > > PIV? Really? If so it should respond to the NIST 800-73 part 2 > SELECT Card Command with the AID of the PIV application. > You can try this opensc-tool command to see if it responds > with a PIV application on the device: > > > opensc-tool -s 00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00 > > What does it return? > > If their goal is to have this device as a PIV and usable on Windows, > I would expect to be CCID as well. > >> >> So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card. >> >> I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days. >> >> Kind Regards >> Andreas >> >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel at lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel >> >> > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From awalls at md.metrocast.net Tue Feb 28 11:33:49 2012 From: awalls at md.metrocast.net (Andy Walls) Date: Tue, 28 Feb 2012 06:33:49 -0500 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> Message-ID: <1330428831.2483.20.camel@palomino.walls.org> On Mon, 2012-02-27 at 12:23 -0700, Anthony Foiani wrote: > Andy, Ludovic -- > > On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau > wrote: > > Le 27 f?vrier 2012 18:46, Anthony Foiani a ?crit : > >> Now to see if there's an easy way to tell the difference between these > >> two types of iKey4000... > > > > You can use the "lsusb" command on GNU/Linux to display the USB Vendor > > ID and Product ID. > > But you need to _have_ the device first. So not really helpful if you > > want to by one, unless you are allowed to bring it back and get your > > money. > > The situation is actually a bit worse. I'm working with an > organization that has already standardized on the iKey4000 and has > already issued them and integrated them into other parts of their > infrastructure. I do have a handful of samples, but if both types are > already out in the field, then I need a solution that can accomodate > both. :( Well, you'll have to build a solution that proerly layers and abstracts the "reader" from the "smart card" that will be difficult. The CCID version (which I don't have) likely follows the USB CCID specification: http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf The non-CCID version certainly does not. From bogus@does.not.exist.com Wed Feb 8 15:49:00 2012 From: bogus@does.not.exist.com () Date: Wed, 08 Feb 2012 15:49:00 -0000 Subject: No subject Message-ID: verdor proprietary protocol. All transfers occur on the USB control pipe with only a 1 or 2 transactions not using a USB vendor proprietary protocol. The end part of a control packet from USB host to device in the protocol are used to specify the command to the device and indicates if a command is for: 1. the device itself (neither reader nor smartcard from what I can guess) 2. the reader 3. the smart-card (PDUs encapsulated in T=1 transport IIRC) Manipulating the reader and device itself isn't all that interesting. The Transport PDU encapsulation and some of the APDUs are clearly following the ISO standards. However, there are a number of what appear to be vendor proprietary APDUs. I personally think implementing support for the iKey4000 "smart card" is hopeless without documentation from SafeNet. If this is really for a business, contact SafeNet and ask if they have a solutions partner that can develop a Linux solution for your organization. It will likely be money well spent, compared to the labor hours you will burn through trying to implement something with no documentation. If Open Source is important to you for long term supportability in house, maybe you can inquire about the cost of the solutions partner implementing an open source solution for you. Regards, Andy From awalls at md.metrocast.net Tue Feb 28 11:53:41 2012 From: awalls at md.metrocast.net (Andy Walls) Date: Tue, 28 Feb 2012 06:53:41 -0500 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: <1330428831.2483.20.camel@palomino.walls.org> References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> <1330428831.2483.20.camel@palomino.walls.org> Message-ID: <1330430022.2483.22.camel@palomino.walls.org> On Tue, 2012-02-28 at 06:33 -0500, Andy Walls wrote: > On Mon, 2012-02-27 at 12:23 -0700, Anthony Foiani wrote: > > Andy, Ludovic -- > > > > On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau > > wrote: > > > Le 27 f?vrier 2012 18:46, Anthony Foiani a ?crit : > > > > The situation is actually a bit worse. I'm working with an > > organization that has already standardized on the iKey4000 and has > > already issued them and integrated them into other parts of their > > infrastructure. I do have a handful of samples, but if both types are > > already out in the field, then I need a solution that can accomodate > > both. :( > > Well, you'll have to build a solution that proerly layers and abstracts > the "reader" from the "smart card" that will be difficult. Sorry, I meant to type: 'You'll have to build a solution that properly layers and abstracts the "reader" from the "smart card"'. Regards, Andy From anders.rundgren at telia.com Tue Feb 28 14:47:19 2012 From: anders.rundgren at telia.com (Anders Rundgren) Date: Tue, 28 Feb 2012 15:47:19 +0100 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: <1330430022.2483.22.camel@palomino.walls.org> References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> <1330428831.2483.20.camel@palomino.walls.org> <1330430022.2483.22.camel@palomino.walls.org> Message-ID: <4F4CE8F7.3060205@telia.com> On 2012-02-28 12:53, Andy Walls wrote: > On Tue, 2012-02-28 at 06:33 -0500, Andy Walls wrote: >> On Mon, 2012-02-27 at 12:23 -0700, Anthony Foiani wrote: >>> Andy, Ludovic -- >>> >>> On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau >>> wrote: >>>> Le 27 f?vrier 2012 18:46, Anthony Foiani a ?crit : > >>> >>> The situation is actually a bit worse. I'm working with an >>> organization that has already standardized on the iKey4000 and has >>> already issued them and integrated them into other parts of their >>> infrastructure. I do have a handful of samples, but if both types are >>> already out in the field, then I need a solution that can accomodate >>> both. :( >> >> Well, you'll have to build a solution that proerly layers and abstracts >> the "reader" from the "smart card" that will be difficult. > > Sorry, I meant to type: > > 'You'll have to build a solution that properly layers and abstracts > the "reader" from the "smart card"'. Or convert it to PIV as Douglas indicated is supported. Then you get built-in support from at least Apple and Microsoft. Regards, Anders > > > Regards, > Andy > > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel From deengert at anl.gov Tue Feb 28 15:43:23 2012 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 28 Feb 2012 09:43:23 -0600 Subject: [opensc-devel] OpenSC support for iKey4000? In-Reply-To: <4F4CE8F7.3060205@telia.com> References: <3bd8dcd0-7af1-40de-a50e-f138993b56f4@email.android.com> <1330428831.2483.20.camel@palomino.walls.org> <1330430022.2483.22.camel@palomino.walls.org> <4F4CE8F7.3060205@telia.com> Message-ID: <4F4CF61B.7070204@anl.gov> On 2/28/2012 8:47 AM, Anders Rundgren wrote: > On 2012-02-28 12:53, Andy Walls wrote: >> On Tue, 2012-02-28 at 06:33 -0500, Andy Walls wrote: >>> On Mon, 2012-02-27 at 12:23 -0700, Anthony Foiani wrote: >>>> Andy, Ludovic -- >>>> >>>> On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau >>>> wrote: >>>>> Le 27 f?vrier 2012 18:46, Anthony Foiani a ?crit : >> >>>> >>>> The situation is actually a bit worse. I'm working with an >>>> organization that has already standardized on the iKey4000 and has >>>> already issued them and integrated them into other parts of their >>>> infrastructure. I do have a handful of samples, but if both types are >>>> already out in the field, then I need a solution that can accomodate >>>> both. :( >>> >>> Well, you'll have to build a solution that proerly layers and abstracts >>> the "reader" from the "smart card" that will be difficult. >> >> Sorry, I meant to type: >> >> 'You'll have to build a solution that properly layers and abstracts >> the "reader" from the "smart card"'. > > Or convert it to PIV as Douglas indicated is supported. > Then you get built-in support from at least Apple and Microsoft. Its not just convert it to PIV, as PIV standards cover the card, not the reader. http://fips201ep.cio.gov/apl.php Lists "Rransparent Reader" which AFAIK does not a requirement CCID, allowing vendor to provide reader drivers.) (I don't see the iKey4000 on the list yet.) There is still the issue that some of these tokens appear to be CCID compliant, and some are not and you can not tell until you buy the token. The vendor could provide the Windows or Mac "reader" driver for the non-CCID tokens and still use the Microsoft or Apple PIV "card driver". (I am just speculating on this...) There are other readers vendors that provide drivers for their readers that are not CCID so why not this vendor. > > Regards, > Anders > >> >> >> Regards, >> Andy >> >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel at lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel > > _______________________________________________ > opensc-devel mailing list > opensc-devel at lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From bogus@does.not.exist.com Wed Feb 8 15:49:00 2012 From: bogus@does.not.exist.com () Date: Wed, 08 Feb 2012 15:49:00 -0000 Subject: No subject Message-ID: 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. //Peter From bogus@does.not.exist.com Wed Feb 8 15:49:00 2012 From: bogus@does.not.exist.com () Date: Wed, 08 Feb 2012 15:49:00 -0000 Subject: No subject Message-ID: 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 las= t common commit for OpenSC/OpenSC.git(staging) and gerrit's repo.
(By the way, this commit where not submitted to OpenSC.git by gerrit -- the= re 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 -- re= cently the OpenSC-staging was merged into OpenSC-SM).
- pick from the current gerrit's changesets the useful proposals and ap= ply them to this branch.
- re-install the Gerit's OpenSC project with the updated github reposit= ory.
- limit direct commits to github's OpenSC-staging (or replicate these c= hanges 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/jen= kins/, https://opensc.fr/gerrit/= -- still under construction),=A0 dedicated to the OpenSC-staging and=20 OpenSC-master. It's needed to implement the glaring lack of an actual= =20 jenkins -- the build of OpenSC linux packages.
=A0

//Peter

Kind wishes,
<= div>Viktor.
=A0
_______________________________________________
opensc-devel mailing list
opensc-devel at lists= .opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel<= /a>

--20cf307d01d80344a404bb3031fd-- From bogus@does.not.exist.com Wed Feb 8 15:49:00 2012 From: bogus@does.not.exist.com () Date: Wed, 08 Feb 2012 15:49:00 -0000 Subject: No subject Message-ID: 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,=A0 tra= nsfer the artifacts from one build to another, ...
For example, in=A0https://opensc.fr/= jenkins/=A0the build on two windows platform depend-on and triggered-by= the build on debian.=A0

In your list you mention Windows: 32 and 64 msi.
Will it be cross-compilation?

=A0

Kind regards,
--
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jean-Michel Pour=E9 - Gooze - http://www.gooze.eu

Kind wishes,
Viktor.


--f46d043c7c1c2dbc6b04bb5cea13-- From bogus@does.not.exist.com Wed Feb 8 15:49:00 2012 From: bogus@does.not.exist.com () Date: Wed, 08 Feb 2012 15:49:00 -0000 Subject: No subject Message-ID: "The problem is that getpass will not return empty string if return key is pressed on the computer keyboard." From bogus@does.not.exist.com Wed Feb 8 15:49:00 2012 From: bogus@does.not.exist.com () Date: Wed, 08 Feb 2012 15:49:00 -0000 Subject: No subject Message-ID: " The function getpass() returns a pointer to a static buffer containing (the first PASS_MAX bytes of) the password without the trailing new=E2=80=90line, terminated by a null byte ('\0'). " So the input should be a null string with getpass on Debian. But the man page also tells that "This function is obsolete. Do not use it." Martin