Re: Call for Adoption: Encrypted Content Encoding

Am 30.11.2015 um 21:10 schrieb Walter H.:
> On 30.11.2015 13:22, Amos Jeffries wrote:
>> The point of this draft is the same. When anything is encrypted with 
>> intentio that the recipient acts on the decrypted content in ways 
>> other than saving it to a file - the sender emits the appropriate C-E 
>> header that says its crypted (and how). Such that the recipient can 
>> decrypt if/when it has the ability. 
> in comparison to encrypted end-to-end encrypted E-mails, there is the 
> same problem; this draft is the same bad idea than the
> publishing the public keys to the wide ...
>

TLS is also end-to-end

> I don't say that the malware detection on client side is not as good 
> as that on any server side; I'd say,
> that the chance to detect malware is better when it is not only at one 
> pont: the client;
>
> just think of the following case:
>
> someone has implemented this draft; that everybody downloading the so 
> uploaded data trusts the server owner ...
> and it absolutely nonsense that the webadmin itself can't clearly open 
> the file natively on the server, because its encrypted ...
>
> data exchange is good, but this way its more than stupid;
>
> there doesn't exist any really USEFUL use case ...
>
>
I don't understand the problem. The message is send from server A 
through server B to recipient C. B can't read the message. As long as C 
can determine the message is from A (and not B) this is the same as with 
TLS, isn't it?

That said it might wishable for TLS end users to contract a third party 
to check the messages before opening itself the messages.

Received on Monday, 30 November 2015 23:15:34 UTC