Implications of a common private keys directory in 2.1

[Robert J. Hansen]

> gpg is intended to run on the client, not the server. A mail service
operator
> should not hold the private keys of its users, never mind perform
encryption
> operations on their behalf. I would question the design of your
architecture if
> you feel this is necessary.

I concur.  This post is agreement, not dissent.

A user ID on a key makes an assertion: "The person named X is in control of
this certificate."  But in this architecture the end-user *isn't* in
control.  You remain in complete control of the private certificate.  You
have the power to completely undermine the system.  So for that reason, it
seems strange to me that your users would have their own private
certificates -- what, precisely, *could* they certify?

Likewise, a signature on a message makes an assertion: "This message went
through the hands of the person who controlled this certificate, and has not
been altered since then."  (Signatures do not prove authorship: that's a
common misconception.  If Alice sends Bob a signed message saying "I love
you", and Bob strips off the signature, places his own on it, and sends it
on to Charlene, Charlene will have a message Alice authored but which Bob
signed.  Charlene can prove the message went through Bob's hands, but she
cannot prove who wrote it.)

But if I'm on your system, and you're the one doing signatures for me, then
what does a signature which claims to be from me really attest?

Your scheme appears to deeply subvert the meaning of signatures and
certificate ownership.  This is crazy.  Maybe it's crazy enough to be a
breakthrough, but so far I'm not seeing it.