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

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

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>
Message-Id: <20161019160121.01D9313356@welho-filter3.welho.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?


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}
   {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" :

/ Kari Hurtta
Received on Wednesday, 19 October 2016 16:01:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 19 October 2016 16:01:57 UTC