[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Thu, Oct 24, 2019 at 4:55 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> Fixed via the correct reference to Annex IV of the Regulation.
>

I don't think it changes the concerns in any palpable sense?

Annex IV doesn't require the use of X.509 TLS certificates, and there's
plenty of compelling reasons not to use X.509 TLS certificates. Whether you
view it as intentional or a bug, the absence of validation data being an
essential part of a QWAC is incredibly useful for ensuring the technical
neutrality AND the robust possibility of using QWACs in a multitude of
systems, and that coupling to TLS is explicitly the sort of stuff that
Recital 27 is trying to avoid.


> Forbidding this attribute in CA Certificates will make it impossible to
>> add the "registration number as stated in the official records" to the TSP
>> Certificate.
>>
>
> This is categorically not true. Because you stated it's "impossible", it
> unfortunately requires me to show why you this is factually false:
> 1) The eIDAS Regulation is technology neutral with respect to the
> approach, and does not mandate the use of the ETSI standards, even though
> in the case of Electronic Seals and Signatures, it grants a presumption of
> compliance with the Regulation
> 2) Within the context of the ETSI profile, one can still issue such
> certificates using the profile defined by ETSI, and simply not doing so
> from the BR-compliant hierarchy
> 3) Even absent that, the issue is not that it's impossible, rather, that
> it's incompatible with the ETSI-specified profile. ETSI can, and does,
> change profiles, and can, and could, do so here.
>
>
> This is the real world we are discussing. These are decisions and
> implementations that are already out there. These are requirements that
> Supervisory Bodies are using to assess compliance with the Regulation.
>

This is still a bit of a misstatement. They're /some/ of the requirements
that /some/ Supervisory Bodies are using.


> I understand your arguments and theoretically you are correct. One could
> include this registration number in an extension, in a ledger, on a public
> web site URI even in an LDAP server.
>

I'm glad we agree here. There are other options, and you aren't limited,
today or in the future.

I think this is important to recognize that the technological neutrality of
eIDAS is exactly what makes it useful; there's nothing requiring you to
adopt a particular technology to fulfill the requirement, and the whole
point of technology neutrality is to recognize particular technical
implementations come with tradeoffs.


> However, all the regulatory authorities have received guidance to follow
> ETSI's recommendations which currently point to the organizationIdentifier.
> Why do we have to continue fighting over this?
>

Because hiding behind eIDAS, when the issue is with ETSI, is
counter-productive. To the extent that ETSI continues to specify things
that are in opposition with the Baseline Requirements, we're going to
continue to have issues, and "But ETSI did it this way" isn't a compelling
argument. The barriers to participation in ETSI alone are reason to be
concerned, but the assumption that it has to be tied to a specific
technical implementation only penalizes TSPs unnecessarily. To the extent
ETSI presumes that TLS certificates are the idealized form of QWACs is
merely a reflection of some CAs' interests and influence; they're
completely ignoring the changes in the technology space that 1) benefit
from QWACs not being TLS certificates 2) allow QWACs to be used far more
widely than they are today, to provide far greater assurances than they do
today.

Supervisory Bodies are not obligated to use the ETSI criteria. There's
presently no presumptive assumption of compliance with eIDAS with respect
to QWACs as there is with QSeals/QSigs, as Supervisory Bodies make that
determination and the Implementation Decisions and Acts define. From
speaking with various CABs and NABs (I promise you, I care deeply about
eIDAS and have done my homework), there is a vast variety of schemes out
there, which while they may use some or most of ETSI with variants, means
this isn't the dire straits you pose it as. The flexibility you have in the
selection of your CAB - and the flexibility the CAB has with respect to the
selection of the scheme used in the production of the CAR for the SB -
means you really aren't as hamstrung as being suggested.

This continues to be a challenge to the extent that some members continue
to promote melding multiple PKIs, with substantially different objectives,
into a unified hierarchy. That's neither good nor necessary. Recall that
some of the most significantly disurptive misuses of PKI - DigiNotar and
Flame - were the direct result of unified PKIs. A number of CA members of
this Forum have taken that lesson to heart - I can point to alt-Roots used
for a variety of specialized services - and that's exactly the lessons we
should be taking.

Continuing to cultivate the Gros Michel of PKIs is only leaving greater
exposure to the Panama disease of PKI, and we need to better diversify, not
simply saying "Well, Cavendish will do". It's learning all the wrong
lessons.


> Let me rephrase:
>
> "This community has not reported to have seen any harm (let alone "ample")
> caused all these years by having organizationUnitName, stateOrProvinceName
> or localityName subject attributes in CA Certificates. HARICA has seen not
> seen errors or warnings or has had any complains about delays or other
> problems from Relying Parties or Subscribers. I am sure other CAs would
> confirm the same thing".
>

I'm not sure who you're defining as "community", but this is definitely
something that the technical standards bodies have run into. You simply
need look at CoAP or Delegated Credentials or the amplification attack
factors of QUIC, or the DoS factors of TLS 1.3, to see that SDOs have been
grappling with the issues here for quite some time. I realize that many
members don't attend IETF, and are not familiar with the technical
developments there, but you can simply look through the presentations to
see how many are concerned about ensure that certificates are minimally
sized, in the context of the Web PKI. And that's not even touching on other
PKIs that have not had to deal with the historic baggage of the Web PKI and
CAs' entrenched behaviours, like Vehicle-to-Vehicle or Wireless Power
Consortium or mFI or USB-certified or FIDO.


> If you search crt.sh you will find hundreds of Root CA and subCA
> Certificates that include organizationUnitName, stateOrProvinceName or
> localityName in the subjectDN. If there was ample harm I can safely assume
> it would have been detected by now and the ecosystem would have problems.
>

My dude, the system has problems, and people are cobbling together
solutions, some of which would functionally exclude HARICA from competing
with other members in this Forum due to the practical technical
implications. For example, some proposals for certificate compression noted
that significantly better compression was achieved by constructing a
dictionary from the top N most popular websites. This means if you used a
certificate from the CAs responsible for those websites, your site would be
faster than if you used a certificate from HARICA, or any other CA not in
the top-N. It also would functionally ossify profiles, imbuing better speed
to the most popular.

And this is why I say that CAs don't really have any insight into this: You
don't see the data from users' having trouble checking OCSP; you may see
the requests, you don't see the sluggishness. You don't see the impact to
time-to-first-byte that affects your customers' websites. You don't see the
impact of having overtly large OCSP responses, including unecessary
certificates. And, in many cases, your customers, the website operators,
don't either. Nor do they see any benefit from the added inclusion of
LogoTypes in the CA certificate, or the added locality data, or the cpsText
rivaling Moby Dick. But the users do and the browsers and the OS do, and
they see the harm.

All of this information does tie back to the Issuer, and the fields in it.
This isn't hyperbole, this are real problems that real engineers are trying
to solve for the majority of the Internet. The niche focus doesn't help,
and actively harms. User's don't have much choice here.


> I'm not trying to convince you it's bad. I need you to convince me it's
> good.
>
>
> Trust me, I'm an engineer! :) If that doesn't work, then I guess the only
> good arguments I have to support this case are the following:
>
> A) CAs must comply with the eIDAS regulation and the legal mandate to
> create Certificates for website authentication that should be able to
> convey the CA information (and its registration number) within the
> end-entity certificates. The currently acceptable solution to comply with
> this legal requirement is to follow the ETSI profile and that's what
> Regulatory Authorities are looking for. I don't need to explain further
> that following the law and regulatory authorities is good.
>

The eIDAS Regulation doesn't require the adoption of the ETSI Profiles,
particularly with respect to Annex IV.

The ETSI profile has a number of significantly questionable limitations,
least of all being the forbidding of automatic cert issuance due to the
requirements imposed (not on the BRs), even in the case of 319 411-1 (i.e.
non-Qualified certificates using the PTC profiles). I am not suggesting
this was malice on ETSI's part, but I would say the misalignment of
objectives is significant enough that it warrants re-evaluating the view of
those technical criteria, and how well they're aligned with browser
objectives.

The argument here boils down to "We should do it because we want to do it
because that's how we were doing it", when as you admit, there are real and
viable technical alternatives, readily deployable, that do not require this.


> B) State and Locality information is useful information for Relying
> Parties that want to lookup a certain Legal Entity and want to narrow down
> their search.
>

This is exactly what CCADB is for, which is made freely available.

There is no need for this information to be expressed within the
Certificate itself. If you want to further make this argument, then you're
functionally arguing that what we should do is fully remove the C and O
fields, require an organizationIdentifier that is an LEI, and then add a
monotonically increasing number to the DN (or, functionally, to the
dnQualifier). This would meet your functional example and the technical
requirements, namely:

1) Unambiguous information about the operating entity
2) Unique DN

Of course, in saying that, it should be obvious that 1 still isn't
/actually/ met. You can similarly look through crt.sh and see how
frequently the O field is a brand name, or a former brand name, of some
now-defunct organization or some entity who has no relationship to the CA
or its operation. And if we expect that CAs will continue that trend, which
we invariably need to in the continued M&A spree we see, then we have to
acknowledge that this information is dynamic, and thus placing it within
the certificate itself is nonsense for this use case. Even an LEI doesn't
tell you who controls the key.

So really, we just need a unique ID per CA. Which is what I said originally
:) That's all we technically need, and for your use case here, that's also
all we functionally need.


> You are a very hard person to convince, I'm sure you know that already.
>

I've got a brand to protect - but also a billion users to protect and
respect and reflect their interests and to ensure website operators have
interoperable choices that are aligned with their needs and interests. Even
if it's not perfect for everyone, it's still better for most.


> I believe one of the main reasons for recent disagreements you have raised
> in various discussions (including the LEI ballot) is that you see harm and
> you are against solutions that are useful for "some" and only promote and
> accept solutions that are useful for "all". For example, in this post you
> could argue that A) is limited to CAs operating in EU territory, and that
> B) is limited to a small set of Relying Parties. I hope in this case you
> will at least accept the legal arguments about the rules that the EU people
> have voted and described through their technical standards, which were not
> considered in conflict or violation of the Baseline Requirements at the
> time of writing, and at least agree on the need to allow the
> organizationIdentifier field in CA Certificates going forward.
>

I don't agree on the inherent need. The argument as to both legal or
technical requirements are unsound.

I'm extremely sympathetic to a desire for a transition, as I've suggested,
if there's a reasonable one.

For example, allowing CAs to issue subCAs for one year with certain added
fields (e.g. organizationIdentifier), provided that sub-CA is limited in
lifetime (e.g. to two years). This would ensure that within three years
(functionally), things have transitioned off. That's an age in Internet
time, but that's more than sufficient time to adopt other technical
practices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/f943cf2a/attachment-0001.html>