User:Johnath/EVDraft13ReviewComments

Working page for discussions around Draft 13 of the EV Certificate Guidelines.

Change Requests - Technical

• 6 (a) 4 specifies a subject serial number that will be non-unique in many cases. At first glance, though, it appears to use the OID for certificate serial number, which should be unique. If this is a supplemental serial number (e.g. to make it easier to look the entity up in the appropriate government database) then we propose adding language which advises implementers not to treat it as unique.

• 26(a)(1)(B) should be tightened up to say something like "If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four (4) days. OCSP responses from this service MUST have a maximum expiration time of ten (10) days."

• 26 (b) seems to incentivize CAs to clear out their CRLs rather than "risk" a long list that takes too long to load. If the goal is to guarantee a minimum level of service, then we propose: "...the CA MUST ensure all requests for CRLs for an EV Certificate chain receive a response in no more than three (3) seconds over an..." This way the user agent knows CRLs are coming, even if they will realistically take longer than 3 seconds to arrive completely.

• 26 (d) creates a window of time (near the end of the cert's life) where revocation will have little effect, since the revocation could disappear as soon as the cert expires. It would be nice if revocations were never dropped, and proper browser practice ought to reject expired EV certs anyhow, but I wonder if there is any objection to adding some time to this, at least. e.g. "Revocation entries on a CRL or OCSP MUST NOT be removed until 2 yrs after the expiration date of the revoked EV Certificate."

• Appendix A: Regarding ECC, we only have plans to support P-256, P-384, and P-521. So our only overlap will be the P-256 curve. Do other browsers have similar plans, and will this present difficulty?

• Appendix A: This list of ECC curves should be changed to reference the NIST names (P-256, etc.) so everyone knows what we're talking about. There are multiple parameters to ECC curves, not just the keysize. Specifying that we're using NIST named curves (vs SECG or ANSI or something else) eliminates any possible confusion.

• Appendix A: There should be no new CA roots or subordinates with RSA keys less than 2048 today. Although they are probably trying to accommodate legacy roots already in the browsers, this document must make clear that 1024-bit RSA keys are too weak and cannot be used.

• We should add (somewhere, I'm not sure where) a section that says something like "Each CA that issues EV certificates must host test web services that allow Application Software Vendors to test their software. At a minimum, EV CAs must host separate web pages using certificates that are (a) valid (b) revoked, and (c) expired."

Change Requests - Procedural/Language

• 2(b) includes language about confirming legal and physical existence as a secondary goal, when it's pretty clear that this is a primary purpose of EV from reading 2 (a) 1. Recommend removing that text, so the line reads, "The secondary purposes of an EV Certificate are to help establish the legitimacy of a business claiming to operate a website, and to provide a vehicle..."

• 5 (b) does not mention verifiable physical presence as a requirement for private organizations though it does for business entities in 5 (d). Is this an oversight? We would very much expect verified physical presence to be a requirement for private organizations as well.

• 18 (b) 4 talks about flagging mixed-character-set domains if they collide with known high-risk domains. With the recent talk about "spear-phishing" (phishing which precisely targets smaller user bases, e.g. employees of a single company) it seems that mixed-character-set homograph attacks might become more widespread. We would like to see all mixed-character-set domains flagged for high-risk screening, but we don't know what percentage of CA requests that represents, in order to gauge how reasonable a request it is.

• 27 (b) (11) currently says: "The CA’s Private Key for that EV Certificate has been compromised;" which makes it a little unclear which key is being referenced. Suggest: "The Private Key of the CA's Root Certificate used for issuing that EV Certificate is suspected to have been compromised;"

• 35 (c) 3 specifies that audit reports must be made available publically. We have had government CAs refuse to release audit reports, deeming them classified, and would like to strengthen this language to explicitly apply it to all CAs. Recommend: "For both corporate and government CAs, the audit report MUST be made publicly available by the CA."

• 37 (a) 1 specifies liability limits. It does not currently specify either way, but we'd like to be clear that this doesn't preclude/prevent class action lawsuits.

Requests for Clarification/Elaboration

• D-F I don’t see logotype mentioned. Does that mean the field is not included in EV certs, or just that it's not vetted?

• 26(a)(1)(A) refers to CRL expiration time. Despite the popular misconception, there is (sadly) no such thing as CRL expiration, at least not one that's baked into the CRL. There is a "nextUptime" field that specifies that a new CRL will be published no later than that time. There's probably more back story to this with the CAB Forum that I'm not tracking.

• 26(a) says that OCSP is optional until Dec 31, 2010 which seems like a long lead time. What are the reasons behind this timeframe?

• 28(a) talks about providing a mechanism for reporting bad citizens, but lacks details. Will this be manual (paper/web form) or is an automated "Report an evil website to CA XYZ" service possible?

• Web Trust failures. If an EV CA fails a WebTrustEV (or equiv) audit, how do browser vendors find out that we shouldn't trust that root any more?

• Has anyone consulted any law enforcement practitioners to determine if these guidelines will actually help in terms of either:
  • preventing issuance to fradulent holders, or
  • prosecuting those individuals?

• As an open organization, we include provisions to allow for alternate, equivalent auditors instead of WebTrust, but we don't seem to specify what grounds will be used to judge equivalency beyond "as approved by the CABForum." Is this something we intend to do either as part of this document, or as an additional document of its own?