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

Wed Sep 25 05:54:39 MST 2019

I would like to answer Wayne’s summary and some of Ryan’s topics with this posting.

1. “Why” versus “why not”

We are on the same page. “Why not” is never good guidance except for gamblers or if a friend asks you a favor. GLEIF neither gambles nor are we asking for a favor. The idea of including LEIs in TLS certs - and many other types of certs as well – came from the industry. We are trying to contribute in two ways:

- Participation in this discussion

- Working with standard’s bodies such as ISO and ETSI for developing rule books on how to technically embed LEIs in certs. This is close to a conclusion with ETSIs recommendation and ISO TC68 running a ballot. In the end this would lead to ETSI and/or ISO 17442 compliant certs.

I don’t see GLEIF in the forefront answering the question on use cases. I believe the industry is much better equipped with customer feedback and demand. However, I would like to share with you the following GLEIF use case:

The EI issuers (LOUs) are obliged to upload files containing all LEI and LEI reference data. The LOUs are free to choose either a daily file delivery or multiple deliveries per day. We use TLS certs in two ways. First, we use this for authentication and encryption in the server to server communication (our TLS certificate). Second, we parse the cert information (their TLS certificate) and verify that the entity signing the file is the originator of the data. Please note, LOUs often use multiple domains and/or sub domains for dev, pre-publication test, and production. On top of that, they might use multiple certs (at least in case of expirations). An LEI would make it easier to link all of this information together. String matching of company names can easily lead to errors. Please note that we wish to expand the number of bodies helping with LEI issuance and management tremendously. We are preparing an event in Washington where McKinsey is going to present the results from an investigation on the inclusion of banks in the LEI issuance process. Given the complexity of company names for subsidiaries that vary only a little, an LEI would offer tremendous help in preventing wrong allocations.

So far, this group  has been discussing TLS certs with LEIs only in the context of browser2server communication. Please note, the HTTPS protocol is widely used in server2server communication. As an example, R3 uses TLS certs for securely connecting nodes in the Corda Blockchain application. No user nor a browser is involved. In GLEIF’s opinion, the relevance of TLS certs for the entire Internet even more suggests embedding LEIs in order to help participants in transactions verifying the identity behind the server. Just looking at browser eco systems might not be broad enough.

2. Identity in or out

>From the comments made by Ryan and Wayne, I have come to the believe that a bigger question is in stake. Should identity be included in certs or not? Obviously, only with EV certs this is currently given. This might has not been perfect in all cases, but served the world a great deal. This opens up two scenarios:

A. Taking identity out of certs, e.g. just use DV certs for securing the transmission between servers and browsers.

B. Leave identity in EV certs

In case of A, the Internet would become a much less secure place unless identity is handled somewhere else. I believe we all know of developments like self-sovereign identity ledgers based on Hyperledger Indy, the work on decentralized identifiers, projects using Ethereum or Merkle-trees etc. I am sure that there are many more. GLEIF is taking part globally to support these development and standards. In DC in October, we are going to demonstrate the LEI in the context of verifiable credentials (claims). As I said in my previous mail, the LEI is supposed to support all eco systems. However, there are two constraints – This will take time as EV certs won’t walk away soon, and even if, the connect between the identity and the various implementations requires even more mapping. Yes, any individual provider could solve all of this in one solution, but that would create less competition and more dependencies on vendors. These are almost political questions which is why I am not taking this further here.

In case B, identity remains in certs which basically means the data of the organization is encoded in specific fields. That is not optimal. It is not just hard for the consumer to interpret this information, in case of changes in the real world one would see a discrepancy between the data in certs and in other places. The LEI could help here tremendously. Ryan’s comment that the information is redundant and the LEI could be mapped outside is only valid in cases of perfection. The strings must be identically the same, otherwise it would require manual work. And we all know that public registries can carry errors as well. Last but not least many registries don’t provide open access or have an API, which makes mapping virtually impossible. This weakens the position of EV certs but could easily be addressed by embedding LEIs. To Wayne’s point: This adds security and agility! Let me give you some food for thought. Why not just carrying the LEI and leave the refence data completely out of certs? It can easily be accessed by any service holding a copy of the data. It would reduce manual work, costs, adds transparency and agility and reduces even the payload. CA’s would be perfectly positioned for this.

I would also like to make a personal comment. The concept of identity is an important aspect of eIDAS. While the regulation is technically agnostic, the inclusion of the real identity in any digital ID is a core concept. This creates “my identity” instead of any vendor’s granted / use case related ID. I believe, as long as TLS certs are around, identity should be included for a higher level of trust.

3. Security

I am neither an expert in the implementation of browsers nor servers. However, as I pointed out many times, I cannot imagine a technical risk or lower technical security when embedding LEIs as extension. My point has always been: Can you explain your concerns? Can you give examples of security issues based on simply extension? So far I have not heard anything that would help me to understand the issue. Coming back to Wayne’s top question: “Why” or “why not”. This applies here as well. What is really in stake?

As Ryan noted, I am new to this group and not familiar with all aspects of the Forum’s governance and rules. My answer is supposed to be purely factual. I hope you find this helpful.

Best,

Stephan

Von: Validation <validation-bounces at cabforum.org> im Auftrag von Wayne Thayer via Validation <validation at cabforum.org>

Antworten an: Wayne Thayer <wthayer at mozilla.com>, CA/Browser Forum Validation WG List <validation at cabforum.org>

Datum: Dienstag, 24. September 2019 um 16:38

An: Ryan Sleevi via Validation <validation at cabforum.org>

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

I'd like to emphasize a couple of the points that Ryan has made that reflect the different perspectives on this issue. First off is "why versus why not". Some advocates of placing LEIs in certs are working under the premise that they should be permitted unless someone can prove that they are a threat. Since it's effectively impossible to envision all possible security threats, I support the notion that we should be viewing the addition of any data skeptically, asking why should we include it?

That leads to the second disconnect, about what constitutes a valid purpose for including an LEI. Here we've been presented with notions that CAs and their customers think it would be a good idea. Unfortunately, that's not at all relevant for user agents who want to know how their users will benefit from including this data. Here is where the use cases come into play. So far what I've heard is a single browser use case in which a user opens the certificate viewer and locates the LEI, then uses that to look up the company in question in some other database? Why would anyone ever do that? Can anyone articulate, from the perspective of a typical browser user, the benefit they will be able to gain from having an LEI in an EV cert?

Understanding the value that relying parties will gain is key because that could show there is more value than risk. This leads to the third disconnect, which is the assessment of the risk induced by including LEIs in certificates. The notion that there is no risk is popular, but I believe there are at least two significant risks:

* The risk of further reducing the agility of EV certificates by adding another piece of validated information. If any significant number of EV certificates require revalidation to remediate an incident, we already have a serious problem given the tedious EV validation process. Adding another validated field just makes it worse. Of course, one can currently argue that LEI is an optional field that could be excluded, but...

* The risk of non-browser certificate consumers becoming dependent on EV certificates containing LEIs. We've seen repeated harms when certificates are used in multiple "trust frameworks" - e.g. browsers and payment terminals. Adding LEIs to EV certificates creates a new risk that those certificates will be used in non-browser use cases that require the LEI but that don't share other characteristics with the browser trust frameworks, such as the need for high agility.

Hopefully this helps everyone to understand some of the concerns I have with this proposal.

Also, the subject of this thread, and Kirk's last message state that LEIs would be added as an extension, but Tim's last ballot and my prior understanding of the proposal was that they are to be an option for the Subject:organizationIdentifier. Has that changed?

- Wayne

On Tue, Sep 24, 2019 at 12:30 PM Ryan Sleevi via Validation <mailto:validation at cabforum.org> wrote:

Inline

On Tue, Sep 24, 2019 at 3:17 AM Kirk Hall via Validation <mailto:validation at cabforum.org> wrote:

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.

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

I can understand that the technical discussion may be difficult to follow, but it's important.

None of the quoted discussion (snipped, to ensure the comments aren't missed), nor the overall phone call, discussed LEIs in certificates specifically. It's important to understand that this isn't simply a conversation about LEIs, which are quite useful, but specifically about LEIs in certificates and how they are used.

The closest we got was in a server-to-server authentication scenario, a desire to record the LEI within an authentication database. But that is clearly not a browser use case, and the machine readable aspect of the LEI has no benefit to the use of browser TLS.

Perhaps to ensure a productive discussion, it would be reasonable to ask you not to repeat points which have, so far, been quite off-topic to the question at hand? After all, if the responses had addressed the question, we wouldn't still be having conversation, or it wouldn't be necessary to say the same thing with no new information.

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.

This is not correct. Entrust DataCard has not demonstrated at all the inclusion of LEIs in certificates in their purpose for browser authentication. GLEIF, in advocating for this, needs to demonstrate.

If GLEIF is not advocating this, and it is instead CAs like Entrust DataCard wishing to sell a new product to an unsuspecting market, one which may harm the security and stability of the browser TLS ecosystem, then Entrust DataCard bears the burden of proof to demonstrate the value. Unless and until that can be done, it's very clear and evident that much harm will be done.

1) A failure to describe how to properly validate this information

2) A failure to describe how this information will be used within browsers

3) A failure to describe how such information will be used in non-browser clients, which will impair the ability to timely respond to browser concerns

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?

This is an interesting rewriting of history occurring. You may not have realized it, but many of the same conversations happened. The *only* reason that the PSD, VAT, and NTR issues were accepted were related to PSD2, and specifically as a temporary solution to allow continued collaboration with ETSI ESI on how it is technologically inappropriate and harmful to use X.509 and TLS certificates to express this information. Luckily, the eIDAS Regulation and PSD2 are technology neutral in this regard, and we're confident that alternative solutions, or modifications to the profile of ETSI ESI, can better address the technological needs of the market and provide stronger assurances.

There are ample ways to communicate domain binding information, which are more flexible than the use of TLS, but provide just as much if not greater assurance. The inclusion of assertions within domain name records, or well-known URIs, are two approaches actively used by a number of modern technologies. Both of these have the benefit of being independent from TLS certificates, thus not impairing things like automation or CA incident response, while also allowing them to be leveraged with more technologies, including DANE and alternative PKI trust models. These technologically superior solutions are useful to explore, and promote greater machine readability.

Of course, having a productive conversation requires a discussion of use cases.

I do hope you will allow GLEIF to respond, and not disrupt such responses as on our prior call.

_______________________________________________

Validation mailing list

mailto:Validation at cabforum.org

https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190925/d14cd52d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5394 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190925/d14cd52d/attachment-0001.p7s>