[Servercert-wg] [EXTERNAL]Re: Subject name requirements for CA Certificates

[Kirk Hall]

+1  You are exactly right.  Plus, what is the value of such a change to our current (and past) practices?

From: Leo Grove <leo at ssl.com>
Sent: Tuesday, October 22, 2019 8:51 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>; Doug Beattie <doug.beattie at globalsign.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Ryan Sleevi <sleevi at google.com>; Bruce Morton <Bruce.Morton at entrustdatacard.com>; vijay at emudhra.com; pfuentes at wisekey.com; manho at certizen.com
Subject: [EXTERNAL]Re: [Servercert-wg] Subject name requirements for CA Certificates

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________

Kirk,

Before we vote on a "default-deny" application to the BRs, I think it prudent to perform a thorough "impact study" of how this might affect other areas in the BRs beyond the subject DN. It might open a can of worms unless we do this methodically and iron out the unforeseen kinks.

Regards,

Leo


On 10/22/2019 4:39 PM, Kirk Hall wrote:
Doug – I have seen discussions of “default-deny”, but that was not in Ballot 199 or in the BRs, correct?

If that is now to be made a rule, shouldn’t the proponents propose that as a ballot so the Member can vote on it?

From: Servercert-wg <servercert-wg-bounces at cabforum.org><mailto:servercert-wg-bounces at cabforum.org> On Behalf Of Doug Beattie via Servercert-wg
Sent: Tuesday, October 22, 2019 2:22 PM
To: Ryan Sleevi <sleevi at google.com><mailto:sleevi at google.com>; Leo Grove <leo at ssl.com><mailto:leo at ssl.com>; Bruce Morton <Bruce.Morton at entrustdatacard.com><mailto:Bruce.Morton at entrustdatacard.com>; vijay at emudhra.com<mailto:vijay at emudhra.com>; pfuentes at wisekey.com<mailto:pfuentes at wisekey.com>; manho at certizen.com<mailto:manho at certizen.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org><mailto:servercert-wg at cabforum.org>
Subject: [EXTERNAL]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/7578e141/attachment-0001.html>