W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Call for Adoption: Encrypted Content Encoding

From: Roland Zink <roland@zinks.de>
Date: Tue, 1 Dec 2015 00:15:09 +0100
To: ietf-http-wg@w3.org
Message-ID: <565CD87D.1090008@zinks.de>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC