- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Sat, 12 Nov 2016 10:18:58 +0200 (EET)
- To: HTTP working group mailing list <ietf-http-wg@w3.org>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Julian Reschke <julian.reschke@gmx.de>, Martin Thomson <martin.thomson@gmail.com>, Eric Rescorla <ekr@rtfm.com>
>>> Do we have a concrete use case for Crypto-Key? If not, I would remove >>> it. If so, I would consider writing a different spec. >> >> Maybe we can discuss this in the meeting, I don't have any objection >> to this. I like deleting code. >> ... > > One use case is over here: > <https://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-09.html#n-example-involving-an-encrypted-resource> > > If "Cryto-Key" isn't defined in the base spec, any other spec that > defines how to pass around the key information will have to define it > itself. That doesn't sound like a good idea to me. > > Best regards, Julian Looks like draft-ietf-httpbis-encryption-encoding needs informal reference to draft-reschke-http-oob-encoding if Crypto-Key is on draft-ietf-httpbis-encryption-encoding. | ⋯ However, the Crypto-Key header field could be | used in one message to provision keys for other messages. + One way to do that is use Content-Encoding header field value, + which moves actual payload to outside of that message where + Crypto-Key header field is used (for example [draft-reschke-http-oob-encoding]). If I understand correclty Eric Rescorla suggest own specification: Crypto-Key header field for HTTP Encrypted Content-Encoding Essentially moving 3. Crypto-Key Header Field https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-04#section-3 to that specification. Then also there need something to be done with examples. / Kari Hurtta
Received on Saturday, 12 November 2016 08:19:33 UTC