[Servercert-wg] Subject name requirements for CA Certificates

[Dimitris Zacharopoulos (HARICA)]

On 2019-10-23 9:46 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Oct 23, 2019 at 2:32 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>     In the absence of any rationale to limit only a c/ountryName,
>     organizationName/ and /commonName /field in subjectDNs of CA
>     Certificates, I propose we create a ballot that clarifies the
>     expectation to include /stateOrProvinceName/, /localityName/,
>     /organizationalUnitName/ and perhaps /organizationIdentifier/,
>     along with their validation rules (we already have good rules for
>     those fields), and add a clause that other fields SHALL NOT be
>     present.
>
>
> As I mentioned, we're not supportive of this. The argument you're 
> advancing is the one that I've tried to highlight is problematic "Why 
> not", not "Why". I appreciate that it's a very compelling argument, 
> because it tries to preserve the incorrectly-presumed status quo, but 
> it's not actually a desirable outcome for us, at least.

We have two issues at hand. Issue one is about CAs that have already 
included subjectDN attributes in CA Certificates. Issue two is what 
should be the expectation going forward. I would like to focus on issue 
two at least in this response.

>
> If you have compelling reason for why this information is necessary to 
> be in a subject, that's worthwhile. There's no technical reason to 
> include this, and there is compelling technical reason to omit it, as 
> it is not information that is necessary for the correct functioning of 
> the certificates, and more importantly, it's not information that 
> needs to nor should be sent in every TLS handshake.

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.

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

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.

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.

Identity information in CA Certificates was not added because of 
technical reasons, you could just have a CN in the subjectDN.

>
> 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. HARICA 
has seen no errors or warnings or has had any complains about delays or 
other problems from Relying Parties or Subscribers. I am sure other CAs 
will confirm the same thing.

>     I hope this will be an uncontroversial issue just like it happened
>     with ballot SC16.
>
>
> This is unlikely :)

Why do we have to disagree even for obvious issues? This is exactly what 
happened in SC16 and we have a precedent. You object to applying a fix 
for a problem that had the same root cause. Google voted "yes" to SC16 
judging that it was a good fix for that particular problem. Why is it 
not a good fix for this problem? The default-deny default-allow 
discussion is a lot more controversial than this issue and definitely 
deserves more discussion.

>     The default-allow default-deny is a very interesting discussion
>     but we have spotted a real practical problem in the guidelines
>     that causes confusion and possible compliance risks that needs to
>     be taken care of sooner than later.
>
>
> I think this is actually the more pressing problem. This is why I 
> tried to focus on the systemic issue, rather than trying, as we did 
> with SC16, to try to patch each individual issue and simply introduce 
> more confusion through inconsistency.

Why patching each individual issue introduces more confusion? This would 
be true if the language introduced to fix the issue was worse than what 
the existing language :) Making things clearer and less ambiguous is an 
improvement and should be welcomed.


Dimitris.

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