<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 2, 2019 at 8:26 PM Tobias S. Josefowitz <<a href="mailto:tobij@opera.com">tobij@opera.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 31 May 2019, Ryan Sleevi wrote:<br>
<br>
> On Fri, May 31, 2019 at 1:02 PM Tobias S. Josefowitz <<a href="mailto:tobij@opera.com" target="_blank">tobij@opera.com</a>><br>
> wrote:<br>
><br>
>> instance before T=10. Whatever the implementation would be (unless maybe<br>
>> in case it is designed solely to fulfil the requirements in the most and<br>
>> obvious degraded ways),<br>
><br>
> This is my operating assumption, which has been borne out of the incident<br>
> reports and issues seen.<br>
<br>
I find it hard to follow you there; I think this may be a bridge too far. <br>
I can easily work with the assumption that some CAs would develop <br>
"interesting" interpretations and implementations when it provides them an <br>
advantage as well as when it allows them to be lazy. I am not willing to <br>
accept - yet - that CAs would invest significant effort to develop such <br>
"interesting" interpretations and implementations just to spite ... <br>
Certificate Consumers, users, essentially, everyone.<br>
<br>
Short of detecting individual changes quasi-immediately, timestamping them <br>
and holding them in a queue for checking for 7 days, I do not see how the <br>
timelines you suggest would be achieved by CAs, and I really do not see <br>
any incentive or lazy path that would get us there. CAs have nothing to <br>
win by detecting late, and implementing late detection while staying <br>
compliant would take lots of effort, negating laziness as a route.<br></blockquote><div><br></div><div>Again, I encourage you to review the past and ongoing CA incidents, and you can see that this thing you see as unlikely - and attributing a particular intent to - is incredibly common, whether through intent or practical execution. The goal of the requirements is not to rest on what the author intends, but to ensure both unambiguous interpretation in the expectations and their desired outcomes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This does however not mean that I would be fundamentally opposed to add <br>
language to prevent "to-spite" implementations, however I am unsure of the <br>
need at this point.<br></blockquote><div><br></div><div>Great. Now that we're clear on what the 'intent' is, it's necessary to find a way to bridge that.</div><div><br></div><div>I wonder if the form of "Must do X in order to achieve Goal Y" represents a useful framing here. The attempted reformulation of this ballot appears to be focused on achieving Goal Y (with significant deferrence given to the CA as to the goal), without consideration of the minimum implementation. Perhaps understanding what the issue is with the existing language may help to find a better way to formalize that - I'm still unclear as to what you see as the root or underlying issue with X that requires modification.</div></div></div>