OpenPGP Card

[Alon Bar-Lev]

Joe Smith wrote:

> *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.

PKCS#11 and Microsoft cryptographic providers are the two APIs available for
accessing cryptographic tokens.
Every application that wishes to use services of vendor in depended
cryptographic tokens uses one of these APIs.
So vendors that developing smartcard provide these interfaces so their card
will be usable.
Enterprises (which are the larger clients) will not but a smartcard that
does not 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 separate 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!

I think you got revocation wrong... Revocation is letting OTHERS know that a
key should not be trusted... There is nothing wrong in leaving the private
key in the smartcard.
Regardless this point PKCS#11 token can be organized that the same X.509 and
PGP certificates will refer to the same private key, so if that private key
is deleted both certificate will be unusable.

> 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 cryptographic 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.

But each user should have one smartcard... It is not logical to force user
to keep several cards in his wallet in order to use several applications.
One smartcard can be used to have tree types of identities: Authentication,
Signature (Email and data), Decryption (Email and data). There is no reason
to divide these into several physical containers.
Users will simply select a different software which can access the same card
as other software...
Application that forces users to use a specific exclusive card will slowly
vanish.

> 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. 

But this is exactly the point!
You should not develop low-level code to access each card's processor in
order to add the ability to work with smartcards, resulting in N separate
implementations.
You can benefit from the PKCS#11 high-level API in order to access
cryptographic tokens (Smartcards, HSM, software).
PKCS#11 is a standard that most vendors support, I can agree that if vendor
did not implement the standard correctly, its token will not work with
applications. For example, Mozilla Firefox will not work with some of the
smartcards out there... And I have no claims to Mozilla, they have done a
great job!

Best Regards,
Alon Bar-Lev.