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
