On Mon, 2010-08-30 at 12:40 +0300, Martin Paljak wrote: > 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.
The handful of drivers with insecure operations I was talking about, I got with the following command: grep -n OPENSSL libopensc/card-*.c But looking closer to each drivers source, I must confess that there are only two of them affected: http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-westcos.c#L1244 http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-rutoken.c#L1376 > 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 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
