[Servercert-wg] Ballots SC20 and SC21

[Ryan Sleevi]

On Thu, May 30, 2019 at 7:44 PM Tobias S. Josefowitz <tobij at opera.com>
wrote:

> On Thu, 30 May 2019, Tobias S. Josefowitz wrote:
>
> > On Thu, 30 May 2019, Ryan Sleevi via Servercert-wg wrote:
>
> [...]
>
> >>  As noted, the math here shows the worst case is now the 'minimum'
> >>  requirement under this proposal. The existing requirements, while
> sharing
> >>  the 'worst' case, have a significantly better 'best' case, which is
> more
> >>  auditable as such.
> >
> > Well, except, how do you systematically *not* detect an issue in your
> > configuration for six days? If you have to detect within seven days, I
> would
> > suppose you have to check ... within seven days, i.e. at least weekly,
> and
> > once you detect, you detected.
>
> Ryan, is it in fact possible that you intepret 1h to mean that CAs should
> review configuration changes they make intentionally/knowingly and within
> their regular processes?
>
> The interpretation underlying SC20, at least as far as I am concerned, is
> that the objective is to first and foremost detect configuration changes
> that somehow "sneaked in", i.e. a software update changing configuration
> (would likely leave the changed config in violation of policy), staff not
> following the CAs internal process (really should be a policy violation),
> rogue staff (hopefully really would also be a violation of a CA's
> policies) or outright adversarial action (also, hopefully, against policy
> in and by itself).
>

Let T=0 be the time I perform my weekly review.
Let T=7 be the time I'm required to perform my next weekly review

If a configuration change is made, authorized or not, at T=3, then under
the existing 1.h, it will be detected at T=7
Under the proposed change, it may not be detected until T=10, which is +7
from the introduction.

The issue I have, and this is is similar to the discussion around
revocation timelines, is that it moves from an absolute scale (weekly) to a
relative scale (within 7 days). The worst case - an issue introduced at
T=0-and-one-second not being detected until T=7 (or T=7-and-one-second) is
in the noise - but case of an issue introduced at T=6 or
T=7-minus-one-second now doesn't get detected until T=13 or
T=14-minus-one-second.

There are benefits to the transition to a relative scale, and I'm
appreciative of those. Most importantly, under the existing language, an
auditor may deem a CA as meeting the BRs provided that they performed their
assessments at T=0 and T=7, and assess compliance regardless of whether or
not they actually detect the T=3 issue. The proposed change would make it
clearly non-compliant, in as much as if the T=3 issue is later detected at
T=23, they've clearly failed to meet the expectation of 1.h and detect it
within 7 days. It also attempts to make the change result oriented - by
assessing violations - rather than performance-oriented - equating
compliance with performing the review, rather than ensuring the review
produces the correct results. My claim is that I would seriously question
any auditor who claimed that a review that failed to determine whether or
not changes violated policies was a review satisfying these requirements,
but I can appreciate the desire not to have to rest on "Google
disqualifying auditors" as a safety valve.

I can appreciate the view that says in order to achieve the 7 day timeline,
then functionally if you last reviewed at T=0, then you have to review at
T=7, in order to ensure that T=0-and-one-second gets detected before
T=7-and-one-second, and that, under 'ideal' conditions, a CA would also
detect any issues from T=0-and-two-seconds to T=7-minus-one-second. But
that's not the leeway it gives CAs. It allows them to defer the stated
detection window to 7 days from the incident, and thus also delay
remediation. The practical application of the revocation policies, and the
interpretations I've heard privately from some CAs, such as internally
suppressing evidence of detection of misissuance until a time as it's
convenient to replace the certificate, by not declaring they've
"determined" misissuance (despite the BRs focusing on 'made aware'), have
demonstrated the need to be as clear as possible with the expectations, and
to read them as 'adversarially' as possible from the desired intent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190531/1bf25f81/attachment.html>