[OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

[Martin Paljak]

On 02.01.2009, at 19:10, Peter Watkins wrote:
> On Fri, Jan 02, 2009 at 11:08:39AM +0200, Martin Paljak wrote:
>
>> In real life most end user software do not check for the status of a
>> certificate (CRL/OCSP)
>
> I suspect that claim is not true. IE7 on Vista and Firefox 3 default
> to using OCSP -- for instance, by the time I followed the recipe for
> the www.mozilla.com demo of the cert that never should've been issued,
> Firefox 3's OCSP check rejected it.
Probably correct. I use Safari and I visit way more secured sites than  
I notice outgoing ocspd request. But browsers are well developed and  
have a lot of developer attention. Features which CAs monetize from  
(EV for example) need to be visible to be able to earn from them (and  
to enable the EV patchwork in the first place). My main concern here  
is OpenID and related RP server software, which is not so old and  
settled as browsers. If I want to break OpenID I want to break the RP- 
OP interaction, not the end-user who is attacked a lot already by  
trojans and worms. This means faking the OP for the RP somehow. Do you  
know of any OpenID RP-s that do OCSP/CRL?

>> I second here the questions often raised about CA-s by Peter  
>> Williams,
>> but the community has managed to subtly ignore the topic. "If there  
>> is
>> a problem (which we don't believe there is) then this is for the PKI/
>> TLS/HTTPS guys to fix", "Just pay to a big company for your certs",
>> "Apparently we use whatever CA certificates Debian uses" are all  
>> signs
>> of delegating the problem somewhere else.
>
> And why not delegate? TLS is a bedrock security technology for current
> Web business -- from a simple Yahoo storefront to millionaires  
> accessing
> their online brokerage accounts. A lot of business have a lot riding  
> on
> TLS and https, and a lot of incentive to fix any problems. And we've  
> seen
> them do just that. It's not perfect (I'm still peeved that Microsoft  
> has
> effectively blocked attempts to give TLS RSA decent forward  
> secrecy), but
> TLS is widely understood to be critically important, and people more
> influential than us, and smarter than me, are working on this stuff  
> -- the
> improved OCSP support in Firefox and IE7 being a good illustration.

I love HTTPS actually. But you can have way different implementations  
with different user interactions.

But OpenID is by nature much more pgp-is (web of trust) than it is  
x509-ish (hierarchical).

There are two sides for the PKI coin. One is CA-s who want to earn  
money by issuing certificates. They have to cater to the ones who give  
them the money - companies who buy certificates. The way the  
certification business has transformed into awkward "trust business"  
is what disturbs me. There are risks (damages eavesdropping for  
example) which RP-s mitigate with certificates. The relation between  
RP-s and CA-s  who certify them is right and justified - it's business.

Then there are end-users like me and you, who CA-s don't really care  
about. They only care that their root certificate would be one of  
those that do not trigger the 'invalid certificate' popup or something  
comparable for the user and are happy if the user happens to have some  
software which can show green somewhere. Most important is not to nag  
the user. A user does not bring direct revenue. This is what disturbs  
me. This has lead to the fact that current PKI implementations only  
cater one need - CA business.


>> In addition to "lets just do what everybody else is doing" OpenID
>> could provide additional mechanisms. I once suggested having a
>> separate configuration file and format for RP libraries to be able to
>> configure white/blacklists and OP certificates/CA-s checksums and
>> trust settings.
>
> Nothing is stopping any RP from doing that. Shoot, that's what  
> Microsoft's
> HealthVault site has been doing for OpenID all along.

This is the "OpenID is an open system - you can do whatever you want  
with it" delegation. Why on earth would  anyone want to have NIST  
level 4 authentication in an OpenID system if the strength is useless  
for most RP-s? If I anyway need to make peer to peer, out of band  
arrangements to make use of the authentication strength, I would  
probably go for SAML peering anyway. Does OpenID want to be as one- 
sided as the rest of the binary "trust business" of CA-s ("in the  
default list" or "not in the default list" of some software)?


I'd like to bring the problem to the attention of developers, OpenID  
RP admins but also end-users. I believe it is hard to change web  
browser implementations in near future but it is possible to change  
OpenID implementations. Just as it is obvious these days that the  
padlock sign in the browser is not enough (thus EV) I want to make the  
point that "We know what is best for you" approach is not enough for a  
flexible future.

So, to focus on OpenID and what OpenID can do in this matter:

- I have nothing against EV certificates - EV is a good core upgrade  
for the core business of CA-s - certification.
- I have a lot against the not-done-by-me pre-made all-or-nothing  
trust decision in the form of "System trusted CA list"
- For uniform user experience different error handling scenarios  
should be defined for OpenID, instead of "left to the platform/tool  
configuration" (cases like CA list missing, self-signed OP certificate  
or something similar)
- Bring those tunables to OpenID spec/guide level, so that  
administrators and integrators would have a single point to tune these  
behaviors (possibly a common format and configuration file which could  
be usable in any OpenID RP implementation)
- Allow to explicitly trust/distrust a set of certificates and CA-s  
(by fingerprints).
- Support basic authorization like white/blacklisting of URL regexps  
in the same configuration file.
- Advocate for EV-aware RP software, RP software that raises alarms if  
OP certificates change suddenly
- ...

I know that OpenID generates much more buzz in the 'transport my XXX  
social network profile to ZZZ' but it could in its basic profile be as  
universally secure as possible. Even for those who don't care.


-- 
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495