User:Johnath/EVDraft13ReviewComments

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

And Gerv's comments on the changes which have been made in response to our feedback.

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.

Clarified in draft 15. The standards do not require this identifier to be unique, merely to disambiguate. So, the word "unique" was removed from the description.

• 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."

Fixed in draft 15.

• 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.

No changes made here. But I don't understand the objection. If the CA is concerned that their CRL might get too big, they can issue different batches of certs with different CRL URLs.

• 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."

After discussion on the CA/Browser Forum mailing list, it was agreed that no change was necessary here. This requirement would place unwarranted burdens on CAs and certificate holders. The RFC states that revoked certs must appear at least on the first regularly-scheduled CRL update after the expiry date.

• 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?

Changed in draft 15 to only specify NIST P-256, as these are minimum requirements only. We need to negotiate separately with the other browser vendors to agree on a common suite of curves.

• 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.

Fixed in draft 15.

• 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.

This was changed in draft 15, but reverted in draft 17. The situation here is too complex to explain in this document; I will do so elsewhere.

• 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."

Added in draft 15 as Appendix C.

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..."

Fixed in draft 15.

• 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.

Fixed in draft 15.

• 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.

There was no discussion on this point.

• 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;"

Fixed in draft 15.

• 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."

Fixed in draft 15.

• 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.

I raised this at the meeting; it was explained that the only thing that can preclude class action lawsuits is government legislation. There's no way we could do so with a statement in this document.

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?

Logotype is still under discussion. I suggested at the meeting that we should ban its inclusion in the meantime, but the discussion moved on and we did not have time to return to the subject.

• 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.

Fixed in draft 15.

• 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?

The CAs are deeply concerned about having to support direct requests for OCSP information from millions of end users. The OCSP server software market is also immature. They want clients and servers which support OCSP stapling to be more widespread before committing to support.

• 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?

I was asked whether, with a full schedule, this was considered to be a deal-breaker for approving version 1.0 of EV, and I judged that it wasn't. So there was no discussion on this point.

• 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?

We need to negotiate this separately with WebTrust. I suggested that they did an RSS feed of status changes, and their representative thought that was a fine idea.

• 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?

There was no discussion on this point.

• 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?

At the meeting, I proposed a motion that CAs with an ETSI audit be allowed to be members of the Forum. This was passed. The representatives from WebTrust and the audit firms also said that they were going to do an equivalence analysis between WebTrust and ETSI to see whether one could do an WebTrust EV Audit on top of an ETSI audit, with a view to making this possible in the future. We may have documents which can help them here.