Re: 2nd Working Group Last Call: draft-ietf-httpbis-encryption-encoding-03.txt

[Julian Reschke <[e-mail]>]

On 2016-10-19 16:13, Poul-Henning Kamp wrote:
> --------
> In message <[e-mail]>, Julian Reschke writes
> :
>
>>>    HTTP/1.1 200 OK
>>>    Content-Type: text/html
>>>    Content-Encoding: gzip, aesgcm
>>>    Transfer-Encoding: chunked
>>>
>>>    {magic marker}
>>>    keyid="[e-mail]";
>>>    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