W3C home > Mailing lists > Public > uri@w3.org > March 2012

Re: http+aes

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Mon, 5 Mar 2012 22:58:39 +0100
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>
Message-Id: <FBD49CF9-65F3-43D1-92E6-A5BA01DAE34E@greenbytes.de>
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 March 2012 21:59:10 GMT