[security] SL comprimise

[John Bradley]

I am more concerned with RP checking CRL to prevent spoofing of an entire IdP.

I don't see any privacy concern with that, unless you happen to be the only user at the IdP.

I will leave the browser OCSP/CRL question alone for the moment,  that is largely out of our control.

Users accept certs that are invalid all the time,  so I have limited expectations of browser based protection at the moment.

I am not arguing for the current SSL/TLS certificates and system system brought to us by our friends at the CAB Forum.

However it is a reality.  

For the FICAM profile we decided that protecting RP from bulk compromises is more important than the possibility of denial of service from a attack on a CA's server.

It depends on what you want the failure mode to be,  open or closed.   

RP's are not making informed decisions at this point.

John B.

On 2011-03-25, at 4:36 PM, Kurt Seifried wrote:

> My concern with this is two fold:
> 
> 1) Unintentional denial of service, if we support strict SSL checks
> then anytime the CA goes down we can't do anything. If we don't do
> strict SSL then really, what's the point? Any attacker that can insert
> their stolen/improper/etc. SSL certificate can most likely also block
> our traffic to the CRL/OCSP server. Ugh.
> 
> 2) Privacy. Every time I go to an SSL enabled website that CA gets to
> record that I went there, what time, my IP, etc. Since I don't have a
> real choice in say which SSL CA a large service like Google uses I
> have to give up privacy in order to use Google services. This is
> especially true for internal services that are security sensitive.
> Ugh. OCSP stapling may help here.
> 
> There are some other major issues but as far as I can tell SSL is so
> fundamentally broken at the design and operational level it can't be
> fixed, I wrote some articles last year but gave up tilting at
> windmills because it was largely having no effect.
> 
> We could do some clever things like
> http://www.networknotary.org/firefox.html which help, but even as a
> highly technical user even I have a tough time assigning trust/etc. to
> SSL certificates presented to me because I have no idea how securely
> the CA is run or how well they truly do verification (and as evidenced
> by this week and articles like https://blog.startcom.org/?p=152 it's
> obvious that there are some very bad worst case scenarios happening).
> 
> My one thought was rating CA's and including an indication of how
> trustworthy the CA issuing the cert for a site is but that I think
> just leads to information overload and people clicking "Ok".
> 
> -- 
> Kurt Seifried
> kurt at seifried.org
> skype: 1-703-879-3176

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20110325/787f31f5/attachment-0001.p7s>