[Servercert-wg] [EXTERNAL]Re: Clarification about EVG 9.2.4

[Kirk Hall]

You always do the same thing: you suggest that someone who disagrees with you hasn’t read your messages, and then you criticize them on some unrelated point.  Do you really think this advances your case or your credibility?

I did read your postings on the subject “Clarification about EVG 9.2.4”, but I did not find them persuasive, or even very relevant.  For further details, see this link.

https://cabforum.org/pipermail/servercert-wg/2019-December/001524.html

From: Ryan Sleevi <sleevi at google.com>
Sent: Wednesday, December 4, 2019 6:38 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [EXTERNAL]Re: [Servercert-wg] Clarification about EVG 9.2.4

On Wed, Dec 4, 2019 at 9:17 PM Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>> wrote:
It would be a massive project for the Forum to catalogue – and maintain through frequent changes including changes of URLs, etc. – 100% of the all world’s national, state, and local registries where a business can be incorporated or licensed.  Who would spend the time on this?

It seems like you may not have read the links? I've seen DigiCert make a great start at this.

And I don't think anyone has ever suggested, besides yourself, that it needs to be a perfect list at first. After all, if we simply started from what CAs use today, such as what Entrust's compliance team uses, I'm sure we'd see it's quickly able to accommodate existing issuance.

And if a registry is not included on the Forum’s approved list – would a CA be prohibited from using that registry to issue an EV certificate to an Applicant even though it is the correct place to obtain the data and even though the registry should be on the list?

Of course. After all, the purpose of requirements - whether the Baseline Requirements or the EV Guidelines - is to ensure that, no matter what CA is involved, we obtain a consistent result.

We obtain that with a list. If an entity is not on the list, it's not issued, until it's clear that it should be. That's no different than our existing process for resolving ambiguities.

Luckily, we know if CAs contributed their existing lists of QGISes, this would easily accommodate existing issuance. So this should be both trivial for CAs to produce, and easily lead to consistent results, right?


The current members of the Forum are probably not even competent to assemble such a complete list as I’m not sure our membership issues in every country of the world.   I recall from a few years ago that in Japan, in some cases a CA must physically visit a local registration office nearest to the corporation to obtain a paper record to confirm a corporation’s existence – there was no national online registry.  So do we have to list all the local office locations?

Luckily, that's not the suggestion, so you're arguing against a strawman :) I'm sure we can discuss these issues as they come up. Does Entrust not issue EV certificates to Japan?


Not sure what problem this proposal is solving.  Seems like it would create its own new problem – an approved list that is incomplete and always needs updating.

Luckily, you just misunderstood the proposal, and that's hopefully easily corrected.

This all started when Dimitris asked about the specific (and potentially confusing) language of our current EVGL rules about how to encode the registry location in an EV cert showing where a Subject was incorporated or licensed.  It seems the only open question is, when the business was incorporated or licensed in a Locality office, should we automatically include the State/Province/Canton location (if any) as well as the Country location.  My opinion is yes, and I can’t see it would do any harm – these are pretty rare cases so probably not worth spending too many cycles on this.  I can’t recall any reported instance where there has been a problem related to encoding the place of incorporation or licensing of an EV cert when the place was a locality.

While I recently learned that Entrust Datacard has not been following compliance bugs, and thus likely unfamiliar with the state of EV in the industry, https://wiki.mozilla.org/CA/Incident_Dashboard shows that, systemically, EV is deeply flawed in practice, particularly around the jurisdiction information. DigiCert has really been leading in the efforts for industry-wide cleanups, especially with their notifications and problem reports to a number of CAs that stemmed from their own challenges, and really harkens back to the days of CAs and browsers working together to strengthen things.

My hope is that Entrust Datacard would be able to apply that same energy and zeal, using its own reviewed sources of QGISes from its years of operational experience, so that we can make sure that we're solving the systemic, industry-wide issues. It's important that we make sure to address problems at their root, systemic causes, and not just paper over them. That's why the incident reporting process is so useful and valuable, and why it's important to make sure that we learn from patterns of issues and seek to meaningfully solve them.

I realize that for a CA only looking at how they do things, this may seem overkill. Of course, browsers and relying parties - those who the certificates are meant to serve and be useful for - care much more about lasting and meaningful changes, that are robust at their core and not variable from CA to CA. After all, isn't the fundamental goal of our work here, whether in TLS, S/MIME, or code-signing, that regardless of the CA that issued it, every certificate should provide exactly the same level of assurance as an equivalent certificate issued by another CA? Whether we view that through the lens of DV, OV, or EV, I'm sure we can agree that consistency between every CA is why we work on standards. The way we get consistency is through clear, understandable, unambiguous rules, that are fair and equitable for all CAs.

We should definitely take inspiration from GLEIF, who recognized the fundamental quality issues if you do anything less than that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191205/6e501fe0/attachment-0001.html>