On Thu, Sep 28, 2017 at 11:50 AM, Gervase Markham <g...@mozilla.org> wrote:
> > The nature of trust is that it's harder to regain than it is to gain in > the first place. Just ask someone who's been the victim of adultery - or > someone who is a now-repentant adulterer. Rightly or wrongly, people get > a first chance, but it's tough to get a second. I think you are right > when you conclude that this is just the way of things, and we should > accept it rather than kick against it. > > Gerv > I am curious how accepting that reality might impact the program. It raises several questions in my mind: Does the root program formally recognize the trust required of key executives and operations staff? Does the program actually concern itself with beneficial ownership - particularly when all parties are asserting that the ownership is passive? If so, how are those assertions and determinations vetted and documented? Regardless of ownership, does the root program require any specific formal assertions or affirmations by CA's key executive staff? Do those or would those include declarations such as "I am formally declaring that I was/will be the senior executive responsible for management and operational decisions of the CA for the period ___. "? Would / should the program require that trusted individuals in key roles regularly certify such claims of responsibility and require that these individuals personally acknowledge an affirmative responsibility to notify the program if their role transitions or that the exercise of their professional discretion within their role has been subverted or curtailed? The spirit of these questions is to inspire some thought as to who are the individuals in whom trust must be granted are and what precisely we are trusting them with and how can we capture in a more formal way just what it is that they are being trusted with and what the program's and community's expectations are regarding any formal affirmative responsibilities related to the trust that's being granted. Business entities lack thought and discretion. It's the trusted people within a CA who either operate the CA pursuant to standard or do not. How can those specific extensions of trust be formally documented and what obligations does that impose on those individuals. How can that be captured in such a way as to hold those who've been granted trust accountable? By way of example, I suspect that a certain R.W. is effectively subject to a lifetime ban from executive and trusted operations roles in any CA in the Mozilla root program. I also suspect that's not really formally documented as such in the general case. I can not imagine that anyone in the management of the Mozilla root program would respond with a "Erm, yes, I guess" to a CA asking the hypothetical question "We're contemplating hiring Richard Wang for COO of our currently publicly trusted CA. But we're good, though, right?" To be quite clear, I am not asking about any particular individual, but making a point that, as you said, trust is far harder to regain than it is to be granted initially. Formalizing the program's recognition of the key participants of the various roles offers the opportunity for holding individual bad actors accountable while also giving the opportunity to hold harmless an executive who reports an attempt at a silent, internal coercion as to his autonomy in his role (perhaps by a purportedly arms-length owner) and that said executive is abandoning the role officially and wishes not to be held responsible for events at said CA beyond time point X. Formalizing the responsibilities and liabilities of the individuals allows punishment and reward. It also has the potential for providing a mechanism for redress, where warranted. Generally speaking it is difficult for a person who is unofficially banned to get officially unbanned. It follows that it's hard to get a status changed when others won't acknowledge the status. Just some thoughts... Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
