- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Wed, 19 Oct 2016 19:01:19 +0300 (EEST)
- To: HTTP working group mailing list <ietf-http-wg@w3.org>
- CC: Julian Reschke <julian.reschke@gmx.de>, Poul-Henning Kamp <phk@phk.freebsd.dk>, 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>
> 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?
https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0196.html
Is this just about moving Encryption header to body?
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]
On https://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-08.html#rfc.section.3.5.3
there is
Crypto-Key: keyid="a1"; aesgcm="csPJEXBYA5U-Tal9EdJi-w"
which you do not want move to body. That is different thing.
And content-type is just here, it is not moved to
server to where out-of-band points:
TTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:00 GMT
Content-Encoding: aesgcm, out-of-band
Content-Type: text/plain
Encryption: keyid="a1"; salt="vr0o6Uq3w_KDWeatc27mUg"
Crypto-Key: keyid="a1"; aesgcm="csPJEXBYA5U-Tal9EdJi-w"
Content-Length: 101
Vary: Accept-Encoding
{
"sr": [
{ "r" :
"http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"}
]
}
/ Kari Hurtta
Received on Wednesday, 19 October 2016 16:01:53 UTC