Hello, On Jul 21, 2010, at 12:40 AM, Stef Walter wrote: > On 07/20/2010 10:16 AM, Martin Paljak wrote: > Gnome Keyring is not going to turn into something like OpenSSL. Here's > the 50,000 foot main goals of Gnome Keyring: > > 1. To be a place to store passwords. > 2. To be a common place to store keys and certificates. > 3. To contain crypto related UI widgets for a consistent experience. > > Point 2 above is where PKCS#11 comes into the picture. Crypto libraries > like NSS can access keys and certificates in Gnome Keyring. > > We're not trying to be a crypto library like NSS. We're not trying to > store 'policy' or 'trust' information. > > In fact I'll be talking about our implementation in a presentation at > the upcoming GUADEC. I checked the architecture picture [1] and what you are trying to do IMHO somewhat mimics what WSGI [2] tries to be for web applications in
Like WSGI does not provide any template systems, PKCS#11 does not provide anything except basic operations like signing and decrypting and encryption. Not really sexy from application perspective. But a lot of neat WSGI utilities exist. gnome-keyring looks like a collection of PKCS#11 utilities, that actually are very useful if it is possible to mix and match them independently from each other and independently from gnome-keyring. So when an application developer wants to use SSL, it still needs to use NSS or OpenSSL or GnuTLS. If it needs to use a certificate, it needs to get it from gnome-keyring and convert to the structure used by the library of choice? Keeping "lists of certificates" (or a list of public keys in that matter) means some kind of associated data. "List of keys I hate" and "List of keys i love" carry extra data with the keys, even if the underlying data structure does not represent it technically. I feel that point 3 has potential, as system-wide UI-s, if properly controlled, provide a good way to have uniform password prompts and thus PIN dialogs. See OpenSC ticket #232 [3] for the feature description. "System prompts" would be superior to mechanisms like gpinentry style solutions. >> From end user application perspective (which is also the smart card >> perspective) the need to access to keys on a card is universal, but >> the PKI parts (which includes trust roots and certificate trust >> settings) have sometimes good arguments to be application specific. >> Sometimes you want a globally accepted root certificate, sometimes >> not. Of course, a central implementation makes it easy to patch (and >> exploit!) bugs in peer certificate validation checks. >> >> If you remove basic requirement of having to work smoothly with >> hardware based keys, the center of gravity is still in the >> application. It *has* to include the logic that uses well known >> protocols to give assisting information to the user about the >> trustability of the given situation, or it has to implement its own >> protocol with the building blocks provided as algorithms. > > I strongly agree here. When it comes to deciding policy and trust, the > application must take the central role. Each application has vastly > different requirements. > > The model of OpenSSH is vastly different from a web browser, yet both > use the same key store and the same types of keys. In the future I > believe there will be more inovation in the areas of trust to solve some > of the problematic areas today. > > So to summarize, in Gnome Keyring we make no trust decisions. As part of > the key store we do make CA certificates available to the crypto > libraries and applications, and these are marked as such. Key stores (like software private keys and a list of hardware based private keys with PKCS#11 hooks to do operations with them) really do not try to impose any kind of semantics to them. Basic crypto. But what about CA certificates? Certificates as such as claims. Collection of certificates is a bunch of claims. Even if a certificate has a matching private key available via the same API and thus it makes technical sense to have it around, it still is a claim in the form of a blob A bunch of CA certificates has no meaning per se. Storing collections of certificates or providing access to them makes sense if you make the management easy. Adding extra functionality that actually tries to ease managing common scenarios (this means arbitrary lists of certificates) and help hook it up with libraries might be more useful than just a place where to get blobs with certificates. This assumes that gnome-keyring (or seahorse) provides a sensible UI, like Apple keychain or Windows certificate manager do. >> 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. > > FWIW, NSS abuses pReserved to no end. In Gnome Keyring we extend PKCS#11 > a bit but remain very conformant to the spec. I did not want to point at NSS specificly, there are other implementations that for example add to PKCS#11 to support their specific authentication scenarios (C_LoginBegin/C_LoginNext/C_LoginEnd) but that is bad, as it gives pkcs11-ish feel but is not interoperable with other solutions. [1] http://live.gnome.org/GnomeKeyring/Architecture?action=AttachFile&do=view&target=gnome-keyring-architecture.png [2] http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface [3] http://www.opensc-project.org/opensc/ticket/232 -- Martin Paljak @martinpaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
