On Wed, Jan 03, 2018 at 05:34:30PM -0800, Lou Wynn wrote: > > The management of users' private key is a little more complicated. I > use two levels of protection. One level is at the organization. An > organization actually has a fourth key, which I call the guard key, > to encrypt the password of user's private key. This guard key is > also managed by the key management system. In addition, a user can > choose another her own password to encrypt the key password too.
That just spreads the potential points of human failure and you run the risk that anyone with access to this guard key would be able to abuse the position to access an employee's credentials (saying they don't have access to the private key doesn't hold any weight on a company intranet where they've probably already got root/admin access). So it'd be too easy for some unscrupulous sys admin (you might trust you, but what happens when you leave, do you know your successor?) has a personal issue with someone in, say, marketing and stitches them up with a few choice forged and signed emails. No, that's a *bad* plan and creates all sorts of horrible legal problems for the company or at least has the very real potential to do so. It seems to me, though, that the idea was to provide a means for the company to repudiate an employee's key even if the employee was no longer available. Perhaps they were fired or just became very ill or any of a host of reasons with varying degrees of potential drama attached. This is a legitimate issue in the corporate environment, but the solution to it is not to maintain an escrow on private keys and passphrases which could subsequently be abused by a technically proficient person within the company. What you should do instead is keep an encrypted and archived copy of the revocation certificate for each employee's key. That way it is still possible to declare that the key and/or employee is no longer sanctioned, but without providing a means where anyone with access to this system could either intercept encrypted communications sent to that key or forge messages appearing to come from it. Any other option is going to end up in a legal dispute eventually and will probably cost *far* more than what you think you're saving yourself from now. Regards, Ben
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users