[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

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

>
> Sure. I believe CAs should be allowed to add more information to the CA
> Certificates for the same reasons we require Subscriber Certificates to
> include *stateOrProvinceName *OR *localityName*. Relying Parties have the
> right to have more information for the issuer in order to disambiguate
> between conflicting companies with the same name and to be able to identify
> the Issuer more accurately. The conflict is significantly less if you have
> organizationName, stateOrProvinceName OR localityName, countryName compared
> to organizationName, countryName.
>

This does not make any sense. We're talking about who the issuing
organization is, of which there are less than a hundred, and which are
unique within their scoped organization and country.

Furthermore, this information has no relevance to relying parties, in as
much as they can and do obtain this information out of band - e.g. CCADB or
from the Root Program.

As best I can tell, this portion of the argument is simply "It's nice to
have", which is ... not a compelling argument. The argument needs to be
compelling enough to say "This is good", and this just seems to be saying
"This doesn't seem bad.


> In addition to that, eIDAS Regulation mandates in Annex I (b) and Annex
> III (b) that the Certificates "SHALL contain a set of data data
> unambiguously representing the qualified trust service provider issuing the
> qualified certificates including at least, the Member State in which that
> provider is established and:
> — for a legal person: the name and, where applicable, registration number
> as stated in the official records,..."
>

Annex I is about electronic signatures, Annex II is about electronic seals.

Neither are applicable to Website authentication, and thus can be
accommodated by ensuring the appropriate EKU separation.

Further, this information can be unambiguously captured, today, using the
existing requirements.


> This has been decided to be carried out in issuerDN field of end-entity
> Certificates. According to RFC5280 section 4.1.2.4 for name chaining, this
> means that the same information must be in the subjectDN of the Issuing CA
> Certificate. ETSI has decided to carry out this "registration number" via
> the *organizationIdentifier *subjectDN field of the Issuing CA
> Certificate, which is why you see several Qualified Trust Service Providers
> including the *organizationIdentifier *attribute in CA Certificates.
>

So I want to make sure it's clear the argument:

- Because ETSI has a profile for certificates used in document signing, the
Baseline Requirements for SSL/TLS should allow such certificates to be
mixed in the same trust hierarchy.

That's not a compelling argument. If anything, that's a reasonable reason
why to forbid.


> 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.


> On a technical level, the only essential element is that a CA's Subject
> name be distinct within the certificate chain. That can be wholly
> accomplished by simply generating a random distinguished name - there's no
> dependency on the X.500 hierarchy for naming, and Relying Parties have or
> can obtain the information out of band (e.g. Microsoft delivers it out of
> band as part of their root store updates via the Friendly name). However,
> since that's a more radical shift, the provision of countryName,
> organizationName, and commonName provides sufficient distinction for the
> operating entity (C+O) and allows them the flexibility for creation of
> multiple CAs (commonName). There is no need for those other fields, and
> there is ample harm caused by them.
>
>
> No harm (let alone "ample") has been caused all these years by having
> stateOrProvinceName or localityName or both in CA Certificates.
>

This is, again, a categorical statement with no evidence, and easily
falsifiable. If you'd stated this more accurately, such as "HARICA has not
seen the harm", this would certainly be a more reasonable statement, and
might provide an opportunity to educate. However, simply making categorical
statements like this suggests an unwillingness to actually learn from
others, and doesn't seem a reasonable path for discussion.

I'm not trying to convince you it's bad. I need you to convince me it's
good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/84661620/attachment-0001.html>