[Servercert-wg] Ballots SC20 and SC21

Ryan Sleevi sleevi at google.com
Mon Jun 3 07:28:54 MST 2019


On Sun, Jun 2, 2019 at 8:26 PM Tobias S. Josefowitz <tobij at opera.com> wrote:

> On Fri, 31 May 2019, Ryan Sleevi wrote:
>
> > On Fri, May 31, 2019 at 1:02 PM Tobias S. Josefowitz <tobij at opera.com>
> > wrote:
> >
> >> instance before T=10. Whatever the implementation would be (unless maybe
> >> in case it is designed solely to fulfil the requirements in the most and
> >> obvious degraded ways),
> >
> > This is my operating assumption, which has been borne out of the incident
> > reports and issues seen.
>
> I find it hard to follow you there; I think this may be a bridge too far.
> I can easily work with the assumption that some CAs would develop
> "interesting" interpretations and implementations when it provides them an
> advantage as well as when it allows them to be lazy. I am not willing to
> accept - yet - that CAs would invest significant effort to develop such
> "interesting" interpretations and implementations just to spite ...
> Certificate Consumers, users, essentially, everyone.
>
> Short of detecting individual changes quasi-immediately, timestamping them
> and holding them in a queue for checking for 7 days, I do not see how the
> timelines you suggest would be achieved by CAs, and I really do not see
> any incentive or lazy path that would get us there. CAs have nothing to
> win by detecting late, and implementing late detection while staying
> compliant would take lots of effort, negating laziness as a route.
>

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.


>
> This does however not mean that I would be fundamentally opposed to add
> language to prevent "to-spite" implementations, however I am unsure of the
> need at this point.
>

Great. Now that we're clear on what the 'intent' is, it's necessary to find
a way to bridge that.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190603/19d9f765/attachment.html>


More information about the Servercert-wg mailing list