Naturally a system like described below must support an*/issuer-defined/* ACLs 
on enrolled keys...
/a
-------- Original Message --------
Subject:        gnome-keyring Question about ACL per storage item
Date:   Thu, 20 Oct 2011 10:17:00 +0300
From:   Elena Reshetova <elena.reshet...@gmail.com>
To:     gnome-keyring-l...@gnome.org



Hi,

I have been studying different solutions available in Linux for securely 
storing certificates, keys and other credentials and one of the solutions I am 
going through is Gnome Keyring.
I saw that it used to have ACL per item in the storage, where one can specify 
basic read/write/delete rules and identify application (or applications?) that 
is allowed to use the item. However, this
functionality is now marked deprecated and I could not find explanations for 
such decision.

The use case I am interested in is very simple. I am as a user would like to be 
able to control what of my secrets are accessible to which applications on the 
system. Because I may have very different
applications installed on my system and not trust each of them in the same way. 
For example, I may have two different key pairs for signing my emails, one for 
corporate emails and one for personal.
Similarly I may be forced to use two different mail clients: for private emails 
my favourite open-source mail client (that my company doesn't feel that it is 
trusted enough) and "company approved"
mail client for company emails. And of course I would like to specify that 
these two email clients should be able to access only a private key from 
corresponding key pair for signing.

I can think of quite many use cases like that.

Are there any plans/desires to have such functionality supported in Gnome 
Keyring? It isn't listed in architecture goals and plans and that's why I am 
interested to ask.

Best Regards,
Elena.

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to