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

[Ryan Sleevi]

Er, it's been pointed out to me I forgot to include myself on the attendees
list, and included Kirk twice. The corrected list should read

Attendees: Ben Wilson, Wayne Thayer, Bruce Morton, Kirk Hall, Tim Shirley,
Janet Hines, Li-Chun Chen, Robin Alden, Shelley Brewer, Daniela Hood,
Joanna Fox, Ryan Sleevi

On Fri, Sep 13, 2019 at 12:44 PM Ryan Sleevi <sleevi at google.com> wrote:

> 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/de85dab0/attachment-0001.html>