1
edit
Security:EV: Difference between revisions
Jump to navigation
Jump to search
→More Contra
(→Contra) |
|||
| Line 22: | Line 22: | ||
* It has been suggested[http://www.usablesecurity.org/papers/jackson.pdf] that some UI presentations of EV are ineffective against phishing. | * It has been suggested[http://www.usablesecurity.org/papers/jackson.pdf] that some UI presentations of EV are ineffective against phishing. | ||
* The standard has been criticized for a very high ''barrier to entry'' for middle and smaller sized CAs, without providing any benefits to relying parties because of low or non-existent liability[http://financialcryptography.com/mt/archives/000835.html]. | * The standard has been criticized for a very high ''barrier to entry'' for middle and smaller sized CAs, without providing any benefits to relying parties because of low or non-existent liability[http://financialcryptography.com/mt/archives/000835.html]. | ||
* C4a3: EV only allows WebTrust as an auditing infrastructure, it does not support ETSI compliant CAs. TS 101 456 is the ETSI standard for qualified certificate authorities who can issue qualified certificates. There are several CA´s currently audited against the ETSI criteria. More information about ETSI certification: http://portal.etsi.org/esi/esi_faq.asp http://www.post.trust.ie/images/sst19.pdf | |||
* D6a3: EV claims to be compatible to qualified certificates, but is practically incompatible to Qualified certificates, due to qualified certificates only being personal certificates, and EV certificates only being organisational certificates. | |||
* A1b: EV only covers server-authentication, which leaves out client certificates, which are necessary for S/Mime, which should protect email, which is the main attack vector of Phising. So EV clearly does not address the Phising problem. | |||
* EV completely ignores the Man-in-the-Browser problem: http://www2.futureware.at/svn/sourcerer/CAcert/SecureClient.pdf It even makes the situation far worse, since the EV certificate claims that the user has a secure connection to the server, which in fact is not the case. | |||
* 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 the EV guideline at the moment. | |||
* The Insurance requirements stated in C4c1 of the EV guideline creates a strong barrier to entry for CA´s, but it doesn´t create a real incentive for the CA to improve the quality of the certificates. A better incentive mechanism should be used. | |||
* EV guideline forgets about the liability demands of the software vendors for their users | |||
* Wildcard certificates are not allowed, which leads to further income for commercial CA´s, but it does not provide real security value. | |||
* D6a3: The OID´s (1.3.6.1.4.1.311.60.2.1.1, ...) which are referenced in the Guideline are from Microsoft, and are not 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 | |||
* B3a2C: Only registered organisations are allowed to receive EV certificates, all other kinds of organiations are left out | |||
* E12b2 demands a protection of private keys, but there is no possibility for anyone besides a developer to actually do that. | |||
* E12b2 only demands the maintaining of the secrecy of the private key, but forgets the initial secrecy. This is a bad, but common practice. | |||
* E12b2 Proof-of-Non-Possession is missing | |||
* K36 Privacy does not seem to be a major topic for EV | |||
* K37 is likely problematic. (Systemic flaws like Man-in-the-Browser could be a problem here) | |||
* AppendixB2c: Privacy issues regarding OCSP over HTTP aren´t being taken care of | |||
== Proposals and Suggestions == | == Proposals and Suggestions == | ||