that ess in 'https'

[Martin Atkins]

David Strauss wrote:
> 
>>I think my favourite solution right now is to require relying parties to
>>support SSL and then use the existing "canonicalization through
>>redirection" feature of OpenID to solve this problem. The problem that
>>doesn't address is where an identity provider starts off on cleartext
>>and migrates to SSL, which admittedly I don't have a good answer to.
> 
> I don't like the redirection system because it still makes an insecure
> hop. It would be more secure to try the https scheme first. I don't see
> why people are resistant to this. The only restriction is that you can't
> have different identities distinguished only by scheme.
> 

It only requires that insecure "hop" if the user enters an HTTP URL into 
the relying party in the first place. If they enter an HTTPS URL, that 
won't be included. If someone manages to spoof the HTTP bit, all they've 
achieved is to create themselves a new identity since the two aren't 
considered equivilent under this proposal.

Perhaps a compromise between these two would be for *schemeless* partial 
URLs (If I enter frank.livejournal.com rather than 
http://frank.livejournal.com) to be defined as trying HTTPS first and 
then HTTP, and whatever one succeeds is the canonical identity. They are 
not considered equivilent as far as "are these two identities the 
same?", but users don't have to concern themselves with entering the 
right scheme. If I log in as "frank.livejournal.com" and the HTTPS 
connection works, the relying party remembers me as 
https://frank.livejournal.com/. If I come back later and log in as 
"http://frank.livejournal.com/" (typing the scheme explicitly) as second 
identity is created. Likewise, if I come back later and log in with a 
schemeless URL but my HTTPS server is gone, a second identity is created.

This has the nice side-effect that we don't burden relying parties with 
the task of parsing/normalizing a URL. They can just shove the URL into 
their database and do string matching on it for future lookups; the 
identity is the same as long as it is character-for-character identical. 
This is how the relying party implementations I'm aware of currently 
treat identity URLs. I don't think it's too taxing to expect a user to 
enter their URL in the same form each time.

On the other hand, setting up an SSL connection has a lot more overhead 
than setting up a plain TCP connection, and sites may object to having 
hundreds of relying parties requesting non-existant paths from their SSL 
sites even though they don't provide identities over SSL. LiveJournal, 
for example, would have to serve a useless a request on its payment 
server every time a LiveJournal user logs in somewhere.

>>However, technically the difference between <http://mydomain.com/> and
>><https://mydomain.com/> is the same as the difference between
>><http://something.mydomain.com> and <http://somethingelse.mydomain.com/>
>>as far as the HTTP protocol is concerned, so if we allow one why do we
>>not allow both?
> 
> It's not the same. It's a different protocol level. SSL is a layer that
> optionally runs beneath HTTP. It's the fact that we specify the protocol
> in the URL that the HTTP request goes over that's weird (for an
> addressing scheme).
> 

If you take the SSL layer out then what you're left with is an HTTP 
server running on a different port, and HTTP considers 
http://whatever.com:80/ and http://whatever.com:81/ to be two distinct 
URLs. You correctly state that SSL is just the transport on which we 
layer HTTP, but the two are distinct even if "https:" just means "use 
port 443" instead. It's a shame no-one implemented RFC2817, since then 
the two would be the same as far as HTTP is concerned.

On the other hand, the difference between IPv4 and IPv6 (which you 
mentioned in a portion of your message that I snipped) does not cause 
any ripples at the HTTP level, since it is defined that implementations 
should try to resolve an AAAA record and then fall back on an A record 
if one isn't found, meaning that the URLs are considered equivilent at 
the HTTP level.