[cabf_validation] Topic for our next VWG call: LEI

[Richard Smith]

Ryan,

I can’t definitively answer your question, but IF a LEI number that has been assigned to one organization can be re-assigned to a completely unrelated organization I think it would completely undermine the stated original purpose of LEIs in the first place.  That being the case I strongly suspect that LEIs are not reassigned.

 

Regards,

Rich

 

https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei

 

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Wednesday, February 6, 2019 1:28 PM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Cc: Richard Smith <rich at sectigo.com>; Tim Hollebeek (tim.hollebeek at digicert.com) <tim.hollebeek at digicert.com>
Subject: Re: [cabf_validation] Topic for our next VWG call: LEI

 

 

 

On Wed, Feb 6, 2019 at 2:17 PM Doug Beattie via Validation <validation at cabforum.org> wrote:

Maybe an example will help:

 

A CA issues a certificate to Stripe Inc, Kentucky.  The LEI matches what’s in the certificate and the CA asserts all is good at this point in time.

 

A week later, the LEI changes the location of Stripe Inc, to New Hampshire.  Relying parties now think the CA asserted/verified Stripe Inc, New Hampshire because that is in the certificate and bound via digital signature in the OU field (although, they are bit confused because the DN in the certificate remains Kentucky).  It appears that the CA validated both identifies, but in fact, the CA never validated Stripe Inc, New Hampshire.

 

How do we reconcile this?  I think it’s important that everyone understands what was validated, and with the ability of LEI data to change, I don’t understand how a CA can include that as validated information.

 

That seems similar in nature to any inclusion of identity in certificates.

 

Using the Sectigo example (Sorry Rich! I would have tried harder for another example, but I was lazy), we have a certificate out there stating that crt.sh is operated by Comodo CA, when in fact, we now know it's operated by Sectigo.

 

I think one possible resolution to this is to understand whether LEIs are unique or if they're reusable. I don't know enough about LEI to have a clear answer about this, but  https://leismart.com/blog/lei-data-is-not-static/ leaves me to think that while the assigned LEI may change, LEIs themselves are not reused.

 

For example, when QuoVadis' certificate operations were taken over by DigiCert, one can imagine that the LEI 'now' used for transactions with "QuoVadis" may now be the DigiCert LEI, rather than QuoVadis' "old" LEI. If that's the scenario, then we're just talking about 'stale' information, and it overlaps with many of the things we're talking about.

 

Alternatively, if the LEI is reused - which I view your Stripe Inc/Kentucky -> Stripe Inc/New Hampshire information to be about - then I agree, we have a much more serious issue, especially if the state of that LEI at the point in time the certificate was validated (which, unfortunately, may be 2+ years before it was actually issued) is not obtainable.

 

Do you have a sense on whether or not the LEI model reuses identifiers, rather than merely creates or associates new identifiers?

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