<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 10:14 AM, Scott Rea <span dir="ltr"><<a href="mailto:scott@scottrea.com" target="_blank">scott@scottrea.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that is a good summary Ryan.<br>
<br>
We are essentially weighing up the difference of adding 2 days to the<br>
minimal possible time for a potential screw up vs a potential<br>
significant reduction in effort for some CAs who accommodate multiple<br>
trust communities.<br>
<br>
I think the latter outweighs the former, and actually reduces the risk<br>
of a correct implementation of the former by those who fall into the<br>
category of multi-trust community support. Lower risk because their<br>
renewal algorithms only need to accommodate the one value rather than<br>
having to check which trust community it is, decide which one takes<br>
precedence if its both, and implement a different value depending on the<br>
outcome. Simpler algorithm, should be lower risk, faster implementation.<br>
<br>
400 is a win-win, whereas 398 is a win-we-don't-give-a-crap...</blockquote><div><br></div><div>Well, there's a critical piece of information still missing - which is understanding who this _actually_ affects versus _theoretically_ affects.</div><div><br></div><div>If it's burdensome to one CA, but that CA is not participating in the Forum, it's hard to understand what impact or concern it would have on them, or why their concerns should trump the concerns of "smallest possible time".</div><div><br></div><div>If it's burdensome to all CAs, then I agree, it might be worth re-evaluating.</div><div><br></div><div>However, it also reiterates the point which we seem to have agreement on - that the Forum exists to set its own rules independent of any other programs. If anything, as SHA-1 has taught us, it may very well be that the Forum may occasionally need to be the more 'aggressive' operation. After all, it's also possible to see the other WebPKIs realize that 398 is better than 400, or even that 91 or 181 are better than 398, and we can all be incrementally pushed to improvement.</div><div><br></div><div>Or it may just be that we attach differing weight as to the value of overlap with other PKIs - I might see no value, you might see strong value. The task for each of us is to help the other understand the why, and if there's room for compromise. I think we might be on the same page as to why I view overlap with other PKIs as a negative, rather than a positive, but I'm still uncertain as to why you see it as a positive.</div><div><br></div><div>That said, we may just have to agree to disagree. Not because "we-don't-give-a-crap", but because our worldview and perspectives disagree, and I see it as more negative than positive. And this view of negativity for overlap is not simply because of this matter (which, on its own merits, is agreeably minor), but to the endemic and systematic attempts at overlap - which, as we've seen with SHA-1 and we've seen in discussions such as root direct issuance (for "administrative certificates" or "legacy certificates"), overlap can be actively harmful. So I take the principled stance to avoid overlap whenever possible, unless it can be demonstrated that the value is not from overlap-for-overlaps-sake, but through a natural and logically sound argument from shared principles.</div></div><br></div></div>