Hello,
On Dec 13, 2010, at 10:30 PM, Frank Morgner wrote:
>>>>> You're not supposed to link against libopensc via the sc_* API but use
>>>>> PKCS#11. It is possible but not encouraged, thus the .pc file is
>>>>> removed.
>>>>
>>>> Why is it not encouraged?
>>
>> The effort that would be required to have a well designed and
>> documented public API and maintain required backwards-compatibility is
>> not comparable to the benefits it would bring. OpenSC does not really
>> have a public API, there's a bunch of sc_* prefixed functions that
>> help to achieve stuff with smart cards, but it is not really
>> consistent. OpenSC is for PKCS#15 cryptographic smart cards. So the
>> API OpenSC should expose should only be the sc_pkcs15_* bunch of
>> functions it actually exports?
>>
>> Compare it to OpenCT. OpenCT has an API (I'd say better one than
>> libopensc) but it "is not an API". I would not encourage anyone to
>> build anything new against OpenCT unless they know what they are
>> doing. Yet it can't be forbidden, and people DO build new things
>> against OpenCT (embedded mostly) even if PC/SC is the preferred API
>> because a) it is accepted as an API by many developers, on many
>> platform b) it is designed, to some extent c) it is documented. Thus
>> it is useful to a greater audience.
>
> A good API should be the aim of good Software. If libopensc's API is
> broken, go fix it!
You are absolutely right. But by declaring PKCS#11 (or CDSA, or CryptoAPI) as
the outside API, we settle on accepted, defined API-s developers already know
and applications already implement.
Disconnecting the internal libopensc API from commitments to the outside world
gives a better position to re-work (lib)OpenSC internals (which is needed for
many things) in a flexible way, without external constraints.
You are most welcome to help improve the (lib)OpenSC API-s to better suit your
requirements, taking into account that most external consumers use (and IMHO
should use) established API-s like PKCS#11, CDSA or CryptoAPI to access smart
cards supported by OpenSC, instead of sc_* API.
> API changes are no problem as long as there are not too many changes.
> For example, it was only this year when OpenSSL decided to provide
> compatibility with future releases (although the project is already 12
> years old). Maybe it takes some time, but only if someone uses your
> software, you can discover problems.
Software projects that have linked against libopensc, which I'm aware of
(search the mailing list, it has been discussed several times before over the
past few years), usually required access to smart cards for signature or
decryption purposes.
Some small utilities also used the sc_* api to transfer APDU-s to cards (like
the transmit_bytes patch you have).
"I need SHA1 hashes, I search the web for "Open SHA1 library" and link against
OpenSSL, done", "I need access to a key on a smart card, I search the web for
"Open smart card library" and link against libopensc, done".
People working on embedded platforms often curse developers for such decisions
as if you only require a SHA1 function, the sha1.c can be way-way smaller than
the full OpenSSL dependency.
This kind of activity is what needs to be avoided by not encouraging linking
against libopensc. Unless you know what for (read below)
AFAIK, all those software packages are by now either obsolete or replaced their
interface to PKCS#11 for a good reason: linking against libopensc for smart
card access means vendor lock-in.
OpenSSH is a good example, which had a semi-broken OpenSC linkage that received
almost no attention from OpenSSH developers but now is quite cool with PKCS#11
support. That works with numerous cards (or HSM-s if you want) that are not
supported by OpenSC and probably would never become supported, as they are
proprietary.
Unfortunately I'm not aware what exactly is the vsmartcard project you're
working on (I don't have a German passport) other than it includes terminal
support and requires additions to OpenSSL for some algorithms which are not
there yet.
I don't know what is the feature you provide to the external world, that would
be interesting and useful to the users of the vsmartcard project.
Your usage scenario is not the same as "requires access to cryptographic
operations on a smart card supported by OpenSC" so you fall into the 1 out of
10 category who probably have a good reason to actually use libopensc instead
of PKCS#11.
Please help me (and probably others) understand and/or give pointers to
reading materials.
> If some things are undocumented, read the source! No problem with that,
> too.
Not some things, most things. Even the ohloh stats for OpenSC [1] tell:
• Mostly written in C
• Mature, well-established codebase
• Increasing year-over-year development activity
• Large, active development team
----> • Few source code comments
"Few source code comments" being the only "warning mark" for OpenSC.
There was some documentation for sc_ functions in opensc.h (distributed as
man(3) pages, now removed), but IMHO that targets the wrong layer of OpenSC.
Emphasis should be on PKCS#15 layer API (pkcs15.h) and that's mostly
undocumented. It is also somewhat incomplete, as has
been demonstrated by Andre and Douglas and Viktor. By writing documentation for
the internal API-s (even adding doxygen comments with a curious and questioning
mindset) would greatly improve the internal documentation and probably find
inconsistencies or other questionable details.
>> Exposing a kitchen sink API is not a good idea. Building against one
>> is not a good idea either. Code re-use (using code from OpenSC) is a
>> different thing than claiming libopensc to be a public library, with a
>> public API. Developers should know how to re-use code without the
>> public library. Distributing a -dev library with a .pc file would be
>> comparable to _asking_ people to link against libopensc, and I guess 9
>> times out of 10 that would not be a good choice.
>
> So I have three possibilities:
>
> 1. Do some magic to use libopensc nevertheless.
> But why should I do this if you're essentially telling me "go away"? I
> can't really expect from you to include new functionality or to adjust
> things, since you are only interested if it concerns OpenSC's internals.
I hope this is not the impression you got :) My personal message should read
"help me understand your goal and through this improve things together".
OpenSC could easily have a public API other than PKCS#11 (or CDSA, or
CryptoAPI) but this should be re-created step-by step, by carefully evaluating
WHAT the libopensc API is, instead of just exposing everything to the outside
world.
A non-standard external consumer (who is not interested in the common
functionality that is present in PKCS#11, CryptoAPI and CDSA) would greatly
help in that matter.
As said, linking against libopensc _for smart card crypto access_ should not be
encouraged for developers coming from Google searches, but this should not be
made impossible on purpose.
> 2. Stay entirely in OpenSC and submit a patch.
> For me this is not an option. What I want to do is too much to be
> included in OpenSC. For example, I wrote a library based on libopensc to
> access the new German identity card (nPA). So far so good, this could be
> integrated into libopensc (which I once intended to do). But I need to
> access this functionality with standard smart card operations from a
> smart card reader emulator, which would pretty much require to access
> libopensc.
This is the problem. For now I've seen three distinct groups of developer
interested in OpenSC:
1. "External developers with no real interest about OpenSC" - "I don't really
care about the details, just let me use smart cards to do my crypto". They
should use PKCS#11, CryptoAPI or CDSA, depending on their requirements and
environment.
2. "Internal developers" - "pinpads, different algorithms, severla cards,
extended APDU-s, PKCS#15, PKCS#11 v2.30, new hashes, all that interesting
stuff, needs to be supported by OpenSC". This should be opensc-devel crew, for
core development and support for the next group.
3. "Developers, with unsupported cards" - "I have a smart card I'd like to add
support for in OpenSC, to allow other developers write code for accessing the
cards by using PKCS#11 (or CDSA, or CryptoAPI) and users use existing
applications with the card". People who write and maintain card drivers for
OpenSC, like me (Estonian eID), Douglas (PIV), Aleksey (Rutoken), Joao
(Portuguese eID) Juan Antonio (Spanish eID), Stef (left the project, but
Belgian eID) and several others, who should be credited accordingly in the wiki
and source code. This is the biggest group of developers actually and a quite
frequently asked question ("I have a card, what do I need to do to add support
for the card in OpenSC?") that unfortunately lacks nice documentation or
tutorial.
Other than "support for German identity card (nPA)", which falls under group 3,
your requirements apparently differ from what is common. It would help if you
explained it either in a higher level overview or in more detail (or from a
different angle).
> 3. Use an own implementation probably duplicating code from OpenSC
> One job, one program! Duplicating code duplicates problems. That's why I
> avoided this so far. But seems like this is the only viable option.
One common way of code sharing in corporate environments is via svn:externals.
While there could be better methods, it achieves the goal of not duplicating
code while also not creating external dependencies and still allowing code
re-use.
> I think this makes OpenSC less usable. Less usable means less
> participation. I have committed several patches to OpenSC, _because_ I
> was using it. I cannot speak for anybody else, but with the current
> development you are at least loosing me.
Using the internet language:
tl;dr explain your usage scenario and requirements, which will make patches and
requirements more obvious and understandable. How could I use vmsartcard
project to see what it does, why and how, without having a German nPA card?
What would others get from it?
>
>> PKCS#11 has the same characteristics as PC/SC. While not the best or
>> most flexible, it is the best we have. I think GnomeKeyring is one of
>> the best examples why interoperability matters and how it can help get
>> things done in real life.
>
> I don't think I understand this. What does hiding functionality have to
> do with interoperability?
I meant interoperability AND modularity. Smart cards should be a commodity (the
world is moving towards this at least) and one property of a commodity is the
possibility to replace the provider.
Take electricity: there are a few different plug types and a different voltage
levels, but that's just a handful. You can plug and play a lot of devices
without requiring knobs on the wall outlet to tune the frequency and voltage.
Yes, there are a lot of power adapters for devices but to date only specialized
setups like data centers have deemed useful to work on DC instead of AC.
[1] http://www.ohloh.net/p/7659
--
@MartinPaljak.net
+3725156495
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
