(I'm splitting the topic because at this point, continuing to discuss
the analogy doesn't have a direct bearing on the inclusion or otherwise
of DM)
Replies inline.
On 16/07/2019 23:23, Matthew Hardeman wrote:
I submit that I disagree somewhat with Gijs' suggestion that Mozilla acts
in the nature of a third-party guarantor here. I further submit that the
more direct analogue is that the community of Mozilla users present
and future is the set of depositing members of the Mozilla Trust Credit
Union, a bank of trust/credit which is lended out to CAs from the pool of
trust + good will of those users -- that pool being under the direction and
management of the Mozilla organization, who, I believe, are literally
acting in the nature of a lender, loaning out the pooled assets (in this
case the sum of the trust extended to Mozilla) to qualified trust-borrowers
(CAs). Mozilla is explicitly in the position of making decisions regarding
where to invest that pooled trust.
But as I already said, unlike financial institutions the trust store cannot:
- moderate the amount of trust/money
- tailor whatever the equivalent of repayments or interest would be to
the profile of risk of a particular debtor (CA)
- demand a security from the debtor (CA)
- demand a guarantor who is liable if the debtor (CA) "defaults".
Instead, it is bound to treat every admitted debtor (CA) exactly the
same, and a yes/no is the only decision it can make. That's... not
really any power over the debtor at all, besides denying them access to
the users ("pool of trust") *for the future only*. That is, at any point
the trust store can stop providing further trust (credit). But there's
almost nothing it can do about trust (credit) that's already been
provided (certainly, in Mozilla's case, about TLS transactions in the
past involving certs issued by the debtor/CA).
Indeed, if Mozilla is a mere guarantor in this process, who precisely is
the lender?
The lenders are the users, the CAs are debtors. Same as your example,
really, except you're putting the trust store in a position where you
claim it can control the debtors (ie as a credit union of users' trust),
and I'm pointing out that such control does not exist in the same way as
it does for lenders in the financial system. Instead the community's
position wrt individual CAs once trust is broken is much more like
someone who has to clean up after the debtor disappears (by
investigating, discussing, then drawing conclusions, then
distrusting-for-the-future and making sure both end users and site
operators aren't unduly inconvenienced by the distrust of the
"defaulting" CA). That's effectively the position of a guarantor - who
can also refuse to act as a guarantor when a loan is setup, ie has a
yes/no choice, but otherwise can't influence the agreement between
lender and borrower itself.
I also disagree with the contention that Mozilla has "effectively no
recourse" should a trust "debtor" (CA) "default" (fail to make "payments"
on the borrowed trust through providing services to certificate subscribers
only in compliance with program and industry guidelines and with proper
validations.) Mozilla's recourse is essentially absolute: you can revoke
the trust you've extended, preventing further damage.
As you say, we can "prevent **further** damage". But there is no
recourse for damage that has already happened. The potential for damage
cannot be limited pre-emptively, nor is it possible to create incentives
for the debtors to repay (ie no way to have a security) and there is no
way to be compensated for damage caused once that's happened. Instead
the trust store (here, Mozilla and the community in mdsp) get to clean
up - and will refuse to sign up as guarantor for the same entity unless
things change drastically, because we're not *that* stupid... And sure,
that prevents future damage, but it does nothing to remedy damage in the
past, which is not normally how things work for financial credit.
~ Gijs
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
