[cabf_validation] Including LEIs as extensions in EV certificates

Sun Sep 22 05:32:54 MST 2019

- Assuming this to be the right CA/B Forum email list for discussing the LEI in certs

Dear all,

Please allow me to summarize GLEIF’s position on including LEIs as extensions in EV certificates – GLIEF is in strong support – based on Google’s comments during the Validation Subcommittee teleconference on Sept. 12.

Google indicated it might prohibit LEIs as extensions in EV certificates even if authorized by a Forum ballot, and might distrust the EV certificates in Chrome or even distrust the issuing CAs roots in Chrome.

To my knowledge no browser vendor has ever rejected a standard or process that was adopted and approved by the CA/Browser Forum (by a ballot and approval of 2/3 of CAs and a majority of browsers). I am used to work with other standard setting bodies and always appreciated the clear rules given to the members. I also understand that this is relevant for the audit program, as it was rightfully pointed out.

My understanding of the formation of the Forum was always about adopting “best practices” by strong consensus of the CA and browser community, acting cooperatively and by consensus. When I read the CA/B Forum website, it always appeared to me as implementation of good governance. Of course, Google like any other market participant is free in making its own choices. However, striving for consensus has a huge value for the entire Internet community. I would not understand why putting the LEI in a cert should divide this important forum. 

Google has said it thinks EV certificates that including LEIs as extensions in certificates would be actively harmful to the ecosystem, and to the security of Chrome’s users.  But there is more at stake than just Chrome users – in fact there is a vast stakeholder group with an interest in having LEIs in EV certificates. Merely everybody participating in any form of e-commerce (and many other use cases) must have a vital interest in understanding whom they are doing business with.

There was also reference to the difficulties when transitioning from SHA-1 to SHA-2, especially relating to remote payment terminals, etc. where certificate replacement was difficult, or difficulties that can arise when publicly trusted certificates are used in software outside of browsers.  I believe this example does not work here. The SHA-1 example was a major transition program, taking quite some time. It was also a transition of a core algorithm (https://www.sslauthority.com/the-difference-between-sha-1-sha-2-and-sha-256-hash-algorithms-2/), requiring changes to server configurations. 

That is something completely different than adding an extension with an alphanumeric value. X.509 explicitly supports these extensions. Any user – including the Chrome browser – could simply ignore the information. On the other hand, if Google would say that Chrome cannot easily handle extensions, I would consider this a major design flaw within Chrome.

However, I strongly believe that this is not the case and that Chrome will have no issues. Ditto for the name clash argument that was put forward. I can understand why this past case caused issues, but this is again irrelevant for adding an extension. Nobody is asking for a change of behavior or existing fields defined by the CA/B Forum.  In Google wants to insist on that argument, I kindly ask Google to provide evidence of past incidents caused by simple extensions.

If Google decides to prohibit LEIs as extensions in EV certificates, it would effectively be blocking LEIs in EV certificates from other browsers and applications as well who want to use LEIs to link to other data on a fast, machine-readable basis. I could imagine this a major anti-trust case if one browser vendor blocks the others. Again, this is all related to the fact that we are talking about a simple extension. So, Google needs to explain the risk and overall stability issues it sees from extensions in EV certificates – unless I understand that, I really can’t provide any meaningful response to Google’s concerns.

The question was raised, if GLEIF itself should issue LEI certificates from non-trusted roots as an alternative to including LEIs as extension in EV certificates?  In a word, no.  GLEIF is an organization managing a network of LEI issuing partners. Several LEI issuers – so-called Local Operating Units (LOU) - are already certified CAs. Since GLEIF itself is not issuing LEIs, the idea of GLEIF issuing special non-trusted LEI certificates does not make sense. Our role is to be the guardian and gatekeeper of the rules and policies defined for the global LEI system. We derive this authority by mandate of the G20. The Financial Stability Board (FSB) is our founding member. Our statutes clearly state what our role and duties are. Becoming a commercial entity is not possible(https://www.gleif.org/en/about/governance/statutes).

In addition, the LEI nor GLEIF are not supposed to create a new trust hierarchy sitting next to all others. We don’t see the sense of that. On the contrary, the LEI should be embedded in other eco systems for the greater good. I would like to state that LEI adds another layer of trust to EV certificates. We spoke about changes in the underlying reference data, e.g. in cases of mergers and acquisitions or bankruptcies. The LEI’s regular update program in conjunction with the possibility for public challenges provides a higher level of trust. In fact, this could help with revocation and the duration of validity. Given Google’s concerns about trust and evaluation, Google should actually be at the forefront of this LEI extension/EV certificate project. The LEI has a lot of value for the Google user base among more.

GLEIF is backed by policy and law. It represents a mechanism mandated by over 150 laws and designed to lower system risk, and it’s hard to see how including LEIs as extensions in EV certificates is posing a trust risk to Google users. Is that the message I should give to the global oversight community including e.g. the FED, Us Treasury, FDIC, CFTC, SEC, and the European commission?

Google also suggested on the Validation Subcommittee call that browsers and applications that want to know the LEI of an EV website can simply gather the corporate registry data from the EV certificate and then do its own lookup of the corresponding LEI in GLEIF’s open access data base.  But that makes no sense.  The whole point of including an LEI in an EV certificate is efficiency so organizations have a uniform, globally recognized and standards based unique 20 digit identifier that is machine readable, will never be reused,  and can be used to access other data using the same number.  There is no benefit requiring applications to add a step: (1) first read EV data, and then (2) use that data to do an LEI look-up every time you want to find an organizations LEI. Basically, each interested party would have to implement a mapping algorithm. This is highly redundant, costly and never completely without errors. The CAs represent the perfect place for providing this mapping within a cert. Besides, I never asked the CA/B Forum for any rule validation change or using any of the GLEIF provided code lists. I could image that this could add additional comfort for CA´s but that is at their discretion.

I would also like to highlight what we spoke about in Thessaloniki. Based on the terrific work of the CA/B Forum in conjunction with WebTrust audits, GLEIF could accept CAs as LEI issuers themselves. Again, this is at the discretion of each firm, but it happens already. 

Other than that, I would suggest not talking about “use cases” for LEIs in EV certificates – some have already been outlined during our Validation Subcommittee call, and there could be many more – so the case has been made already. 

On the call, Google raised security and trust concerns that I do not understand. At this point and to allow moving forward with your ballot, Google needs to describe in detail the problem, why the LEI could pose a risk to Google users and the EV ecosystem. As long as I don’t understand what this is really about, I cannot provide an answer beyond my remarks above.

In summary, I hope that Google will finalize its assessment with a clear statement for including the LEI in TLS using the Forum’s email list for its response, if any. I am looking forward to seeing a successful ballot soon.

Best regards,

Stephan

Stephan Wolf 

CEO 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Global Legal Entity Identifier Foundation (GLEIF)

Mobile: +49 151 52753557

Web: www.gleif.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190922/23eacaf7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1891 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190922/23eacaf7/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1926 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190922/23eacaf7/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 6006 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190922/23eacaf7/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5112 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190922/23eacaf7/attachment-0001.p7s>