[Servercert-wg] Ballots SC20 and SC21

[Ryan Sleevi]

On Fri, May 31, 2019 at 1:17 PM Tobias S. Josefowitz <tobij at opera.com>
wrote:

> I am a little short on time, so please allow me to cherry-pick one thing
> first that I think would really help me understand - I am also quoting
> very selectively because of that:
>

No worries!


>
> On Fri, 31 May 2019, Ryan Sleevi wrote:
>
> > On Thu, May 30, 2019 at 5:42 PM Tobias S. Josefowitz <tobij at opera.com>
> > wrote:
> >
> > The current language is inclusive of all systems and changes. A failure
> to
> > achieve that thus rests with the CA.
> >
> > The current language is functionally inclusive. All the enumerated
> systems
> > are in scope, and if a CA fails to review such a configuration, the CA
> has
> > violated the NetSec requirement.
> >
> > The proposed change weakens that, without any room for debate.
> >
> >> To whoever would be tasked to perform an audit.
> >>
> >
> > Right, and that's a problem, because the information provided by the
> audit
> > does not include the scope; neither the CA's materials nor the assessment
> > report include this. As a consequence, I, as a relying party, cannot be
> > confident that the sole security relevant system determined by the CA is
> > their router, which would be a wholly valid under the proposed language.
> > The auditor's fiduciary duty (in the case of WebTrust) or regulatory duty
> > (in the context of ETSI) is to the customer and/or supervisory body, and
> we
> > know this can be, has been, and likely is being gamed.
>
> But is it not the case that all a CA would have to say currently is "Hi
> Ryan, hi $auditor, meet Hans. Hans reviews our configurations weekly. He
> pinky-swears."? Sure, saying this would not technically make them
> compliant, but how do you even go about that distinction?
>

I think we're in agreement that the pinky-swear wouldn't be compliant. Your
question about how it would be detected is apt - I very much want to
improve the detectability, which is why I've focused and emphasized so much
on the importance of transparency (at least with respect to the BRs), which
we've seen has been tremendous. As our WebTrust and ETSI friends can
attest, I've similarly pushed for transparency in what they're assessing -
for example, having the auditor report that they found Hans' pinky-swear to
be an appropriate demonstration of compliance (which then allows me to look
closer at both the CA and the auditor).

However, in this case, I'm considering the 'when things go wrong' scenario.

When Hans doesn't do this, and the Web server gets popped and an XSS is
added to slurp the RA's/CA's credentials, and then use that to manually
approve a certificate for 'google.com' (for example), I go ask the CA for
an incident report and ask them to tell me what they were doing and why
their systems should have fixed this. When they reveal Hans wasn't actually
doing this, it's clear that the CA was violating the NetSec requirements,
and calls into question what the auditor was doing to assess that Hans was
and had been, since they clearly weren't. We've got an unambiguous
violation of the requirements.

Now, under the proposed language, the CA defines the scope such that Hans
is only supposed to check the router, and the documented procedure is that
Hans SSHes in and checks the access log and makes sure it hasn't changed
since Hans' last access. That meets the objective definition of the
requirement, as proposed, even if that's not the intent, due to the
subjectivity afforded. When the Web server gets popped and a bad
certificate is issued, during the investigation, the CA reveal that Hans
was only checking the router. The problem, now, is that the CA is going to
claim it "misunderstood" the requirements, whether through translation
issue, lack of technical knowledge or expertise, "Hans didn't train their
replacement", etc. The problem here, with the proposed language, is that
such a response might actually be valid and compliant with the NetSec
requirements! The auditor might not have caught it because it was their
first audit, and the CA was "confused" (whether malicious or ignorant, it's
impossible to tell), and we all declare it's a mulligan and the CA
continues on as if nothing happened.

This is why the interpretation and flexibility issue are so important, and
the need for the strict and objective requirements or, when it's not
possible to do (which is, understandably, many things), the need for
transparency in both the CA practices and the audits.

A canonical example of this is the disclosure that Mozilla requires of the
specific domain validation methods from 3.2.2.4 that are employed by a CA,
and not allowing their CP/CPS to simply say "We comply with this overall
section". But if you look through the incident reports, you can see how
frequently it's necessary to require the CA to demonstrate precisely how
they comply with a given requirement, and areas where flexibility is
afforded easily lends to misinterpretation which in turn leads to issues,
but for which the CA would claim isn't a violation (just a
misunderstanding), and thus any sanction is unwarranted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190531/0e0601b5/attachment-0001.html>