Why remove DH key exchange? Wouldn't the remove the capability for <span class="Apple-style-span" style="font-style: italic;">arbitrary </span>RPs and OPs to establish an association unless the OP supported SSL? Key word is arbitrary. I'd hate to lose the ability to securely exchange a secret with an OP that doesn't expose an SSL OP endpoint.<div>
<br></div><div>DNS poisoning attacks are possible without SSL, I know. But sniffing a password in plaintext is so much easier than poisoning someone's DNS server, especially if said DNS server has mitigations against poisoning already. So it seems there are legitimate uses for OPs without SSL support, but that goes completely away without DH.</div>
<div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Mon, Mar 16, 2009 at 10:48 PM, Allen Tom <span dir="ltr"><<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
+1<br>
<br>
I'd be very happy to see 1.1 clearly deprecated, and in an ideal world, existing 2.0 implementations would already 2.1 compliant.<br>
<br>
If anything, I'd like to see things removed from 2.0, such as the DH key exchange.<br>
<br>
The 2.1 spec should mostly clarify ambiguous portions of the 2.0 spec, especially wrt to delegation and directed identity.<br><font color="#888888">
<br>
Allen</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
Martin Atkins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
David Recordon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Carsten,<br>
I agree with you. It's time to make sure that 1.1 is clearly deprecated and that everyone implements 2.1 once it is completed.<br>
<br>
</blockquote>
<br>
Is there some compelling reason not to make 2.1 a superset of how 2.0 is implemented today? (That is to say, not a superset of the spec as written, but a superset of the parts of it that are implemented and the errata.)<br>
<br>
I think in an ideal world every existing, well-behaved 2.0 implementation would already be a fully-compliant 2.1 implementation. This implies a research-driven approach involving the studying of existing implementations; there should be a high barrier to specifying anything that disagrees with an existing, well-behaved implementation.<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</blockquote>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br></div>