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

Fri Aug 23 13:37:06 MST 2019

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.

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

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.

-Tim

From: Ryan Sleevi <sleevi at google.com> 
Sent: Friday, August 23, 2019 10:44 AM
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

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:sleevi at google.com> > 
Sent: Tuesday, August 20, 2019 2:28 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto: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 <mailto: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 <mailto:sleevi at google.com> > 
Sent: Tuesday, August 20, 2019 2:13 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto: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 <mailto: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 <mailto: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/caea4a5c/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/servercert-wg/attachments/20190823/caea4a5c/attachment-0001.p7s>