Re: gnome-keyring GNOME Keyring and Seahorse Goals and Vision
- From: Martin Paljak <martin martinpaljak net>
- To: Stef Walter <stefw gnome org>
- Cc: Adam Schreiber <sadam gnome org>, Seahorse mailing list <seahorse-list gnome org>, "gnome-keyring-list gnome org" <gnome-keyring-list gnome org>
- Subject: Re: gnome-keyring GNOME Keyring and Seahorse Goals and Vision
- Date: Mon, 11 Oct 2010 08:46:52 +0300
Hello,
On Oct 10, 2010, at 8:55 PM, Stef Walter wrote:
> Perhaps. There was an interesting idea brought up at GUADEC by Tobias
> Müller. The suggestion of storing trust assertions as certificates
> signed by different keys (for various purposes).
>
> This can be added as an implementation once the actual specifications
> and PKCS#11 extensions for trust assertions are agreed on.
Why extend PKCS#11 for this?
If you say that the NSS turst bits are from 10 years ago, then the trust thing has already gone standard - CKA_TRUSTED (since PKCS#11 v2.11).
PKCS#11 has CKA_TRUSTED and certificates have extended key usages. Shouldn't combining the two fix the problem? I mean, if you "trust" a CA shouldn't you then also trust it to give out certificates with proper EKU-s to those for whom the use is ... trusted? The problem is that it is not allowed to change this attribute from cryptoki applications. Nevertheless, if you want to overload PKCS#11 for something like this, you can as well abuse it. But PKCS#11 is not supposed to be a generic certificate store and I don't suggest to abuse or extend it like this.
I would suggest building upon a simple container abstraction of arbitrary lists. The technical "trusted for website authentication" flag means nothing in a non-closed environment without additional context and the three trust settings don't cover everything. Basically it will allow the authentication procedure to successfully evaluate to "true" by allowing a certificate chain validation but does not deal with the trust related authorization, which IMO is a human decision based on contextual input information and also emotions, not an algorithm internal to some application. As noted on the page, applications have different flavor and even more importantly: users have different trust preferences. To actually make the trust settings usable, applications need to work with them, display warnings, extra questions. This means more work for application develoepers-integrators than in the keyring app. Very few applications improve anything on the crypto related trust handling, the nicest app at the moment seems Chrome.
So instead of trying to figure out the extension for conveying the "trust bit" over PKCS#11, very good certificate management capabilities should be built into Seahorse and made possible to expose it to applications in convenient ways. That means integration with OpenSSL, PKCS#11, NSS, whatever else.
Also, this will conflict-relate a little to NSS shared DB initiative.
--
@MartinPaljak.net
+3725156495
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]