[cabf_validation] Minutes of the August 29, 2019 Validation Subcommittee Call

[Ryan Sleevi]

Thanks, Dean.

Having carefully read that document, I don't believe it answers any of the
questions we have regarding the value proposition. A specific and
quantifiable concern is with respect to encoding this information within a
TLS certificate.

A substantive concern here is that a TLS certificate, first, foremost, and
in the context of browsers, exclusively must address the domain namespace
as the primary identifier, for the purpose of binding a public key and
domain name. Alternatives to TLS certificates, such as DANE, functionally
do this as well, by using an alternative expression (within the domain name
system). Adding additional namespaces, such as an LEI, creates significant
challenges and risks, which we already see within the OV/EV certificate
space, such as the discussion of certificate lifetimes and validation.

If the objective is to bind a domain name to other identifiers, rather than
another public key, there are many ways of expressing this, still using
certificates, but without requiring that they be bound within the TLS
server certificate. Indeed, extensions to TLS exist precisely to provide
for binding external authenticators or identifiers to the TLS session.
Perhaps the most widespread example of this is the notion of "TLS Channel
Bindings", which Microsoft has long integrated within their core Windows
authentication stack, to allow Kerberos and NTLM authentication
technologies be used, and still strongly bound to the TLS channel.

Thus, I think the substantive question remains to ask: Why does this need
to be addressed within the TLS layer, given that many superior
technologies, which wholly avoid the compatibility and interoperability
issues, are readily available? I am hoping that GLEIF will be able to have
answers that compare and contrast the alternatives considered.

Again, this is not an objection to the notion of using certificates (as an
abstract) to bind to identities or other namespaces. After all, S/MIME
certificates are widely used and have no such binding to a domain name
(instead, they bind to an e-mail address), and document signing
certificates are widely used where the only binding is to the legal
identity. This is, fundamentally, a question about the technology space,
and about the intersection of two ostensibly incompatible technologies.

To further help illustrate this, in advance of our call:
- If GLEIF intends for the LEI identity to be the primary thing that a
relying party TLS client identifies their peer by (i.e. for server to
server communication), there is no need to make use of the id-kp-serverAuth
EKU, nor, for that matter, to encode within the domain name itself. If the
TLS client is explicitly intending to talk to a TLS server identified by a
given LEI, they may readily use a different EKU to indicate this
authentication technology and method, and encode the LEI in any number of
ways. The peer can then verify it's talking to the "expected" LEI.
- If this is intended to allow communication with a variety of LEI
entities, then there are ample technologies for providing that LEI, or that
LEI<->domain binding, independent of the TLS server certificate, and in
ways that are more robust and secure.
  - For example, rather than relying on TLS server certificates, GLEIF
could issue certificates directly and/or run their own root authority
program, continuing to use a distinct (i.e. non-id-kp-serverAuth) EKU.
  - These certificates could be exchanged in a manner appropriate to the
S2S protocol; for example, if using HTTP as the protocol, fetching a
hypothetical resource /.well-known/gleif/v1 "resource" could return a
signed attestation, which incorporates the TLS channel bindings if
necessary (e.g. if intended for session authentication vs domain assertion
authentication), using a certificate issued to that LEI by GLEIF or their
approved CAs
  - Such an approach would also work for a S2C/B2C scenario, such as to
custom applications (e.g. a user's banking application)

In these models, the robustness and agility of the TLS ecosystem, and its
assertions based on domain, are not impacted, and such solutions readily
interoperate with the existing ecosystem. GLEIF would not need to deal with
the CA/Browser Forum at all; such certificates, by virtue of not being
id-kp-serverAuth and instead a GLEIF-specific OID, could be fully overseen
by GLEIF and the LEI ROC, allowing GLEIF the agility it has already
demonstrated in the oversight of the Global LEI System.

If used for client authentication scenarios, such as the eIDAS references
in the document, in which a client authenticates to a server, there is
similarly no need to deal with the CA/Browser Forum at all, provided that
such certificates do not contain the id-kp-serverAuth EKU. Such
certificates would interoperate already with the ecosystem without any
modifications needed, and could use a profile wholly overseen by GLEIF.

All of this is, of course, contingent upon understanding that with respect
to id-kp-serverAuth, such an EKU is first and foremost bound to the domain
name, and that introducing additional, alternative naming types, which are
not themselves directly maintained by the domain name system or its
dependencies (e.g. through the addition of dNSName, iPAddress, or sRVName
SANs), is incompatible with and likely to be detrimental to the existing
security and stability of the ecosystem.

This is not a response specific to GLEIF, and is similar to discussions
with a number of other entities that wish to add additional identifiers to
certificates. In general, any presumed benefits of encoding within TLS
server certificates are likely to be unrealized, due to how the TLS
protocol itself works, while there's known and demonstrable harm to the
ecosystem due to the lack of agility imposed by the additional verification
overheads and responsiveness.

With this context, I look forward to speaking with GLEIF, and any other
entity desiring LEIs or other identifiers in certificates, to better
understand their use cases and objectives, and to collaboratively identify
solutions that help truly find the best of both worlds, and that not only
remain interoperable with existing systems, but leverage the best of the
systems we have while bringing new value forward.

On Fri, Aug 30, 2019 at 1:31 PM Dean Coclin via Validation <
validation at cabforum.org> wrote:

> FYI-With regard to the LEI ballot, a GLEIF rep has agreed to attend the
> next call as an invited guest (per the discussion on the call). In
> addition, they have provided the attached for some background reading.
>
>
>
> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Wayne
> Thayer via Validation
> *Sent:* Thursday, August 29, 2019 11:59 AM
> *To:* CA/Browser Forum Validation WG List <validation at cabforum.org>
> *Subject:* [cabf_validation] Minutes of the August 29, 2019 Validation
> Subcommittee Call
>
>
>
> Attendees: Tim Hollebeek, Tim Shirley, Ryan Sleevi, Dean Coclin, Shelley
> Brewer, Arno Fiedler, Bruce Morton, Li-Chun Chen, Daniela Hood, Joanna Fox,
> Janet Hines
>
> 1. LEI Ballot
> Tim: Ryan had a bunch of comments.
> Ryan: worth it to rehash here. There is definitional stuff that’s not
> essential.
> Ryan: Two main issues: If you have an organization, how do you determine
> the org is associated with the LEI? Second, do we have a clear value
> proposition? There is enough info in existing certs for a relying party to
> map it to an LEI.
> Tim: Start with second question. We can get the GLEIF people to share
> their motivations.
> Ryan: They want user to be able to click on LEI in certificate UI and
> access the information they maintain. But that’s not what we’re discussing
> - that would be a URL.
> Tim; Browser UI considerations are completely out of scope of the Forum.
> Certs already contain a lot of info the browsers don’t display in their
> UIs. Better to focus on ability of CAs to validate info put in a
> certificate.
> Ryan: Is adding more info to a cert good or bad? More info can reduce
> agility. Second, there isn’t additional work from the CA. You can use the
> info in the certificate to find a unique mapping to an LEI. So is the extra
> info in the certificate useful?
> Tim: without LEI in the relying parties must properly perform the
> matching, and there is nuance to it. I would like to let the GLEIF folks
> explain why it’s valuable rather than relying on second hand
> characterizations of their motivations.
> Ryan: agree that we want to hear from GLEIF. However, in all the scenarios
> that have been presented, the relying party is going to go look up the
> organization in their database. That’s not much different than using the
> existing info to perform the lookup.
> Ryan: the concern is that there is a cost in terms of agility, without a
> clearly defined benefit. I’d like to know how the GLEIF folks envision this
> information being used by actual relying parties.
> Tim: Direct match again identity is one example. Let’s get the GLEIF folks
> into the discussion. I’ll ping them, perhaps get them on the next call.
> Dean: Stephan Wolf would be an invited guest to the Validation WG.
> Ryan: They can also respond on the questions list or on GitHub.
>
> 2. Method 6 Ballot
> Doug isn’t on the call. No discussion.
>
> 3. Certificate Lifetime Ballot
> Ryan: The reasons that DigiCert provided for certain dates that are
> difficult are incredibly valuable. If others have data on good things that
> will be impacted by the timing of this ballot, now is the time to bring
> them up.
> Tim: If this is really part of a multi-stage process, it would be good to
> start discussing later stage timing now so that people can start planning
> and justifying now.
> Ryan: I totally agree. Gerv shared the desire to further reduce 2 years
> ago. I want to get to a point where we can further reduce, but I don’t have
> a timeline. I want to get the current lifetime down to address the pain
> felt from recent incidents. I also see major challenges to further
> reductions. I see further reductions of lifetimes as a longer term goal.
> Reducing data reuse is another thing. We can and should reduce domain
> validation intervals further in the future. The reduction to 1-year does
> not require automation or some of the bigger changes that shorter lifetimes
> will require.
> Tim: One thing I’ve been confused about - you often speak of challenges to
> CAs, but it’s the subscribers who have the problems.
> Ryan: I’m talking about 2 things. More frequent OV/EV org validation is an
> issue for many CAs. Challenges to subscribers are more about reductions
> below one year. Subscribers that are challenged by replacing a cert once a
> year are also a problem for ecosystem agility. I’m not sympathetic to that.
> SHA-1 deprecation, serial number entropy, underscore issues show the need
> for subscribers to be able to make changes.
> Tim: thank you. Any other comments?
>
> 4. Any Other Business
> No other business.
>
> Call ended.
> _______________________________________________
> 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/20190830/ca8fbc14/attachment.html>