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. The CAs are not going to clear out their CRLs earlier than the expiration date of the certs, and (see below) we aren't proposing to force them to keep them in longer.

• 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. There are some user agents (e.g. phones) which can't yet cope with 2048 bit certificates. The grandfathering compromise introduced in draft 15 was considered to be unfair, as it privileged CAs who already had such roots. There was some back-and-forth on this; eventually, given that NIST says that 1024 bit roots are OK until 2010, I agreed that the language could be reverted to the original wording in draft 11. It may be that we want to revisit this at a later date, but my view is that it should not hold up the establishment of v1 of the Guidelines.

• 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. We would need to look at whether such domains will ever exist in practice, given that I believe that IE implements a no-script-mixing policy for IDN.

• 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. We had quite a bit of discussion on this; there were some creative ideas, which I will report separately.

• 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. I didn't bring it up because I didn't have any course of action to recommend.

• 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. They are also going to look at separating the audit criteria out to enable non-Webtrust auditors to audit against them.

Dan Veditz Comments

Dan had some additional comments, some of which I think may have got overlooked in the collation.

• 5(d)(1) specifies "MUST have a verifiable physical existence", but that's only for businesses that don't meet the requirements in 5(b). It looks like most incorporated entities would fall under 5(b) and get to skip that check. And since you can pretty much incorporate a mail drop (see various investigative journalistic reports about untraceable Caribbean tax shelter funds, etc) this looks like a big dodge so the CA's can say "physical verification is in there" without actually having to do it in practice. I call foul if that's the case.

Lack of physical existence check fixed in draft 15.

• 6(a)(1) what if the "full legal organization name" alone exceeds 64 bytes? Truncate? Abbreviate?

There was quite a bit of discussion of this at the meeting. See the new language in draft 17. We do allow abbreviations in common use in the Jurisdiction of Incorporation.

• There is no 14(b)(2)? Maybe (3) is the missing (2) because that section refers to "subsecton (3) below" which is really 14(b)(4).

There is when you view the document in Word; this is an OpenOffice.org bug.

• So the "face-to-face" validation of Principal Individuals in 14(b)(4) is through Notaries, who have never ever been known to be bribed or bamboozled in any country anywhere.

They are, at least, legally responsible for their assertions. However, I didn't bring up this point because no alternative was suggested.

• Given 5(b)(1) does not mention a physical existence check, does 16(a) apply only to 5(d) organizations or does it imply the location will be verified for all organizations?

Lack of physical existence check fixed in draft 15.

• 14(b)(4)(c) -- how in the world do you "independently verify" that a Notary "did perform the Services"? The bit about checking that the Notary is legally qualified in the jurisdiction is good though.

You call the Notary, using a number obtained in a method other than asking the Applicant, and confirm that they did, in fact, notarise the documents.

• In 16(a)(2)(A) what does "listed at the same address" mean? If you can find the Applicant in the phone book or some such you can apply 16(a)(2)(A)(1) and not have to do a physical visit? Or as long as the address matches what's on their tax form the CA may "rely" on the applicant saying "oh yeah, that's where we do work"? I can easily imagine an internet business run from a virtual location using an accountant's or lawyer's address for their taxes (listed by a "Qualified Governmental Tax Information Source") and then using the same for the cert. But I guess if it's that well structured we're at least talking about organized crime and they would never stoop to phishing.

It is, at least, unlikely that a lawyer or accountant whose office was registered for tax purposes would conspire as part of a phishing scheme. What this clause means is that you have to confirm that the address the applicant submitted is, in fact, the address given for that business in at least one independent information source.

• 16(a)(2)(A)(2) sounds reasonable (should any Applicants actually fall under that section). But what qualifies as a "reliable individual or firm" that actually does the verification?

Whatever the CA can convince their auditors of :-).