[Servercert-wg] Subject name requirements for CA Certificates

[Vijay Kumar M]

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/fabeab09/attachment-0001.html>