[OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining Google & Yahoo user experience research

[Peter Williams]

I've decided to follow up why I feel duped, to see if it's legit. A much simpler explanation is that I'm still (!) just not thinking right about OpenID2, yet, fundamentally (probably because I'm just too stupid, or perhaps fixated in older paradigms).





I like the innovation. But I'd feed highly duped by the writing, as a security engineer, if the above holds. Folks from  the bottom of the class (like me) just would not make the correct interpretation of the standard, by themselves.





In appendix A.1 (following up section 7.1) of http://openid.net/specs/openid-authentication-2_0.html#XRDS_Sample, we see evidence that an 'Identifier' is not limited to the HTTP URL scheme, in the line:-



http://example.com/user       http://example.com/user       URL   No trailing slash is added to non-empty path components



And, we may recall the long debate that concluded that the YADIS protocol (handling claimed identifiers) need NOT be conforming to the HTTP protocol (the whole 301 semantics issue) given the actual writeup, the intent of XRDS discovery (an Identifier is an "OpenID", distinct from  current webland ideas about URLs that are HTTP URL Scheme complying, and the Internet principle that (reasonable) protocol profiling of such as HTTP is always legitimate, anyways.





Thinking now anally like a security evaluator, http://yadis.org/papers/yadis-v1.0.pdf reduces HTTPS to a definition that specifically omits the role of HTTPS and PKI ciphersuites to properly manage secure namespaces (which enforce the HTTP URL scheme). It basically references TLS (vs the SSLv3 implemented in Navigator-compatible browsers (Mozilla and IE)) - a dumb layer 4 security transform set that is not involved in URL resolution, and does not enforce navigator's "secure URLs" feature.



At the same time, we have to note that OpenID recommends the use of https, during discovery. As the https run is being initiated by a server thread, vs a browser, given the nature of XRDS discovery, we really cannot assume that navigators secure URL controls are being mandated  (where "control over a domain-name" is asserted and validated using certification and X.509 cert path processing). XRDS discovery seems to simply want the server auth (and anti-replay) functional areas, to address the traditional crypto-level MITM against the DH process. OpenID2 Auth itself now replaces the secure naming role that certs play/ed in SSLv3-era secure URL resolution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081021/9e9fc4df/attachment-0002.htm>