- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 6 Mar 2012 11:57:44 +0100
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Ian Hickson <ian@hixie.ch>, URI <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Anne, On Tue, Mar 06, 2012 at 09:25:42AM +0100, Anne van Kesteren wrote: > On Tue, 06 Mar 2012 07:55:07 +0100, Willy Tarreau <w@1wt.eu> wrote: > >So you mean that it's the *real* decryption key which is passed in > >userinfo? It appeared obvious to me that it was just an identifier for a > >key that the client had fetched somewhere else (eg: on the same site via > >https or at least without passing via the CDN). If the real key is > >passed in the response, then I fail to get the use case since your CDN > >gets the key as well :-/ > > How? A resource on server S links to a resource on CDN C using http+aes. > C's resource is encrypted. C does not know the key. The key is hosted on > S's resource as part of the http+aes link. When the user agent fetches C's > resource it does not include the key, but decrypts it as data comes in. So > C never knows anything about the bits it is hosting, S and the user agent > do. This is what I understood first but Ian's explanation seems to imply that the key itself is passed along with the response because it would otherwise be too complex to manage keys. Maybe there is something that I did not understand then. Willy
Received on Tuesday, 6 March 2012 10:59:25 UTC