My question to the browser vendors, in particular Mozilla, is still unanswered:
> Doesn't that call for more a rigorous action from the browser vendors > (given that Verizon is apparently no longer a CABF member, so the > stick of cancelling their membership is already ineffective)? As demonstrated by the cclearning.accenture.com case, Verizon does its own "risk assessment", decides to not follow the BR, Mozilla (Corp.) remains silent... and then everyone goes back to regular schedule? I don't think that's an appropriate way of dealing with this issue. Meanwhile I had another look at Verizon's EV SSL machinery. Since its inception, the EV Guidelines have very clearly stated: "CAs MUST support an OCSP capability for Subscriber Certificates that are issued after Dec 31, 2010." (Draft 11 from 20 October 2006 already had it, in version 1.4 it disappeared due to the BR being incorporated by reference) And http://www.verizonenterprise.com/us/products/security/identity/ssl/evssl.xml at least states: "We support and use Version 1.3 of the Extended Validation Certificate Guidelines developed by the CA/Browser Forum" They refer to an older version of the EV Guidelines on their Web site, but their CP/CPS (http://cybertrust.omniroot.com/repository/Cybertrust_CPS_v_5_4.pdf) on the other hand is fine when saying: "SureServer EV issuance and management practices comply with the current version of the said Guidelines." Ok, then in 2013 there must sure[server]ly be an OCSP responder for these EV thingies, right? Just an unfortunate glitch that they forgot to include the respective URI in the cert... but nobody is perfect. Let's see if we can figure out ourselves where that responder lives: > $ openssl s_client -connect ev.omniroot.com:443 </dev/null 2>&0 | openssl > x509 -noout -text | grep http > > URI:http://crl.omniroot.com/SureServerEV.crl > CPS: http://cybertrust.omniroot.com/repository Ah, must be ocsp.omniroot.com, most likely. Let's try: > $ host ocsp.omniroot.com > ocsp.omniroot.com is an alias for evocsp.us.omniroot.com. > evocsp.us.omniroot.com has address 64.18.17.38 Great! Apparently they operate a responder in the US. Let's try to ask it for the status of the "ev.omniroot.com" cert, then: > $ curl -siH Accept: > http://ocsp.omniroot.com/ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en%2F2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAAAAAATOE8KOLdzwV > HTTP/1.1 404 Not Found > Date: Sun, 06 Oct 2013 14:13:55 GMT > Server: Apache/2.2.15 (CentOS) > Content-Length: 389 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > <html><head> > <title>404 Not Found</title> > </head><body> > <h1>Not Found</h1> > <p>The requested URL > /ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en/2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAAAAAATOE8KOLdzwV > was not found on this server. > </p> > <hr> > <address>Apache/2.2.15 (CentOS) Server at ocsp.omniroot.com Port 80</address> > </body></html> Ouch. Hmm, apparently no GET support here yet - wasn't there a section about this somewhere in the BR... (13.2.2)? Well, anyway, let's be nice and try again, this time with POST: > $ echo > ME8wTTBLMEkwRzAJBgUrDgMCGgUABBQ5h1nWidcsYM7en/2U9AwLuY57WgQUm3tY6z0D5IfI5IzqRnySVOk2u54CDgIAAAAAATOE8KOLdzwV > | openssl base64 -d -A | curl -iH "Content-Type: application/ocsp-request" > -H Accept: --data-binary @- http://ocsp.omniroot.com > HTTP/1.1 200 OK > Date: Sun, 06 Oct 2013 14:14:04 GMT > Server: Apache/2.2.15 (CentOS) > Last-Modified: Mon, 18 Feb 2013 16:54:02 GMT > ETag: "20117-7-4d6029275fa0f" > Accept-Ranges: bytes > Content-Length: 7 > Connection: close > Content-Type: text/html; charset=UTF-8 > > server Wow, fantastic! It's telling us that it is a *server* (not some toy, in case you were wondering). And of course text/html is perfectly matching for a request of type application/ocsp-request, isn't it? Going back to the first message in this thread and the Netcraft blog entry, what is really egregious is not so much the fact that Netcraft found "an EV certificate without an OCSP URL!" for enroll.americanexpress.com - the point is that Verizon does not provide a working OCSP responder for their EV certs *at all*... even though the EV Guidelines made a responder mandatory as of January 1, 2011 (see above). I fail to see a reason why Mozilla's next action should not consist of reverting the Cybertrust-related changes committed with https://bugzilla.mozilla.org/show_bug.cgi?id=493709, and only re-enable Verizon for EV after they have completed a new full WebTrust EV audit. Kaspar P.S. Apart from the non-compliant businessCategory attributes mentioned before, the issuer DN for the Verizon EV SSL CA also does not meet the requirement from BR section 9.1.4: there's no countryName RDN (it's just "O=Cybertrust Inc, CN=Cybertrust SureServer EV CA"). _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
