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

[Kirk Hall]

So… Google eliminated the EV UI in Chrome in September, and you have stated for years that EV identity information is of no value in user security.  So why are you trying to tell CAs what EV corporate registry data sources they should use when issuing EV certificates?  What’s your interest?

When it comes to discussion of corporate registry validation rules for EV certificates, I think CAs are more interested in the views and opinions of browsers who support EV and website identity instead of those who don’t.

From: Ryan Sleevi <sleevi at google.com>
Sent: Thursday, December 5, 2019 7:13 AM
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: Re: [EXTERNAL]Re: [Servercert-wg] Clarification about EVG 9.2.4

Hi Kirk,

As always, I appreciate the point to provide clarification. I think it's a good chance to highlight when you may be confused by something, and seek clarification first, before responding to a strawman. Regrettably, this message shares the same.

You suggest it's unrelated points, however, it seems you may simply not understand. I'm happy to clarify for you to reduce your confusion, since I can understand you may not be familiar with the developments in the industry. My suggestion to read the links was to suggest you read DigiCert's incident report, in depth, as they really showed that even the strawman arguments being made by Entrust Datacard don't hold water or stand up to scrutiny. They've shown not only is it possible for a CA to enumerate the sources their compliance team has identified, but further shown that in doing so, they've been able to detect industry-wide non-conformities. If you'll recall, Entrust Datacard was one of the CAs affected, in part because they'd not been following these discussions and thus not had a chance to examine their own systems.

I can understand you may not find them persuassive, but I do believe you may simply be misunderstanding. As always, I remain available to clarify. Hopefully, the previous message I provided you has shown that what you believe to be the suggestion - some global list created a priori - is simply not what's being discussed. As previously captured, if CAs and their compliance teams, including Entrust Datacard, merely examine their existing issuance and what organizations they've identified as suitable for complying with the EV Guidelines, we can quickly and rapidly make progress on a clear, consistent, and unambiguous list, which resolves a host of systemic, industry-wide issues (including Entrust DataCard's own issues), and lead to more reliable certificates for everyone.

Surely you can find that both relevant and persuasive. I see no reason why we should leave up to each individual CA's discretion on how to arrive at things. This is no different, in spirit or in execution, then the Forum long having since recognized "Any other equivalent method" as being laughably and woefully insecure and inadequate. It's time to move on from those past, failed approaches, and make real progress!

Again, and to avoid confusion:
Does Entrust Datacard maintain a list of QGIS that it has evaluated as complying with the EV Guidelines for purposes of incorporation information? If so, can you please share it?

Of course, it may be the answer is no, and that Entrust Datacard relies on each validation agent to independently evaluate, for each request, the appropriate QGIS. The related incident dashboard shows how woefully inadequate this approach is, so I think we can clearly state that such an approach is laughably insecure in practice, and thus not worth continuing :)

On Thu, Dec 5, 2019 at 12:51 AM Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>> wrote:
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<mailto:sleevi at google.com>>
Sent: Wednesday, December 4, 2019 6:38 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org<mailto: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/f8554c7a/attachment-0001.html>