[cabf_validation] Draft Minutes of the September 12, 2019 Validation Subcommittee Call

[Ryan Sleevi]

Attendees: Ben Wilson, Wayne Thayer, Bruce Morton, Kirk Hall, Tim Shirley,
Janet Hines, Kirk Hall, Li-Chun Chen, Robin Alden, Shelley Brewer, Daniela
Hood, Joanna Fox
Invited Guests: Stephan Wolf, GLEIF Foundation, Simon Wood from Ubisecure(?)

Note: Because of the nature of the discussion, and the invited guests, I
tried to take detailed notes here, for those that were not able to
participate in learning from GLEIF about the LEI system.


Agenda: Discussion of LEI in certificates

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

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.

Ryan then began to explain the previous call, and why Stephan had been
invited. In the previous discussion, Ryan and Tim had started discussion on
GitHub, and then continued on the call, about how to match the EV
organization information to a LEI. They had been discussing the specific
procedures a CA would need to do to match the information. During that
discussion, Ryan had highlighted that within an EV certificate, we have a
serialNumber field that, combined with the jurisdiction of incorporation,
matches 1:1 with a LEI. If you look at the process for a LOU to issue a
LEI, there’s a specific list of Registration Authorities recognized by
GLEIF, which lists the jurisdictions of incorporation for those
Registration Authorities, and then the LEI is issued based on a
registration number associated with that registration authority. If you
look at the process that was proposed to validate the LEI to be included in
a certificate, it became clear that all the information needed to look up
in the GLEIF database was there: a jurisdiction of incorporation and a
business registration number. Because the information was all there in EV
certificates already, it was unclear why relying parties would want a LEI
if it was in a certificate, how would it be used, and why wouldn’t the fact
that relying parties can look up a LEI in the GLEIF Index based on the
information in the EV certificate satisfy that need? Ryan was hoping that
Stephan, rather than the CAs, could explain why this additional field would
be useful, and asked Stephan to explain more.

Kirk objected that it should be a question for Stephan, because GLEIF
doesn’t issue certificates. That should be a question for CAs and how they
want to use it. Ryan attempted to clarify that the question was intended
for Stephan, and Kirk objected, saying it was wrong to ask Stephan about
why LEI should be in certificates. Kirk repeated that a LEI was a globally
unique number, and thus relying parties would not have to parse the
existing EV data. He felt that was a sufficient reason, and there should be
no reason why browsers would have concerns with including that. He felt
that if CAs think there is a market for it, and he does, then he doesn’t
understand why CAs would be prevented from including it.

Stephan expressed appreciation for being invited to the call, having
previously attended the Thessaloniki F2F and had some e-mail exchanges with
Dean Coclin. He shared that a LEI Number is not like other registration
numbers, like a DUNS number, in that it’s a unique, globally recognized
identifier endorsed by the G20 nations, including being recognized by
various national laws. The Dutch government recently required that the
Dutch business registry must include in the LEI, beginning in 2020. The
analogy was that the business registration number is like the national ID
card, while a LEI is more like a passport, because it’s internationally
recognized. One question they had heard is whether or not the LEI would be
useful to include in certificates, and TLS certificates in particular for
Server to Server communication. GLEIF was encouraged in Thessaloniki to
hear that some CAs felt it would be useful to include.

Ryan explained that, on the previous call, there was discussion about how
within an EV certificate, there is a unique business registration number
and a jurisdiction of incorporation already included. When discussing about
how a CA might validate a LEI for inclusion in the certificate, the
proposal had been that a CA would then go to the GLEIF database and try to
match to a LEI, by matching those fields. What was not clear is that if it
was possible to look up a LEI based on the jurisdiction of incorporation
and registration number, why wouldn’t that be sufficient for Relying
Parties? What is the additional value of having the LEI in the certificate,
if you can determine the LEI, if it exists for that registration, based on
the information already present within the certificate? If that’s a
misunderstanding, is there information not present in an EV certificate
that would be needed to look up the LEI?

Stephan mentioned that there are definitely discrepancies in names and
legal forms, the latter of which have only recently been standardized by
ISO and are not yet widely used. Any CA that follows the CA/B Forum
Guidelines on EV certificates, they’ll include all the information to make
you believe the organization you’re dealing with is the organization you’re
dealing with. A LEI could give you additional assurance, even if there are
discrepancies. With EV certificates, people struggle on how to parse
certificates and parse subject names. With the business registration
number, in doing server to server communication, how can a server be sure
that the registration number is actually present within the business
database for that jurisdiction? You need a globally unique identifier. When
GLEIF had conversations with ITU and ISO, which were responsible for X.509,
the recommendation and idea to include this information in the Subject of
certificates came from them.

Ryan responded that it didn’t quite answer his question, and tried to
clarify. He explained in the EV guidelines, there’s a process CAs perform
to validate that there is a unique business registration number for an
organization, and that the jurisdiction of that business registration is
also encoded within the certificate. This information matches to the
process that a LOU does for issuing a LEI, using the GLEIF Registration
Authorities Code List. It’s expected that, if a LEI certificate was going
to be issued, the business registration data source a CA would use would
map 1:1 to one of the GLEIF Registration Authorities, and that the business
registration number would be the same. The previous conversation suggested
that the validation process for issuing a certificate with a LEI is that
the CA would verify the organization using one of those data sources, and
then using the GLEIF index, find the LEI that matched that business
registration number, using that GLEIF Registration Authority. It would seem
that the same information that would be included in an EV certificate is
the same information that would be used to validate the LEI before
including it in a certificate. When it comes to how this information would
be used, a TLS client would be fully able to use the GLEIF Concatenated
Files and perform that same process that CAs might do, looking up the
registration number for that jurisdiction of incorporation, and match to
the LEI. So why require the CA to do this validation, which is no better
than what a client would do? Is there a misunderstanding about what the
validation process should be?

Stephan responded that it was mostly correct, but the devil was in the
details. In multiple countries, there may be multiple registration
authorities with different levels of quality. An example is the business
registry in Mexico, which was recently rejected by GLEIF as a reliable data
source. For LEIs, you must use the tax registry in Mexico, because there's
a higher accuracy of the organization. If a CA put a business registry
number in a cert, using the business registry of Mexico, while LEI will
only have the tax number, from the tax registry. Matching that is the
process a CA would need to do, and if they couldn’t, it might be better not
to include the LEI within a certificate. For example, if the registrant
provides their LEI number, and the proof that it’s correct, then there
might be additional assurance for all downstream participants. The other
thing that’s often overlooked is the reuse of numbers. Certificates expire,
but people keep a copy of them. A LEI is unique over time, and is never
going to be reused or replaced by somebody else, so you have a lifelong
mapping to the organization. For the majority of cases, the registration is
complex, such as Germany, and Stephan has seen CAs fail to include all the
necessary information. The knowledge required around the world, and with
all of these registries, is not with the users of certificates, and Stephan
believes they’d like a unique way to identify an organization on a global
scale. Including a LEI in a certificate would help reduce the number of
steps those users would need to do to identify the company.

Ryan said it was very helpful, and opened up new questions that didn’t come
up on the last call. Ryan highlighted that Stephan mentioned expired
certificates, and how having a LEI within an expired certificate would be
useful. However, for TLS, you can’t use an expired certificate, and you
can’t archive any data associated with that certificate, because TLS is an
online negotiation protocol. Ryan explained that while he can understand
why, for cases like document signing, that would be extremely valuable, and
ETSI has spent a lot of time defining standards to provide that long-term
archival and assurance. However, for TLS specifically, it was not clear why
having a LEI within an expired certificate is useful.

Stephan explained that in the server-to-server authentication protocols,
you do the authentication of the server, and then you do the encryption of
the transport. The encryption can be done without requiring an EV
certificate; any certificate works. What we’re discussing is about the
identify information used to authenticate the server. That information is
important for the application using the data. When discussing expiration of
certificates, it’s correct that at the moment of connection the certificate
is checked for correctness. However, people still keep a record of who they
communicated with and use that information in their databases.

Ryan was still confused about the issue with expiration and why it was
important to have something unique over time. At the time of the
connection, you have the business registration information, you have the
jurisdiction, you have the GLEIF data for that point in time. It would seem
like that’s what you would need if you wanted to associate it after the
fact, or, if you wanted, a client could do the lookup within the data and
record the LEI into their database. Ryan didn’t dispute that LEIs had a
number of useful properties, but when it comes specifically to TLS clients,
it seemed like any of the use cases identified on the previous call
involved the client looking up in the GLEIF Index based on the LEI. If a
client was willing to look up in the GLEIF Index to learn the other
business names of the organization, or affiliated entities, it’s not clear
why they couldn’t also look up the LEI based on the information already in
EV certificates.

The second question Ryan had that had come up on the previous call, and
which was highlighted in Stephans answer, is that the set of business
registries used by CAs today for EV certificates is not as reliable as the
set of Registration Authorities that GLEIF uses. In the past, there’s been
a discussion on this topic, and there’s currently discussion being led by
DigiCert, to adopt a model similar to GLEIF, which is to provide an
explicit list of Registration Authorities that CAs can use for EV
certificates. If the CA/B Forum had that list of authorized registration
authorities, it seems like the data quality issue Stephan raised could be
addressed. If the data source a CA used for an EV certificate was from a
registration authority recognized by GLEIF, you can always look up the LEI.
If the data source a CA used for an EV certificate was from a registration
authority recognized by GLEIF, then there wouldn’t even be a way to include
a LEI to begin with.

Stephan wanted to clarify that the idea is that the applicant for the
certificate would provide the LEI themselves. If the CA could then verify,
according to their validation rules, that the LEI really belongs to this
entity, then the CA could put the LEI in. GLEIF is not saying 100% of LEIs
should match 100% with the organization information within the
certificates; the understanding is whether or not they match would be at
the discretion of the CA.

Ryan highlighted that the specific proposal by DigiCert, which had been
discussed on the previous call, would not have worked like Stephan
described. That’s why it was important to get GLEIF on the call, to better
understand the proposed validation process, and the browser benefit of
including the LEI in the certificate. The current proposal is, assuming the
applicant already has a LEI, the CA already has a defined process for
confirming the identity of the applicant with sources like the business
registry. Even though the LEI is associated with a business registry, the
CA still needs to go to that business registry and confirm that the
information matches the applicant they’re talking to before they’d put that
information in a certificate. They can’t simply use the information in the
GLEIF Index. So when it comes to validating the LEI, it’s simply a process
of matching, that the LEI is matched with the business registry they used
to verify the applicant.

Stephan wanted to make it clear that GLEIF has never attempted or tried to
convince members of the CA/B Forum to not use their validation rules or the
CA/B Forum guidelines on validation. He’d heard that someone had said GLEIF
thought their system was better, but that’s not at all GLEIF’s position.
CAs would continue to do what they do, according to the requirements they
need to meet. However, a LEI could be a valuable tool in this process, and
could help downstream applications. In the long run, when more and more
governments recognize the LEI within their corporate registration systems,
it might be possible to use the LEI as part of the validation process. But
that’s more of a future vision, and not for the discussion.

Stephan mentioned that there were two dimensions to the conversation. On
one dimension, there had been questions in the past from Tim, about whether
they could use LEI data, or just the fully corroborated LEIs. Stephan tried
to explain the different corroboration levels in those past conversations,
but in the end, it seemed everyone was happy to just go with fully
corroborated. In future versions, it might be worthwhile to revisit,
because that doesn’t allow easily issuing certificates to organizations not
covered by the validation rules today.

Stephan said the other dimension of the discussion is whether the
information is redundant. If he’s understanding Ryan’s position correctly,
Ryan’s suggesting that if we have all the information in EV certificates,
and we have a business registry number, it could be matched outside the
cert by downstream applications. Stephan felt that’s where the interest
from the CA industry was, so that downstream applications wouldn’t have to
do that, because the CA would do it. Downstream clients might get that
wrong, so it’d be better to have a CA do that work for them.

Ryan said that was a perfect lead to his final question. He’s seriously
doubtful about a number of CA’s validation processes. However, if we
imagined a world where the CA/Browser Forum restricted the list of business
registries to a specified list, and did what DigiCert had proposed in the
past, which was uniquely identify which business registry was used within
the certificate, just like GLEIF pioneered with the RA code, would that
allow a 1:1 mapping to GLEIF Registration Authorities, and would there be
any incompatibilities on the client to do the lookup? It’s not clear that
there are, but if there are, it would seem like these are existing problems
CAs would need to deal with, and we should try to address them now.

Stephan replied that we’re at a first stage, and GLEIF is convinced that
including LEIs in certificates is a sensible and reasonable step forward,
but acknowledged that not everyone is convinced. If the CA/B Forum wanted
to develop a list of business registries, GLEIF would be more than happy to
help that development and collaborate. This is just a discussion about the
minimum requirements to put a LEI in a certificate, but that doesn’t
restrict future collaboration. GLEIF is not the only organization
developing this list, it’s in collaboration with the international business
registry community and in working with local regulators and whether or not
the national list is suitable for their legal purposes. Another place of
discrepancies is with legal forms, and their abbreviations and
representations in different languages. There’s a huge opportunity to use
those international standards.

Ryan responded that it did not answer his question, and suggested they
continue the conversation offline after the call, to better understand, to
give others a chance to ask questions.

Kirk stated he wanted to describe his understanding of why LEIs were
introduced and how they’re used, and then wanted Stephan to tell Kirk if he
was right or if he was wrong, because he thought it might answer Ryan’s
question. Kirk then described his understanding, which was that with the
financial crisis of 2008, many financial organizations had complex
relationships, and had difficulty understanding their exposure to the
failure of a particular company. They had lists of their investments, but
no easy way to calculate the exposure. They could have looked up all of
those organizations by registration numbers and jurisdiction of
incorporation, but that wasn’t practical to uniquely identify each company
to efficiently find that company. Kirk’s understanding was that the first
use was to calculate risk profiles, but has now been used in many other
ways.

Stephan confirmed that was correct, and wanted to try to explain how this
relates to certificates. The original concerns were less about financial
services, and more about insurance, and understanding the exposure to
insurance risks. The financial regulators wanted to shore up the system,
but also make sure it never happened again, because citizens would have
suffered. When the FSB was tasked by the G20 about how to avoid systemic
risk, they created the LEI system and thought beyond that, and suggested
the LEI should be used in any financial transaction, which is slowly
happening. For example, the SWIFT payment network has proposals to use the
LEI within the SWIFT network. This means that the LEI automatically becomes
part of the Known Your Customer routines that banks would use. The banks
would be interested in using the LEI across the board, so that when the
banks connect in a server to server network, they can use the LEI, and
don’t have to map the information. The LEI becomes part of the DNA of the
banking industry, and that then expands into many other industries, since
you can’t run a business without a banking account in so many places around
the world. The LEI system was not only about managing crisis, but also
gaining efficiencies and transparency in real time transactions, rather
than lengthy manual processes. This is why the banking industry expressed
interest in having LEIs within certificates.

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.

Ryan thanked Stephan for sharing about the value of LEI, which is something
Ryan’s been supportive of. There are many elements of the LEI model that
Ryan felt the CA/B Forum could look to adopt, such as the approach to
governance and how to mitigate the risk of unreliable LOUs. For many uses,
LEIs are fantastic. While LEIs within document signing certificates can
have huge and obvious value, specifically to TLS certificates, and
specifically as used by browsers, Ryan’s concern was that including LEIs in
certificates would be actively harmful to the ecosystem, and to the
security of Chrome’s users. He asked if Stephan would be open to having
additional calls to better discuss and better understand if there are other
technological options to addressing some of the use cases. One of the
challenges, as a browser vendor, has been dealing with the confusion that
has resulted from ITU and ISO’s approach to X.509. Many of those early
ideas have not only not panned out, but turned out to be harmful to the
security and stability of the Internet. He wanted to discuss more to
understand the use cases for LEIs in TLS certificates, and to explore
potential technical alternatives that don’t expose Chrome users to security
risk.

Stephan said this is just a start, and Rome wasn’t built in a day. He’s
still surprised at the complexity involved in the business registry system,
and appreciates the time and effort spent to discuss and understand.
Stephan made it clear he does not share the concerns about the risks, and
felt it will lower risk, rather than increase it. Stephan thought that, by
further discussion, the perspective that LEIs in TLS certificates pose a
risk would reverse, and committed to discussing further. A long shot vision
might be to have CAs become LOUs, but that’s a long shot, and we have to
start somewhere.

Kirk said it would be helpful if Ryan wrote down what the threats were.
He’s heard it said, but he has never really understood the risks. If there
was a position paper, it would be something they could address.

Ryan responded that it’s a bit like certificate lifetimes, so he’s not that
optimistic that it would address Kirk’s confusion, but indicated he was
hopeful that continued conversation with Stephan and GLEIF will be able to
find solutions that don’t present risk.

Kirk asked what is the risk, because Chrome wouldn’t have to display that
data. Kirk wanted to spend the remainder of the call discussing this.

Stephan wanted to share that GLEIF has just finished work on a semantic
representation of the LEI file, and plan to produce an RDF file that can be
absorbed. Rather than needing to connect to a GLEIF server, Stephan thought
Chrome could connect to Google’s network to look up information about
companies. GLEIF is also planning to approach schema.org, which might be an
additional incentive.

Ryan indicated that with only a few minutes left on the call, he didn’t
think it would be a productive conversation to try and have with so little
time. Kirk asked about adding it to the agenda of the next call, and Ryan
said it would be better to continue the conversation with Stephan and GLEIF
to better understand LEIs in TLS certificates used by browsers. Ryan was
surprised by the difficulty CAs had in understanding the benefits to
reduced certificate lifetimes, and given the nuances and complexities,
suggested it would be much more difficult.

Kirk wanted to understand the concerns to try and address them. Ryan
suggested it would be better to continue the conversation with Stephan and
GLEIF, to see if productive solutions might be identified, rather than
simply listing concerns that might not be understood.

Wayne suggested it’s unlikely we’d have a constructive conversation for the
remainder of the call, and said that it sounded like a follow-up call with
Stephan and Ryan might be valuable to address the concerns. Stephan
clarified that GLEIF does not normally engage in 1:1s, and asked if would
it make sense to have another broad call with CAs. Ryan said he did not
think a broad call would be as productive as needed, given that the current
position of Chrome is that it would be actively harmful to include LEIs in
TLS certificates, and may require Chrome potentially needing to block the
certificates or even the CA that issued them. Because of how serious that
would be, Ryan wanted to try and find a way to avoid that, by making sure
there’s a better understanding about why LEIs should be in TLS
certificates, relative to the risks.

Stephan clarified that a 1:1 on the technical merits is fine, but if
discussing risks to the CA industry, it is only fair to include CAs. Ryan
clarified that it’s specifically risk to Chrome’s root program, and the
security of Chrome users, and while CA input is valued, this is an area
where browsers have always made independent decisions and defined their own
policies specific to their products, not within the CA/B Forum. Other CAs
and products may differ on how they prioritize and view things, but Ryan
was viewing it through the perspective of the risk LEIs in certificates
would pose to products that use the Chrome Root Store.

Wayne suggested we should continue the conversation, and that the mailing
list might help, and this may be an opportunity for future calls. Wayne
thanked Stephan for joining and spending so much time discussing the issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190913/5d32422c/attachment-0001.html>