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

Re: Call for Adoption: Encrypted Content Encoding

From: Walter H. <Walter.H@mathemainzel.info>
Date: Mon, 30 Nov 2015 11:32:32 +0100
Message-ID: <565C25C0.1020703@mathemainzel.info>
To: John Mattsson <john.mattsson@ericsson.com>
CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 30.11.2015 08:45, John Mattsson wrote:
> On 29/11/15 11:20, "Walter H."<Walter.H@mathemainzel.info>  wrote:
>> On 28.11.2015 03:43, Martin Thomson wrote:
>>> On 26 November 2015 at 20:48, Walter H.<Walter.H@mathemainzel.info>
>>> wrote:
>>>> can someone tell me REAL USEFUL use case where someone would need
>>>> this way of having something encrypted on a webserver?
>>> The two use cases where this is likely to appear in the short term are:
>>> 1. web push - where an encrypted resource is created on a server by
>>> one entity and retrieved by another.  The server doesn't get to see
>>> the contents.
>> I'd say this is the wrong answer, this can be done alternativly as used
>> to do
>> (pushing an encrypted .rar or .zip is exactly this use case with
>> advantage,
>> there is no implicit malware impact ...)
>> for security reason exactly this way you mentioned must be forbidden;
>> there mustn't be a way pushing malware to a server,
>> which the server itself has no possibility to clean it ...
> Using .rar or .zip for encryption is not an option. Not only are they
> proprietary, non-standardized compression algorithms, the encryption parts
> are based on passwords and at least the .zip encryption is seriously
> flawed…
I didn't say that these are the only alternative ways, .zip or .rar is 
just an example;
it depends on what you want to encrypt;
if for is only something standarized an option, then use the 
OpenDocument standard;
these can be encrypted, too;

by the way: the need of this nonsense;
because its like open the door and shooting down anybody non-blind who 
comes in ...

use HTTPS ...

Received on Monday, 30 November 2015 10:32:59 UTC

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