User:Johnath/EVDraft13ReviewComments

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

Change Requests - Technical

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

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

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

• There are many typos and formatting errors (some perhaps caused by compatibility issues with OpenOffice, but not all). I assume someone from the CAB forum will work through those.

Change Requests - Procedural/Other

• The section called "Government Entity" is "to be completed". That's an important section to be either completed, or formally deferred until another release of the doc.

Requests for Clarification/Elaboration

• I don’t see logotype mentioned in sections D/F. Does that mean it's not included, 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?

• 37(a)(2): Does that mean Mozilla has to have formal written contracts with all EV vendors?

• What is the policy on EV certificates in the enterprise? Are applications allowed/prohibited from offering UI or a CCK to allow enterprises to create EV intranet certificates? That's probably outside the scope of this EV document.

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