Problems with Extended Validation SSL

  1. C4a3: EV depends on WebTrust, does not work with ETSI

  2. D6a3: Incompatible to Qualified certificates
  3. A1b: Only covers server-authentication
  4. Does not address Man-in-the-Browser, even makes it worse by making the user thinks the connection is safe.
  5. There does not exist an official version of the EV Guidelines yet, but C4b3 requires to have a URL to the approved version of the EV in the policy. So it is impossible to fulfill.
  6. C4c1: Insurance requirements only create a barrier to entry for CA´s, and don´t improve the quality of the certificates.
  7. EV guideliens forget about the liability demands of the software vendors for their users
  8. Wildcard certificates are not allowed. -> Further income for commercial CA´s, questionable security value.

  9. D6a3: The OID´s (1.3.6.1.4.1.311.60.2.1.1, ...) are from Microsoft.
  10. The OIDs aren´t documented properly: http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.3.6.1.4.1.311.60.2.1.3&submit=Display&action=display

  11. B3a2C: Only registered organisations
  12. E12b2 demands a protection of private keys, but there is no possibility for anyone besides a developer to actually do that.
  13. E12b2 only demands the maintaining of the secrecy of the private key, but forgets the initial secrecy. This is bad common practice.
  14. E12b2 Proof-of-Non-Possession is missing
  15. K36 Privacy does not seem to be a major topic for EV
  16. K37 is likely problematic. (Systemic flaws like Man-in-the-Browser could be a problem here)
  17. AppendixB2c: Privacy issues regarding OCSP over HTTP

  18. 4.1.a It's impossible to fullfill all laws
  19. http://www.sslshopper.com/article-phishing-with-ev-ssl-certificates.html

  20. http://usablesecurity.org/papers/jackson.pdf

A website was using a wrong EV certificate:

See ExtendedValidationSSL

EvProblems (last edited 2010-01-13 16:34:35 by PhilippGuehring)