[cabf_validation] [EXTERNAL]Re: Including LEIs as extensions in EV certificates

[Ryan Sleevi]

On Sat, Sep 28, 2019 at 10:01 AM Stephan Wolf <Stephan.Wolf at gleif.org>
wrote:

> We agree that
>
> - the LEI is a useful identifier for all kinds of uses cases, e.g. S/Mime,
> Code Signing etc. (I very much hope for your support when we tackle these).
>

To be clear: I don't think we've established this, nor even discussed this.
I think it's important that we not conflate these things, and let's keep
the discussion focused in order to keep it productive.


> - For TLS certificates, the LEI added as an extension (which was as well
> your recommendation several months ago) doesn’t cause any harm in terms of
> technical security, crypto algo, processing time, loopholes etc.
>

I do have trouble understanding what you're saying here, as I've not really
seen any contributions from GLEIF on this topic. Perhaps you can rephrase
what you're saying? If you're saying that the inclusion of LEI does not
impact the cryptographic strength of a certificate, then I don't believe
we're in agreement, because as you touch on later, you do not understand
the importance of agility, or how the inclusion of a LEI is a detriment to
that agility.


> We disagree
>
> - whether the LEI causes harm in the longer term. Wayne and you used the
> example of lowered agility for future developments or higher burden for
> obtaining a cert. In contrast, I am of the opinion that the LEI adds
> agility especially in those cases described in my last email. If used by
> CAs the way we discussed, it also doesn’t slow them down.
>

I'm afraid we're no closer to agreement on this with your latest message.
To be clear, GLEIF has not really articulated any use cases yet nor a
vision for how they can or should be used by browsers.

At a minimum, there is a validation step required. For example, I should
not be able to assert a LEI for the Global LEI Foundation in a certificate
for www.google.com - not only would that not make sense, but that would be
actively harmful to anyone relying on LEIs to be an assertion about the
domain name. So we know we need some step to validate that an entity
requesting a certificate is identified by a LEI, and we know it's simply
not sufficient for the applicant (e.g. "www.google.com") to say "This is my
LEI, please put it in". I do hope we can agree on that basic requirement?

If we do agree on that basic step, then it's clear that this is something
more than simply validating the domain name, and this is clearly something
that requires a human in the loop to actually validate and assert, which
makes automation or replacement that much more difficult. This should seem
undeniable, and thus it should seem clear to slow things down.

I've shared with you a number of technologies that would make such an
assertion problematic and questionable, to which you've not responded to. I
can understand a lack of familiarity with the technological concerns, but I
do not believe it appropriate to simply dismiss them as inconsequential. We
must engage on substance if we're to make progress.


> - I understand your mails also as an expression of concern that the
> industry, and the browser vendors in particular, become dependent on an
> external source. I do not believe that such a dependency exists. However,
> even in case you feel this way please acknowledge that the LEI is the
> trusted identifier by the G20, the FSB, over 80 regulators and embedded in
> over 150 laws globally.
>

Could you highlight where this concern was raised? I've not seen this
raised by anyone, and so I am quite concerned that if you believe this is a
concern, then some of the more basic points of the messages may be deeply
misunderstood. If you can highlight the message(s) you feel that there's
concern about external sources introduced, I would greatly appreciate
correcting that misunderstanding.


> Please allow me not to comment any more on all arguments triggered by past
> issues. Neither the SHA nor the Symantec example fit here. For me this is
> more an expression of a general discomfort.
>

I'm afraid that, without acknowledging the substantive decades-long
experience of stakeholders, you are largely saying that you will ignore the
feedback from those with the experience you wish to learn from. That's
unfortunately a good way to shut down conversation, if there's no regard to
learning or appreciation for understanding the concerns.


> However, in case the Forum votes “pro LEI in TLS certs”, I do not believe
> that you would have sufficient justification to block these certs, to
> declare them invalid or untrusted.
>

Unfortunately, this lies the heart of the misunderstanding, despite
repeated efforts to correct. The Forum is a discussion group for the
collaboration on ensuring conflicting Root Program requirements are not
introduced. It does not, nor has it ever, defined either policy or what is
secure or acceptable. The reason, for example, that our requirements are
called the "Baseline Requirements" is that they reflect a common minimum,
not necessarily something secure or desirable.

Could I encourage you to perhaps review a recent presentation by the Chair
of the Forum at the CA Day 2019?
https://cabforum.org/pipermail/public/2019-September/014766.html

It's important to understand: Browsers, such as Google, Apple, Microsoft,
and Mozilla, engage in direct, 1:1, contractual relationships with CAs to
define their hierarchies. If you're not familiar with PKI, it might be best
to think of each of these as separate PKIs: Google defines what the Google
PKI is, Apple defines what the Apple PKI is, etc. Each of these Root
Programs are responsible for supervising the CAs that they trust (if any),
including what can and cannot be issued underneath the hierarchies that
they trust. Each of these are a vendor relationship.

Again, it's important to note: There's no requirement that any of these
companies use third-party CAs. It's wholly possible, on the technology, to
use first-party CAs (as we see with code-signing in popular app stores, or
in hardware drivers), or to use alternative PKIs (such as the DNS PKI). The
choice to use third-party CAs, by browsers, is a choice of convenience, not
because it is technologically better for security (in many ways, it's
worse).

Functionally, it should be thought of each browser defining their own
profile. This is not a difficult concept to grasp: it's incredibly similar
to how each browser defines their own profile about what web technologies
to use and implement. We regularly see browsers adopt additional
restrictions or deviations in Web technologies: for example, Apple's
Intelligent
Tracking Prevention
<https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/> series
of changes to Safari restrict a whole host of "standard" technologies in
order to better protect user privacy. Similarly, Mozilla Firefox's Third-Party
Cookie Blocking
<https://blog.mozilla.org/blog/2019/09/03/todays-firefox-blocks-third-party-tracking-cookies-and-cryptomining-by-default/>
similarly
redefines and restricts how various Web technologies work. These are
specific to individual products, in the furtherance of their product
security and privacy goals.

Similarly, sometimes browsers don't implement the same features, because
they might have concerns about the security or compatibility. Just because
a 'standard' exists, it doesn't mean browsers are expected to implement and
ship it, especially not in some coordinated fashion. For example, browsers
decided to remove support for TLS 1.0 and TLS 1.1, even though sites were
using it, in order to better protect their users (Apple
<https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/>,
Google
<https://security.googleblog.com/2018/10/modernizing-transport-security.html>,
Mozilla
<https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/>,
Microsoft
<https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/>
).

The choice with certificate profiles is no different: Browsers make
individual choices about what to support, or not to support, based on their
product security goals. The design of PKI - from the 1990s to present - is
that each "Root Program" defines their own certificate profile. The entire
existence of auditing, as a PKI practice, was about assessing compatibility
between profiles, and ensuring that the consumer of the audit (the Root
Program) could be confident that the practices of the CA were fairly stated
and that those practices would not cause compatibility issues. If they
would, the Root Program would reject that CA.

Just like browsers reject connections using SSL3 as insecure, or TLS 1.0 or
1.1 as insecure, it's perfectly reasonable for browsers to treat
certificates with unsupported extensions as insecure, and it's perfectly
reasonable for browsers to prohibit the issuing of those certificates from
underneath Root CAs that participate in their program. If the CA
organization wants to issue such certificates, they need to use a different
Root CA, not trusted by that browser, to do so.

When the Forum puts something to a vote, and potentially adopts it, it does
not, nor can it, mandate browsers support it. It's no different than, say,
a voluntary standard published by ETSI, by IETF, by the W3C, or by any of
your favorite standards organizations du jour. It's descriptive, not
normative. However, unlike those other organizations, the criteria used by
the Forum are used to develop audit standards which, presently (and this
has changed over time), browsers accept. If the audit criteria accepted
something that the browsers rejected, that only serves to devalue the audit
criteria, and may lead to audits being rejected.

A good example of this is the ETSI EN 319 * series of audit criteria, used
by a number of European CAs. The assessment criteria (since it's not really
an audit) use a period of two years, rather than what Root Programs require
(and what the BRs capture) as 1 year. This has lead to multiple audit
reports from European auditors being rejected, because they do not align
with the Root Program requirements, even when the Baseline Requirements say
the audit criteria is acceptable.

Hopefully this further emphasizes why the Baseline Requirements do not, nor
have they ever, dictated what Root Programs find acceptable, and the
decision to accept or reject a certificate, or to prohibit the issuance of
such certificates in hierarchies trusted by those Root Programs. If CAs
organizations wish to issue such certificates, they can - but not using any
of their publicly trusted certificates included in browsers.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190928/295f15a2/attachment.html>