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 > [email protected] > skype: 1-703-879-3176
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
