4
edits
Security:EV: Difference between revisions
Jump to navigation
Jump to search
→Contra
(→Pro) |
(→Contra) |
||
| Line 19: | Line 19: | ||
=== Contra === | === Contra === | ||
* The CA/Browser forum, which maintains the standard, is not accessible to all the CAs in the Mozilla root certificate store, because of the requirement for | * The CA/Browser forum, which maintains the standard, is not accessible to all the CAs in the Mozilla root certificate store, because of the requirement for an annual Webtrust (or equivalent) audit. | ||
* While the Mozilla project has one vote in the Forum, we cannot control for certain how the EV guidelines may change in the future. | * While the Mozilla project has one vote in the Forum, we cannot control for certain how the EV guidelines may change in the future. | ||
* Higher level of validation of the organization, similar to the proposed EV standard, exist and are offered already today by most CAs. It's the subscribers which makes the decision about which level of verification to perform. Therefore EV doesn't provide anything which isn't available today. | * Higher level of validation of the organization, similar to the proposed EV standard, exist and are offered already today by most CAs. It's the subscribers which makes the decision about which level of verification to perform. Therefore EV doesn't provide anything which isn't available today. | ||
* 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 | * C4a3: EV requires an annual audit against Webtrust or equivalent criteria which may not be financially possible for some CAs in the Mozilla root store. | ||
* A1b: EV only covers server-authentication, which leaves out client certificates, which are necessary for S/Mime, which should protect email. | |||
* A1b: EV only covers server-authentication, which leaves out client certificates, which are necessary for S/Mime, which should protect email | |||
* 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. | * 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. | ||
* 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. | * 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 | * 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. | * 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 | * 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: | * B3a2C: In the current versionof the EV Guidelines, 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 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 only demands the maintaining of the secrecy of the private key, but forgets the initial secrecy. This is a bad, but common practice. | ||