Alon Bar-Lev wrote:
When you raise this issue... It seems that PKCS#11 is not implemented not because of licensing problems... But because if PKCS#11 will be implemented then there will be no work to be done for each specific card...
But this strategy can, and <crystal_ball_mode> will </crystal_ball_mode> backfire :) From personal experience, companies are much more likely to choose a standard, interoperable solution (-> PKCS#11 -> X.509) than paying for a proprietary[1] solution. [1] In a sense that I can't describe exactly, OpenPGP card + GnuPG feels more proprietary than any closed-source smart card with PKCS#11 driver provided. The metric of 'proprietary-ness' would be in this case: the number of different smart-cards and interfaces supported by GnuPG. IMHO, the overall situation would get better for GnuPG and OpenPGP card if someone wrote a GPL-compatible PKCS#11 driver for the OpenPGP card. Then: a) OpenPGP cards can be used by other applications, not just GnuPG. (OK, they can be used in other applications even now, but noone sane will write card-specific code when they can use a high-level, universal API like PKCS#11). b) GnuPG switches to PKCS#11 and uses the GPL-compatible PKCS#11 for the OpenPGP card. It doesn't even have to dynamically link to it. As Alon did remark earlier, the general movement in the industry is towards multi-purpose smart-cards. OpenPGP card currently doesn't fall into this category.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
