"Zeljko Vrba" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
IMHO, PKCS#11 has succeeded where ISO7816 has failed: providing a
(relatively) simple way to interface with many smart-card
implementations, many of which aren't ISO7816-compliant above level 3 -
they even don't support basic interindustry commands, but provide their
own proprietary and undocumented command set
PKCS#11 is a crypto token enchange system
ISO7816 is a specification for a card interface.
They are 100% unrelated. Perhaps you meant the abondoned PKCS#13 which is
what many cards use.
*PKCS#11 has nothing at all to do with smartcards.*
The fact that many propretary card drivers export a PKCS #11 interface is
mearly coincedence.
That said, I think allowing a pkcs #11 interface as well as OpenPGP Card
interface is useful in its own right.
Doesn't gpgsm support PKCS#11?
One of the larger reasons why Werner is probably reluctant to support
PKCS#11 in GPG is that X509 (which pkcs#11 is almost always used with) does
not interface well with OpenPGP. It makes beteter sense to have a seperate
X509 key, rather than use your key for both X509 and OpenPGP. For example,
your CA can revoke your key leaving you with one key that is invalid X.509,
but valid OpenPGP? Yuck!
Werner designed the OpenPGP Card such that the interface works well with
OpenPGP. OpenPGP cards are intended to be used for authentication and
OpenPGP only. They are not designed for things such as SSL, SSH, TLS, S/MIME
, or any other cyrptographic purpose. It is important to ensure that people
do not confuse X.509 and OpenPGP, but implementing PKCS#11 in gpg may blur
things too much.
Besides it is hard enough to support just one card, imagine the problems
that could arise if people started using cards with broken PKCS#11 drivers,
and asssumed the problem was in gpg.
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
