[Servercert-wg] QI*S and possible improvements

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Thu Dec 5 09:25:20 MST 2019



On 2019-12-05 5:26 μ.μ., Ryan Sleevi wrote:
>
>
> On Thu, Dec 5, 2019 at 8:00 AM Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg <servercert-wg at cabforum.org 
> <mailto:servercert-wg at cabforum.org>> wrote:
>
>
>     I am creating a new thread to discuss about this interesting
>     topic. I'd like to separate this from specific question I had for
>     the EVG with the decision about what QIS we should use.
>
>     Here are my thoughts:
>
>     On 2019-12-05 4:38 π.μ., Ryan Sleevi via Servercert-wg wrote:
>>     We should definitely take inspiration from GLEIF, who recognized
>>     the fundamental quality issues if you do anything less than that.
>
>     As we have discussed in the past for the Network Security
>     Requirements, if there was an industry solution that matched our
>     expectation as an Industry, we should defer to that. Ryan, from
>     your previous messages, I understand that you trust the process
>     that GLEIF is using to vet the local LOUs which seems to be the
>     right place for validating Legal Entities worldwide. We should
>     ensure that this solution:
>
>
> I don't think this is an accurate summary of 
> https://cabforum.org/pipermail/servercert-wg/2019-December/001523.html

The summary mostly came from 
https://cabforum.org/pipermail/servercert-wg/2019-December/001521.html 
where you stated:

"The LEI RA list is a great starting point, although with some caveats 
in that it contains a set of organizations that aren't necessarily the 
same as what we look for in EV certificates, which is understandable 
given the differences in LEI and EV. However, the approach is sound, and 
as a starting point, it's a great starting point."

Further down, you state:

"As the presumptive experts in this space, and with long-standing 
internal policies that accumulate this information (in terms of what 
QGIS sources are valid),/it should be relatively trivial to compile an 
initial list similar to LEIs/, and from there, discuss any controversial
or complicated issues."

I might have misunderstood that last part but it seemed to me that you 
implied we could compile a similar "Registration Authority" list, just 
like the one that "LEI Issuers" use to vet an organization under the 
GLEIF scheme. Is that correct?

>      1. is widely accepted in similar industries that require
>         organization information to be accurate. I believe this has
>         been answered already since the Banking sector and Governments
>         use this information to make trust decisions
>
> This is a bold statement that *significantly* misunderstands the 
> purpose of both EV and LEIs. I'm not even sure how to fully rebut it, 
> because "the information to be accurate" fundamentally misunderstands 
> the difference in purpose of the information and it's use.

I'm sorry for the confusion, I was just trying to link some of the 
current EVG requirements for the vetting of a QIIS. In section 11.11.5 
of EVG it says "(1) Industries other than the certificate industry rely 
on the database for accurate location, contact, or other information; 
and". I hope this clarifies the intent of my statement.

>     1.
>
>
>      2. is resilient to attacks with self-reported information. The
>         draft LEI ballot in the Validation Subcommittee discussed
>         about the various "assurance levels" of information and agreed
>         to use "Fully corroborated" information.
>
> This is certainly not the case.

Why not? LOUs (LEI Issuers) use the information from the list of 
"Registration Authorities" to validate the Organization Information and 
issue an LEI. This information is then added in the LEI database along 
with the "assurance level" of the information vetting. To pick a 
"random" example, https://search.gleif.org/#/record/7ZW8QJWVPR4P1J1KQY45 
shows that this information was vetted according to the GLEIF scheme by 
an approved LEI Issuer 
(https://search.gleif.org/#/record/EVK05KS7XY1DEII3R011), and also 
includes the "Registration Authority" (Division of Corporations, 
Department of State) Delaware, United States of America, RA000602) which 
is in the approved list of 
https://www.gleif.org/content/2-about-lei/7-code-lists/1-gleif-registration-authorities-list/2019-12-05_ra-list-v1.5.pdf.

If the GLEIF scheme requires an LOU to go through at least the same 
level of rigor as described in the EV Guidelines for the "Fully 
Corroborated" assurance level (to accept the "Registration Authority" as 
reliable for "Fully Corroborated information"), why should this be repeated?

I may very well be missing the exact procedure that LOUs have to 
validate information and "fully corroborate" it, I'd have to go back to 
Stephan's presentation in Thessaloniki or online information on GLEIF's 
web site to double check.


>      1. the information is regularly updated. I think this has been
>         established in the process that GLEIF is using
>      2. is regulated by transparent policy. The LEI policy and all
>         related practices are all publicly available
>      3. effective supervision. There seems to be an effective
>         supervision by GLEIF and the hierarchical scheme that is used.
>         Stefan gave us specific examples where LOUs didn't perform
>         their duties as they were supposed to, and they were removed
>         from the scheme.
>      4. ... feel free to add other concerns/questions that we should
>         collectively try to answer.
>
>     Therefore, my recommendation would be for the SCWG to consider
>     using GLEIF's process and their LOUs as QIS for EV, with a
>     phase-in period of course. Is this something Members would be
>     interested in exploring?
>
> This is a completely different proposal than what was discussed. It 
> would be the end of any value of EV whatsoever to treat the LOUs as 
> QISes, because that's not what an LOU is at all. If members want to 
> explore that, that's certainly something the Forum can do. However, to 
> avoid any ambiguity, since it seems like my "No" was interpreted as 
> "Yes", I can categorically state that exploring this proposal and 
> adopting it would eliminate any value provided by EV for us. That 
> seems strong, but that's the reality: if EV is to be useful to us, it 
> must be useful.
>
> My suggestion was not to adopt LOUs or LEIs, which are solving a 
> functionally different problem and should not be conflated with EV, 
> but to adopt the approach of enumerated business registration 
> authorities. I can understand the term "Registration Authorities" may 
> confuse some CAs, leading them to conclude I was suggesting LOUs can 
> be RAs (which is really what Dimitris' proposal is; not QIS, but RAs), 
> but I'm trying to use the GLEIF term to make it clear which GLEIF list 
> is being discussed.
>
> Stephan has helpfully provided it for the folks not as familiar with 
> GLEIF, and to reiterate, is 
> https://www.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list - 
> but that's very different from the use of LOUs as RAs, which this 
> proposal is.

Yes, the terminology is confusing. My intended suggestion was to use 
GLEIF's Registration Authorities as a collection of potential QISs. 
GLEIF has more than 700 "Registration Authorities", which are basically 
"business registries", which could be used as QIS according to the EV 
Guidelines if they additionally passed the requirements of 11.11.5 (for 
QIIS), 11.11.6 (for QGIS). Is this correct?

While searching more information about the "fully corroborated" status 
of vetted information (does it come from only one "RA"? Multiple "RAs"? 
Are there different "assurance levels" for "RAs"?), I think it is worth 
exploring the option of using this list, at least as "input" for the 
"Qualified" algorithm described in the EVG. Obviously further work is 
needed to analyze this list against lists that other CAs, like Digicert, 
have disclosed.


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191205/4bef0757/attachment-0001.html>


More information about the Servercert-wg mailing list