Thanks Wayne, This comment is made entirely in my personal capacity, and should not be assumed to reflect the views of my employer...
Upfront disclaimer: I don’t think I have an answer, but I hope I can help define the problem. Your question takes me back to the early days of CAs, when it took a while for people to separate the trust and liabilty issues into two groups: 1 - a CA’s liability for performing its designated functions and 2 - liability for subsequent use of the certificates issued by the CA. An important part of that learning process was understanding the separation of CA and RA roles. It looks to me like part of the issue here is that DarkMatter’s desired position conflates the two, in that they want to be a subordinate CA in their own right, but then also market products whose trustworthiness relies at least in part on DarkMatter being the trust anchor. If I “trust” a CA, I’m essentially trusting it to maintain the security and integrity of its signing keys, and to maintain the security and integrity of its certificate-issuing process. But that’s very different from “trusting DarkMatter” in all aspects of its business - including what it does with the certificates it issues, especially when it issues them to itself in order to include its own products in a trust hierarchy. The problem with adding them to a CRL, in my view, is the semantics of that action. If presence on the CRL means “there’s a problem with this CA in its exercise of its functions, as defined above”, then adding them to a CRL *because you have reason to distrust what they do with their products* would be misleading. Is the solution to oblige DarkMatter to be its own *root* CA (as opposed to being the subordinate CA of a trusted root that does *not* conflate roles as described above? That way, the onus is entirely on the relying party to decide whether or not to trust DarkMatter’s self-signed certificates. Hope this helps, R Wilton _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
