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

Sun Oct 13 07:25:34 MST 2019

Ryan,

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

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. Your software is neither to crash nor could the LEI in any other way cause harm to the user, opening back doors, etc. The browser could simply ignore the extension and leave it e.g. to plugins to display any LEI. 

I also don’t see any security issues for the administration of servers. Any admin would still install the cert coming from a CA like they do today. I do not share any fears that the LEI extension could cause harm to the server and its administration. 

For me, the inclusion of LEIs is technically safe and sound, and in line with recommendations from the standard setters. I would like to leave it with the experts in this forum to come to a final conclusion.

In my opinion, your security concerns address a broader fear that the inclusion of the information could cause dependencies, procedural issues such as in data validation etc. I understand your points however I don’t share your opinion. Maybe it is simply fair to agree that we disagree. Please note, I am not a member of the CA/B Forum nor is GLEIF going to participate in any voting. Based on an invitation, I have just expressed my view with the hope that this group finds it helpful.

Thanks

Stephan

Von: Validation <validation-bounces at cabforum.org> im Auftrag von Ryan Sleevi via Validation <validation at cabforum.org>
Antworten an: Ryan Sleevi <sleevi at google.com>, CA/Browser Forum Validation WG List <validation at cabforum.org>
Datum: Samstag, 12. Oktober 2019 um 19:36
An: Stephan Wolf via Validation <validation at cabforum.org>
Betreff: Re: [cabf_validation] Validation WG meeting minutes 2019-10-10

On Sat, Oct 12, 2019 at 4:50 AM Stephan Wolf via Validation <validation at cabforum.org> wrote:

Hi,

Please see my remarks embedded in red. Hope this helps.

Thanks

Stephan

Von: Validation <validation-bounces at cabforum.org> im Auftrag von Doug Beattie via Validation <validation at cabforum.org>
Antworten an: Doug Beattie <doug.beattie at globalsign.com>, CA/Browser Forum Validation WG List <validation at cabforum.org>
Datum: Freitag, 11. Oktober 2019 um 20:58
An: CA/Browser Forum Validation WG List <validation at cabforum.org>
Betreff: [cabf_validation] Validation WG meeting minutes 2019-10-10

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, thus he didn’t believe there were any technical security issues with the approach
I said two distinct things. 
A) I gave a GLEIF use case. For all other use cases CAs should ask their customers. One example was given of a student’s plugin in the browser to retrieve data.
B) I asked Ryan several time if there were any security or technical issue associated with the inclusion of extensions. I never got an answer. The examples provide are of a different nature, e.g. concerns about validation, dependencies to 3rd party systems, etc. With regards to that I replied that this is the exact same with other EV related information such as business registry numbers. I concluded that there were no real security issues other than procedural concerns.

Hi Stephan,

I'm hoping you can clarify your remarks. I think it's important to separate out the feelings from what you said, or at least make it clear when you were expressing your feelings. For example, while it's true that you stated "you never got an answer" on the call, I provided a clear answer for you on the call. If we'd like the minutes to reflect that, and you were unsatisfied with the call, then we can totally go back to the recording, and I'd be happy to repeat that answer, which is that these fundamentally are security and technical issues.

Similarly, for the clarity of minutes, it might be useful to clarify when you state "I concluded that there were no real security issues", we can reword it here to express you made the statement. I certainly disagreed with you on the call about this, and provided details.

It might be that this approach to minutes isn't helpful for capturing that back and forth, and we should try a different approach to minutes if you're still unsatisfied, because I think it's important the minutes reflect that I responded to each of your points here. If you don't feel that was the case, we can probably reword these minutes to better show that, which might make it easier to see how it was.

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

·         ETSI and ISO are both pushing developing technical standards for LEIs in TLS certificates in general 

·         The question was raised if Ryan would suggest eliminating all identity information from TLS certificates. The answer was yes. This is not a discussion I could add anything. However, in case EV certificates continue to be used, the LEI adds an incredible value by providing an additional layer of trust, external verification becomes easier etc.

I don't believe this is an accurate reflection of the minutes or the discussion. I think it'd be useful to go back to the recording.

For the purpose of minutes, I don't think "This is not a discussion I could add anything" would be too useful, and I think your statement about my answer misses much of the important clarification and subtlety I provided. I can understand if that nuance was a bit hard to follow, and that's why going to the recording can help.

·         EV certificate data cannot change once issued, but LEI data can and thus will be more up to date and accurate. The LEI data can change outside the certificate e.g. in cases of M&A, bankruptcy etc.

I don't believe this was a point you raised on the call, and so I'm not sure it'd be appropriate to record in the minutes. It's certainly true that I expressed my own value statement and raised this, in the context of LEIs being required for CAs, but I think for the minutes, it's important to be clear about who said what, and in what context. You've certainly raised this on past calls, but we should make sure the minutes are accurate to what was said.

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.

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?

·         LEI is at least as valuable 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

o    Ryan replied that this isn’t tied to TLS and that perhaps the right location for this additional data in in DNS, it’s 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

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

·         What does it mean when including this in TLS certificates

·         What is the validation process

·         Etc.

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 in TLS certificates.  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 (Browses). 

·         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

o    Slows down issuance and replacement because the data needs to be accurate and up-to date

o    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

o    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

o    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

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

·         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 X.509 and how this specifies the important organization attributes:

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

o    X500 directory's never materialized

·         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

_______________________________________________
Validation mailing list
Validation at cabforum.org
https://cabforum.org/mailman/listinfo/validation

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