On Fri, April 24, 2015 6:34 am, Moudrick M. Dadashov wrote: > Kathleen, wouldn't be it easier to apply the transferred CA the same > requirements as to any other? That means the new CA must have its > operations audited under its ***fully completed transfer*** operations. > > The root and all associated intermediates must pass audit against > ***then applicable*** requirements only after having the CP/CPS clearly > disclosing the details/nature of the transfer.
When you say "the same requirements as any other" - are there fundamentally any differences here than a CA cross-signing a new root certificate? Are there fundamentally ay differences here than a CA signing a new unconstrained intermediate? I think that is truly the crux of the question, and frankly, I don't think there is. We have two standards for "organizations capable of causing certificate issuance" - Those who apply to Mozilla and wish to be single-handedly responsible for their destiny. - Those who find another CA who will sign their certificate, and thus avoid Mozilla review. In exchange for not having to do the Mozilla process (or any other root processes), they lose their independence. For example, their "partner CA" may decide a year later to charge them 10X what they originally stated, and there's nothing the CA can do, other than accept their "partner CAs" extortion (er, contract renegotiation based on changing business conditions). No business likes having that sword hanging over their head, but at the same time, it's "nice" to not have to rely on the unreliable Mozilla community to do a timely review. Similarly, the "partner CA" takes on risk that by allowing the CA to avoid Mozilla review, the CA may botch things, and that will cause the "partner CA" to suffer. So it's a set of trade-offs, but it's unquestionably a double standard. J don't see having the double standards as necessarily a bad thing either - it recognizes the business realities, such that no organization likes to wait on 30 different root stores and 30 different timeframes before they can conduct business. On the Mozilla side, being volunteer driven, the timelines vary wildly, and the thoroughness of review varies wildly. I think in recent months, we've all become more attune to the thoroughness, but I know I personally still greatly struggle with the timeliness. Kathleen's the one consistent performer through all of this, which is necessary, but not sufficient. This is the long-winded way of saying I think Kathleen's proposals make perfect sense. I don't think it introduces any new risks to the community that are not inherently there, while offering a sensible path forward that recognizes the tradeoffs. As the community and process approves, and things like "disclosed sub-CA" becomes some thing maintained automatically by CAs, we'll be in a better place to align the two processes. Then, if someone wants to start a CA, they can either block on the community review (new CA) or the community can rely on an external party (the "partner CA") to do the initial review, knowing their financially incentivized to do it 'right', and then the community can review "after the fact" and take appropriate action. In either event, full transparency is there, and full review is possible at any time, so I don't think there's any harm Kathleen's proposal. At best, for those nervous about the "community review" phase, we could just tack on an added "Oh, and you have to tell moz.dev.security.policy after you did this, rather than just updating your URL with the disclosure", and we can go on our merry way at our leisure. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
