[OpenID] D-H vs SSL

[Andrew Arnott]

Peter, no offense, and maybe it's just me, but you have a strong tendency to
snow with acronyms.  What is DOCSIS/DSLAM and CO?
How in the world can you get a free HTTPS certificate that nearly all RPs
will accept for $0?  It seems to me that there is a price for SSL if you're
hosting your own OP or even vanity URL using SSL, since you need a cert that
most browsers and RPs trust.
--
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


2009/3/19 Peter Williams <pwilliams at rapattoni.com>

>  What is that price?
>
>
>
> Its zero, today. DDNS registers the current DHCP address from the
> DOCSIS/DSLAM multiplexor at the CO, and one uses the wifi router to define
> ones persistent domain suitable for https URI.
>
>
>
> I know folks are trained to think in VeriSign mantra (that all CA work has
> to be a giant national infrastructure- with entierprise corporate practices
> and trillion dollar warranties. Bbut don’t fall into that trap - in a UCI
> space. Just think like of home wifi router, as your OP (or the vanity
> discovery point).
>
>
>
> *From:* general-bounces at openid.net [mailto:general-bounces at openid.net] *On
> Behalf Of *Allen Tom
> *Sent:* Thursday, March 19, 2009 11:57 AM
> *To:* Andrew Arnott; OpenID List
> *Cc:* Martin Atkins
> *Subject:* Re: [OpenID] D-H vs SSL
>
>
>
> The DIY ethic of OpenID is also one of its main strengths, as as Johannes
> pointed out, there are plenty of scenarios where someone might want to run
> an OP without HTTPS. For instance, I'm not willing to pay the price to
> support HTTPS on my own personal domain.
>
>
> As I mentioned earlier, I only brought up DH because I felt that it could
> be something that could be removed from the core spec, with the goal of
> making the spec lighter. Given the discussion so far, it looks like there
> are good reasons for keeping DH in the spec.
>
> Allen
>
>
> Andrew Arnott wrote:
>
> Well, the spec allows for session types to be implemented that are not
> defined in the spec.  If DH is ever removed from the OpenID spec, I hope the
> spec can reference another DH spec that keeps it alive as a spec that people
> can optionally implement.
>
>
> --
> 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
>
>  2009/3/19 Allen Tom <atom at yahoo-inc.com>
>
> If we consider OAuth's secret exchange mechanism for HMAC-SHA1 sigs,
>
>    - OAuth Service Providers usually issue a Consumer Secret to the
>    developer, without any input from the developer. (hopefully via HTTPS)
>    - OAuth Request Token and Access Token secrets are issued by the
>    Service Provider to the Consumer (also, hopefully via HTTPS), without any
>    input from the Consumer
>
> Returning cleartext secrets via HTTPS would be consistent with OAuth.
>
> Although DH on top of SSL is safer than cleartext and SSL, is the overhead
> of having the spec discuss DH worth it? If the OP is unable to generate a
> strong secret on its own, or if the transport layer between the RP and OP
> cannot be secured using HTTPS, then arguably the entire system has issues.
>
> I only mention DH, not because I have an issue with DH, but because one of
> OpenID's most desirable traits is its relative simplicity. The spec is
> pretty straightforward, and it's not all that hard to implement. Sites that
> want a richer (and more complicated) SSO protocol standard have alternatives
> that are already in production and are widely used.
>
> Allen
>
>
>
> Ben Laurie wrote:
>
>  Ah. I see.
>
>
>
> So, I am going to be lazy, because I have not checked the spec, but
>
> its considered good practice when establishing a shared secret for
>
> both sides to contribute to that secret. Is that true for the
>
> cleartext secret?
>
>
>
>
>
>
> _______________________________________________
> 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/20090319/92e82485/attachment-0002.htm>