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

[Ryan Sleevi]

On Sat, Sep 14, 2019 at 5:50 PM Kirk Hall via Validation <
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> * 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>
> *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/20190914/1f26baee/attachment.html>