On Sun, Feb 20, 2022 at 3:06 PM Peter Bowen <[email protected]> wrote:
> I do not think this request, or other requests for a new Externally > Operated Subordinate CA, should be rejected or accepted based on > whether the CA operator is applying for inclusion of a root CA they > operate. > This conclusion may, unintentionally, seem to suggest something I was not proposing. I'm hoping this was simply trying to be carefully worded to limit the scope of what you agree with, although it may be misinterpreted as being a rephrasing of my position, which it isn't. The past discussions you link to are with respect to a different scenario than the one we find ourselves in now, and so too were the proposals different. Note that I'm not suggesting that subordinate CAs be prohibited, as the previous posters suggested, but rather that such subordination be placed on hold unless, and until, the CA has undergone adequate review. This speaks to Dimitris' point, or perhaps misunderstanding, about the root inclusion process. The suggestion of there being simply a three week review process overlooks the significant, and transparent, vetting that occurs on the CCADB Case and Bugzilla issue prior to acceptance, including, as has been previously mentioned, the detailed CP/CPS review by someone who regularly performs CP/CPS reviews, and with a vested interested towards protecting users. The incentives, process, and outcomes are all radically different with respect to subordination, and yet the risks are, at best, the same, or as previously highlighted, even greater than those risks of a root (due to shared fate). I'm not sure if you share Dimitris' position that the quality, competenancy, and outcomes of an externally-delegated review are commiserate with those of one performed by the root inclusion process. If they are distinct, and have differences in competencies and outcomes, then I'm not sure why the externalized subordinate CA review would be seen as acceptable, except for "tradition". Yet that tradition is both inconsistent with the goals, and inconsistent with the other practices, and so I do believe it's worth suggesting here to break from that misguided tradition, and to defer the acceptance or rejection of the subordinate until the root has been completed. Unless we're assuming that the policy aims are to guarantee inclusion, this seems entirely consistent with the existing policies and practices. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHFJrH-OngoTA18XhoUw_b1dR0qM5hh%2BWvZzR-Kpz%3DJAXw%40mail.gmail.com.
