[OpenID] [LIKELY_SPAM]Re: Problems with delegation and directed identity OPs

[John Bradley]

OSIS has test endpoints published for a number of tests.
http://osis.idcommons.net/wiki/Main_Page

Feedback and volunteers to produce new tests are welcome.

We will be meeting at IIW to review plans for the next interop  
including openID tests.

Best practices for documents for OPs are defiantly required.

We won't speak of the new OP that is currently in beta who is forcibly  
normalizing everyones URI to http:
even if they type https: into the openID login box.

If the OP for the iName is registered iBroker ie selling = and @ names  
send me the link and I will look into it.
That should not be happening.

There are a number of SSL issues including RPs not checking CRL or OCSP.
People thought revoking a site cert for a OP wouldn't be necessary.

Well it happened to Sun when the cert for there OP was discovered to  
be weak,  as are perhaps many other cert's where the keys were  
generated on Debian.

No security is perfect,  however we should do our best to avoid the  
obvious mistakes.

Regards
John Bradley
=jbradley

On 6-Nov-08, at 1:34 PM, Peter Watkins wrote:

> On Thu, Nov 06, 2008 at 03:39:21PM -0500, Deron Meranda wrote:
>
>> Yes, I agree.  I'm still just playing with it, but I was pretty sure
>> that security could be compromised if SSL wasn't used during
>> delegation discovery.
>
> SSL/TLS ought to be used throughout. It's nice if the discovery URL
> has https protection, but what's the point if the OP endpoint uses
> http and is therefore vulnerable to MITM? Sure, it's more complex
> than simple browser-website MITM, but https certs and CPUs are cheap,
> so these attack vectors ought not exist anymore.
>
> The other day I wanted to test XRI with the app I'm working on, and I
> don't want to pay $ for an iname, so I plugged in the = nym for a
> prominent member of the OpenID community. IIUC, the XRI spec requires
> the first stage of XRI discovery to use https. But the login page I
> ended up at used plain old http. And the <form> didn't even specify
> an https action to receive the password it requested! (Yes, I emailed
> the iname owner about it.) My app had good reason to believe that it
> knew the correct hostname to contact, but beyond that, no crypto  
> assurance.
>
>> Even then, it seems that some RPs don't really do SSL correctly;
>> they don't completely validate the SSL certificates against a
>> trusted list of root CAs.  So if self-signed SSL certs don't raise
>> any warnings; then SSL is sort of compromised anyway.
>>
>>
>> It's things like this that really need to get documented.
>
> Agreed. It'd be nice to set some system up for testing; for this
> specific test, at least the https cert wouldn't cost anything. :-)
>
> -Peter
>