Here are some ideas for reasonable new/enhanced policies (rough
sketches to be discussed and honed before insertion into a future
Mozilla policy version):
1. If a CA operator (the entity whose audits and statements ensures
compliance with BR, CCADB, Mozilla, etc. policy requirements) ceases
operation without transferring the relevant assets and
responsibilities, it must notify the CCADB and/or Mozilla and
indicate which, if any, provisions are in place for ensuring orderly
handling of issued certificate revocations etc. during a transition
period. Based on this Mozilla will decide when to remove the
affected roots from its trust store, and if any protective filters
will be added to ensure the wind down operator does not issue new
certificates contrary to the wind down plan. All CA operators are
encouraged to have a pre-assessed contingency plan for this already
on file within or along with its CP/CPS documents, such that Mozilla
may express, before such an event, what the consequences for
certificate holders and relying parties would be should the plan ever
get invoked.
2. If a CA operator wishes to transfer operations control of a CA
private key to a different CA operator not already accepted into the
Mozilla root program for the applicable trust aspects (web, web EV,
mail etc.), it must if at all possible delay the actual transfer of
control or possession until Mozilla has received and processed such
an application. The gaining applicant may indicate in their
application that the application is for the potential takeover of one
or more existing roots (named or not at that stage). It is
explicitly noted that the contractual and economic aspects of such a
transfer may happen before the actual transfer, making it easier to
comply with financial and other regulations regarding disclosure of
such a transaction.
3. If a CA operator organization has a significant change in its
controlling ownership, it must notify Mozilla and/or the CCADB as
soon as possible, with a confidential notification possibly preceding
the public notification. Mozilla shall be entitled to reassess its
trust in the CAs operated by that CA operator based on the public
reputation and public assurances made by the new owners. It is
explicitly noted that de facto authority over existing CA operator
personnel, rather than de jure completion of a sale/merger/etc. is
the relevant point in time, thus if possible, Mozilla should be
notified (in confidence if need be) before that point.
4. If a CA operator organization changes only its formal legal
structure while leaving the controlling ownership and other essential
aspects intact, Mozilla considers this a minor event for which a
simple update in the CCADB is sufficient. This generally does not
change the trust status of the CAs operated by that CA operator.
On 06/04/2017 04:24, Peter Kurrasch wrote:
I have no issue with the situations you describe below. Mozilla should
act to encourage the good behaviors that we would want a new, acquiring
CA to exhibit while prohibiting the bad--or at least limiting the damage
those bad behaviors might cause. It's in this latter category that I
think the current policy falls short.
Consider a situation in which I have a business called Easy Pete's
Finishing School for Nigerian Princes. As the name might suggest, the
nature of my business is to train potential scammer after potential
scammer and set them free on the Internet to conduct whatever naughty
things they like. It's a very lucrative business so when I see a root
cert coming up for sale it's a no-brainer for me to go out and purchase
it. Having access to a root will undoubtedly come in handy as I grow my
business.
Once I take possession of the root cert's private key and related
assets, what will limit the bad actions that I intend to take? For the
sake of appearances (to look like a good-guy CA) I'll apply to join the
Mozilla root program but I'm only really going through the motions--even
in a year's time I don't really expect to be any closer to completing
the necessary steps to become an actual member.
And it's true that I may be prohibited from issuing certs per Mozilla
policy, but that actually is a bit of a squishy statement. For example,
I'll still need to reissue certs to the existing customers as their
certs expire or if they need rekeying. Perhaps I'll also get those
clients to provide me with their private key so I may hold it for "safe
keeping". Sure, it's a violation of the BR's but I'm not concerned with
that. Besides, it will take some time until anyone even figures out what
I'm doing.
The other recourse in the current policy is to distrust the root cert
altogether. Even then it will take time to take full effect and who
knows, maybe I can still use the root for code signing? And then there
are the existing customers who are left holding a soon-to-be worthless
cert....
Leaving behind this land of hypotheticals, it seems to me the policy as
written is weaker than it ought to be. My own opinion is that only a
member CA should be allowed to purchase a root cert (and assets),
regardless if it's only one cert or the whole company. If that's going
too far, I think details are needed for what "regular business
operations" are allowed during the period between acquisition of the
root and acceptance into the Mozilla root program. And should there be a
maximum time allowed to become such a member?
*From: *Nick Lamb via dev-security-policy
*Sent: *Tuesday, April 4, 2017 3:42 AM
*To: *mozilla-dev-security-pol...@lists.mozilla.org
*Reply To: *Nick Lamb
*Subject: *Re: Criticism of Google Re: Google Trust Services roots
On Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch wrote:
I must be missing something still? The implication here is that a
purchaser who is not yet part of the root program is permitted to take
possession of the root cert private key and possibly the physical space,
key personnel, networking infrastructure, revocation systems, and
responsibility for subordinates without having first demonstrated any
competence at running a CA organization.
This appears to me to simply be a fact, not a policy.
Suppose Honest Achmed's used car business has got him into serious debt.
Facing bankruptcy, Achmed is ordered by a court to immediately sell the
CA to another company Rich & Dick LLC, which has never historically
operated a CA but has made informal offers previously.
Now, Mozilla could say, OK, if that happens we'll immediately distrust
the root. But to what end? This massively inconveniences everybody,
there's no upside except that in the hypothetical scenario where Rick &
Dick are bad guys the end users are protected (eventually, as distrust
trickles out into the wild) from bad issuances they might make. But a
single such issuance would trigger that distrust already under the
policy as written and we have no reason to suppose they're bad guys.
On the other hand, if Rich & Dick are actually an honest outfit, the
policy as written lets them talk to Mozilla, make representations to
m.d.s.policy and get themselves trusted, leaving the existing Honest
Achmed subscribers with working certificates while everything is
straightened out, all Rich & Dick need to do is leave issuance switched
off while they reach an agreement.
Because continuing trust is always at Mozilla's discretion if something
truly egregious happened (e.g. Achmed's CA is declared bankrupt, a San
Francisco start-up with four employees and $6Bn of capital buys their
hardware for pennies on the dollar and announces it'll be issuing free
MITM SSL certificates starting Monday morning) then Mozilla is still
free to take extraordinary action and distrust Achmed's root immediately
without waiting until Monday morning.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
