- From: John Mattsson <john.mattsson@ericsson.com>
- Date: Mon, 30 Nov 2015 10:42:59 +0000
- To: Walter H. <Walter.H@mathemainzel.info>
- CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <D281E4C3.419FA%john.mattsson@ericsson.com>
On 30/11/15 11:32, "Walter H." <Walter.H@mathemainzel.info> wrote: >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 ... I think this should be used in addition to HTTPS. TLS is not the solution to everything. In the WebPush scenario, using only HTTPS would lead to the Push Service having access to, and being able to modify the content. Content-enryption + HTTPS looks like a good general solution that can be used independently of content-type.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 30 November 2015 10:43:32 UTC