On 07/20/2010 10:16 AM, Martin Paljak wrote: > Hello, > > A huge backlog of e-mails to go through, but here's a thought on the > subject:
Thanks for responding. > The Linux "paradox of choice": it > is so good to be able to choose from so many possibilities, that it > becomes bad that there's so many implementations to choose from. For > example, I use GNOME on Linux but for long used k3b for writing > disks.. Because it just used to be the easiest to use application :) > Do you want to promote gnome-keyring (if that's the component you're > working with) to something like OpenSSL (what *GNOME applications* > will rely on when they need SHA1 or crypt with AES, instead of using > OpenSSL) or something like CDSA/Keychain is, that is will be used > when you use the function that conceptually translates to OpenURL() > with a https URL in a GNOME application? 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. > 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. > So maybe the > "PKCS#11 directory" [3] is the best solution I've seen this far. That's certainly a good start. > 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. > 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. That's definitely the goal. Flexibility, transparency and usability are high up on the list. > Last but not least, I'm personally somewhat religious about "trust" > and how the term is used (and abused) by many vendors. Even if there > can be two people who agree on what the term means for them, it is > essentially a very personal decision. I've seen warning about things > not being "trusted" or seen green and assuring "trusted" signs when > my internal decision about the actual case has been 100% opposite. > Technical validity or a boolean answer of "1" for a certificate chain > validation is not the same as trust. It will depend on your business > sector as well, if you work in the CA business or military sector you > probably would think differently ;) Thanks! Much appreciated. And if you feel at any point like you'd like to get involved, please join in. Cheers, Stef _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
