[Servercert-wg] Ballots SC20 and SC21

[Ryan Sleevi]

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

> >> It is not our intention to provide more discretion to CAs or auditors,
> but
> >> to gain clarity as to what monitoring is the minimum requirement. This
> is
> >> important because in order to design their system monitoring controls,
> CAs
> >> require a definition of which security metrics should be monitored.
> Ballot
> >> SC-20 outlines those configurations that the NetSec committee considers
> >> security-relevant (as a minimum).
> >>
> >
> > Then the ballot needs to be changed, because as written, it allows for
> > subsetting the existing systems and thus excluding, from scope, items
> which
> > are presently in scope. Further, it does not clarify that it serves as a
> > minimum, nor does it express the principles for what might be seen as
> > appropriate for additional scoping, which has the consequential effect
> > (with the previous change) of thus being seen as setting a 'maximum'.
>
> The mechanism that you refer to/propose for "exlcuding items from scope"
> would here be by going from "Review configurations" to "shall identify
> which configurations [...] are security relevant. [...] violations shall
> be detected within at most seven (7) days", or do you see another one
> even?
>

The current language is inclusive of all systems and changes. A failure to
achieve that thus rests with the CA.

Under the proposed language, the CA determines the scope (via "shall
identify"), and determines the process ("documented assessment"). This
means that issues that occur in the systems outside of the identified
configurations, or which are not included within the documented assessment,
are no longer matters of non-compliance. The CA followed its documented
assessment for the identified configurations - and the failure to
appropriately identify configurations or assess is not, in fact, a NetSec
violation, but merely an operational failure by the CA, subject to debate.

That's the situation I'd like to avoid.


> > Except, for relying parties - and importantly, for browsers - this
> removes
> > a degree of transparency and certainty in interpretation, and instead
> > replaces it with ambiguity and discretion. This is why I say this change
> is
> > also a net-negative.
>
> The mechanism leading to loss of transparency and certainty in
> interpretation also being ... moving away from "Review configurations"?
>

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.

Under the proposed language, the CA is given full discretion to identify
the systems that are security relevant, and thus failures in that process
are not failures in the NetSec requirement. I think an excellent study of
this is the CAs which have failed to contemplate XSS protection within
their systems, or XML injection attacks, or other varieties of ways in
which they handle user-supplied data, which can allow exploiting the
RA-provided systems. The security assessments I've seen of CAs, both
independently reported and those provided by CAs, suggest this is rather
systemic and endemic. My approach has been to point to NetSec requirements
in that it includes all systems - including, say, their partner CDNs used
to deliver OCSP and CRL information.

The proposed change weakens that, without any room for debate.


> >> It is likely that under the current NSRs, CAs already make
> determinations
> >> on how the term ?configuration? should be understood in the context of
> >> their system environment. Thus, we do not see our proposal to reduce
> >> security. Rather, we aim to make a common process visible and
> measurable.
> >>
> >
> > Visible and measurable to whom? I see nothing to improve confidence of
> > Browsers and Relying Parties, and I see that as problematic, in
> combination
> > with the previous remarks.
>
> 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.

The solution for this in the BRs, at least, has been to require public
documentation everywhere CA discretion is given, either by form or as a
practical matter of root store policy. The existence of Certificate
Transparency is furtherance to this effect - as the shocking number of
Same-City and Same-State certificates shows, or the broader set of
https://wiki.mozilla.org/CA/Incident_Dashboard CA incidents, show that CAs
systemically struggle on both policy and practice when human judgement is
involved.

I can appreciate the appeal of moving from a more rigid set of
interpretations within the NetSec in to a model that is flexible for CAs
which truly are capable of doing new and innovative things /securely/ to be
able to do so. However, I think such CAs are, through demonstrable
evidence, not in the majority of those CAs trusted by browsers. Throw in
the challenges of interpretation, the issues with oversight (e.g. the ETSI
model of every EU member state defining their own NAB and SB and CAB
accreditation process), and the barriers in language, culture, and
expectations that exist, and such flexibility becomes rife for new issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190531/0f723537/attachment-0001.html>