Dear Andreas, it is not uncommon to place two application DF on the card, one for electronic signatures based on a qualified certificate and one for signatures, authentication and encryption using a non-qualified certificate. The main reason for doing this in separate applications is, that the application for secure signatures based on a qualified certificate usually needs a security evaluation according to some national law or the European signature directive, while the other does not.
Most card suppliers have such an evaluated standard signature application (mostly based on DIN 66291 or CWA14890/eSignK), making it easy for certification authorities to integrate their card. However, most users also want to use the same card for electronic signatures based on a non-qualified certificate. These applications are then commonly used for client/server authentication, message integrity and encryption. I guess a good example is the upcoming German health insurance card and the health professional card. Both have separate applications, one for electronic signatures based on a qualified certificate (DF_QES) and one for simple signatures, client/server authentication and encryption (EF_ESIGN). The Austrian e-card is build in a similar way. In an ideal world, all applications on a card would be listed in the EF_DIR and each application would have it's own PKCS#15/ISO 7816-15 meta-data to describe it's keys, pins and data objects. A generic middleware like OpenSC could then use this meta-data and offer objects on the card to higher application layers (e.g. though PKCS#11) - Unfortunately we are not living in an ideal world and card application designers still tend to ignore ISO 7816-15. Andreas Andreas Jellinghaus schrieb: > Does anyone have a card with two confliciting applications? > How common are cards with two applications? > Why would anyone put two applications on one card? > > I'm scared we might fall for an overengineering trap here, > so lets first see if there is a real world problem, and what > the easiest solution to this is. > > I can understand that people might put a wallet and signature > keys on the same card - even if I think that is not wise - > but that shouldn't harm opensc - it could simply ignore the > wallet which it can't use anyway. > > But why would someone put two "application" on a card both > with keys for signing/encryption? ok, german qualified signature > cards (at least mine) have three keys with different pin numbers, > but it still is one "application" as far as I understand. why > would anyone have two? > > and if so, why can't this be handled with a config file entry? > sure, you wouldn't see the other app unless you knew about it > and changed the config file. > > I don't know this whole topic well. if you tell me it is a real > world problem for lots of people with cards in their hand, then > lets fix it right away as good as possible. but if it is only a > theoretical problem: please don't invest any work in it. > > for example in theory it might be possible to get a qualified > signature card with official signed and blessed keys and certs > and then also put your own private pkcs#15 structure on it side > by side. in practice that is a scenario we do not need to support > at all. > > my experience talking to users so far is already this: smart cards > are already far to complex, and thats one of the reasons why people > don't use them as much as they could (IMO should). lets not add > complexity unless we are sure it is needed. > > Regards, Andreas > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 171 8334920 --------- http://www.cardcontact.de _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
