> 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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
