As a company, we pay for key software licenses, manage the keys, set policy for keys and provide support for the keys, all in order to encrypt company data. It is part of the employee's identity, yes, but it is their identity here at the company. When they leave, the leave that part behind with the company. Part of our Employee handbook is about not using company assets for personal uses.
That said, I can understand why, in a non-business environment, it would be a sticky issue. If someone brings their own key / email addresses to use on a server, they will want to use that elsewhere. But that sounds more like an administration setting. Businesses will want "restricted key management", where users can upload their keys, but not remove them. Otherwise, allow everyone full access to their keys via "open key management".
We have a several PGP users in the office. There are two things that we might like to see in a company-wide solution.
It is on a per-person basis at the moment, but it would be nice to have rules set up (much like spam filter rules) that can make decisions on when to sign, and when to encrypt. I expect most of our users will want to continue using their mail readers and not use the web client. But how would they, then, tell Zimbra to encrypt their email?
The policy rules are built on rather simple building blocks: header values, items in subject line. (Examples: If Sensitivity header is "confidential", then encrypt message. If subject starts with "[GPG]" and Priority is High, then encrypt.)
There should also be rules that run on a failure to find a key. So that it can reject emails it could not encrypt.
On a global level, I would like to see the ability to enforce some items, like make everyone sign every mail that goes out. (A possible corporate policy).
We found that PGP's concept of Master Keys can be quite useful. These are keys that are added to every encrypted message you send. In most cases, it is so that you can always include your own key. This allows you to always decrypt anything you send, even if you did not send it to yourself. But, it could also be used to include a corporate key. This could solve the problem of personal keys leaving with people. If an important business email was encrypted from or to an ex-employee, it would give administrators a way to decrypt it and make sure that information was given to the new employee in that role.
One other though came up, what about Provisioning?
With LDAP authentication, it does not automatically create the account information needed for the user. Bug id 7235. Will you have to take care of that as well, or will you simple focus on authentication and encourage people to vote for auto-provisioning?
Either way works, and I'm sure you thought about it, but I just wanted to note this potential headache.
Thanks for the input. on Key policy. At this point I am inclined to make key management integral. I am sorry I haven't made more visable proccess, but I have one Zimbra project that is higher priority, and it's a lot of source code that needs to be correct before I am confortable releasing anything.
The biggest change is that I am working on ditching the Cryptex adapter. It doesn't work well with larger key sizes (which are mandatory at this point) or with large streams.
^bump ... just checking to see how the progress is. I know you have priorities but I wanted to throw my hat in if you need any help. I'm not a java programmer but if you need testers/documentors whatever, I'm sure there are quite a few of us that would be up for poking around :)
Currently I'm not at any of the beta releases for 5 so I'm not sure how many if any hooks may be in your code reliant on v.5 but I'm sure I could work around this or upgrade to a beta release.
my luck you/re anal and doing all of your own testing :p either way there will be docs needed ;)
@Joshua: Can you give a short status of the work progress?
I'm very interested =)