On Fri, April 24, 2015 7:52 pm, David E. Ross wrote: > If a root has already been added to the NSS database, we must assume > that it has undergone the Mozilla process for that inclusion. The > process involves looking not only at the root but also at the > certification authority; at least that is what appears in both the > public discussion of the request to add the root and in the stream of > comments in the bugzilla.mozilla.org bug report that initiates the > request. > > If a root in the NSS database is transferred to a new owner and that new > owner already has roots in the NSS database, I assert the new owner has > already undergone sufficient scrutiny. I limit my assertion, however, > to cases where the transferred root has characteristics (e.g., trust > bits, EV status) in common with roots already owned by the new owner. > That is for example, I would not accept EV status on a transferred root > if none of the other roots of the new owner have EV status. > > We trusted the old owner of the root and we trust the new owner. Thus, > we can trust the transferred root to the minimum level we trusted the > two owners. In the environment of OpenPGP, this is analogous to the Web > of Trust.
I know this is how you want it to work, and how people naively think it works, but it isn't how it works. I tried to make the logical reasoning as explicit as possible: - If a root is added to the Mozilla store, it is because it wants to issue publicly trusted certs. - The community cares about the entities issuing publicly trusted certs. - However, not all organizations that can issue publicly trusted certs go through community review. - Therefore, there are organizations who can issue publicly trusted certs that do not go through community review. Thus any argument that says "All organizations that issue publicly trusted certs are community reviewed" is false, both demonstrably and in practice, and arguments predicated on this can be shown to be based on a mistaken assumption. Your ascription of trust to the organization, rather than the root, also mistakenly understands what the community review process does. The *WHO* of the organization is entirely irrelevant, according to the policy. It is the *WHAT* they're doing that matters. If the WHAT does not change, then it should not matter that the WHO changes. Again, I thought this was spelled out, but the community review is of policies and practices, not people. We don't keep the brown-eyed CAs out to the benefit of the blue-eyed CAs, we don't keep the non-American out for the American, we don't take the brands we use every day versus the brands we've never heard of. That's not the community review. It may be how you review, but it just means that those arguments are ignored, because that's not how the policy works. If you find this still unsettling or uncomfortable, then the exercise is what I asked of you originally - demonstrate how this functionally differs from a root that signs an intermediate with "CA:TRUE" capability. Under the current policy, the root is required to: 1) Disclose the intermediate 2) Disclose the CP/CPS 3) Disclose the audit, which they must have That is the current standard for what "Capable of issuing trusted certificates" must meet. How does this differ - purely on a technical level? It doesn't. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
