[cabf_validation] Including LEIs as extensions in EV certificates

[Ryan Sleevi]

On Sun, Sep 22, 2019 at 7:10 PM Stephan Wolf via Validation <
validation at cabforum.org> wrote:

> Please allow me to summarize GLEIF’s position on including LEIs as
> extensions in EV certificates – GLIEF is in strong support – based on
> Google’s comments during the Validation Subcommittee teleconference on
> Sept. 12.
>

Unfortunately, the most important part, for which our hour on the call
failed to identify, is that you do not identify for what purpose.

This is essential to making any forward progress, and until GLEIF is able
to provide a clear statement of purpose and use case, for browsers, in the
use of TLS, which has a host of nuances and complexities in browsers.


> To my knowledge no browser vendor has ever rejected a standard or process
> that was adopted and approved by the CA/Browser Forum (by a ballot and
> approval of 2/3 of CAs and a majority of browsers). I am used to work with
> other standard setting bodies and always appreciated the clear rules given
> to the members. I also understand that this is relevant for the audit
> program, as it was rightfully pointed out.
>

I'm afraid this still is greatly confusing the purpose of the Forum. You
can read more within our Bylaws at
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v2.2.pdf ,
which GLEIF just agreed to when joining the Forum.

I've highlighted some choice points:

The Certification Authority Browser Forum (CA/Browser Forum) is a *voluntary
gathering*
The Forum has no corporate or association status, but is simply a group of
Certificate Issuers and Certificate Consumers that communicates or meets
from time to time to discuss matters of common interest relevant to the
Forum’s purpose. The Forum
*has no regulatory or industry powers over its members or others. *

The Forum has never, in its history, defined the rules for CAs or for
browsers. These have always been matters of private contract between Root
Programs (typically, browsers), and the CAs for which they delegate the
issuance of certificates to. For many PKIs, delegation to third-parties is
not practiced at all; for example, the code-signing platforms of Apple and
Google do not employ the use of third-party CAs, nor do the hardware
certification programs of any of the vendors within the Forum, even though
both also use certificates in PKI.

The Baseline Requirements, while developed by the Forum, were standards
that no CA followed until required so by Root Programs. Root Programs
regularly apply unilateral restrictions within their Root Programs, as they
compete on areas like security and respond to changes in the security risks
to the browsers users. The Forum exists to promote discussion, but the
relationship between browsers and CAs, as it does in quite literally every
public and private sector PKI, remains a matter of private agreement or
certification between the participants.

The choice of what certificates a browser recognizes are, like any other
voluntary standard, just that, reflecting the needs of that particular
software product, its users, and its risks. There is no concept of "The
PKI" - Public Key Infrastructure was designed to be many entirely separate
PKIs. Your standard IPhone or Android device will, in the process of
booting, no doubt leverage dozens to hundreds of entirely disparate PKIs,
ranging from the PKI of the firmware used to securely boot the device to
the authentication of the device's peripherals. PKIs are disparate based on
purpose and community.

No two browsers in the Forum have an exactly identical set. This reflects
the needs that they have different security requirements and goals, and
thus operate their Root Programs separately. This is a feature, not a bug,
reflecting the differences in markets these browsers compete in, the
different use cases their products support, and the different needs of
their different use communities.

It's important to understand that there is no technical reason for browsers
to use CAs or certificates at all. Alternative technologies exist, such as
DANE, which allow the binding a domain name and a public key without
needing to involve a CA at all. Similarly, as demonstrated by the above
scenarios regarding code signing, browsers could also operate the CAs their
users use themselves. This is not a threat, it is a reiteration of how PKI
was designed and intended to be used for. There is no existential mandate
to make use of third-party CAs, but when they are used, it's through
voluntary choice by the CA to ensure their products interoperate with the
browser.


> My understanding of the formation of the Forum was always about adopting
> “best practices” by strong consensus of the CA and browser community,
> acting cooperatively and by consensus.
>

Your understanding is incorrect.

The Forum provides a venue to ensure Browsers do not place conflicting
requirements on CAs that voluntarily participate within the browsers root
programs, by facilitating discussion and feedback. This allows
interoperability among the Web PKI space, which refers to the set of CAs
within browsers, and thus allows easier interoperability within browsers.
Prior to the Forum, it was much easier to see this reflected in the private
arrangements between CAs and browsers. If different browsers had different
requirements, CAs would have to act as the intermediary to identify and
communicate those conflicts. Similarly, browsers had to spend significant
effort working to communicate with all of the CAs in their programs, often
repeatedly answering similar questions. By arranging a common mailing list,
and periodic meetings, those barriers to communication can be reduced.

That is the sole and only purpose of the Forum. Any other suggestion is
ahistorical and not reflected in the past or present activities.

Within the Forum membership, there are a number of CA members which have
had their certificates rejected for trust or been actively distrusted. It
does not seem it would be aligned with "best practice" to suggest those for
which a browser vendor does not trust should be the ones deciding what
browser vendors should trust, does it? T

Policies are set, first and foremost, through browser Root Programs. The
purpose of the Baseline Requirements is to enshrine methods of meeting
those various Root Program requirements, and, more practically, to serve as
a template for the development of audit criteria that may be used by
individual Root Programs to assess compliance.

This again is fundamental to PKI since its introduction. In a historic view
of PKI, the one imagined by the ABA and reflected in the contemporary
reports produced in the late '90s and early '00s, each Root Program would
operate their own audit programs, with their own audit criteria, and
typically directly perform the audits themselves. Such a matter is
expensive, and so it's only natural that the cost of such a program would
and should be passed on to any CAs wanting to be certified. This practice
was readily adopted by a number of governments, who adopted their own
government-specific PKIs back then. However, this represents an
exponentially more expensive proposition for CAs, and thus CAs have
self-organized for the development of the Baseline Requirements, just as
governments look to develop interoperable criteria and schemes. CAs that
demonstrate compliance can reduce their costs substantially.

None of this is fundamentally required by a Root Program. Originally,
audits were only a minor part of a Root Program compliance, with much more
being placed on contractual due-diligence and business relationships. In
time, audits grew to be more prominent, as Root Programs looked to reduce
their operational costs, which were being passed on to CAs. However, as
ETSI and WebTrust can attest, Browsers have raised a number of concerns
about the quality and assurance of the audits performed by their members,
and have suggested that we may be better returning to a Browser-overseen
audit scheme. Certainly, there are ways to do so affordably, but with
greater assurance of compliance.

However, audits alone have never been sufficient for trust, nor have the
Baseline Requirements, for which the audits are based upon. Root Programs
make a determination, both based on the Root Program requirements they have
set forth, as well as their own individual policies about what sort of
organizations they enter into a contract or agreement with. The
relationship between a browser, the certificates it accepts, and the CAs it
recognizes, is inherently a private affair, much as it is any other vendor
relationship that software suppliers deal with: contractors, outsourcers,
physical security vendors, etc.

Perhaps a better comparison, to help drill this point down, is that
browsers are voluntarily and intentionally removing support for TLS 1.1 and
TLS 1.0. The IETF has not moved these documents to Historic. There are many
communities that still accept these protocols. There are many devices that
/only/ support these protocols, and thus will be left inaccessible as
browsers do this. And browsers are still doing it, because it's in the
interest of the security of their users, and such interoperability is
actively harmful to their users. Certificates are the same, whether we're
talking lifetimes or LEIs.

Google has said it thinks EV certificates that including LEIs as extensions
> in certificates would be actively harmful to the ecosystem, and to the
> security of Chrome’s users.  But there is more at stake than just Chrome
> users – in fact there is a vast stakeholder group with an interest in
> having LEIs in EV certificates. Merely everybody participating in any form
> of e-commerce (and many other use cases) must have a vital interest in
> understanding whom they are doing business with.
>

GLEIF has made this position known, but provided scant technical detail.
Google has attempted repeatedly to help GLEIF understand, and it's
interesting to see this posted without any acknowledgement of those
efforts, nor any progress towards achieving that understanding.

The Baseline Requirements are not intended nor primarily developed for the
use of server-to-server TLS certificates, for example. The requirements of
payment terminals and TLS, for example, are handled by PCI. The
requirements of wireless authentication servers are handled by the Wi-Fi
Alliance. Both systems are voluntary. Similarly, there is no requirement
that binding information to a domain be accomplished through TLS
certificates; in many ways, this actively harms the agility of the TLS
ecosystem.

If GLEIF were to demonstrate how it such information will be used, and not
merely that it will potentially be used, we remain committed to helping
GLEIF finding a technical solution that is in line with modern security
practices, and not based on an antiquated view of technology that
originated within the ITU-T in the 1980s and never materialized (the X.500
DIT).

That is something completely different than adding an extension with an
> alphanumeric value. X.509 explicitly supports these extensions. Any user –
> including the Chrome browser – could simply ignore the information. On the
> other hand, if Google would say that Chrome cannot easily handle
> extensions, I would consider this a major design flaw within Chrome.
>

This fundamentally misunderstands the role of certificates.

Adding information that is not used by browsers is actively harmful to
browsers and the agility of the ecosystem.

This is because non-browser consumers come to rely on this information.
When it comes time to make changes, in order to enhance the security of
users when they browse the web, site operators and CAs complain that
changes would break such non-browser use cases. However, it is wholly
inappropriate to cater to these non-browser use cases for precisely that
reason. PKIs were designed to be robust, and if the use case is, for
example, server to server communication, it can and use a separate PKI,
rooted in separate trust anchors, to express this difference of information.

This is quite literally why the concept of PKI audits was introduced: to
accommodate there being different trust anchors, used for different
purposes and different communities, and to allow the careful choice of
interoperability.

The inclusion of this added information, if not directly used by browsers,
is thus actively harmful to the agility of the ecosystem. The solution is
to ensure that such PKIs do not overlap, by either ensuring that such
certificates are not TLS certificates, much as browsers, in
contravention/extension of the Baseline Requirements, already require for
e-mail or code signing certificates through the use of Extended Key Usages.

The issues that GLEIF rejected unfortunately reflect that misunderstanding,
about the harm of having a single Unified PKI as opposed to how PKI was
designed and is operated: as a network of separate PKIs. SHA-1 deprecation
was not a matter of replacing the server certificates: the issues mentioned
first and foremost were due to the fact that, despite browsers having
supported SHA-256 for some time, legacy (unsupported) software and
non-browser use cases (like payment terminals) did not. Similarly, the
discussion of underscores or internal server names was because the systems
using these certificates needed to interoperate with other, non-browser
cases. The challenges in distrusting Symantec certificates were, similarly,
largely not due to browser compatibility (of which many comparable CAs
existed), but because a number of Symantec customers had coded non-browser
using applications to only expect Symantec certificates. In all of these
cases, the choice was clear: interoperate with browsers, or interoperate
with legacy systems, but you cannot do both simultaneously.

In order to prevent customers from needing to making such choices, which
only come up when things have truly gone wrong, it's best to prevent such
accidental interoperability as early on as possible. Unless and until there
can be a clear demonstration about the specific use cases intended for
browsers, and technical alternatives explored, there's no value in
discussing or proposing further changes.


> The question was raised, if GLEIF itself should issue LEI certificates
> from non-trusted roots as an alternative to including LEIs as extension in
> EV certificates?  In a word, no.  GLEIF is an organization managing a
> network of LEI issuing partners. Several LEI issuers – so-called Local
> Operating Units (LOU) - are already certified CAs. Since GLEIF itself is
> not issuing LEIs, the idea of GLEIF issuing special non-trusted LEI
> certificates does not make sense. Our role is to be the guardian and
> gatekeeper of the rules and policies defined for the global LEI system. We
> derive this authority by mandate of the G20. The Financial Stability Board
> (FSB) is our founding member. Our statutes clearly state what our role and
> duties are. Becoming a commercial entity is not possible(
> https://www.gleif.org/en/about/governance/statutes).
>

GLEIF functionally is a trust hierarchy, using powers derived from the LEI
ROC to oversee the GLEIF Index and the LOUs. This is exactly what PKI is
meant to technically express. GLEIF removes information when it's
challenged - this is conceptually the same as revocation. GLEIF recognizes
LOUs on the basis of criteria for the issuance of LEIs - this is
conceptually the same as certification. LOUs issue LEIs - this is
conceptually the same as issuance.

In classic PKI terms, the LEI ROC acts as a "Policy Management Authority",
overseeing GLEIF, which is functionally the CA.

The benefit for such an approach, which is exactly what PKI was intended to
facilitate, was that it avoids entirely the necessity of relying on
browsers to try and oversee the correct association of LEIs, domain names,
and keys, which is essential for there to be any value in expressing LEIs
in certificates.

This is not sophistry: Within the IETF, multiple working groups, including
the TLS and JOSE working groups, are moving to other PKIs other than those
used by CAs, in order to support new and interesting use cases. The use of
TLS Delegated Credentials, for example, wholly avoids the X.509 certificate
syntax, even though it is used to bind public keys to connections. There is
no technical reason to use an X.509 approach for these cases, and it's both
more secure and more flexible to avoid doing so.


> In addition, the LEI nor GLEIF are not supposed to create a new trust
> hierarchy sitting next to all others. We don’t see the sense of that. On
> the contrary, the LEI should be embedded in other eco systems for the
> greater good. I would like to state that LEI adds another layer of trust to
> EV certificates.
>

Without the demonstration of how it will be used, it can be shown, based on
the proposal, that LEIs reduce the trust in certificates, by highlighting
conflicts between the information encountered in the certificate, as well
as creating more opportunities for validation failures.


> There is no benefit requiring applications to add a step: (1) first read
> EV data, and then (2) use that data to do an LEI look-up every time you
> want to find an organizations LEI.
>

As noted above, the core reason is to ensure that non-browser dependencies
are reduced.


> Other than that, I would suggest not talking about “use cases” for LEIs in
> EV certificates – some have already been outlined during our Validation
> Subcommittee call, and there could be many more – so the case has been made
> already.
>

Unless and until GLEIF does so, there can be no productive conversation,
because GLEIF is unwilling to engage in meaningful dialog.

We remain committed to helping GLEIF finding solutions, but that requires
some degree of good-faith engagement by GLEIF, which messages like this
unfortunately harm that perception. On the call, as shown in the minutes,
neither GLEIF nor Entrust DataCard, who appears to be a primary supporter
of LEIs, could demonstrate the use case.

I think this is essential. You're asking browsers to interoperate with
LEIs, which comes with significant risk of harm by being used by
non-browser applications. Unless you can ensure that such information will
not be used outside of browsers, it remains actively harmful to the
security of browsers. If the primary purpose is to use it outside of
browsers, such as for code signing, then this is the wrong working group:
this working group explicitly does not discuss code signing, by charter.

There's no reason to expect browsers to modify their Root Programs to
permit such certificates, nor is it reasonable to suggest browsers should
interoperate with PKIs that do issue such certificates, as a consequence,
when such information only carries with it risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190923/c730cf3b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1891 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190923/c730cf3b/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1926 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190923/c730cf3b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 6006 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190923/c730cf3b/attachment-0005.png>