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

• 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 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 analog..." This way the user agent knows CRLs are coming, even if they will realistically take longer than 3 seconds to arrive.

• 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

• 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 has been compromised;"

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.

• 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 make sure this doesn't preclude/prevent class action lawsuits.

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?

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