[cabf_validation] [EXTERNAL]Re: Including LEIs as extensions in EV certificates

[Kirk Hall]

We have already covered the purposes for including LEIs as extensions in EV certificates on our Sept. 12 Validation Subcommittee call, and other places – see excerpts from below.

Wayne recapped the status of the prior call. On the prior call, there was discussion around the purpose of putting a LEI in certificates. Wayne asked Stephan to share about the reasoning of wanting to put LEI numbers into EV certificates.

Ryan attempted to clarify this question from the previous call, but Kirk stated it wasn’t Stephan’s idea, but the idea of a number of CAs. Kirk shared that, as former CA/B Forum Chair, he was invited to attend a LEI event to learn more about LEI. He initially had concerns about their validation process, as well as business concerns about whether it was possible to match LEI data with EV data with no errors, and that he’s now satisfied it’s something that can be done.

Kirk shared that Entrust Datacard is interested in issuing these certificates, and that he believes several other CAs are as well, and believes users are interested in such certificates. He stated LEIs can be used to get corporate news from sources like Reuters and Bloomberg, so that could be one use. One complaint Entrust Datacard has heard is that current EV certificates, which include information like the state of incorporation and the registration number, creates a unique identifier but is awkward, because applications have to parse all of that, and compare it to different certificates that might be from Germany or the UK and at the national level. The benefit of LEI is that it’s a unique 20 digit alphanumeric code that is pretty much a perfect identifier around the world. Kirk did not believe Stephan should be asked about why LEIs should be in certificates, although he may have an opinion, but this is something CAs want and would like to proceed with. ***

Kirk mentioned he had seen the LEI used in other places beyond banking, such as Bloomberg and Reuters. When you look up a company profile, it has a LEI. It’s a very useful way for disambiguating companies, which Kirk felt applications and websites could do. Kirk then read the speaker list for an upcoming GLEIF event as examples of other companies interested in LEIs, and mentioned other organizations, like custom bureaus, and asked Stephan to talk a bit about who these speakers are and the use cases of LEIs today.

Stephan described a previous meeting GLEIF held in San Francisco, where the objective was to better understand the digital world and how the LEI could help. Stephan mentioned that he shared a vision then of signing documents and other cases, which Kirk would know because Kirk was there. However, GLEIF hasn’t stopped there, and is looking to address the use cases of other industries. There are a number of trading networks using blockchain and hyperledgers, where people build distributed supply chains for virtual information, and that some blockchains use certificates for server to server communication in their architecture. It makes perfect sense to integrate the LEI there as well. Wherever GLEIF has gone, people have said this is a no-brainer and that this is a good idea. This also allows for unique possibilities to test ideas with national regulators.

Kirk wanted to ask his final question, which is whether there was any advantage to using a LEI to uniquely identify a corporation, rather than their place of registration and corporate serial number?

Stephan explained that the Chinese customs agency had mandated the LEI as an essential field for 29 nations. If you want to deal with China and are in one of these 29 countries, you need to include a LEI. In the US, US Customs and Border Protection want to combine the LEI along with the geocode and a bar code, and GLEIF is working with them to try and establish a system to better understand the import/export declarations.

Kirk felt that clearly shows the value of a LEI and why it should be in a certificate.

https://cabforum.org/pipermail/validation/2019-September/001317.html

In addition, ETSI would like to include LEIs as optional extensions in QWAC and PSD2 certificates.  See ETSI TS 119 495 at Sec. C.6:


“In case there is no PSD2 Authorization Number, other forms of registration recognized by the NCA can be used in place of a PSD2 Authorization Number. If necessary to ensure uniqueness the authorization number can contain a prefix including the type of institution, as listed in PSD2 [i.2] article 1.1: Credit institution - CI, Payment institution - PI, Electronic money institution (or e-money institution) - EMI, Account information service provider exempted under Article 33 of PSD2 (they have only the AIS role) - RAISP.

“In other cases the unique identification number presented in the certificate is e.g. Legal Entity Identifier [LEI], VAT number or National Trade Register number. The identification number is required to be one recognized under ETSI EN 319 412-1 [1] / ETSI TS 119 412-1 [2].”

So the reasons for including LEIs in EV certificates are adequately specified by the CAs who are proposing this ballot.  This is not something that GLEIF needs to prove to anyone.

The Server Certificate Working Group certainly didn’t require more when we allowed PSD, VAT, and NTR identifiers to be added to EV certificatesas extensions in Ballot SC17 last May, and at that time when Google objected to including any of those additional identifier numbers in the Subject DN, you said “but you can include any extra data you want in a certificate as an extension”.  Remember that statement?

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Monday, September 23, 2019 3:41 PM
To: Stephan Wolf via Validation <validation at cabforum.org>
Subject: [EXTERNAL]Re: [cabf_validation] Including LEIs as extensions in EV certificates


On Sun, Sep 22, 2019 at 7:10 PM Stephan Wolf via Validation <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:
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.

Unfortunately, the most important part, for which our hour on the call failed to identify, is that you do not identify for what purpose.

This is essential to making any forward progress, and until GLEIF is able to provide a clear statement of purpose and use case, for browsers, in the use of TLS, which has a host of nuances and complexities in browsers.

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.

I'm afraid this still is greatly confusing the purpose of the Forum. You can read more within our Bylaws at https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v2.2.pdf , which GLEIF just agreed to when joining the Forum.

I've highlighted some choice points:

The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering
The Forum has no corporate or association status, but is simply a group of Certificate Issuers and Certificate Consumers that communicates or meets from time to time to discuss matters of common interest relevant to the Forum’s purpose. The Forum has no regulatory or industry powers over its members or others.

The Forum has never, in its history, defined the rules for CAs or for browsers. These have always been matters of private contract between Root Programs (typically, browsers), and the CAs for which they delegate the issuance of certificates to. For many PKIs, delegation to third-parties is not practiced at all; for example, the code-signing platforms of Apple and Google do not employ the use of third-party CAs, nor do the hardware certification programs of any of the vendors within the Forum, even though both also use certificates in PKI.

The Baseline Requirements, while developed by the Forum, were standards that no CA followed until required so by Root Programs. Root Programs regularly apply unilateral restrictions within their Root Programs, as they compete on areas like security and respond to changes in the security risks to the browsers users. The Forum exists to promote discussion, but the relationship between browsers and CAs, as it does in quite literally every public and private sector PKI, remains a matter of private agreement or certification between the participants.

The choice of what certificates a browser recognizes are, like any other voluntary standard, just that, reflecting the needs of that particular software product, its users, and its risks. There is no concept of "The PKI" - Public Key Infrastructure was designed to be many entirely separate PKIs. Your standard IPhone or Android device will, in the process of booting, no doubt leverage dozens to hundreds of entirely disparate PKIs, ranging from the PKI of the firmware used to securely boot the device to the authentication of the device's peripherals. PKIs are disparate based on purpose and community.

No two browsers in the Forum have an exactly identical set. This reflects the needs that they have different security requirements and goals, and thus operate their Root Programs separately. This is a feature, not a bug, reflecting the differences in markets these browsers compete in, the different use cases their products support, and the different needs of their different use communities.

It's important to understand that there is no technical reason for browsers to use CAs or certificates at all. Alternative technologies exist, such as DANE, which allow the binding a domain name and a public key without needing to involve a CA at all. Similarly, as demonstrated by the above scenarios regarding code signing, browsers could also operate the CAs their users use themselves. This is not a threat, it is a reiteration of how PKI was designed and intended to be used for. There is no existential mandate to make use of third-party CAs, but when they are used, it's through voluntary choice by the CA to ensure their products interoperate with the browser.

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.

Your understanding is incorrect.

The Forum provides a venue to ensure Browsers do not place conflicting requirements on CAs that voluntarily participate within the browsers root programs, by facilitating discussion and feedback. This allows interoperability among the Web PKI space, which refers to the set of CAs within browsers, and thus allows easier interoperability within browsers. Prior to the Forum, it was much easier to see this reflected in the private arrangements between CAs and browsers. If different browsers had different requirements, CAs would have to act as the intermediary to identify and communicate those conflicts. Similarly, browsers had to spend significant effort working to communicate with all of the CAs in their programs, often repeatedly answering similar questions. By arranging a common mailing list, and periodic meetings, those barriers to communication can be reduced.

That is the sole and only purpose of the Forum. Any other suggestion is ahistorical and not reflected in the past or present activities.

Within the Forum membership, there are a number of CA members which have had their certificates rejected for trust or been actively distrusted. It does not seem it would be aligned with "best practice" to suggest those for which a browser vendor does not trust should be the ones deciding what browser vendors should trust, does it? T

Policies are set, first and foremost, through browser Root Programs. The purpose of the Baseline Requirements is to enshrine methods of meeting those various Root Program requirements, and, more practically, to serve as a template for the development of audit criteria that may be used by individual Root Programs to assess compliance.

This again is fundamental to PKI since its introduction. In a historic view of PKI, the one imagined by the ABA and reflected in the contemporary reports produced in the late '90s and early '00s, each Root Program would operate their own audit programs, with their own audit criteria, and typically directly perform the audits themselves. Such a matter is expensive, and so it's only natural that the cost of such a program would and should be passed on to any CAs wanting to be certified. This practice was readily adopted by a number of governments, who adopted their own government-specific PKIs back then. However, this represents an exponentially more expensive proposition for CAs, and thus CAs have self-organized for the development of the Baseline Requirements, just as governments look to develop interoperable criteria and schemes. CAs that demonstrate compliance can reduce their costs substantially.

None of this is fundamentally required by a Root Program. Originally, audits were only a minor part of a Root Program compliance, with much more being placed on contractual due-diligence and business relationships. In time, audits grew to be more prominent, as Root Programs looked to reduce their operational costs, which were being passed on to CAs. However, as ETSI and WebTrust can attest, Browsers have raised a number of concerns about the quality and assurance of the audits performed by their members, and have suggested that we may be better returning to a Browser-overseen audit scheme. Certainly, there are ways to do so affordably, but with greater assurance of compliance.

However, audits alone have never been sufficient for trust, nor have the Baseline Requirements, for which the audits are based upon. Root Programs make a determination, both based on the Root Program requirements they have set forth, as well as their own individual policies about what sort of organizations they enter into a contract or agreement with. The relationship between a browser, the certificates it accepts, and the CAs it recognizes, is inherently a private affair, much as it is any other vendor relationship that software suppliers deal with: contractors, outsourcers, physical security vendors, etc.

Perhaps a better comparison, to help drill this point down, is that browsers are voluntarily and intentionally removing support for TLS 1.1 and TLS 1.0. The IETF has not moved these documents to Historic. There are many communities that still accept these protocols. There are many devices that /only/ support these protocols, and thus will be left inaccessible as browsers do this. And browsers are still doing it, because it's in the interest of the security of their users, and such interoperability is actively harmful to their users. Certificates are the same, whether we're talking lifetimes or LEIs.

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.

GLEIF has made this position known, but provided scant technical detail. Google has attempted repeatedly to help GLEIF understand, and it's interesting to see this posted without any acknowledgement of those efforts, nor any progress towards achieving that understanding.

The Baseline Requirements are not intended nor primarily developed for the use of server-to-server TLS certificates, for example. The requirements of payment terminals and TLS, for example, are handled by PCI. The requirements of wireless authentication servers are handled by the Wi-Fi Alliance. Both systems are voluntary. Similarly, there is no requirement that binding information to a domain be accomplished through TLS certificates; in many ways, this actively harms the agility of the TLS ecosystem.

If GLEIF were to demonstrate how it such information will be used, and not merely that it will potentially be used, we remain committed to helping GLEIF finding a technical solution that is in line with modern security practices, and not based on an antiquated view of technology that originated within the ITU-T in the 1980s and never materialized (the X.500 DIT).

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.

This fundamentally misunderstands the role of certificates.

Adding information that is not used by browsers is actively harmful to browsers and the agility of the ecosystem.

This is because non-browser consumers come to rely on this information. When it comes time to make changes, in order to enhance the security of users when they browse the web, site operators and CAs complain that changes would break such non-browser use cases. However, it is wholly inappropriate to cater to these non-browser use cases for precisely that reason. PKIs were designed to be robust, and if the use case is, for example, server to server communication, it can and use a separate PKI, rooted in separate trust anchors, to express this difference of information.

This is quite literally why the concept of PKI audits was introduced: to accommodate there being different trust anchors, used for different purposes and different communities, and to allow the careful choice of interoperability.

The inclusion of this added information, if not directly used by browsers, is thus actively harmful to the agility of the ecosystem. The solution is to ensure that such PKIs do not overlap, by either ensuring that such certificates are not TLS certificates, much as browsers, in contravention/extension of the Baseline Requirements, already require for e-mail or code signing certificates through the use of Extended Key Usages.

The issues that GLEIF rejected unfortunately reflect that misunderstanding, about the harm of having a single Unified PKI as opposed to how PKI was designed and is operated: as a network of separate PKIs. SHA-1 deprecation was not a matter of replacing the server certificates: the issues mentioned first and foremost were due to the fact that, despite browsers having supported SHA-256 for some time, legacy (unsupported) software and non-browser use cases (like payment terminals) did not. Similarly, the discussion of underscores or internal server names was because the systems using these certificates needed to interoperate with other, non-browser cases. The challenges in distrusting Symantec certificates were, similarly, largely not due to browser compatibility (of which many comparable CAs existed), but because a number of Symantec customers had coded non-browser using applications to only expect Symantec certificates. In all of these cases, the choice was clear: interoperate with browsers, or interoperate with legacy systems, but you cannot do both simultaneously.

In order to prevent customers from needing to making such choices, which only come up when things have truly gone wrong, it's best to prevent such accidental interoperability as early on as possible. Unless and until there can be a clear demonstration about the specific use cases intended for browsers, and technical alternatives explored, there's no value in discussing or proposing further changes.

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).

GLEIF functionally is a trust hierarchy, using powers derived from the LEI ROC to oversee the GLEIF Index and the LOUs. This is exactly what PKI is meant to technically express. GLEIF removes information when it's challenged - this is conceptually the same as revocation. GLEIF recognizes LOUs on the basis of criteria for the issuance of LEIs - this is conceptually the same as certification. LOUs issue LEIs - this is conceptually the same as issuance.

In classic PKI terms, the LEI ROC acts as a "Policy Management Authority", overseeing GLEIF, which is functionally the CA.

The benefit for such an approach, which is exactly what PKI was intended to facilitate, was that it avoids entirely the necessity of relying on browsers to try and oversee the correct association of LEIs, domain names, and keys, which is essential for there to be any value in expressing LEIs in certificates.

This is not sophistry: Within the IETF, multiple working groups, including the TLS and JOSE working groups, are moving to other PKIs other than those used by CAs, in order to support new and interesting use cases. The use of TLS Delegated Credentials, for example, wholly avoids the X.509 certificate syntax, even though it is used to bind public keys to connections. There is no technical reason to use an X.509 approach for these cases, and it's both more secure and more flexible to avoid doing so.

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.

Without the demonstration of how it will be used, it can be shown, based on the proposal, that LEIs reduce the trust in certificates, by highlighting conflicts between the information encountered in the certificate, as well as creating more opportunities for validation failures.

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.

As noted above, the core reason is to ensure that non-browser dependencies are reduced.

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.

Unless and until GLEIF does so, there can be no productive conversation, because GLEIF is unwilling to engage in meaningful dialog.

We remain committed to helping GLEIF finding solutions, but that requires some degree of good-faith engagement by GLEIF, which messages like this unfortunately harm that perception. On the call, as shown in the minutes, neither GLEIF nor Entrust DataCard, who appears to be a primary supporter of LEIs, could demonstrate the use case.

I think this is essential. You're asking browsers to interoperate with LEIs, which comes with significant risk of harm by being used by non-browser applications. Unless you can ensure that such information will not be used outside of browsers, it remains actively harmful to the security of browsers. If the primary purpose is to use it outside of browsers, such as for code signing, then this is the wrong working group: this working group explicitly does not discuss code signing, by charter.

There's no reason to expect browsers to modify their Root Programs to permit such certificates, nor is it reasonable to suggest browsers should interoperate with PKIs that do issue such certificates, as a consequence, when such information only carries with it risk.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190924/e2f3aab5/attachment-0001.html>