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

Mon Oct 21 11:43:07 MST 2019

I’ve made some edits to the minutes to address input from Ryan and Stephan.  Here are the updated minutes.

================================================

If I omitted anything or mis-represented your statements, please let me know.  This was one heck of a meeting to take minutes for.

Attendees

Ben

Bruce

Daniela

Doug

Enrico

Gordon

Janet Hines

Kirk

Li-Chun

Rich

Ryan

Shelly

Stephan

Tim H.

1.       Anti-trust statement

2.       Assign note taker

Doug

3.       Other ballots

Spring cleanup ballot:  Ryan: took over and received some comments.  Will take one more look and merge in changes. Push out draft ballot tomorrow.

Method 6: Doug to take a look at that soon.

4.       Further LEI discussion

The LEI discussions was very long and intense, so this is a summary of the key points by the primary participants in this discussion and I've omitted the details in order to get the minutes out in a more consumable format.

Stephan:

*       Provided concrete use cases (server to server) and never heard back

o   Ryan commented that this was a good example for where non publicly trusted certificates would be sufficient.  More on this below

o   Ryan said that this is a technical security risk (removing things from browsers that were held up because of non-browser dependencies) 

*       Stephan didn’t hear of a direct security threats for browsers and their users from using LEIs in certs. There seems to be no technical security rick or issues with the approach other than potential dependencies in downs stream applications.

*       There’s no difference between including EV certificate data and or an LEI link as they both chain back to a business registry.

*       ETSI and ISO are both working on standards for the inclusion of LEIs in certificates (all kinds not just TLS)

*       LEIs add an incredible value to EDV certificates for transparency and timeliness of identity information

*       EV certificate data cannot change once issued, but LEI data can and thus will be more up to date and accurate

o   Ryan said that if data can change in the certificates, then there is a risk because it can't be changed quickly and efficiently. 

*	If you believe in EV and if you believe in certificates, then LEIs help.  If no, then this is a completely different discussion.

*	Ryan said there are robust ways to express identity in the domain name that reduce risk to browsers

*	Once the identity information is contained in the EV certificate, it can’t be changed where as LEI data can be updated.

*	Ryan said that the fact the identity information can change over the lifetime of the certificate represents challenges. The information in the EV certificate therefor is  uncertain.

Gordon:

*       LEIs add more readability to the similar info that is in the EV certificate today, but extends it

*       How relevant is this consumption to the browsers?

*       Gordon asks why any information in certificates

*	Ryan said there was some discussion on the list.  The introduction of multiple data sources (EV data sources, LEI data sources) introduces risk.

*       LEI is at least as valuable/relevant as the EV information already.

*       Gordon is working with some students to build a plug-in that pulls LEI number from the certificate and then displays the data to the user.  The intent is to help address the Stripe type issue

*	Ryan mentioned that some browsers today intentionally don't expose the TLS information from certificates, because of privacy reasons. So a solution like that would, at a minimum, require shipping new browser extension APIs and getting them released, and that can and does take time.
*	Ryan also shared that such solutions doesn't work for users who use antivirus that locally intercepts TLS, like various Forum members provide or have provided, or for corporate firewalls. Using an alternative way of communicating this data can make it work in more situations, including those extremely common ones.
*	Ryan replied that this isn’t tied to TLS and that perhaps the right location for this additional data in in DNS or in a .well-known location, its data associated with the domain and not with setting up a secure TLS session.

*       Separating this data our of TLS certificates sounds all good and great, but this is going to take a long time to build out and get rolling

*	Ryan replied that it was quite the opposite.  Following the suggestions posted on the list, one could get this going more quickly than that:

*	What does it mean technically when including this in TLS certificates?
*	What is the validation process?
*	Etc. those all need to be worked out.

Ryan

*       Ryan repeated this multiple times: The core question is not why LEI (there are lots of valuable use of this data), but the question is “Why LEI in TLS certificates”, and more specifically “Why LEIs in TLS certificates that interoperate with browsers”.  There needs to be compelling reason that it belongs there without introducing risk

*       What are the befits to the Root Stores that store the Roots vs. the risks for those (non-TLS specific) use cases that are not needed directly by the browsers

*       Every cert use not intended to interact with browsers introduces risks, and the goal is to remove all of these external risks.

*       The risk of external, non-browser based dependencies only increases over time, so to bring new fields and uses into TLS certificates needs to be very closely reviewed to be sure that the value is greater than the risk for the Root Store programs (browsers). 

*       One of the greatest risks to the Browsers' users: Challenge to being compliant with non-browser driven requirements and use cases.  Need to minimize to the maximum extent possible to limit harm to the browser community

*       There are risks to the eco system and more specifically to the browsers.  Browsers use TLS certificates for the purposes of securing browser to server sessions.  The additional of any more data into the certificates represents risks, technical risks

*	Slows down issuance and replacement because the data needs to be accurate and up-to date
*	Additional data can be added incorrectly and can result in misissuance which would have been otherwise avoided if the data was not present to begin with

*	Note the recent issues with states in certificates

*	Ryan has proposed alternatives to including data within the TLS certificates which he believes can be accomplished more quickly than by including similar data in TLS certificates
*	There are challenges when different users start using the browser root stores for unintended ways, for example:

*	SHA-1: Payment systems should have used non-public roots, and in the end this slowed down adoption of SHA2 in general
*	1024 bit migrations were hindered by non-browser implementations 
*	Server to server should be private PKI 
*	One CA mentioned that shortening validity period of the TLS certificates would impact their customer who is using them for non- browser purposes (bank systems).

*       There are numerous open questions about the inclusion of LEIs into certificates which will need to be address if the Why is answered.

*       In addressing the topic of ITU-T and X.509, and how distinguished name attributes were designed and specified:

*       In addressing the topic of X.509 and how this specifies the important organization attributes:

*	The structure of the subject DN of certificates was intended to be a pointer into an X500 directory where additional attributes could be obtained and used.
*	X500 directory's never materialized
*	You can read more of this in the discussion of RFC 2693
*	The ITU-T's evolution of X.509 is no longer compatible with the Web. Development of the profile used within web applications has continued in the IETF, and certificates that conform to the ITU-T specification will be rejected by applications like browsers that use the IETF specification.
*	 

*       The Root programs trust CAs for the purposes of enabling secure browser sessions and any additional reliance on TLS certificates for other purposes, or for conveying additional data increases risk without necessarily adding any value

*       If there is information to be included in certificates and not used by browsers, it creates not only risks of dependencies it creates risk in validation and also creates risks in replacement and revocation which is important for the security of the browsers.

From: Validation <validation-bounces at cabforum.org> On Behalf Of Stephan Wolf via Validation
Sent: Thursday, October 17, 2019 8:02 AM
To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Validation WG meeting minutes 2019-10-10

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 <mailto: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/20191021/ef168bd8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20191021/ef168bd8/attachment-0001.p7s>