- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 19 Oct 2016 16:46:16 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP working group mailing list <ietf-http-wg@w3.org>, Patrick McManus <pmcmanus@mozilla.com>
On 2016-10-19 16:13, Poul-Henning Kamp wrote:
> --------
> In message <7c879010-2145-fabc-9f97-d05de90e5147@gmx.de>, Julian Reschke writes
> :
>
>>> HTTP/1.1 200 OK
>>> Content-Type: text/html
>>> Content-Encoding: gzip, aesgcm
>>> Transfer-Encoding: chunked
>>>
>>> {magic marker}
>>> keyid="me@example.com";
>>> salt="m2hJ_NttRtFyUiMRPwfpHA"
>>> {magic terminator}
>>> [encrypted payload]
>>
>> Because you might want to ship the parameters somewhere else. See
>> example in
>> <https://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-08.html#rfc.section.3.5.3>.
>
> Yeah, I thought about that, but the more I study it, the more I don't
> see why HTTP needs to get involved in either activity.
>
> All this stuff can be done with existing HTTP mechanisms, by defining
> a new C-E which carries its own metadata in the body, like all other
> C-E's, and the enourmous advantage of that is that it is backwards
> compatible.
But how would you handle the case describes above -- where the metadata
(content type, encryption material) is served from a server different
from the one having the (encrypted) payload?
Best regards, Julian
Received on Wednesday, 19 October 2016 14:47:28 UTC