Hello, First, thank you for a constructive review.
On Aug 30, 2010, at 1:54 AM, Andre Zepezauer wrote: > I had a look at the NEWS file to see which improvements it will bring to us. > After reading > this list of changes some questions arises to me: NEWS file can be and probably is incomplete. But then again, it only lists the *user visible* changes. Most of the actual improvements (except for graphical installers) and changes inside are not user visible. NEWS file is morally outdated (it has long pointed to WhatsNew wiki page, that has not been updated in 4 years). > 1. From my perspective the most important improvements are bug fixes and > additional driver support. These could have done in a 0.11.x release > too. Therefore my first question is: Where are these major improvements, > which let to the API/ABI break in the upcoming version of opensc? And > why they are worth of doing so? The only external API and ABI is PKCS#11. And OS X Tokend implementation, but that does not care about internal API/ABI changes and needs to be upgraded anyway by OpenSC team to match any (usually unknown before release) changes by Apple Inc. That's a huge difference, as there are no longer external applications that link against libopensc (the choice to link against libopensc instead of a generic API like PKCS#11 is IMHO questionable from the beginning). Thus the whole topic of API/ABI becomes almost irrelevant. The last relevant OSS application to link against libopensc was OpenSSH up to version 5.3, which also moved to PKCS#11. Such changes need to be done at some stage to get rid of extra baggage and re-focus on what is relevant in the current moment. PKCS#11 has (finally) become more "accessible" and developers more aware of the better solutions for cryptographic hardware integration (PKCS#11, CryptoAPI, CDSA) > 2. The announcement of the GOST public key algorithm seems to me very > optimistic. Because the current implementation isn't functional at all > [1][2]. Good catch. > It would be very surprising to me, if there is at least one > single person who could explain (to an ordinary user) how to get this > stuff to work. Question: Why declaring such non functional stuff as a > new feature? AFAIK the only cards/tokens that support GOST seem to be Rutokens and thus we have to take the developers word on that as I have tried to get a Rutoken but those e-mails faded away, I did not get a reply from the vendor. I don't know anyone else on this list who has a Rutoken and could verify (or in that sense, care about) the functioning of GOST algorithms and key generation etc. What maybe needs to be done is better phrasing of what the actual "support for" means. There sure is code in OpenSC that deals with GOST algorithms, but how and where it is exposed, needs to be documented. Aleksey, can you explain the situation with GOST in more detail? > 3. The use of openssl in some drivers is also very questionable. For > example there are a handful of drivers which use openssl for every > cryptographic operation. That means, these drivers will extract the keys > from the card and operate with them on the host side. Please list the drivers, preferably with source links to insecure operations. OpenSC is supposed to work with keys in hardware, but due to several reasons there has been code in OpenSC that has not followed this principle. Some of it already got removed [1]. Working with plaintext keys in software needs to be made very clear, transparent and explicit. OpenSC is perceived as "software that works with smart cards" thus it is reasonable to expect for all (plaintext) key operations, unless otherwise noted or explicitly requested, to take place in secure hardware. Doing something else is a usability/security bug. > In combination > with the "insecure default setting" this makes card cloning an easy > task. Cloning assumes that there's already a lot wrong with the cards, the personalization process, the card driver as well as the user. Smart cards can't do miracles if other processes are out of sync with requirements. Nevertheless, software key generation or operation must be taken care of, so please provide links to suspicious source lines. > So, what could have been done in a new major version? Watching on the > list of open tickets, there are many issues besides graphical installers > and new drivers. Some suggestions: It would be nice if you could add ticket related comments directly to tickets as well. Also, feel free to provide fixes for any issues, as the pre-release is only meant to test the deliverability of OpenSC to different platforms. There are still many unfixed issues. But bug-free software is useless if you can't (easily) get it onto your computer and use it. > #70 is maybe not specific to mozilla. An entry in the configuration file > could help. It would empower the user to explicitly name the > applications for which the non-repudiation keys and certs are visible. Ideally, the user should NOT be forced to change anything in the configuration file, unless he/she really needs to cater to a specific usage scenario or needs to enable debug to troubleshoot an issue. Ideally, "well known, popular open source consumer software" (Firefox, Thunderbird, OpenSSH, OpenVPN... anything else?) should work flawlessly with standard configuration. Ideally, OpenSC PKCS#11 module should expose all on-card objects as specified in PKCS#11 v2.20 and without any tweaks. >From (EU) legal and technical perspective, it might make sense to limit >non-repudiation keys to certain applications. But how? By creating two PKCS#11 >modules, one with non-rep keys, one without? It might also make sense to have separate modules for key encryption keys only as well? The current approach of creating a hacked PKCS#11 module could be improved, and the selection of keys to go into a firefox-pleasing PKCS#11 module be made much more explicit. But better yet, Firefox/NSS should be fixed. As there's growing interest to use NSS on Linux [2], it should be an interesting challenge to anyone interested in great Linux compatibility of smart cards. IMHO, that's just a Firefox usability issue at the moment. > #110 would be nice, if a module written for "0.12" is working for all > 0.12.X releases Yes, it would be nice. But FWIW, the whole loadable module interface should be removed. We can now see that the original reason why it was added for only caused a fork of OpenSC code, distributed without source, and finally, after they were forced to release the code, with no intent of trying to work with the community to integrate things back into OpenSC [3]. I'm sure there will be people in Spain that will create an add-on package for DNIe, and we need to make it possible for them. But in the long run, there is no point in extra efforts for allowing companies to piggy-pack on OpenSC code for providing standard interfaces. We can't support users if they ask and it only obscures facts, as it makes OpenSC the culprit if the driver does not work. If you have a proprietary card, provide proprietary software to use it. Or provide open source driver in OpenSC, if you care about it. That's my personal opinion. > #151 is one of the most important issues of opensc. It is caused by the > fact, that opensc doesn't evaluate the pkcs15 structures on smart cards > very well. This prevents interoperability in both directions. Cards > initialised with opensc won't work with other libraries and vice versa. > Viktor Tarasov has supplied a first patch [4510]. A followup could be > found here [3]. In short: Not evaluating/populating the > supportedAlgorithms structure in TokenInfo makes it nearly impossible to > handle pkcs15 cards correctly. PKCS#15 compatibility enhancements are important. Your patch you referenced needs to be integrated/tested as well. I hope somebody else will voice their opinion about it, I have not found the time to cross-reference with PKCS#15 and the rest of the code to figure out the correctness of it. > #158 could be closed, because the named check is at the right place, and > should stay untouched Please update the ticket. I don't have any cards that suffer from the "split key" issue. > #220 seems to me, that the attached patch only works for pkcs11-tool. Correct. > What will happen if anybody wants to use this kind of token with > mozilla. Why not using the emulation layer? > p15card.flags |= SC_PKCS15_CARD_FLAG_LOGIN_REQUIRED Does not make sense, as the described (bogus) PKCS#11 module is for a HSM, not for a PKCS#15 card driver in OpenSC. It is the cryptoki application (pkcs11-tool) behavior that is tweaked [4]. > #252 the reporting user has a card initialised with software by siemens. > So this ticket doesn't belong to pkcs15init. Correct. More like a card driver issue. > The problem is caused by > the fact that opensc is evaluating the proprietary security attributes > of EF and DF (tag 86 in FCI) and not evaluating the > "CommonObjectAttributes.accessControlRules" Please update the ticket accordingly. I've heard from people using CardOS cards, that the problem with CardOS is the abundance of different configurations, which are difficult to detect precisely. > To summarise my impression of the upcoming 0.12.0 release, the feature > set is low. ... > The most user visible things are the graphical installers > and the support of new cards. That's exactly one of the main goals. > Other changes are bug fixes and small > improvements. Things that have could been done in 0.11.X releases too. None of the internal code shifts would have been feasible in the old tree, as a new 0.11.X release. > While there will be more supported cards in the new release, the support > of REAL pkcs15 cards is still the same. Which isn't impressive at all. The abundance of PKCS#15 emulation drivers in OpenSC is a sign that a) OpenSC PKCS#15 support needs improvements or b) strict PKCS#15 is always not important, as there are new emulation drivers but there are few core PKCS#15 changes. I believe the reason for sloppy PKCS#15 support has been the ignorance of PKCS#15 by card/software vendors and the interest of developers to get THEIR cards working (meaning accessible via PKCS#11 and/or usable with pkcs15-init) with as little effort as possible. Which can't be blamed per se. Please, if you feel you can help to improve things on the generic PKCS#15 level (what you have demonstrated with this e-mail), try to provide patches to make the PKCS#15 compatibility of OpenSC more impressive. > This will hopefully change in the next major release 0.13.0 which may be > years away. Remember that 0.11.0 was first released in the year 2006 > [4]. And we could have continued the 0.11.X line for another few years and end up with 0.11.37. Or we can have 0.17.X next year. There is a similar story on Linux 2.8/3.0 and what Linus thinks about it. One of my goals has been to refine the definition of "OpenSC software" and make it universally available to users. This means usable releases for major platforms downloadable from opensc-project.org, and a better understanding on what OpenSC is and what it is not. But apparently there is still a lot to do, as you can find new blog posts telling "... Then I installed OpenSC/OpenCT. For the reader I then installed pcsc-lite and libccid". As I wrote in a previous e-mail, having a framework to actually allow to roll out releases to all people and all supported platforms equally, without any lag, provides the foundation to to speed up the release cycle, without the users having to figure out what release of SCA os SCB or SCX contains the relevant OpenSC release he/she is after. We *need* to be able to *deliver* OpenSC to people, for OpenSC to be successful. And not as a niche product for Linux and Unix freaks, but as a relevant open source software generally useful with smart cards, for both pre-personalized cards and with PKCS#15 (or at least close/partial) personalization capabilities. Yes, there are bugs and issues and whatnot, but if it is difficult to grab the latest software for your platform, try it out and see if it works for you or not, we will not gain new users. Potential contributors usually come from among users. Contributors fix issues. > Another point to mention is, that non of the upcoming releases has > improved support of real pkcs15 cards as it's goal [5]. Changing this, > could be a good point to start to make opensc more interoperable with > well initialised pkcs15 cards. See above. If you feel it is important and you think you can help, your contributions are most welcome. I can only say that "PKCS#11 v2.20 compliance validation" and "PKCS#15 conformance improvements" could be permanent sub-goals of OpenSC releases. Thanks, Martin [1] http://www.opensc-project.org/opensc/changeset/4646 [2] https://wiki.mozilla.org/NSS_Shared_DB [3] http://www.opensc-project.org/opensc/ticket/205 [4] http://www.opensc-project.org/opensc/ticket/220#comment:3 -- Martin Paljak @martinpaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
