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

[Tim Hollebeek]

I am going to be listening to the recording, and comparing it to the
proposed minutes.

 

-Tim

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Kirk Hall
via Validation
Sent: Wednesday, September 18, 2019 1:37 PM
To: Kirk Hall via Validation <validation at cabforum.org>
Subject: [cabf_validation] Amended draft Minutes of the September 12, 2019
Validation Subcommittee Call

 

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  <http://schema.org>
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/115881c1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190918/115881c1/attachment-0001.p7s>