On Mon, Jan 15, 2018 at 4:22 PM, Ryan Sleevi <r...@sleevi.com> wrote:
> > > On Mon, Jan 15, 2018 at 4:11 PM, Eric Mill via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> That said, GlobalSign's offer to cut certificate lifetimes down to X >> months >> during the short-term, and to make sure OneClick is disabled within Y >> months from now, seems like a reasonable compromise that doesn't undercut >> the incentive for GlobalSign or their customers to rapidly transition to >> more secure methods. It seems like there should be a value of X and Y that >> are acceptable. >> > > There are a lot of factors to consider, as I tried to highlight, that > contribute to whether or not X can be > 0 and whether Y can be > 0 (e.g. no > issuance, immediate discontinuance) at all. That is, these additional > factors beyond the protocol itself inherently contribute to whether or not > there is a generalizable answer. Factors such as ecosystem impact versus > ecosystem risk, existing practices that can be used as mitigating factors, > the level of trust necessary to ascribe to the issuing CA (and the steps > that are taken to mitigate failures of that trust) - all influence that > calculus. > I can only go on what's on the public list, but if it is as it appears and GS proactively researched their offering, identified a similar weakness via a separate BR method, and voluntarily turned off their implementation right away, that is the kind of activity I would think Mozilla and Google would want to encourage (and not accidentally penalize). An X of 3 months (90 days) and a Y that resembled Let's Encrypt's deprecation timeline, might help offer a lifeline without introducing unacceptable risk. I understand that there are other factors, including the level of review the protocol has been subject to and a holistic consideration of GlobalSign's infrastructure and history, including non-public information, and I'm not saying it would be necessarily unfair to keep GS' OneClick offline for shared hosts. But I do think that incentivizing proactive security interventions on the part of CAs is another factor worth considering. -- Eric -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
