[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Wed, Oct 23, 2019 at 2:32 PM Dimitris Zacharopoulos (HARICA) <
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.

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.

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.


> I hope this will be an uncontroversial issue just like it happened with
> ballot SC16.
>

This is unlikely :)


> 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. Failure to resolve the systemic issue just leads to
more misinterpretation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/ffcaff18/attachment.html>