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

[Ryan Sleevi]

On Tue, Sep 24, 2019 at 10:37 AM Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> Also, the subject of this thread, and Kirk's last message state that LEIs
> would be added as an extension, but Tim's last ballot and my prior
> understanding of the proposal was that they are to be an option for the
> Subject:organizationIdentifier. Has that changed?
>

Kirk's seemingly confused, but so are you, I think? :)

With the PSD2 ballot, to support the existing profile for ETSI ESI, since
ETSI ESI made it clear they'd be unable to correct the technical issues in
a timely fashion, we allowed a temporary exception to include the VAT and
national registry numbers in the Subject:organizationIdentifier. This
information, however, must also be present in a certificate extension that
is specific to PSD2 at present, as specified in SC16.

Kirk's confusion likely results from the same confusion he had with respect
to LogoType, which Mozilla shared similar concerns on
mozilla.dev.security.policy, and Kirk was similarly seemingly frustrated
by. In that discussion, it was unambiguous (as a result of SC16) that other
Subject attributes could be used. However, when it comes to X.509v3
extensions, there's slightly more flexibility. The confusion, it seems,
results from noting that there are rules with respect to validating that
information and how it's asserted in a public context, specifically
designed to prevent CAs from stuffing "random things" into certificates
without there being a harm-reduction calculus by the browsers that trust
the CA's certificates. Much like LogoType is prohibited from such
publicly-trusted TLS certificates as used in browsers, so too would a LEI
extension.

However, on a technical level, expressing it within an extension is
sensible, if it can be determined that there's a valid use case, and that
there's a valid use case specifically for browsers.

Like PSD2, the original proposal was to place this information within the
Subject:organizationIdentifier. This presumption fatally ignores that the
Subject field is hierarchical, as it was envisioned to be used parallel to
the X.500 DIT used with X.400, in which ITU-T would oversee a global naming
service and publish all information. This design assumption is key to
concepts such as nameConstraints, for example, which constrain the
hierarchies.

Note that including a LEI (or a PSD2 identifier) in the Subject field would
have been as bad practice then as it was now; in a Subject world, the LEI
would have a top-level authority of the LEI ROC, followed by (optionally)
the LOU, followed by the LEI, all three of which would be distinct OIDs
within GLEIF's OID arc, and comprise the totality of the subject. That is,
following X.509, one would have done something like "O{or something like
it}=LEI, {oid for LEI}={LEI value}". However, this would have still been
anathema to X.509, since the certificate was just an indicator that the
holder of the key was used to modify the X.500 directory, which is where
all secondary information would be stored. Information would not be
expressed in the certificate, but the directory, and the certificate was
just a de-facto unique ID.

Of course, the X.500 DIT never materialized, and the issues with it are
well documented (e.g. RFC 2693, which represented a significant effort
within the IETF to sort out the ontological mess created by X.500). As a
consequence, folks got into the (bad) habit of trying to stuff database
information in certificates. This is counter to modern security practice,
which uses certificates to express capabilities (i.e. "can only be used for
TLS"), rather than store information about the key holder identity.

That said, if identity information is to be encoded in certificates, modern
certificates in an internet enabled world, particularly those used for TLS,
and especially for browsers, make use of the subjectAlternativeName, which
is more flexible than the Subject in that it allows scoping name types to
their use, as well as allows for the expression of constraints (via
nameConstraints). This is why domain names go in the dNSName, rather than
the commonName, for example.

For a "modern" LEI design, one would nominally not include the information
at all, as you highlighted. However, if the information was included, it
would be in a subjectAlternativeName, as an otherName, with a defined
constraint processing model if constraints are intended. Of course, if the
goal is to create or empower CAs to issue for any LEI, then the latter part
- the constraint model, is not necessary. As this constraint model was not
necessary for PSD2 - that is, any ETSI ESI-using TSP can attest to any
national registry, for example - then placing this information within an
extension, rather than the subjectAlternativeName, better highlighted the
constraint processing model and simplified the encoding by a few bytes.

This is what is meant by understanding the use case, because the design
space has significant implications throughout, and it's less practical to
list all the things that don't work, versus trying to understand the goal
and trying to highlight solutions that can work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190924/ea6fe58a/attachment.html>