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