[OpenID] Backwards Compatibility

Andrew Arnott andrewarnott at gmail.com
Tue Mar 17 21:10:12 UTC 2009


Why remove DH key exchange?  Wouldn't the remove the capability for arbitrary
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.
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.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire


On Mon, Mar 16, 2009 at 10:48 PM, Allen Tom <atom at yahoo-inc.com> wrote:

> +1
>
> 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.
>
> If anything, I'd like to see things removed from 2.0, such as the DH key
> exchange.
>
> The 2.1 spec should mostly clarify ambiguous portions of the 2.0 spec,
> especially wrt to delegation and directed identity.
>
> Allen
>
>
>
>
> Martin Atkins wrote:
>
>> David Recordon wrote:
>>
>>> Hey Carsten,
>>> 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.
>>>
>>>
>> 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.)
>>
>> 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.
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090317/36c23ad0/attachment-0002.htm>


More information about the general mailing list