On Jul 20, 2010, at 7:42 PM, Jean-Michel Pouré - GOOZE wrote: > 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.
As I wrote before, I still believe that personalization/enrollment/key generation is a) sensitive b) complicated c) specific (technically) d) varying (procedurally). From API perspective, I don't think there will be so many GNOME applications that will want to *generate* keys or programmatically change token PIN codes. Key generation to "somewhere secure" is not the same as token personalization (compare the host keys that are generated when installing OpenSSH to company-wide client certificates/keys/cards). Nor is it the same as managing TPM-s for example. Don't mix up API-s and GUI-s. From API perspective, OpenSC already provides an API (either hidden in libopensc or somewhat functioning via PKCS#11) for personalizing tokens. But you're right, there's no nice GUI with functionality like pkcs15-init provides. That's a deficiency. The generic rule is that 99% of (smart card) use cases spend 99% of the time using keys and only 1% of time (once) generating them. -- Martin Paljak @martinpaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
