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

Re: http+aes

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 5 Mar 2012 23:29:16 +0000 (UTC)
To: Willy Tarreau <w@1wt.eu>
cc: URI <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.64.1203052326360.6189@ps20323.dreamhostps.com>
On Mon, 5 Mar 2012, Willy Tarreau wrote:
> I wouldn't go to such extremities, but at least I think that we're just 
> facing a layering violation. Only the contents have to be encrypted so 
> that the caches cannot use them, while the transport remains unchanged. 
> So a new scheme is not appropriate for this, a Content-Encoding would be 
> much better. User agents would be configured to know that content- 
> encoding XYZ requires a deciphering key whose ID is presented in the 
> header itself and should have been retrieved via another channel.
> Example :
>     Content-Encoding: aes-ctr-128; keyid=0x34751806
>     Cache-control: no-transform

This would require changes at the intermediaries. It would also require a 
mechanism to link keys to IDs, which is non-trivial given the same-origin 
policy, multiple browsing contexts, subresources, etc.

> This has the benefit of working out-of-the-box without affecting 
> existing intermediary components.

It would seem to me to require slightly more effort than the scheme 
approach on this front.

(We did actually consider something like this.)

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 5 March 2012 23:29:39 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:55 UTC