Implications of a common private keys directory in 2.1

[Carola Grunwald]

"Robert J. Hansen" <rjh at sixdemonbag.org> wrote:

>> 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?

>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.

Hi Andrew, hi Robert,

many thanks for your replies.

But why does a person have to be in control of a signature key? Why not
a server in the name of a company resp. its employees.

Talking about mail, when transmitting messages we currently have two
encryption principles in common use. There's server-to-server security
provided usually by SSL/TLS, where nevertheless the communication
partners can't influence the all-knowing servers building the route. And
there's true end-to-end cryptography done by PGP/SMIME at the client
applications, which also leaks valid (envelope) information thinking of
message size and structure and the enormously talkative header section.

Now let there be a corporate server, which 'cleans' the header of
outgoing mail, adds some nonsense data of random size and encrypts the
result into a single PGP message block, which it finally forwards after
adding the recipients' mail addresses as the only header line. The
message block's signature only documents the identity of the sender who
logged into the server, and, btw, with --faked-system-time doesn't even
leak whether it was processed at business hours or at midnight. At the
recipient's corporate server that mail is decrypted using the
recipient's key, the original mail structure restored, a line
representing the signature status added to the header and the result
delivered to the POP3 client.

This concept of an enhanced transport security layer offers external
adversaries least possible information while it doesn't preclude the
sender from adding another inner encryption/signature layer created with
a key she herself controls.

Hope that helps to understand what I'm aiming at.

Kind regards

Caro