[Servercert-wg] Subject name requirements for CA Certificates
Leo Grove
leo at ssl.com
Tue Oct 22 20:51:16 MST 2019
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> *On Behalf
> Of *Doug Beattie via Servercert-wg
> *Sent:* Tuesday, October 22, 2019 2:22 PM
> *To:* Ryan Sleevi <sleevi at google.com>; Leo Grove <leo at ssl.com>; Bruce
> Morton <Bruce.Morton at entrustdatacard.com>; 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:* [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/6156c1ea/attachment-0001.html>
More information about the Servercert-wg
mailing list