[cabf_validation] [EXTERNAL]Re: Making progress on disclosures of data sources

[Kirk Hall]

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.

Here were Doug’s questions, which are very reasonable given the work required for all in your proposal: [1] “I understand what you are asking for, but the question is why is this needed?”  [2] “I’m not necessarily against the ballot because it will level the playing field and we’ll all need to use “good” sources, but is that a known issue that is impacting the security of the ecosystem?”

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.

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).  Please do *not* respond with a list of general complaints about CAs and whether they can be trusted, are lazy, have made mistakes in other areas, this has been discussed before, etc.  Your views on these topics are well known and do not need to be repeated here - it’s irrelevant to the question, and would be a waste of everyone’s time.

All we want to know is – do you have any actual examples of errors made by CAs in government registry validations for EV certificates that would justify your proposal?  If yes, please disclose your examples relating to government registry look-ups for EV validation with specificity; if not, please say so.

Here are the EVGL requirements:


EVGL Sec. 11.2.2. Acceptable Method of Verification
(1) Private Organization Subjects: Unless verified under subsection (6), all items listed in Section 11.2.1(1) MUST be verified directly with, or obtained directly from, the Incorporating or Registration Agency in the Applicant's Jurisdiction of Incorporation or Registration. Such verification MAY be through use of a Qualified Government Information Source operated by, or on behalf of, the Incorporating or Registration Agency, or by direct contact with the Incorporating or Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Incorporating or Registration Agency, or from a Qualified Independent Information Source.

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Wednesday, April 22, 2020 2:11 PM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CA/Browser Forum Validation SC List <validation at cabforum.org>
Subject: [EXTERNAL]Re: [cabf_validation] Making progress on disclosures of data sources

On Wed, Apr 22, 2020 at 4:44 PM Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>> wrote:
I understand what you are asking for, but the question is why is this needed?

Considering that this has been the single greatest failure of CAs in the past year, I'm honestly shocked and disappointed that it's not immediately and readily obvious. GlobalSign itself has had significant quality control failures that have lead to revocations, due to its failure to abide by the Baseline Requirements. I'm sure you're familiar with these, as you've been personally responsible for responding to the incidents about how GlobalSign is working to restore trust to the community and address these issues.

When this approach was posed on our previous validation calls, which you were present on, this was discussed, and the ballot being proposed here was seen as a viable way forward to balance CAs concerns. I realize there's a lot going on, but that was only two months ago, and you were personally a participant in that discussion - https://cabforum.org/pipermail/validation/2020-March/001417.html

I would say that, if CAs want to have any public trust that they're still capable of issuing and validating identity information, they should recognize this as the greatest existential threat to their relevance and legitimacy. This was a systemic issue that affected large and small CAs alike, and revealed remarkable negligence in validation practices, such as invalid states and provinces within a given country.

If you'd like, I'm happy to post the issues that members in this Forum have had over the past year, and why systemically this was the approach we proposed. The alternatives we considered would be to explicitly prohibit identity from certificates, and to ensure that such display is not possible so as not to mislead users, but that's a much bigger change, so we wanted to try to find a way to work together and find a constructive path to address this systemic issue.

I’m not necessarily against the ballot because it will level the playing field and we’ll all need to use “good” sources, but is that a known issue that is impacting the security of the ecosystem?

I had hoped that every representative in the CA/Browser Forum, especially in this group, actively followed industry trends and carefully reviewed every CA incident. I realize that's perhaps an unfair assumption on my part, so if it's useful, I'm happy to compile the list - of GlobalSign issues or of the broader industry. The entire point of these incident disclosures is to make sure we're looking at trends and patterns and coming up with systemic fixes. If you have alternative proposals for the systemic set of issues, that'd be great, but it sounds like you're either unfamiliar with or don't believe that it's been an issue?

This is perhaps the lowest friction change possible, and thus should be trivial towards improving the industry.

Given Google is against identity in TLS certificates and has removed all EV chrome treatment, it seems like an odd item for Google to be advocating.

Luckily, it sounds like you're also confused here as well, which is unfortunate, given the amount of discussion that's been had in the CA/B Forum. Such a statement is a fairly significant misrepresentation of what Chrome has done, as has been communicated to GlobalSign in the past CA/Browser Forum Face to Faces, so I'm hopeful that we can correct this once and for all. You can read more details about Chrome's EV treatment at https://chromium.googlesource.com/chromium/src/+/refs/heads/master/docs/security/ev-to-page-info.md , which still exists.

Of course, given the seeming lack of familiarity with the industry incidents and trends, I can understand why it might seem like an odd item. However, to the extent this information still impacts TLS, and is still present in TLS, it's vitally essential to ensure that users can rely on it and CAs do not misrepresent, mislead, or outright abdicate the trust afforded to them. Further, if there's ever to be future collaborative efforts on non-TLS presentations of identity, we have to have some reasonable starting point. You might recall we've discussed this in the Forum in the past - https://cabforum.org/pipermail/servercert-wg/2020-January/001555.html - and as recently discussed at our Bratislava F2F by Mike Reilly of Microsoft.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200422/675aec7d/attachment-0001.html>