[Servercert-wg] Ballots SC20 and SC21

[Tobias S. Josefowitz]

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.

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.

> I don't share this optimism. As a practical matter, I expect the time
> between checks to be *greater* - that is, rather than checking every T=7
> days, they'll move to check every T=10 or T=14. As long as nothing goes
> wrong, they're wholly in compliance with the /new/ requirements, whereas
> they'd be out of compliance under the /existing/.

I would say that any implementation is to be measured for compliance also 
against hypothetical unwanted (and thus unpredicted) changes, but my 
interpretation may well be clouded by my intent here. I would thus suggest 
to add "*any possible* policy- and standard violations shall be detected 
within at most seven (7) days", or any even better language that will 
ensure that compliance is to be measured against possible, not actual 
changes/violations.

> Hopefully the above shows how, as a practical matter, the proposed changes
> would create a deferral of detection of non-compliance to being when
> there's an issue and a NetSec violation, rather than the current approach,
> which would flag it during audit. As I said, I can see value in both
> approaches, but that's why I think it needs to either be clearly stated
> both the implementation and the result, which is additive, rather than
> replacing.

When it comes to the timeline question specifically, I would really think 
that it must be possible to come up with a provision that suitably deals 
with all cases. At the very least I would say that "you must do X, and 
then you also must do (basically?) X again, weekly" is not very elegant.