[cabf_validation] Validation WG meeting minutes 2019-10-10

Thu Oct 17 05:01:50 MST 2019

Dear all,

Of course, I don’t want to cause more work for the minute taker. Here are my main contributions supporting my last email:

>From the recording:

17:15 on validation

17:50 on compatibility of LEI inclusion with ITU-T X.509 | ISO/IEC 9594-8 and the upcoming ISO 17442 and ETSI standards

23:10 on use cases

24:15 on technical risk, my statements regarding our different views 

25:05 on a concrete use case from GLEIF

26:20 Ryan on “dependency risk” as technical security risk, responding to my point that I don’t see technical risks other than maybe misuse in downstream applications other than browsers. 

39:20 My response to Ryan’s proposal to probably segregate identity information from TLS certs. I said, if you believe in EV, the LEI adds value. Otherwise it is a completely different discussion.

45:50 on advantages of having an LEI for consistency reasons in case of changes in the real world. 

You state below that GLEIF’s contribution is likely exhausted. I would phrase it differently. I have been consistent in my contribution in meetings and emails. I am very happy to continue in case of new arguments. 

Just by coincidence, I have been to OECD in Paris this week. The use EV certificates heavily when parsing websites. They fetch and interpret the EV information and match it with other sources. The LEI in certs would be highly welcomed by the team.

I am going to be in DC next week with very limited time. However, in case of urgent matters please reach out to me by mail.

Best,

Stephan

Von: Ryan Sleevi <sleevi at google.com>
Datum: Sonntag, 13. Oktober 2019 um 18:12
An: Stephan Wolf <Stephan.Wolf at Gleif.org>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>
Betreff: Re: [cabf_validation] Validation WG meeting minutes 2019-10-10

On Sun, Oct 13, 2019 at 10:25 AM Stephan Wolf <Stephan.Wolf at gleif.org> wrote:

Ryan,

I leave it with the minute taker to go back to the recording.

Thanks.

This is somewhat unfortunate, since it means the proposed edits create significantly more work, as you're insisting that you said these things, but such is life.

We'll need someone to go over the recording to see if you said these things and if they're accurately represented. I had hoped the explanation and context might have avoided this, or led to corrections or clarifications which might not require going back to the recording to confirm, but if you feel that these views were captured on the call and not the minutes, despite the concerns raised, then we can go and evaluate if that was the case.

I am still of the opinion that you have not answered my question why the inclusion of an LEI could cause security issues for the browser and its users. 

While I don't want to conflate the minutes with a continuing discussion, I can understand you're not satisfied with the answer, despite the many attempts, from many people, publicly and privately, to explain to you the concerns. Given how many people have engaged, publicly and privately, with GLEIF to express and explain these concerns, I do agree that it's unlikely that we'll make further progress with here, and that ultimately, it will be up to browser root programs as to whether to accept the risk posed and to permit that CAs within their respective programs to issue such certificates. It does seem that we've likely exhausted the insight GLEIF can provide, relative to the question of "why" in certificates, and it seems we should continue that discussion to resolution. It also seems that GLEIF does not have opinions on the validation aspect, which is essential should they be allowed, and so if they are allowed, that will remain something for the Forum to independently set.

Again, I think there's great benefit in LEIs, but that benefit does not exactly transcribe to certificates, particularly when they cause real, meaningful, and lasting harm to a more secure, more agile, more robust Web PKI.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191017/80fffd7d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2582 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20191017/80fffd7d/attachment-0001.p7s>