<div dir="ltr">Gerald,<br><br>As you are migrating your Sun users, please consider:<br><h3 class="post-title entry-title"><a href="http://blog.nerdbank.net/2008/07/how-to-make-your-openid-provider-case.html">How to make your OpenID Provider case insensitive</a></h3>
<br>And I would add to the highly recommend best practice of redirecting to HTTPS, to also highly recommend that all directed identities result in an HTTPS claimed identifier as opposed to the HTTP "equivalent" one.<br>
<br><div class="gmail_quote">On Mon, Aug 11, 2008 at 2:15 PM, Gerald Beuchelt <span dir="ltr"><<a href="mailto:beuchelt@sun.com">beuchelt@sun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Martin - <br>
<br>
Thank you for the advise. Once we have migrated a significant
number of our user population, we are quite determined to redirect. <br>
<br>
However, this does not solve the initial RP-side normalization to
HTTP based identifiers. In my opinion, it is a necessary step, but not
sufficient. But I would agree that performing a redirect on the HTTP
port to HTTPS should be a highly recommended best practice. <br>
<br>
Best, <br><font color="#888888">
<br>
Gerald</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<br>
Martin Atkins wrote:
<blockquote type="cite">
<pre>Gerald Beuchelt wrote:
</pre>
<blockquote type="cite">
<pre>In a nutshell, we would like to require all users to use <a>https://</a>
prefixed OpenID identifier, so that RPs normalize and discover over
HTTPS, instead of HTTP. The obvious issue is that -- to my knowledge --
<a href="https://openid.sun.com/user" target="_blank">https://openid.sun.com/user</a> != <a href="http://openid.sun.com/user" target="_blank">http://openid.sun.com/user</a>. At this point
I see an opportunity for the OpenID community to address some of the
recent vulnerabilities: if RPs started to recognize both <a>https://</a> and
<a>http://</a> prefixed identifiers as the same entity, or at least allowed
easy linking, users could migrate with a lot more ease.
</pre>
</blockquote>
<pre>It's worth noting that allowing <a href="http://example.com/" target="_blank">http://example.com/</a> to redirect to
<a href="https://example.com/" target="_blank">https://example.com/</a> as per the spec does not create a vulnerability for
<a href="https://example.com/" target="_blank">https://example.com/</a>. Due to the non-equivalence of the two, an attacker
that compromises <a href="http://example.com/" target="_blank">http://example.com/</a> has not also compromised
<a href="https://example.com/" target="_blank">https://example.com/</a>. Were RPs to consider the http: and https: URLs
equivalent, this would actually defeat the security provided by SSL
since an attacker could attack the http: URL and compromise the https:
URL for free.
Therefore I would advise that if you are going to allow only https:
identifiers that you consider the "final URL" after discovery, rather
than the initial URL the user enters. This would allow the OP to
redirect the non-SSL version to the SSL version of the identifier, which
is something that most SSL-supporting OPs do already and I think is
considered to be a best practice.
_______________________________________________
general mailing list
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br></div>