- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Mon, 31 Oct 2016 18:54:11 +0200 (EET)
- 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