[Servercert-wg] Subject name requirements for CA Certificates

[Dimitris Zacharopoulos (HARICA)]

On 2019-10-24 10:26 μ.μ., Ryan Sleevi wrote:
>
>
> On Thu, Oct 24, 2019 at 2:57 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto: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.

Hope the eIDAS argument is more compelling.

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

Forgive me, check out Annex IV which is for "QUALIFIED CERTIFICATES FOR 
WEBSITE AUTHENTICATION". Some CAs actually use the same RootCAs when 
applying to Root programs in order to facilitate S/MIME and TLS.

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

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

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

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

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

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.

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

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. Especially for large countries like China or the 
United States, finding an organization by just using the name and the 
country is like looking for a needle in a haystack. If a Relying Party 
wants to search this information, it will be unaware of CCADB. Most 
likely the relying party will find the subject information as displayed 
in the X.509 certificate and look for this entity using a popular search 
engine. If the results are too many, then State and/or Locality and 
-even better- the organization number, would assist to narrow down the 
results. Helping Relying Parties locate which Legal Entity is signing 
their Certificates is good.

You are a very hard person to convince, I'm sure you know that already. 
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.


Thanks,
Dimitris.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/d86b573e/attachment-0001.html>