On Tue, 2010-07-20 at 18:16 +0300, Martin Paljak wrote:
>
> If you plan to provide higher level GNOME API-s, my suggestion would
> be NOT to piggyback on PKCS#11. You may end up abusing it. If the
> specification tells that pReserved should be NULL, it really should be
> NULL. There are PKCS#11 providers with additional functions to support
> specific key activation authentication. The end result is something
> that's pkcs11-ish but is not PKCS#11. Yes, there can be many
> interpretations of a specification but it is best to KISS. Best for
> interoperability and best for developers, who don't need to guess but
> have explicit API-s and explicit conformance. If you need to work with
> PKCS#11, work with it like the PKCS#11 Tokend [4] does: just create a
> provider for your framework that can be used to pump in PKCS#11 based
> keys. And PKCS#11 won't provide for anything else but key access. If
> application will anyway need to use GNOME API-s, you can forget as
> much as you want about PKCS#11. If PKCS#11 is a concept that the
> developer should know, pkcs11-help
> er or libp11 can be used to help them.
+1
Maybe the API shoud be able to manage a smartcard, i.e. erase,
initialize, set pin, transfer certificates, etc ... So you can build a
nice management interface in Seahorse.
Kind regards,
--
Jean-Michel Pouré - Gooze - http://www.gooze.eu
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
