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

Fri Aug 23 10:43:39 MST 2019

Hey Tim,

Just checking in to see if you had thoughts about the proposed changes
here. Similarly, I'd be curious if folks from GLEIF are watching this
discussion and aware of the proposal, or, if not, whether you plan to make
any outreach to GLEIF or the LEI ROC to solicit feedback. Much as we saw
with ETSI and PSD2, it would be good to make sure we're not specifying
things in a way that misunderstand the procedures used by LOUs or the LEI
ROC and GLEIF.

I realized I forgot to summarize one of the other suggestions I made on the
GitHub, which is that I suggested removal of the "SHALL be compared and
SHALL be reported". My concern with that language is that the comparison
rules here are not specified, and the reporting process is left very
ambiguous and in an arguably unauditable way. SHALL has the implications of
MUST, and the implications here are worth considering. For example, it
suggests reporting to the registration authority - but it's ambiguous as to
whether that represents the LOU or the Jurisdictional authority. Similarly,
it's ambiguous as to what reporting to the "GLEIF Foundation" (Note: much
like ATM Machine, it's duplicating the word at the end of the acronym and
thus not correct) entails.

For example, imagine a certificate with an embedded LEI was issued. Later,
it was determined that the CA's "reporting" mechanism was to send a message
to spam at gleif.org and say "I know one of your LEIs is wrong" (and nothing
more). To the CA, they might fully argue that they adequately reported.
However, I don't think that would raise to meet the definition set forward,
and thus, I think it can be reasonably be argued that the certificate was
misissued, on procedural grounds, and thus needs to be revoked within 5
days. As a CA, I'm sure that's not the desired outcome you might have, and
thus, removing the text seems eminently reasonable.

If, as has been suggested by others, the intent is to "give back to the
community", as it were, then I think we might want to formalize this a bit
more, and perhaps challenge the LEI at the LOU. Of course, given that LEIs
are renewed on an annual basis, the challenge seems likely to be more
disruptive for GLEIF and the LOU than beneficial, as some differences are
to be routinely expected and within the bounds of the threat and risk
models that GLEIF is operating on.

Have I perhaps misunderstood the considerations here? Hopefully that
explains in greater detail those concerns.

On Tue, Aug 20, 2019 at 6:52 PM Ryan Sleevi <sleevi at google.com> wrote:

> Thanks Tim!
>
> I left a number of comments on
> https://github.com/cabforum/documents/pull/139#pullrequestreview-277466868 and
> tried to offer concrete suggestions.
>
> There's still a non-trivial amount of (unnecessary) marketing copy, which
> I've flagged for deletion.
>
> I've tried to formalize the validation process more, and in doing so, I'm
> even more skeptical of the value. That is, a properly validated EV
> certificate (which we know a number of members of this Forum are struggling
> with doing correctly, apparently) should have sufficient information to
> determine the associated LEI within the certificate already. That is,
> searching by the subject serialNumber and jurisdiction, assuming the CA
> properly validated and encoded the certificate, seems like should be
> sufficient to determine the associated LEI.
>
> Another element to consider is the intersection between ISO 17442
> versions, and how that should impact. For example, ISO 17442:2019 is the
> current version (under review), replacing the (withdrawn) ISO 17442:2012.
> I'm not aware of a freely available copy of ISO 17442:2019 - are you? This
> does make it somewhat more difficult to verify the correctness here, with
> respect to both Section 4 and Section 6 of the aforementioned ISO standard.
> I've attempted to compare against GLEIF's LEI-CDF Level 1 format, but I'd
> definitely want to check against ISO 17442 before including within the BRs.
>
> On Tue, Aug 20, 2019 at 3:48 PM Ryan Sleevi <sleevi at google.com> wrote:
>
>> Oh, for sure. I wasn't trying to fork discussion, so much as provide more
>> specific and contextual suggestions for generalized problems. The nice
>> thing is that I can make or suggest changes on the GitHub in order to make
>> it easier for you to evaluate/integrate, but post the links back here for
>> the Forum to provide context and visibility, which I'll now go and do :)
>>
>> On Tue, Aug 20, 2019 at 3:29 PM Tim Hollebeek <tim.hollebeek at digicert.com>
>> wrote:
>>
>>> Okay, I was trying to keep the discussion here because not everyone uses
>>> github, but I’m not picky.  If you want to discuss it there that’s fine.
>>>
>>>
>>>
>>> -Tim
>>>
>>>
>>>
>>> *From:* Ryan Sleevi <sleevi at google.com>
>>> *Sent:* Tuesday, August 20, 2019 2:28 PM
>>> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
>>> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
>>> servercert-wg at cabforum.org>
>>> *Subject:* Re: [Servercert-wg] LEI Ballot - looking for second endorser
>>>
>>>
>>>
>>> Sounds like there was still some confusion. If you open a draft pull
>>> request, it's easier to discuss inline and offer clearer suggestions then
>>> on ways to resolve.
>>>
>>>
>>>
>>> On Tue, Aug 20, 2019 at 2:27 PM Tim Hollebeek <
>>> tim.hollebeek at digicert.com> wrote:
>>>
>>> I made both of the changes you wanted – added a requirement for
>>> FULLY_CORROBORATED, and removed an unnecessary sentence or two from the
>>> definitions.
>>>
>>>
>>>
>>> -Tim
>>>
>>>
>>>
>>> *From:* Ryan Sleevi <sleevi at google.com>
>>> *Sent:* Tuesday, August 20, 2019 2:13 PM
>>> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
>>> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
>>> *Subject:* Re: [Servercert-wg] LEI Ballot - looking for second endorser
>>>
>>>
>>>
>>> Tim,
>>>
>>>
>>>
>>> Are you open to feedback within GitHub, including potential corrections?
>>> If so, you can open a draft pull request (e.g. as done with
>>> https://github.com/cabforum/documents/pull/138 ) which can allow such
>>> comments and collaboration, as discussed at the Greece F2F.
>>>
>>>
>>>
>>> I don't see any changes from the issues discussed on the call. I know
>>> you've expressed an opinion that changes will not be made unless someone
>>> gives you alternative text, but I'm curious if it was intentional in this
>>> case to not incorporate that feedback before seeking a co-endorser?
>>>
>>>
>>>
>>> As the ballot currently stands, this would be a No vote from us, and so
>>> I'd like to try to help you understand the concerns we've raised
>>> previously, so they can be integrated before proceeding to ballot, if
>>> possible.
>>>
>>>
>>>
>>> On Tue, Aug 20, 2019 at 1:54 PM Tim Hollebeek via Servercert-wg <
>>> servercert-wg at cabforum.org> wrote:
>>>
>>>
>>>
>>> Ballot SC??: Legal Entity Identifiers
>>>
>>> Purpose of Ballot: Allow for the inclusion of globally unique LEI
>>> identifiers
>>>
>>> into the cabfOrganizationIdentifier field.
>>>
>>>
>>>
>>> The following motion has been proposed by Tim Hollebeek of DigiCert and
>>> endorsed
>>>
>>> by Richard Smith of Sectigo and ??? of ???.
>>>
>>>
>>>
>>> ---MOTION BEGINS---
>>>
>>>
>>>
>>> Amend the EV Guidelines version 1.7.0 as follows:
>>>
>>>
>>>
>>>
>>> https://github.com/cabforum/documents/compare/master...timfromdigicert:Ballot-LEI?expand=1
>>>
>>>
>>>
>>> ---MOTION ENDS---
>>>
>>>
>>>
>>> The procedure for approval of this ballot is as follows:
>>>
>>> Discussion (7+ days)
>>>
>>> Start Time: ???
>>>
>>> End Time: ???
>>>
>>> Vote for approval (7 days)
>>>
>>> Start Time: ???
>>>
>>> End Time: ???
>>>
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> http://cabforum.org/mailman/listinfo/servercert-wg
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190823/4808c99a/attachment.html>