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

[Ryan Sleevi]

On Fri, Oct 11, 2019 at 2:58 PM Doug Beattie via Validation <
validation at cabforum.org> wrote:

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

Thanks Doug. That was a rollicking discussion and I appreciate your
attention to capturing many of the points and counter-points. A few various
notes inline, along with some parenthetical context (not for the minutes)
to just follow-up with details from the call.


>
>
> 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
>
> o    Ryan commented that this was a good example for where non publicly
> trusted certificates would sufficient.  More on this below
>
Ryan said he had responded on-list about this, and had commented that this
was a ...

(For reference, this was
https://cabforum.org/pipermail/validation/2019-September/001326.html and
https://cabforum.org/pipermail/validation/2019-September/001331.html )

·         ETSI and ISO are both pushing for LEIs in TLS certificates
>
> ·         LEIs add an incredible value
>
> ·         EV certificate data cannot change once issued, but LIE data can
> and thus will be more up to date and accurate
>

typo: LEI

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
>

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.


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

in DNS or in a well-known location (This is covered more at
https://cabforum.org/pipermail/validation/2019-September/001343.html )


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

typo: 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
>
> 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
>

In addressing the topic of ITU-T and X.509, and how distinguished name
attributes were designed and specified:
.... (the existing two bullets you have)
* 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.

(For those following the minutes / discussion, there's a long thread about
the history at
https://mailarchive.ietf.org/arch/msg/pkix/nWgnNZHh2w2l-WfbHKozpm2IWcQ but
you can specifically see statements like
https://mailarchive.ietf.org/arch/msg/pkix/we0XqK42bGXaTzt9ixfy_MzHlM8 and
https://mailarchive.ietf.org/arch/msg/pkix/icAhX49EDqT3AJADiRWckr1teTk to
help emphasize that it's an either/or proposition with ITU-T's X.509 or RFC
5280 )


> ·         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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191011/1b2c4d7b/attachment-0001.html>