[cabf_validation] Making progress on disclosures of data sources

[Kirk Hall]

OK, you have answered our question – you don’t have any concrete examples you can provide of actual cases where a CA used an “improper” government registry data source to validate the corporate registry number and existence of the Subject in an EV certificate.  You can’t succinctly answer the question is why your proposal is needed.  And you can’t present any evidence that the use of government registry data sources is a known issue that is impacting the security of the ecosystem.  That’s what I thought.  That raises questions about the merits of your proposal.

I’m sure you will now post a lengthy and negative response covering many unrelated issues, and also insulting me and my company.  Do that if you find it entertaining, but please understand – no one reads those tweets.

From: Ryan Sleevi <sleevi at google.com>
Sent: Wednesday, April 22, 2020 3:08 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: CA/Browser Forum Validation SC List <validation at cabforum.org>; Doug Beattie <doug.beattie at globalsign.com>
Subject: Re: [EXTERNAL]Re: [cabf_validation] Making progress on disclosures of data sources



On Wed, Apr 22, 2020 at 5:38 PM Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>> wrote:
Ryan, Doug asked you two fairly simple questions in response to your proposal on “disclosures of data sources”.  Your proposal requires disclosure of all the government registry data sources used by a CA during EV validation.

This is not true. This has been repeatedly addressed on the call, in the minutes, and in the proposed text itself. I encourage you to read it, and highlight if there's confusion, but I think an absolute statement like this is really harmful to productive collaboration.

It only requires the disclosure of certain Agency of Registration or Agency of Incorporation information.

Your lengthy response was not really responsive at all, but instead brought up a list of unrelated complaints about CAs that we have heard before.

An absolute statement like "unrelated complaints" is easily demonstrated as false. If you'd like to express why you're having trouble seeing how they're related, I'm happy to enlighten you, because it sounds like you've not been following the work of your colleagues in this space, who have been filing and responding to incidents on behalf of Entrust, as well as participating in the broader industry-level conversations.

But let's be clear here: This is a small change. It'd be great to accomplish this in the Forum, because this is about transparency. If transparency is difficult, especially for something so trivial, then we've got a much bigger problem.

Do you actually have ANY concrete examples you can provide of ACTUAL cases where a CA used an “improper” government registry data source to validate the corporate registry number and existence of the Subject in an EV certificate (see EVGL Sec. 11.2.2 requirements below).

I like how you've reframed this from an area that saw significant productive agreement, in our recent Face to Face in Bratislava, as somehow being a controversial or unsupported assertion. Perhaps it's worth reviewing some of our minutes https://cabforum.org/2020/03/20/minutes-for-ca-browser-forum-f2f-meeting-49-bratislava-19-20-february-2020/#Defining-the-source-for-state-and-province-standard-name-formats , about the systemic data quality issues undermining faith.

We've seen revocations from the following CAs where the CA improperly used or encoded the Agency of Incorporation or Agency of Registration, the Serial Number, or the Jurisdiction fields associated with those CAs, or misrepresented the businessCategory. All of these fields are directly, and unquestionably, related to the problem set here. And this is just a smaller set of the broader set of quality control issues.

I've had discussions and debates with specific CAs over their selection of Agency of Incorporation / Agency of Registration. A prime example here is whether, within Sweden, Finansinspektionen meets the criteria set forth or whether the Bolagsverket suffices. But that's not what this is. This is about simple transparency and consistency. If CAs are *opposed* to that, or don't see the clear and obvious merits, then there's really a systemic issue at play here that's unlikely to find any productive collaborations going forward. Transparency is table stakes.

Asseco DS / CERTUM

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1600301
Camerfirma

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1600114
DigiCert

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1413761
  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1576013
D-TRUST

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1599561
Entrust Datacard

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1599484
GlobalSign

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1575880
QuoVadis

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1589047
  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1581234
  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1576283
  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1593357
SECOM

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1576133
Sectigo

  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1590810
  *   https://bugzilla.mozilla.org/show_bug.cgi?id=1575022
And this is just a subset of the issues related to the broader set of concerns. Seeing certificates issued to "Some-State" and "Some-City" was a clear wakeup call to the systemic failure going on, and arguments to the contrary are unfortunately simply not acceptable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200422/dd70c197/attachment-0001.html>