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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
