[Servercert-wg] Subject name requirements for CA Certificates

Wed Oct 23 04:18:14 MST 2019

Hi Pedro,

I was just pointing that if you intend to create a cross certificate, then it may not be possible because the subject DN of the roots contains fields not currently permitted as Subordinate CA subject DN fields.  Of course, the rules could change between now and then, and of course having some extra DN fields might not be a problem if the Subordinate CA name definition is not considered default-deny.  If you have no plans to create cross certificates to this root, then it’s not an issue at all.

Doug

From: Pedro FUENTES <pfuentes at WISEKEY.COM> 
Sent: Wednesday, October 23, 2019 2:33 AM
To: Vijay Kumar M <vijay at emudhra.com>
Cc: Doug Beattie <doug.beattie at globalsign.com>; Ryan Sleevi <sleevi at google.com>; Leo Grove <leo at ssl.com>; Bruce Morton <Bruce.Morton at entrustdatacard.com>; manho at certizen.com; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Subject name requirements for CA Certificates

Dear all,

Same here... WISeKey doesn’t have any cross-certification but independent roots. 

In our case the roots have been transferred to the OISTE Foundation, but the subject name remains at it was, so the O field contains “WISeKey”. 

If there’s any particular reason why our name is appearing in this thread, I’d really appreciate more information, because I’m a bit confused. 

Thanks and best regards,

Pedro

Le 23 oct. 2019 à 07:10, Vijay Kumar M <vijay at emudhra.com> a écrit :

Hi Doug,

This mail is not related to the original subject of this thread. But, just to clarify on eMudhra being quoted in your email as cross certified. 

eMudhra roots are not cross certified and all are independent Root certificates added in trust store. If there are any pointers why you felt this is cross-certified, please let me know. That will help us understanding. We can discuss on a separate thread.

Regards,

Vijay

From: Doug Beattie <doug.beattie at globalsign.com> 
Sent: 23 October 2019 02:52
To: Ryan Sleevi <sleevi at google.com>; Leo Grove <leo at ssl.com>; Bruce Morton <Bruce.Morton at entrustdatacard.com>; Vijay Kumar M <vijay at emudhra.com>; pfuentes at wisekey.com; manho at certizen.com
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: RE: [Servercert-wg] Subject name requirements for CA Certificates

Many (all?) of the recent roots added to the Mozilla trust store have similar issues and cross certificates to these will not be permitted, so I suggest you also weigh in if you want to ever create Cross Certificates to them:

*	Entrust G4
*	SSL.com
*	eMudhra
*	WISekey
*	Hong Kong Post

In fact, it’s not clear why these roots were approved in the first place if they didn’t meet the requirements clarified in Ballot 199 with “default deny” logic applied.

https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport

Doug

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Tuesday, October 22, 2019 4:32 PM
To: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Subject: Re: [Servercert-wg] Subject name requirements for CA Certificates

On Tue, Oct 22, 2019 at 4:14 PM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

Ryan,

We’re saying the same thing as far as “older -> old -> new -> intermediate -> end entity".  New roots should be able to be cross signed only with older roots.  That is what we did and is consistent with your comments below, so totally agree.  

The unfortunate aspect of this is that the subject DN of our “old” root isn’t compliant with the current definition of Subordinate CA subject DN, thus the issue if/when we treat a Cross Certificate as a Subordinate CA certificate when it comes to naming requirements.  If this was not an issue, we wouldn’t be having this conversion.

Then it's unclear where the issue is?

If "new" complies with the BRs, then signing "new" with "old" is not an issue. Old can still comply with the BRs, signing "new", which also complies with the BRs.

The whole point of this exercise is to provide a path to phase out certificates that do not comply with the BRs, and to continually move new issuance on to newer, "more compliant" (i.e. more recent) issuing hierarchies. It may be that "older" and "old" are trust anchors on legacy systems - and that's why you create that path to "new" for them.

If "new"'s subject does not comply, you create "newer" - and move your issuance to that.

New signs newer -> totally fine with the BRs

Old already signed new -> totally fine with the BRs

Older already signed old -> totally fine with the BRs

Now, the only scenario I can see this being an issue is if a path "old -> new" wasn't created, "new" doesn't comply with the BRs, "old" is still subject to the BRs, and "new" is included as a trust anchor on some systems, while "old" is included as a trust anchor on other systems. That is exactly the scenario that I don't want to have happen / have to support, and it reflects a problem in the design/ceremony when "new" was created (that it wasn't cross-certified to 'old' to ensure continuity). This only happens, though, if you're not following the above flow, so it's hard to see how agree with X but also X is a problem.

I would certainly like to hear from others, CAs and Root program members on their view of this situation.   Does everybody feel that cross certificates between roots should be prohibited when the “old” root subject DN does not contain exactly C, Org and CN?  I have to assume this is a problem for more than just GlobalSign.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/35909373/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/35909373/attachment-0001.p7s>