ietf-openpgp
[Top] [All Lists]

RE: Split Implementations of PGP

2005-03-16 14:26:09

Forward without download: I've got a 100MB document and a piece of text
saying, "here is the very important document you need to send to foo".  I
*chose* to trust the server, this time, to decrypt the message for me and
tell me the body structure (a big document and a piece of text).  I download
the text, and I decide to forward the document.  I tell the server to do the
forwarding for me on my behalf.

Note that I *chose* to trust the server FOR THIS MESSAGE ONLY.  That is why
we asked the question about split implementations.  It would be VERY BAD if
we had to trust the server with our private key.

-----Original Message-----
From: owner-ietf-openpgp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openpgp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Ingo 
Luetkebohle
Sent: Wednesday, March 16, 2005 8:14 AM
To: Jon Callas
Cc: OpenPGP
Subject: Re: Split Implementations of PGP



Am Mittwoch, den 16.03.2005, 01:46 -0800 schrieb Jon Callas:
Something that would help those of us doing crypto and IMAP 
would be 
for IMAP to be less fussy about message size.

[...]

It would be very usefull, for me at least, if you could re-state your
use-case here.  I'm getting the impression that I'm missing something
fundamental.

I'm always reading about server-side decryption.  Some people seem to
see it as a solution for the "one big chunk of ciphertext" 
problem.  I'm
not sure what else it would be good for.

For me, server-side decryption is a nightmare.  Pure and evil.  

It conflicts with my beliefs about how an end-to-end crypto solution
should work.  Its not a solution, its a kludge and I'd much rather
address the *real* problem.

The server is completely untrusted.  Much too much of my personal data
is on other's servers already.  Organizations or people, who 
might have
different priorities in protecting it than I have.   Thats why I use
end-to-end encryption when it matters.

If people say, adressing the real problem would require 
influencing the
senders behaviour, and we can't do that, and so we need a work-around
now -- fine.  I can understand that.  But still, shouldn't that prompt
us to think about wether we *need* to be able to influence the senders
behaviour in more ways than we can now?


P.S. Regarding IMAP and message sizes:  If I get an encrypted message,
the size of the attachment *is* the message size.  That decryption
yields a different size doesn't matter because it occurs on 
the client,
after download.

Regards

-- 
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



<Prev in Thread] Current Thread [Next in Thread>