[Servercert-wg] QI*S and possible improvements

[Ryan Sleevi]

On Thu, Dec 5, 2019 at 8:00 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <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


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

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

>
>    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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191205/3d08b558/attachment.html>