[cabf_validation] [EXTERNAL]Re: Suggested edits to draft Minutes of the September 12, 2019 Validation Subcommittee Call

[Kirk Hall]

I have to admit that I did not scroll all the way to the end of your response to my edits, Ryan, so I didn’t see your comments at the bottom.

You asked me this question “[D]o you believe these details [added by my edits] are important for the minutes?”  My response is yes, I think the additional details I propose to add to the Minutes are very important.

On the call, you stated the following about Googles position on LEIs in EV certificates, as I included in my edits to the Minutes:

“***Google’s position is, again, that it would be actively harmful to include LEI numbers in EV certificates and Google doesn’t see a path forward at present to allow the issuance in TLS certificates without potentially blocking those certificates or even blocking the CA, and that’s a very serious thing but that’s the ecosystem harm that Google see by putting LEI numbers in EV certificates.”

You have said this before, and many CAs are wondering what the “ecosystem harm” is that you see from adding an organization’s LEI to an EV certificate as an extension after proper validation by the CA (that is the goal of the draft ballot we are working on now).  You have also said that validated LEIs added as extensions to EV certificates would be “actively harmful” to Chrome users.

These are pretty strong statements, and CAs who could have their roots distrusted in Chrome simply because they included an LEI number in a certificate (in the manner approval by a CABF ballot) are all eager to know: what is the “ecosystem harm” you see that would justify such a step by Google?  What is the harm from LEIs to Chrome users that you foresee?  We have asked for an explanation several times, but so far you have not responded.

The LEI ballot has been delayed by weeks because of your stated concerns, so at this point it would be useful to get a clear statement from Google on the harm LEI data so we can collectively respond, and perhaps even satisfy your concerns.  That would allow us to move forward on the ballot.

Many CAs and browsers were not on the call, and on such an important issue this (distrusting CA roots, ecosystem harm, etc.)  it’s appropriate to include relevant details taken from the meeting recording.

From: Ryan Sleevi <sleevi at google.com>
Sent: Saturday, September 14, 2019 7:22 PM
To: Kirk Hall via Validation <validation at cabforum.org>
Cc: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Subject: [EXTERNAL]Re: [cabf_validation] Suggested edits to draft Minutes of the September 12, 2019 Validation Subcommittee Call

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________


On Sat, Sep 14, 2019 at 5:50 PM Kirk Hall via Validation <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:
Sorry – one more edit marked [5] after the fourth paragraph from the top

[5] Change

Kirk objected that it should be a question for Stephan, because GLEIF doesn’t issue certificates.

To:

Kirk objected that it should not be a question for Stephan, because GLEIF doesn’t issue certificates.

Kirk: The combination with objected makes it seem that you're objecting to it not being a question for Stephan, when you made it clear you did not believe that GLEIF should be asked why LEIs should be in certificates.

I attempted to capture that, with your "objection" to the previous discussion. However, I'm sure we can reword it so that it's clear that you did not feel GLEIF should have any say on the inclusion within certificates, if that's your intent.


From: Validation <validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org>> On Behalf Of Kirk Hall via Validation
Sent: Saturday, September 14, 2019 1:57 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: [EXTERNAL][cabf_validation] Suggested edits to draft Minutes of the September 12, 2019 Validation Subcommittee Call

Thanks for taking such detailed Minutes, Ryan.  Here are four suggested edits.  To find where the edits would go in your text at the bottom of this message, look for the corresponding number in [brackets].  I have indicated the time on the recording for each edit.

PROPOSED EDITS

[1] At 06:20 - Change:

He initially had concerns about their validation process, as well as business concerns about whether it was possible to match LEI data with EV data with no errors, and that he’s now satisfied it’s something.

To:
He initially had concerns about their validation process, as well as business concerns about whether it was possible to match LEI data with EV data with no errors, and that he’s now satisfied it’s something that can be done.


[2] At 41:45, change:

Stephan confirmed that was correct, and wanted to try to explain how this relates to certificates. The original concerns were less about financial services, and more about insurance, and understanding the exposure to insurance risks.

To

Stephan confirmed that was correct, and wanted to try to explain how this relates to certificates. The original concerns were less about financial services, and more about insurance of financial instruments, and understanding the exposure to financial instrument insurance risks.

No objections to these two edits.

[3] At 55:20, change:

Ryan indicated that with only a few minutes left on the call, he didn’t think it would be a productive conversation to try and have with so little time. Kirk asked about adding it to the agenda of the next call, and Ryan said it would be better to continue the conversation with Stephan and GLEIF to better understand LEIs in TLS certificates used by browsers. Ryan was surprised by the difficulty CAs had in understanding the benefits to reduced certificate lifetimes, and given the nuances and complexities, suggested it would be much more difficult.

Kirk wanted to understand the concerns to try and address them. Ryan suggested it would be better to continue the conversation with Stephan and GLEIF, to see if productive solutions might be identified, rather than simply listing concerns that might not be understood.
To:

Kirk again said it would be nice to know what Ryan thought the risks were.  Ryan indicated that with only a few minutes left on the call, he didn’t think it would be a productive conversation to try and have with so little time. Kirk asked about adding it to the agenda of the next call.  Ryan said yes if Kirk would like to discuss it and Kirk said he would.  Ryan said it would be better to continue the conversation with Stephan and GLEIF to better understand LEIs in TLS certificates used by browsers so that CAs could understand. Ryan was surprised by the difficulty CAs had in understanding the benefits to reduced certificate lifetimes, and given the nuances and complexities, suggested given the nuances and complexity here it would be much more involved topic.

Kirk said CAs needed to know what Ryan’s concerns were before Stephan’s additional data would be useful to them.  Ryan said that’s why he wanted to work directly with Stephan to see if they could come up with a productive proposal rather than having to debate the concerns.  He would be much more interested in providing a constructive solution than having frankly argumentative approaches.  Ryan said he found Kirk’s approach more argumentative than productive, so he preferred to work with Stephan so they could come up with a productive solution.   Kirk disagreed with that approach, and asked “A solution to what?”  Kirk said you’ve got to define a problem before you can come up with a solution, and again asked Ryan to describe the problem for the group, as Kirk didn’t think anyone understood what Ryan saw as the problem.  Ryan said he had to run to another meeting.
Kirk, do you believe these details are important for the minutes? When speaking to other people on the call, there was concern expressed that this was not only not necessary to include, but would actively be unproductive. For example, in the minutes, I elided the places where you interrupted when other folks were speaking, because that did not seem necessary to minute in detail.

I'm curious whether you feel the proposed new section adds anything that was not captured in the minutes. I don't believe it does, and I think it does a disservice to your own contributions to highlight. However, if you feel it is important, and relevant to understanding the discussion of LEIs, we can certainly try to be more accurate here.

For now, consider it an objection to the change, to better understand how we can best communicate the discussion.

[4] At 57:10, change:

Wayne suggested it’s unlikely we’d have a constructive conversation for the remainder of the call, and said that it sounded like a follow-up call with Stephan and Ryan might be valuable to address the concerns. Stephan clarified that GLEIF does not normally engage in 1:1s, and asked if would it make sense to have another broad call with CAs. Ryan said he did not think a broad call would be as productive as needed, given that the current position of Chrome is that it would be actively harmful to include LEIs in TLS certificates, and may require Chrome potentially needing to block the certificates or even the CA that issued them. Because of how serious that would be, Ryan wanted to try and find a way to avoid that, by making sure there’s a better understanding about why LEIs should be in TLS certificates, relative to the risks.
To:

Wayne suggested it’s unlikely we’d have a constructive conversation for the remainder of the call, and said that it sounded like a follow-up call with Stephan and Ryan might be valuable to address the concerns. Stephan clarified that GLEIF does not normally engage in 1:1s, and asked if would it make sense to have another broad call with CAs. Ryan said he did not think a broad call would be as productive as needed  He stated Google’s position is, again, that it would be actively harmful to include LEI numbers in EV certificates and Google doesn’t see a path forward at present to allow the issuance in TLS certificates without potentially blocking those certificates or even blocking the CA, and that’s a very serious thing but that’s the ecosystem harm that Google see by putting LEI numbers in EV certificates, and so Ryan would like to try to find some way to avoid that by making sure there’s a better understanding of the value proposition relative to the risks Google sees.  Because of how serious that would be, Ryan wanted to try and find a way to avoid that, by making sure there’s a better understanding about why LEIs should be in TLS certificates, relative to the risks.

Thanks. I think the original minutes, rather than your proposed additions, capture with sufficient detail, and thus I do not believe these changes are worthwhile or appropriate. I appreciate your attempt to provide greater detail to what was said, but I don't think it is necessary for the discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190918/d838a275/attachment-0001.html>