Re: http+aes URI scheme

This idea should be cross-referenced with the thread that began here

http://lists.w3.org/Archives/Public/www-tag/2009Dec/0122.html

which never got resolved (basically whether 'secret URIs' are good practice
vs. bad practice). Remember the good-practice argument is that it's good to
identify resources with URIs and in some cases with confidential URIs (and
keeping said URIs out of data paths that would lead to disclosure, such as
browser address bars), because this makes for good security hygiene, CSRF
protection, etc.; the bad-practice argument was that by casting the
combined identification and authorization of such resources as URIs, they
become unprotectable, because there is something about URIs, not possessed
by non-URIs, that make URIs unprotectable.

If the larger community embraces secret URIs, then what the TAG has to say
on the matter may be irrelevant, and we'll be playing catch-up in the
future as we have had to do with so many other things. That may be
perfectly OK, especially if there is currently no consensus within the TAG.

Jonathan

On Mon, Mar 5, 2012 at 10:17 AM, Noah Mendelsohn <nrm@arcanedomain.com>wrote:

>  I think this will likely be of interest to the TAG. A discussion has
> sprung up on uri@w3,org. Basically, the HTML5 specification is proposing
> an http+aes URI scheme. Quoting selectively from [1]
>
>  URI scheme syntax: Same as http, with the userinfo component instead
> used for specifying the decryption key. (This key is provided in the form
> of 16, 24, or 32 bytes encoded as ASCII and escaped as necessary using the
> URL escape mechanism; it is not in the "username:password" form, and the
> ":" character is not special in this component when using this scheme.) URI
> scheme semantics: Same as http, except that the message body must be
> decrypted by applying the AES-CTR algorithm using the key specified in the
> URL's userinfo component, after unescaping it from the URL syntax to
> bytes. If there is no such component, or if that component, when unescaped
> from the URL syntax to bytes, does not consist of exactly 16, 24, or 32
> bytes, then the user agent must act as if the resource could not be
> obtained due to a network error, and may report the problem to the user.
>
> [...]
>  Security considerations:
>
> URLs using this scheme contain sensitive information (the key used to
> decrypt the referenced content) and as such should be handled with care,
> e.g. only sent over TLS-encrypted connections, and only sent to users who
> are authorized to access the encrypted content.
>
> User agents are encouraged to not show the key in user interface elements
> where the URL is displayed: first, it's ugly and not useful to the user;
> and second, it could be used to obscure the domain name.
>
>
> Noah
>  [1] http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme
> -------- Original Message --------  Subject: http+aes  Resent-Date: Mon,
> 05 Mar 2012 10:21:40 +0000  Resent-From: uri@w3.org  Date: Mon, 05 Mar
> 2012 11:21:06 +0100  From: Julian Reschke <julian.reschke@gmx.de><julian.reschke@gmx.de>  To:
> URI <uri@w3.org> <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org><ietf-http-wg@w3.org>
>
> FYI:
>
> 	http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme
>
>
>