[Servercert-wg] Subject name requirements for CA Certificates

[Leo Grove]

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>