headers
Kornel Lesi | 14 Jun 2012 11:24
Gravatar

The enc: URL scheme


I've proposed a new URL scheme in the public-html list (as a response to http+aes scheme and video
encryption discussed there):

http://lists.w3.org/Archives/Public/public-html/2012Jun/0094.html

--

-- 
regards, Kornel Lesi¨½ski
Permalink | Reply | 3 comments |
headers
Cheney, Austin | 14 Jun 2012 13:22
Favicon

RE: The enc: URL scheme

The technicalities of this proposal may be different and more acceptable than the prior http+aes scheme,
but the principle intention appears to remain the same.  Security of addressing is mutually exclusive to
the security upon the artifact resolved at the address.  This said it appears that attempts to hide the
artifact by making the address unintelligible to sniffing by third parties is only obfuscation, which is
not security at all.  What that really means is that if a CDN is untrusted before use of a URI encryption
scheme it will continue to be untrusted after use of an encrypted URI scheme and any problems associated
with the absence of trust remain unresolved at the frustration of legitimate infrastructure
monitoring.  If my security argument is valid then a scheme to encrypt URI is actually harmful to security. 
If this is actually harmful to security then it seems the parties that primarily benefit are only
untrusted CDNs and media at cost of confidentiality, and likely integrity, to the end user as well as the
information service acted upon by that end user.  Confidentiality would be harmed because the
originating source remains untrusted and may therefore redistribute information of the connection
during or after the connection to unauthorized parties.  Integrity could be harmed because the CDN
remains untrusted may therefore transmit a similar artifact embedding tracking data or malicious code
outside of any integrity verification, such as hash comparison.

Outside of security concerns that may or may not be valid an encryption scheme upon URI destroys web
openness.  When the web is no longer an open platform it will be a less desirable platform compared to
proprietary alternatives with better application performance, fewer transmission bottlenecks, and
fewer security concerns.

Austin

-----Original Message-----
From: Kornel LesiĊ„ski [mailto:kornel <at> geekhood.net] 
Sent: Thursday, June 14, 2012 4:25 AM
To: uri <at> w3.org
Subject: The enc: URL scheme

I've proposed a new URL scheme in the public-html list (as a response to http+aes scheme and video
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kornel Lesi | 14 Jun 2012 13:44
Gravatar

Re: The enc: URL scheme

Sorry if it wasn't clear, but the proposal is for encryption/integrity of response body.

The URL itself is not encrypted and it does not attempt to obfuscate location of the resource. 

--

-- 
regards, Kornel Lesi¨½ski
Permalink | Reply | 0 comments |
headers
Michael A. Puls II | 15 Jun 2012 08:28
Picon

Re: data URIs - filename and content-disposition

On 3/1/2012 12:48 PM, Alessandro Angeli wrote:
> However, as far as I can tell, it is possible to achieve an even more
> generic and flexible result than what would be accomplished by the
> HEADERS param in a completely standard-compliant way by using the
> message/* MEDIATYPE, so that the payload (DATA part) of the "data:" URI
> would be a complete message/*, including its header fields.
>
> For example, using message/http, one would have (all in one line):
>
> {data:message/http,HTTP 200 OK|Content-Type:text/plain;charset=utf-8
> |Content-Disposition:attachment;filename=%22hello world.txt%22||HELLO
> WORLD}
>
> I used {} to delimit the URI and I used spaces and | for readability,
> but they are supposed to be escaped as %20 and %0D%0A (that is, I used |
> to represent a new line). I also used unescaped reserved chars because
> of the consideration at the end of this message.
>
> Using message/rfc822:
>
> {data:message/rfc822,Content-Type:text/plain;charset=utf-8
> |Content-Disposition:attachment;filename=%22hello world.txt%22||HELLO
> WORLD}

Both of those sound cool. I like the latter better as there's no need to 
specify http stuff. The message/rfc822 format is fine too.

"message/rfc822" for the mime type in the data URI though is not. I 
might want to create a data URI for a real message/rfc822 file and I 
wouldn't want that being interpreted as something that has an embedded
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 28 Jun 2012 17:13
Picon

draft-ietf-6man-uri-zoneid-01.txt

Hi,

The draft "Representing IPv6 Zone Identifiers in Uniform Resource
Identifiers", available in various formats at
https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/ ,
has passed WG Last Call in the IETF. Before it's submitted
to the IESG, we'd appreciate comments from this list. If you
happen to have seen an earlier version, please do look at the
latest one (-01) which is substantially different.

Please keep the CC's intact or add a CC to <ipv6 <at> ietf.org>.

Also please comment before July 4.

Thanks
   Brian Carpenter
Permalink | Reply | 3 comments |

Gmane