that ess in 'https'

[David Strauss]

Martin Atkins wrote:
> Joaquin Miller wrote:
>>
>> But i thought our audience was
>>   the people who
>>      we would like to see
>>          use URLs to identify their personas.
>>
> 
> That's very poetic.
> 
> However, "do it for the users!" is not a justification for producing a
> flawed system, especially if that system is related to identity and
> we're compromising on security.

OpenID compromised on security the moment it allowed pulling identity
pages from any non-https location. I only support allowing http mode for
sites that don't need to care much about identity compromise, and that's
at the RP's discretion.

I'm planning on implementing better enforcement mechanisms at
GetOpenID.com so users can control whether to allow pulling insecure
identity pages for their ID.

> I'm beginning to wonder exactly what the use case of SSL identity pages
> is. The only thing identity pages are used for (as far as OpenID is
> concerned) is finding the identity server URL, so I have to assume that
> the use case in mind is to prevent "spoofing" of the identity URL to get
> the consumer (relying party) to connect to the wrong place.

Exactly. If you spoof the identity page, the whole OpenID system is
compromised because the RP will connect to a rogue server for ID
verification. A rogue server can assert any identity it wants.

> But if HTTP and HTTPS URLs are equivilent, surely I can just spoof the
> HTTP version of your HTTPS URL and defeat the object entirely!

No. Not if the RP either checks for the https page first or remembers
that a particular OpenID supports https identity pages and refuses to
fall back to http after one successful https identity page download.
Some RPs may choose to only allow https mode identities. It shouldn't
ever be the user's concern which scheme is being used. It should be the
RP's. We just need some standards so RPs can consistently implement the
varying level of security without user concern.

Here's a scenario where equivalence is good: An RP starts out as a
simple photo sharing site and allows any level (http or https) level of
signon. Later, the site starts commercial operations and stores credit
card numbers for easy purchases. The site should be able to start
requiring https identity pages without having to ask users to port their
old http identities to https ones. The site should be able to be upgrade
identities without worrying that OpenID servers might have a completely
different identity stored at the https page.

The key here is not forcing OpenID server to implement http and https
pages. It's just forcing OpenID servers not to host two different
identities at the same basic URL with just different schemes. That would
be enough.

> I also wonder whether SSL-supporting relying parties are actually doing
> proper certificate checks for SSL identity URLs. If so, which
> authorities should they trust? Should a relying party care if the
> hostname on a certificate is wrong as it currently is for VeriSign's
> PIP? Should a relying party check for certificate revocations? These
> things should also be in the spec, really.

Of course the RP should check such things, but your conclusion is
flawed. The complexity in implementing a good SSL client isn't an
argument for not using SSL. Choosing root certificates to trust isn't
easy, and it never will be. It's still a necessary task. Good security
is often complex.

- David