On Sat, 9 Dec 2017 09:51:59 +0100 Hanno Böck via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> On Fri, 8 Dec 2017 16:43:48 -0700 > Wayne Thayer via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > The root CA is ultimately responsible for subordinate CAs it has > > signed. > > I see a problem with that, as this is far from obvious. I saw "responsibility" here as meaning responsibility to the Trust Stores on behalf of the Relying Parties. For the Relying Parties themselves I think the right pattern is: Try filing a Problem Report with the Issuer, if the result isn't satisfactory, complain to your Trust Store(s). We can do the rest, can we not? The Trust Stores have just as much reason to distrust a root CA which can't keep its subCAs from breaking the rules as they do if this root CA were to break the rules directly themselves. That's sort-of the lesson from Symantec too, right albeit in their case the problem was RAs? It should be in the Root CA's interest to make sure that every sub-ordinate CA, whether physically under its control or not, is properly operated, and if there's a suspicion that it's not being properly operated, to get that sorted out. Handling problem reports is part of the proper operation of the CA. It may be that root CAs decide the best way to _achieve_ this objective [for a subCA they don't actually intend as simply a cross-signature to bootstrap another root] is to insist upon being the point of contact for Problem Reports, and they'll pass them on, so this way they have oversight. Or that they insist on the Problem Reports going to an alias, Exchange DL or similar that sends a copy to the root CA, I don't think we need to dictate how this is done, only to re-emphasise that as the root CA making sure the Problem Reports are handled properly is ultimately your responsibility, however you discharge it, not a situation for buck passing. We definitely mustn't be shy about problems affecting another business with a Trust Store. If Microsoft's executive management has any sense there is an institutional firewall between their Trust Store and their Certificate Authority functions, and the former is able to make decisions independent of their potential impact on the latter. If a root CA finds that it is politically uncomfortable to have two very different relationships (Programme Member: Trust Programme / CA: subCA) to the same public company, well, that's unfortunate, and I would suggest the less awkward way forward is to bring the subCA relationship to an ordered close. Perhaps Microsoft shouldn't be in both games (and if so, the same for Google), but that again is not a problem for Mozilla. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
