http://blog.gmane.org/gmane.comp.web.openid.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.web.openid.general/8086 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Andrew Arnott 2008-08-27T23:47:28 http://comments.gmane.org/gmane.comp.web.openid.general/8084 Apparently rfc2817 allows an http url tp be used for https security. Given that Apache seems to have that implemented [1] and that the openid url is mostly used for server to server communication, would this be a way out of the http/https problem? I know that none of the browsers support it, but I suppose that if the client does not support this protocol, the server can redirect to the https url? This seems like it could be easier to implement that XRI . Disclaimer: I don't know much about rfc2817 Henry [1] http://www.mail-archive.com/dev-tech-crypto< at >lists.mozilla.org/msg00251.html http://www.ietf.org/rfc/rfc2817.txt Home page: http://bblfish.net/ Story Henry 2008-08-27T19:58:15 http://comments.gmane.org/gmane.comp.web.openid.general/8082 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Shane B Weeden 2008-08-27T01:02:23 http://comments.gmane.org/gmane.comp.web.openid.general/8081 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general John Bradley 2008-08-25T21:21:26 http://comments.gmane.org/gmane.comp.web.openid.general/8075 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Nat Sakimura 2008-08-20T11:15:18 http://comments.gmane.org/gmane.comp.web.openid.general/8072 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Paul 2008-08-19T00:28:34 http://comments.gmane.org/gmane.comp.web.openid.general/8071 As this year's Google Summer of Code pencils down date has passed, with great pleasure I announce that CL-OpenID version 1.0 Release Candidate 1 is out. Cl-OpenID is an implementation of OpenID protocol in Common Lisp. It implements OpenID Authentication 2.0 standard and is compatible with OpenID Authentication 1.1. Both Relying Party (formerly called OpenID Consumer), and OpenID Provider are implemented. CL-OpenID is available on terms of GNU Lesser General Public License version 2.1 with Franz Inc.'s preamble, also known as LLGPL (Lisp Lesser General Public License). The project has been developed as a Google Summer of Code 2008 project, developed by Maciej Pasternacki and mentored by Anton Vodonosov. Original application is published at. CL-OpenID home page is at http://common-lisp.net/project/cl-openid/ Current code is in darcs repository http://common-lisp.net/project/cl-openid/darcs/cl-openid/ The 1.0 Release Candidate 1 version is tagged 1_0_rc1 in darcs, and is also downloadable from http://common-lisp.net/project/cl-openid/files/ (MD5 checksum for 1.0rc1 tarball is 248dbf1338a645505e9c53462867c93e), either directly, or with ASDF-Install. Full documentation is at http://common-lisp.net/project/cl-openid/darcs/cl-openid/README.html Final status report and plans for the future is published on my blog, at http://blog.pasternacki.net/2008/08/18/gsoc-status-update-week-12-final/ Maciek Pasternacki 2008-08-18T20:06:06 http://comments.gmane.org/gmane.comp.web.openid.general/8067 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Andrew Arnott 2008-08-15T08:28:50 http://comments.gmane.org/gmane.comp.web.openid.general/8066 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Uday Subbarayan 2008-08-14T17:27:39 http://comments.gmane.org/gmane.comp.web.openid.general/8065 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Andrew Arnott 2008-08-13T23:41:56 http://comments.gmane.org/gmane.comp.web.openid.general/8044 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Gerald Beuchelt 2008-08-11T19:44:34 http://comments.gmane.org/gmane.comp.web.openid.general/8034 Hy, the PAPE-Spec [1] defines three authentication policies and states that "additional policies can be specified elsewhere and used without making changes to this document. The policies described below are designed to be a starting point to cover the most common use-cases. Additional polices can be found at http://schemas.openid.net/pape/policies/." Since implementing theses policies requires changing my Provider AND the RP-Code (for a start there is no webservice or such like that tells you the relationship between the policies), I was wondering if anyone has already seen any peace of code that supports more than these three. Also since the addition of a policy would require to change both (Provivder and RP), I don't see how additional policies could spread out. Why should my RP request the additional policy "using-a-blue-keyboard" if I already know that the only OP in the world that supports this policy is the one I've written. To me this seems like a great way to break interoperability and support the creation of local dialects instead of a sound specification. Anyone has any thoughts on this? Regards, Christoph Eunicke [1] http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html Christoph Eunicke 2008-08-09T09:21:12 http://comments.gmane.org/gmane.comp.web.openid.general/7982 Hello. I have found resources for enabling web applications with OpenID for PHP, Ruby, ASP.NEt etc... I develop apps with Delphi and Intraweb (Service apps with own built in Web servers and as IIS DLL's) Deployed on MS windows servers. Is there an implementation of OpenID distributed as a DLL or a web services implementation? I will keep looking around and see what else is out there. Thanks. Lou Feliz 2008-08-08T14:17:13 http://comments.gmane.org/gmane.comp.web.openid.general/7979 Hi All, I have just published the second part to my blog on OpenID and usability; this part focusing on usability and the authentication process. You are welcome to read and comment: http://www.barnraiser.org/ Tom tom 2008-08-08T13:20:49 http://comments.gmane.org/gmane.comp.web.openid.general/7973 Security Advisory (08-AUG-2008) (CVE-2008-3280) =============================================== Ben Laurie of Google's Applied Security team, while working with an external researcher, Dr. Richard Clayton of the Computer Laboratory, Cambridge University, found that various OpenID Providers (OPs) had TLS Server Certificates that used weak keys, as a result of the Debian Predictable Random Number Generator (CVE-2008-0166). In combination with the DNS Cache Poisoning issue (CVE-2008-1447) and the fact that almost all SSL/TLS implementations do not consult CRLs (currently an untracked issue), this means that it is impossible to rely on these OPs. Attack Description ------------------ In order to mount an attack against a vulnerable OP, the attacker first finds the private key corresponding to the weak TLS certificate. He then sets up a website masquerading as the original OP, both for the OpenID protocol and also for HTTP/HTTPS. Then he poisons the DNS cache of the victim to make it appear that his server is the true OpenID Provider. There are two cases, one is where the victim is a user trying to identify themselves, in which case, even if they use HTTPS to "ensure" that the site they are visiting is indeed their provider, they will be unable to detect the substitution and will give their login credentials to the attacker. The second case is where the victim is the Relying Party (RP). In this case, even if the RP uses TLS to connect to the OP, as is recommended for higher assurance, he will not be defended, as the vast majority of OpenID implementations do not check CRLs, and will, therefore, accept the malicious site as the true OP. Mitigation ---------- Mitigation is surprisingly hard. In theory the vulnerable site should revoke their weak certificate and issue a new one. However, since the CRLs will almost certainly not be checked, this means the site will still be vulnerable to attack for the lifetime of the certificate (and perhaps beyond, depending on user behaviour). Note that shutting down the site DOES NOT prevent the attack. Therefore mitigation falls to other parties. 1. Browsers must check CRLs by default. 2. OpenID libraries must check CRLs. 3. DNS caching resolvers must be patched against the poisoning attack. 4. Until either 1 and 2 or 3 have been done, OpenID cannot be trusted for any OP that cannot demonstrate it has never had a weak certificate. Discussion ---------- Normally, when security problems are encountered with a single piece of software, the responsible thing to do is to is to wait until fixes are available before making any announcement. However, as a number of examples in the past have demonstrated, this approach does not work particularly well when many different pieces of software are involved because it is necessary to coordinate a simultaneous release of the fixes, whilst hoping that the very large number of people involved will cooperate in keeping the vulnerability secret. In the present situation, the fixes will involve considerable development work in adding CRL handling to a great many pieces of openID code. This is a far from trivial amount of work. The fixes will also involve changes to browser preferences to ensure that CRLs are checked by default -- which many vendors have resisted for years. We are extremely pessimistic that a security vulnerability in OpenID will be seen as sufficiently important to change the browser vendors minds. Hence, we see no value in delaying this announcement; and by making the details public as soon as possible, we believe that individuals who rely on OpenID will be better able to take their own individual steps to avoid relying upon the flawed certificates we have identified. OpenID is at heart quite a weak protocol, when used in its most general form[1], and consequently there is very limited reliance upon its security. This means that the consequences of the combination of attacks that are now possible is nothing like as serious as might otherwise have been the case. However, it does give an insight into the type of security disaster that may occur in the future if we do not start to take CRLs seriously, but merely stick them onto "to-do" lists or disable them in the name of tiny performance improvements. Affected Sites -------------- There is no central registry of OpenID systems, and so we cannot be sure that we have identified all of the weak certificates that are currently being served. The list of those we have found so far is: openid.sun.com www.xopenid.net openid.net.nz Notes ----- [1] There are ways of using OpenID that are significantly more secure than the commonly deployed scheme, I shall describe those in a separate article. Ben Laurie 2008-08-08T10:50:59 http://comments.gmane.org/gmane.comp.web.openid.general/7971 It seems that I have now _twice_ unsubscribed from JanRain's myOpenID newsletter. This is odd, because I never subscribed to it. I'm not in the habit of unsubbing from stuff I never subscribed to; normally I instead treat such material as spam, and blocklist it. I make a special case when I know I subscribed to something else, on the principle that an honest mistake may have occurred. I hope this unsubscribe mechanism works. Jack Cleaver 2008-08-08T07:58:06 http://comments.gmane.org/gmane.comp.web.openid.general/7962 The Identity in the Browser (IDIB for short) project has launched over on Google Code today: http://idib.googlecode.com The goal of this project is to produce an open source extension to Firefox that helps with usability problems and addresses several security vulnerabilities around OpenID. Ideally this is the start of making sense of what identity in the browser would look like. In the future, this could be the basis for integrated support in all modern browsers if the project goes well. A couple of key points: * This is still very rough and not meant for general users yet * The work may lead to extensions to the OpenID protocol that may take shape in the form of specifications - more information can be found on the project page wiki: http://code.google.com/p/idib/w/list * The discussion about IDIB is happening on the mailing list here: http://groups.google.com/group/idib Hope to see you there! - Scott Scott Kveton 2008-08-07T17:51:28 http://comments.gmane.org/gmane.comp.web.openid.general/7956 Hi, I wonder if someone could check out my delegation html code in : http://markcross.openid.co.uk/ As it delegates to Verisign PIP, but I cannot then use markcross.openid.co.uk with http://www.bibleapps.com/ & Google Friend Connect :-( Many thanks, Mark Mark Cross 2008-08-07T10:52:55 http://comments.gmane.org/gmane.comp.web.openid.general/7955 If the spec calls for any legal URI, and there is no theoretical length limit (but a practical limit because of what servers will allow to get through), how many OpenID servers (OP or RP) "in the wild" today would pass compatibility testing? I decided to research this matter more, and found one that seems prepared to fail: http://code.djangoproject.com/wiki/CookBookShortcutsOpenIDAuthentication I can't be sure because I don't read Python and I'm not even reading past that 5th line, but it seems simple enough - the input field for URI is 30 characters wide and will accept a maximum of 50 characters. I found something about a 255-byte limit (or 512, or 1024) for proxies, but this seems to be more about URI's in general and less about OpenID specifically: http://www.oreillynet.com/xml/blog/2007/12/question_does_the_uri_length_r.html And then, finally, I found an earlier thread on this very topic between Martin Atkins and Brad Fitzpatrick: http://lists.danga.com/pipermail/yadis/2005-May/000317.html I just read through the specs for v2.0 (and then searched for '50' and '255' to make sure I hadn't missed anything), but the only mention of either is for 'assoc_handle' and 'openid.response_nonce'. I went back to v1.0 and checked, discovering that there *was* mention under "Appendix D. Limits": http://openid.net/specs/openid-authentication-1_1.html#limits Is there some reason this section was removed under v2.0? -Shade SitG Admin 2008-08-07T08:45:03 http://comments.gmane.org/gmane.comp.web.openid.general/7944 OpenID Uri versus Email addresses -> Oh no I hear you cringe; not that old discussion again;) After six months of usability testing on youth in Sweden I am happy to publish the first in a series of OpenID usability reports, the first being about the OpenID URis versus the email address and how we dealt with the issue. Blog at http://www.barnraiser.org/ Thought some of you may find it useful. As always, comments welcome. tom tom 2008-08-05T10:12:21 http://comments.gmane.org/gmane.comp.web.openid.general/7933 Do the specs currently forbid RP's from differentiating between URI's based on capitalization? If not, I'd like to propose that they do, for two reasons; 1) Flexibility of implementation: not having to avoid a particular (favored/usual) programming method catering to the limitations of the platform or (database) software. 2) Certainty of identity; not letting NorMalUser into NormalUser's account when their Identity-hosting site doesn't see them as conflicting, and being able to recognize ShadowsInTheGarden.com as the same user as shadowsinthegarden.com by translating the string to all upper (or lower) caps for comparison :) -Shade SitG Admin 2008-08-05T00:52:40 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.openid.general