Modernizing Web-of-trust for Organizations

[Ben McGinnes]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180105/9936a000/attachment.sig>