[Servercert-wg] Subject name requirements for CA Certificates

[Man Ho]

Hongkong Post's cross-certificate is created because of the rollover of the existing Root Certificate to a new Root Certificate. Some browsers have not yet included the new Root Certificate into their root certificate program. So, it is used to build another chain of trust back to the existing Root Certificate for subscriber certificates that are issued under the new Root Certificate. Both Root Certificates are owned and hosted by Hongkong Post, i.e. the same Root CA.

By the way, it is interesting to see that by definition of Cross Certificate in the BR:-
Section 1.6.1 Definitions of related terms:

Cross Certificate:   A certificate that is used to establish a trust relationship between two Root CAs.

Publicly-Trusted Certificate:  A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software.

Root CA:  The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.

Root Certificate:  The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.

Subordinate CA:  A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.


Hongkong Post's cross-certificate should not be considered as Cross Certificate because it is used to establish a trust relationship between two Root Certificates, not two Root CAs. And both Root Certificates are owned and hosted by the same Root CA. Is my understanding correct?


On 23-Oct-19 5:22 AM, Doug Beattie wrote:
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/370701ec/attachment-0001.html>