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

[Kirk Hall]

Here are the amended draft Minutes of the September 12, 2019 Validation Subcommittee Call.  Ryan Sleevi did the initial draft, and I proposed edits based on the meeting recording.  Ryan suggested one change to my edits, which I accommodated by different wording.  There have been no other comments by other members, so I am posted this amended draft.


Attendees: Ben Wilson, Wayne Thayer, Bruce Morton, Kirk Hall, Tim Shirley, Janet Hines, Ryan Sleevi, 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 [Ryan Sleevi] 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 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.

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 saying that it should not 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 Stephan's 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 of financial instruments, and understanding the exposure to financial instrument insurance risks. 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<http://schema.org>, which might be an additional incentive.

Kirk again said it would be nice to know what Ryan thought the risks were.  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.  Ryan said yes if Kirk would like to discuss it and Kirk said he would.  Ryan said it would be better to continue the conversation with Stephan and GLEIF to better understand LEIs in TLS certificates used by browsers so that CAs could understand. Ryan was surprised by the difficulty CAs had in understanding the benefits to reduced certificate lifetimes, and given the nuances and complexities, suggested given the nuances and complexity here it would be much more involved topic.

Kirk said CAs needed to know what Ryan's concerns were before Stephan's additional data would be useful to them.  Ryan said that's why he wanted to work directly with Stephan to see if they could come up with a productive proposal rather than having to debate the concerns.  He would be much more interested in providing a constructive solution than having frankly argumentative approaches.  Ryan said he found Kirk's approach more argumentative than productive, so he preferred to work with Stephan so they could come up with a productive solution.   Kirk disagreed with that approach, and asked "A solution to what?"  Kirk said you've got to define a problem before you can come up with a solution, and again asked Ryan to describe the problem for the group, as Kirk didn't think anyone understood what Ryan saw as the problem.  Ryan said he had to run to another meeting.

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  He stated Google's position is, again, that it would be actively harmful to include LEI numbers in EV certificates and Google doesn't see a path forward at present to allow the issuance in TLS certificates without potentially blocking those certificates or even blocking the CA, and that's a very serious thing but that's the ecosystem harm that Google see by putting LEI numbers in EV certificates, and so Ryan would like to try to find some way to avoid that by making sure there's a better understanding of the value proposition relative to the risks Google sees.  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/20190918/b3268b27/attachment-0001.html>