[Servercert-wg] Subject name requirements for CA Certificates

[Paul Walsh]

On Oct 23, 2019, at 11:46 AM, Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org> 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 countryName, 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.

[PW] When you say “‘we’re' not supportive of this", is it safe to assume that you are referring to Google? Or are you you speaking on behalf of all browser vendors? Absolutely no sarcasm here. 

If you are referring to Google, what do other browser vendors think? 

I note from the group website that Opera, Microsoft Cisco and Apple are “Internet Browser Vendors” members. Are they still actively involved? I’ve been an onlooker to this forum for a long time but only joined as an “interested party” as I felt the need to offer my participation, so it’s possible I haven’t been on the receiving end of their participation. 

Are there any plans to encourage participation from other browser vendors? What about innovative browsers like Brave and others that are taking market share from the incumbents? Collaboration with vendors that are likely to become a dominant leader is best encouraged while they’re on the rise, not when they’re on top.

Regards,

- Paul

> 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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/56a96882/attachment.html>