[Servercert-wg] LEI Ballot - looking for second endorser

[Ryan Sleevi]

On Fri, Aug 23, 2019 at 4:37 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> I’ve made a first pass through your comments and am preparing responses,
> but I’ve been a little bit busy because I’m currently at a conference.
> I’ll be back next week.
>

Great


> Your additional explanation is helpful and I welcome additional suggested
> language improvements you may have.  There are a few sticky issues that are
> tough to address and the current language reflects my initial attempt to
> solve some of the problems.
>

Yup. This is where I think "less is more", and we can focus on the
substantive issues and ambiguities, and defer some of thornier issues that
might be simply "nice to haves".


> The ambiguity about who to report it to is a consequence of being unable
> to come up with a good way of dealing with the fact that the CA may be
> aware which of the two sources is likely to be wrong, and therefore might
> know the right organization to report the error to.  However I’m not sure
> that it is easy or even possible to come up with exhaustive rules that
> adequately address all the possible situations.
>

Thanks. This, to me, suggests all the more reason that we should remove
that mandate entirely. It's functionally not auditable, it's not guaranteed
to produce the right result (in terms of your intent vs the language), and,
at best, it's not essential to the validation process itself.


> As far as the GLEIF folks go, yes, they are watching this discussion, and
> had the opportunity to review the language before I posted it.  However
> they are less familiar with CABF politics and the subtleties of coming up
> with appropriate ballot language for the BRs.
>

Great. I do hope they know they can chime in on the questions at cabforum.org
to provide any clarifications or concerns. In particular, it would be great
if representatives from GLEIF could clearly and concisely express the value
of expressing this within the certificate, given that, at present, a
properly validated EV certificate should be linkable (via the serialNumber
and a GLEIF-recognized Registration Authority [1]) to the LEI. It seems as
if all the necessary information is already there.

If the concern is that EV certificates do not express the GLEIF
registration authority (in terms of EV certificates, Government Agency for
the Jurisdiction of Registration / Jurisdiction of Registration), then I
would imagine that might be solvable via a different means, and to the
benefit of all EV certificates, by pursuing a path similar to LEI and
creating a codelist of allowed Government Agencies and how to encode them,
to accompany the serialNumber. This functionally moves the binding of
LEI<->Registration Agency from being done by the CA, which of course is an
error prone and unreliable process, and onto something the Relying Party
can do when evaluating the certificate.

As it stands, there's no functional or normative improvement with respect
to adding LEIs; unlike the ETSI case in which the additional fields are
restricted by the ETSI documents to only be used by CAs that are on a legal
obligation and regulatory supervision, the addition of the LEI field would
allow misissuance without any substantive consequence to the CAs who
included it. That's the status quo with EV certificates, and so isn't a
change - but that, combined with the above remarks about serialNumber,
suggest that perhaps there isn't much value in adding LEI?

Having someone from GLEIF articulate the purpose, intended use case, and
value proposition would be great, as otherwise, adding additional
information to the certificate just seems to introduce additional risk of
misissuance, additional barriers and challenges to issuance, and no
additional value for Relying Parties over the existing profile.

[1]
https://www.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190823/1d5ef82a/attachment.html>