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. As worded in the BRs, .9 and .10 do not, in and of themselves, given the facts, provide sufficient level of interoperable assurance. Their continued use is a holistic examination not just as to whether or not it is possible to design methods compliant to the existing language and/or whether to remove the existing language, but whether or not their usage represents an immediate risk to the ecosystem. To some extent, this is a similar discussion to the question of SHA-1 issuance post it being forbidden (due to security reasons), and whether sufficient information can be determined as to mitigate the limited risk. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
