On Mar 28, 2010, at 11:39 , Jean-Michel Pouré - GOOZE wrote: > On Sun, 2010-03-28 at 11:21 +0300, Martin Paljak wrote: >> Terms such as "smart card GUI" and "smart card application" are really >> vague, especially if you're talking about smart cards with >> PKI/cryptography in mind. > > Sorry, I meant a graphical interface to pkcs15-tool and pkcs15-init. I > was thinking of gpa (GNUPG Assistant) card manager tool. Run gpa and > then Window->Card manager.
I don't know of such tools. > Basically the manager should be able to: > * Erase and initialize a card. > * Create RSA keys on computer or on card. > * Create X.509 certificates on computer or on card. > * Revoke certificates. > * Remove and transfer objects on card. > > Therefore, building on top of seahorse or Gnomint seemed to me a good > idea. This is the idea of Unix to rely on commands. IMHO it is important to have a distinction between PKI setups and "noPKI" setups. If you're looking for a real full PKI solution, that also manages smart cards, you probably want a full-blown CA infrastructure with CRL-s/OCSP-s/LDAP-s and everything that comes with maintaining a CA. CA functionality (dealing with certificates) does not make sense otherwise - there's no point in revoking certificates in case of a selfsigned certificate or in a PKI where the sum of public keys is 5. Managing subscriber tokens in such a "real CA" setup is often a separate process from the CA functionalities. EJBCA has an extensions, http://www.hardtokenmgmt.org/ that implements a framework for managing such centralized setups (but I suspect it does not work with OpenSC PKCS#11) Then there is the "noPKI" setup where the focus is on end-user tokens (which don't have security officers for example) and managing "your tokens" (generating keys, moving objects on and off the card). I believe that such "home users" don't really care about certificate management in a GUI, the keys either don't need certificates or the certs come from an external source or they are selfsigned anyway. Of course, there are situations when having this kind of separation is not wanted or needed. YMMV as they say. >> The closest thing to a useful infrastructure project on Linux might be >> the Qt QCA, which has PKCS#11 support thanks to Alon Bar-Lev. >> >> See http://sites.google.com/site/alonbarlev/qca-pkcs11 for more >> information. > > I missed this, thanks. It is a common API that could be used by a GUI. > Are there already GUIs for this API? What CryptoAPI is for Windows and CDSA/Keychain is for Mac OS X, QCA should be for Qt/KDE I remember somebody saying on an IRC channel that he got it working for either KMail or Konqueror but I'm not sure and don't have the log to verify that it's not wishful thinking. But then again, these API-s deal more with _using_ the keys and certificates on the card than dealing with personalization matters. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
