Re: On remedies for CAs behaving badly
On Monday, June 5, 2017 at 11:17:17 AM UTC-5, Ryan Sleevi wrote: > While on paper the idea sounds quite good, it turns out to simply trade > technical complexity for complexity of the non-technical sort. As such, > it's best to focus on meaningful and actionable technical solutions. Ryan, I greatly appreciate the time you spent crafting a thoughtful response to my idea/question and am especially grateful for the great depth of relevant references you provided. Having taken [some of] these into account, I find I fully concur with your assessment. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On remedies for CAs behaving badly
On 05/06/17 16:52, Matthew Hardeman wrote: > Has there ever been an effort by the root programs to directly assess > monetary penalties to the CAs -- never for inclusion -- but rather as > part of a remediation program? Another fact to bear in mind when discussing this is that, for a number of reasons, and unlike e.g. Microsoft, Mozilla has no formal contract with the CAs in its program. The relevance of that to this idea should be reasonably obvious. :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On remedies for CAs behaving badly
On Mon, Jun 05, 2017 at 08:25:22PM -0500, Peter Kurrasch via dev-security-policy wrote: >Consider, too, that removing trust from a CA has an economic sanction >built-in: loss of business. For many CA's I imagine that serves as >motivation enough for good behavior but others...possibly not. I think it's a strong motivator, it's just that CAs trust that the collateral damage of broad distrust will prevent trust stores from deploying the sanction. Essentially, CAs use relying parties as a human shield against having meaningful sanctions deployed against them. Hence "Too Big to Fail". >(For example, who gets to keep the money collected?) Me, of course. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On remedies for CAs behaving badly
Consider, too, that removing trust from a CA has an economic sanction built-in: loss of business. For many CA's I imagine that serves as motivation enough for good behavior but others...possibly not.Either way, figuring out how to impose, fairly, an explicit financial toll on bad CA's is likely to be as difficult as figuring out any of the other remedies that are presently available. (For example, who gets to keep the money collected?)From: Matthew Hardeman via dev-security-policySent: Monday, June 5, 2017 10:52 AMHi all,I thought it prudent in light of the recent response from Symantec regarding the Google Chrome proposal for remediation to raise the question of the possible remedies the community and the root programs have against a CA behaving badly (mis-issuances, etc.)Symantec makes a number of credible points in their responses. It's hard to refute that the time frames required to stand up a third party managed CA environment at the scale that can handle Symantec's traffic could happen in reasonable time.In the end, it seems inevitable that everyone will agree that practical time frame to accomplish the plan laid out could take... maybe even a year.As soon as everyone buys into that, Symantec will no doubt come with the "Hmm.. By that time, we'll have the new roots in the browser stores, so how about we skip the third party and go straight to that?"Even if that's not the way it goes, this Symantec case is certainly a good example of cures (mistrust) being as bad as the disease (negligence, bad acting).Has there ever been an effort by the root programs to directly assess monetary penalties to the CAs -- never for inclusion -- but rather as part of a remediation program?Obviously there would be limits and caveats. A shady commercial CA propped up by a clandestine government program such that the CA seems eager to pay out for gross misissuance -- even in amounts that exceed their anticipated revenue -- could not be allowed.I am curious however to know whether anyone has done any analysis on the introduction of economic sanctions in order to remain trusted -- combined with proper remediation -- as a mechanism for incentivizing compliance with the rules?Particularly in smaller organizations, it may be less necessary. In larger (and especially publicly traded) companies, significant economic sanctions can get the attention and involvement of the highest levels of management in a way that few other things can.Thanks,Matt___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On remedies for CAs behaving badly
On Mon, Jun 5, 2017 at 9:16 AM, Ryan Sleevi via dev-security-policy wrote: > On Mon, Jun 5, 2017 at 11:52 AM, Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> Has there ever been an effort by the root programs to directly assess >> monetary penalties to the CAs -- never for inclusion -- but rather as part >> of a remediation program? > > The extent upon which there can be meaningful discussion about this is > going to be understandably significantly limited, for non-technical reasons. > > I can simply point you to the existing precedent and discussions around > such proposals: > > 2) Examine the CA/Browser Forum's multiple discussions around CA liability > in the context of EV, with Browsers uniformly voting against imposing > additional liability due to the fact that no liability claim for > misissuance has ever been successfully claimed, and thus it merely > represents an artificial barrier to market entry that predominantly Western > CAs use to exclude those in other jurisdictions It is also worth noting that many CAs are fairly small companies. Many CAs are privately held or small portions of much larger companies, so estimating their sizes can be hard. However there are a few data points: Buypass posts total revenue (https://www.buypass.no/om-buypass/selskapet/n%C3%B8kkeltall): They reported revenue of 192 million Norweigan Krones in 2015; using today's exchange rate, this is about $23 million US dollars. WISeKey reported QuoVadis (whom they acquired) had revenue of $18 million US dollars in 2016 (https://www.wisekey.com/press/wisekey-completes-acquisition-of-cybersecurity-company-quovadis-and-becomes-an-pki-internet-of-things-security-industry-leader/) There are almost surely EV CAs that do even less revenue per year. Therefore what is small to one company may be huge to another. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On remedies for CAs behaving badly
+1 Thanks, M.D. On 6/5/2017 7:16 PM, Ryan Sleevi via dev-security-policy wrote: On Mon, Jun 5, 2017 at 11:52 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Has there ever been an effort by the root programs to directly assess monetary penalties to the CAs -- never for inclusion -- but rather as part of a remediation program? The extent upon which there can be meaningful discussion about this is going to be understandably significantly limited, for non-technical reasons. I can simply point you to the existing precedent and discussions around such proposals: 1) Examine the DigiNotar case, both with respect to liability and with respect to insurance 2) Examine the CA/Browser Forum's multiple discussions around CA liability in the context of EV, with Browsers uniformly voting against imposing additional liability due to the fact that no liability claim for misissuance has ever been successfully claimed, and thus it merely represents an artificial barrier to market entry that predominantly Western CAs use to exclude those in other jurisdictions 3) Examine CAs' CP/CPS statements with respect to disclaiming liability. 4) Examine CA's Relying Party Agreements regarding the obligations of an RP prior to having liability While on paper the idea sounds quite good, it turns out to simply trade technical complexity for complexity of the non-technical sort. As such, it's best to focus on meaningful and actionable technical solutions. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On remedies for CAs behaving badly
On Mon, Jun 5, 2017 at 11:52 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Has there ever been an effort by the root programs to directly assess > monetary penalties to the CAs -- never for inclusion -- but rather as part > of a remediation program? > The extent upon which there can be meaningful discussion about this is going to be understandably significantly limited, for non-technical reasons. I can simply point you to the existing precedent and discussions around such proposals: 1) Examine the DigiNotar case, both with respect to liability and with respect to insurance 2) Examine the CA/Browser Forum's multiple discussions around CA liability in the context of EV, with Browsers uniformly voting against imposing additional liability due to the fact that no liability claim for misissuance has ever been successfully claimed, and thus it merely represents an artificial barrier to market entry that predominantly Western CAs use to exclude those in other jurisdictions 3) Examine CAs' CP/CPS statements with respect to disclaiming liability. 4) Examine CA's Relying Party Agreements regarding the obligations of an RP prior to having liability While on paper the idea sounds quite good, it turns out to simply trade technical complexity for complexity of the non-technical sort. As such, it's best to focus on meaningful and actionable technical solutions. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
On remedies for CAs behaving badly
Hi all, I thought it prudent in light of the recent response from Symantec regarding the Google Chrome proposal for remediation to raise the question of the possible remedies the community and the root programs have against a CA behaving badly (mis-issuances, etc.) Symantec makes a number of credible points in their responses. It's hard to refute that the time frames required to stand up a third party managed CA environment at the scale that can handle Symantec's traffic could happen in reasonable time. In the end, it seems inevitable that everyone will agree that practical time frame to accomplish the plan laid out could take... maybe even a year. As soon as everyone buys into that, Symantec will no doubt come with the "Hmm.. By that time, we'll have the new roots in the browser stores, so how about we skip the third party and go straight to that?" Even if that's not the way it goes, this Symantec case is certainly a good example of cures (mistrust) being as bad as the disease (negligence, bad acting). Has there ever been an effort by the root programs to directly assess monetary penalties to the CAs -- never for inclusion -- but rather as part of a remediation program? Obviously there would be limits and caveats. A shady commercial CA propped up by a clandestine government program such that the CA seems eager to pay out for gross misissuance -- even in amounts that exceed their anticipated revenue -- could not be allowed. I am curious however to know whether anyone has done any analysis on the introduction of economic sanctions in order to remain trusted -- combined with proper remediation -- as a mechanism for incentivizing compliance with the rules? Particularly in smaller organizations, it may be less necessary. In larger (and especially publicly traded) companies, significant economic sanctions can get the attention and involvement of the highest levels of management in a way that few other things can. Thanks, Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
