On 4/24/2015 5:30 PM, Ryan Sleevi wrote:
Ryan, I don't know how fundamentally different those CAs are but we all have agreed that CA is "An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs".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?
So I thought everybody "standing under the umbrella" is treated the same way.
Cross-signing scenarios may or may not result in creation of a new CA, probably this is the most noticeable difference.
Whatever they do, a Mozilla applicant must be a CA by definition, right? Therefore the clarification of HOWs below is definitely useful in the process of transferring-gaining the "new CA" status but shouldn't be considered as an alternative Root inclusion option.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.
Thanks, M.D.
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
