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

Re: Encryption simplification

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Mon, 31 Oct 2016 18:54:11 +0200 (EET)
Message-Id: <201610311654.u9VGsBGE021539@shell.siilo.fmi.fi>
To: Costin Manolache <costin@gmail.com>
CC: Martin Thomson <martin.thomson@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Julian Reschke <julian.reschke@gmx.de>, HTTP working group mailing list <ietf-http-wg@w3.org>
Costin Manolache <costin@gmail.com>: (Mon Oct 31 08:13:02 2016)
> 1. Why not add the Crypto-Key to the binary header ? If we have to deal
> with binary encoding, we can at
> least avoid parsing more text headers - and it doesn't have to be b64.

This

http://httpwg.org/http-extensions/encryption-preview.html#introduction

| For example, it might be necessary to store a file on a server without exposing its contents 
| to that server. Furthermore, that same file could be replicated to other servers (to make it 
| more resistant to server or network failure), downloaded by clients (to make it available 
| offline), etc. without exposing its contents.

does not mention it, but I think that there was hidden 
(for this draft) motivation where reponse headers was 
served from originin server via https (that include 
Crypto-Key) but actual payload is served from another 
server. That content-encryption provides encryption
for that payload. Another Content-Encoding (Out-Of-Band)
moves payload to other server.

https://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-08.html#rfc.section.3.5.3

was mentioned.

/ Kari Hurtta
Received on Monday, 31 October 2016 16:54:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 31 October 2016 16:54:51 UTC