- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 5 Mar 2012 22:58:39 +0100
- To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
- Cc: Willy Tarreau <w@1wt.eu>, Ian Hickson <ian@hixie.ch>, Yngve Nysaeter Pettersen <yngve@opera.com>, URI <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Am 05.03.2012 um 22:41 schrieb Poul-Henning Kamp: > In message <20120305200850.GI30594@1wt.eu>, Willy Tarreau writes: >> On Mon, Mar 05, 2012 at 06:09:35PM +0000, Poul-Henning Kamp wrote: > >> Example : >> Content-Encoding: aes-ctr-128; keyid=0x34751806 >> Cache-control: no-transform >> >> This has the benefit of working out-of-the-box without affecting existing >> intermediary components. > > That doesn't really improve the crypto scheme or key-handling in > any meaningful way. > > It does make it slightly less hackish as HTTP considered. Something along the lines of Link: <https://serverA/keys/1234>; rel="content-decryption" would expose the key only to parties authorized to retrieve it. If the client sends the resource URL in the referer header, then the key url does not need to be specific even, but the matching key could be selected by serverA. <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Monday, 5 March 2012 21:59:09 UTC