On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 18 months is not significantly different from 825 days. So there's really > no benefit. > So it sounds like you're supportive of 13 months, then, so that we arrive at an effective and meaningful maximum. > People have to stop wanting to constantly change the max validity period. > This is an entirely unproductive line of reasoning. The only reason that we're at a point of discussing incremental approaches seems to be because CAs resisted making meaningful steps all at once, and instead preferred a phase-in, like SHA-1. Proposals were put forward to make it a significant and meaningful difference, and there appeared to be wide browser support in spirit - and the only question being about the timing of the phase in. Thus, it seems reasonable to begin discussing how to approach that - and it doesn't seem productive to suggest the community should not discuss this. > It's difficult enough to communicate these changes to consumers and > customers, and it really drives them nuts. I can only imagine what a > non-integral number of years will do to various company's planning > and budgeting processes. > So this argues in favor of 13 months, rather than 18 months. The communication difficulties are not expanded upon here, but it seems that if CAs spent more time investing in interoperable automation, these communication issues would evaporate, because they'd no longer be an issue. > I would propose, instead, a minimum one year moratorium on proposals > to change the max validity period after the previous change to the max > validity period goes into effect. That would make much more sense. > I'm sure to a CA it makes sense, especially if the argument is that change is hard for them to do. Yet, at the same time, attempts to propose moratoriums on misissuance by CAs have consistently failed. A moratorium on discussions on how to reduce risk only seems valuable if would also imposed a moratorium on trust for those CAs that have issues. Since I'm sure that's not desirable for CAs, I hope we can agree that discussions of how to reduce the risk of such issues is highly relevant and necessary to resolve. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
