security

[Martin Atkins]

Johannes Ernst wrote:
> On Oct 26, 2006, at 10:01, Martin Atkins wrote:
>> Hmm. When was it decided that a scheme-less URL should start of as HTTPS
>> and then be tried as HTTP. I was part of the camp arguing adamantly
>> against that when it was being discussed, but I don't recall a
>> conclusion to the debate.
>>
>> This attack was one of the very reasons I was against this spec-mandated
>> guesswork.
> 
> I don't recall that such a thing was decided.
> 

Indeed, not long after I posted this I was reviewing the spec for other 
reasons and found this:

8.2 Normalization
-----------------

The End User's input MUST be normalized into an Identifier. If the End 
User supplies input that does not include a scheme (http, https, or 
xri), then the application needs to determine if the input is an XRI or 
a URL missing the "http://". To do so, the application SHOULD examine 
the first character of the input. If it is an XRI Global Context Symbol 
(=, @, +, $, or ! see Section 2.2.1.2 of [XRI Syntax 2.0]), then the 
input SHOULD be treated as an XRI. If it is not, then the input SHOULD 
be treated as an http URL, and prefixed with the string "http://".

URL identifiers MUST be further normalized by applying the rules in 
section 6 of RFC 3986, following redirects when retrieving their 
content, and finally applying the rules in section 6 of RFC 3986 
(Normalization and Comparison) to the final destination URL. This final 
URL should be noted by the Relying Party as the Claimed Identifier and 
used during authentication requests.

----------------

Note in particular the end of the first paragraph, which states simply 
that one should prefix http://. HTTPS URLs must be spelled out as 
https://, which is a bit of a shame (we're optimising for the insecure 
case as far as users are concerned) but I can't think of any way to 
securely support the short form of both http: and https: URLs.