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

Re: http+aes

From: Carsten Bormann <cabo@tzi.org>
Date: Tue, 6 Mar 2012 07:23:02 +0100
Cc: Ian Hickson <ian@hixie.ch>, URI <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <939C0D08-99B2-411F-960C-D8E54C42503B@tzi.org>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
On Mar 6, 2012, at 05:07, Manger, James H wrote:

> 1. Encryption without integrity (as http+aes delivers) is almost worthless.

That is certainly true if we were talking about actual security objectives.
However, it seemed to me this is about DRM, not about security, so maybe it is more important to be able to claim "the content [sic] is encrypted with 256-bit AES" than to get actual security against sophisticated attacks (which would trivially target Ian's party "A" instead of this scheme here).

With the security issues properly spoken for, something different.

The more interesting observation for me is that there is an HTTP URI stuck in there trying to get out.

I.e., instead of 

http+aes://uEdF00VkBLCfriveitl6cv4H@cdn.com/tehmovie.mov

one would really like to see

frob:hixie-3:uEdF00VkBLCfriveitl6cv4H:http://cdn.com/tehmovie.mov

From the point of the server B (and most parts of the mechanics in client A), this is a normal HTTP request, so we have that normal HTTP URI as the third element of the frobnicating URI scheme (and it could be ftp:// for that matter).  All we want is that, once HTTP has done its magic, the retrieved content [sic] is post-frobnicated in some way, e.g. in process hixie-3 that uses keying material uEdF00VkBLCfriveitl6cv4H and AES-CTR to decrypt the payload in some as yet unspecified way.  The explicit indication of the post-processing style provides algorithm agility and decouples the URI scheme from the specific type of post-frobnicating.  A simple registry could be used to manage the post-frobnicating specifications (which, apparently, still need to be written -- outside the HTML spec, please).

Why does post-frobnicating have to be part of the URI at all (as opposed to a header field like Content-(En)coding etc.)?  Of course, that is not *necessary*, but I do see the convenience factor of lumping this in there.  (It also can be used for pre-frobnicating for request bodies.)

Gre, Carsten

PS.: Consistent with the ~ 12 % facetious content of this message, Apple's spelling correction is trying to change "frobnicating" into something else...  I hope none of that is left in this message.  But I'm quite serious that, if this is done, it should be done this way.
Received on Wednesday, 7 March 2012 14:22:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 March 2012 14:22:48 GMT