Connecting the Legal Entity Identifier (LEI) ecosystem to the SSL/TLS Certificate world

In our recent blog we talked about how we believe the SSL/TLS ecosystem is better served when identity and encryption are viewed as separate (but connected) concepts. Interestingly we’re seeing a similar principle echoed (in part) across some members of the browser community, specifically Google Chrome, with the downgrading of the EV UI to display only encryption indicators. Whereas we understand Google’s approach, after all they have only done good things to help drive the adoption of SSL to all time high rates, we can’t help but wonder if there is a better way to connect identity and encryption in Certs and return some perceived value to the identity assurance aspects.

We believe that identity has a firm place in the SSL/TLS world when implemented in a user friendly, secure and consistent way. We are excited to now be able to talk specifically about our approach to the ongoing identity and/or encryption debate and how we’re connecting SSL/TLS products to the traditionally physical corporate identity world.

Identity assurance across online use cases

Users relying on company identity data for any online use case need several things. They need it to be:

  • Live and accurate – representative of the company at the time of relying it
  • Regulated and consistent – there should be a credible standardized validation workflow of identity data
  • Transparent – published to a publicly accessible and verifiable open database
  • User friendly – Doing Business As should be supported where complicated group holding names would otherwise confuse users (KLM vs Koninklijke Luchtvaart Maatschappij N.V.)
  • Detailed when needed – as well as providing the ‘who is who’ aspect of company identity, when needed give insight into ‘who owns whom’ for corporate structure understanding
  • Challengeable – if inaccuracy is suspected, there should be a protocol to challenge

The Legal Entity Identifier (LEI) ecosystem, overseen by the GLEIF (Global Legal Entity Identifier Foundation), was designed to meet all these requirements. Whereas the most common use case for LEIs today remains within financial reporting, the LEI has the potential to be a central single corporate identifier for a multitude of use cases:

TrustCubes is initially focusing on the applicability of LEIs to SSL/TLS Certificates. Published LEI data is already known as a qualified data source to CAs, and some CAs already use LEI information when validating SSL applications. However that’s where the connection to LEIs ends rather than begins.

This is where our approach is different. Due to our partnerships with DigiCert as our issuing CA and with Ubisecure as our LEI Issuer, TrustCubes is now running a pilot that sees us issue EV SSL Certificates containing Legal Entity Identifiers. For the first time we’re connecting two very separate ecosystems – the physical world company identity ecosystem of the GLEIF and the online SSL/TLS ecosystem of the Certification Authorities with an aim to enable better, more relevant identity in Certificates.

Taking a deeper look at LEIs in SSL Certs

TrustCubes issues LEI enabled EV SSL Certificates from our Intermediate Certificate Authority (operated and maintained as part of the DigiCert PKI hierarchy). To view an LEI enabled EV SSL Cert, go to https://www.trustcubes.com and click on the padlock and view the SSL Certificate.

Open the ICA to view the Subject Details information.

The TrustCubes ICA include two OIDs:

1.3.6.1.4.1.52266.1 is the Legal Entity Identifier number. This OID is registered by the GLEIF specifically to contain LEIs within Certificates. The OID references an LEI number that has been added to the GLEIF database – https://www.gleif.org/en/lei/search#query=984500505FE80CD0NE58

1.3.6.1.4.1.519.1 is the DUNS number. This is a secondary corporate identifier maintained by Dun & Bradstreet. We will discuss the applicability of DUNS in future blogs as we further develop the conversation around the value of including multiple identity indicators. We see a time soon where “two form identification” could provide real value to end users.

End Entity Certificates issued by TrustCubes have a slightly different structure during the pilot phase:

The LEI belonging to the company are entered into the OU field in the Subject DN. As the pilot progresses we will subsequently stop using the OU field and instead add the LEI to an OID in the End Entity Certificate to mirror the structure of the ICA.

How to get an LEI enabled SSL Cert

LEI enabled Certificates are available at https://www.trustcubes.com/lei-ssl, or for resellers via the Partner API. Talk to us today if you want to know more about this pilot.

A few final thoughts. In a time where browser UI changes are making it harder for users to understand who the company is behind a website, connecting LEIs to SSL is a positive step towards a more standardized and useful company identity ecosystem. However these new advances and collaborations underpinning the availability and credibility of identity data should give all browser vendors an opportunity to consider how better to display identity assurance to their users.