On Wed, Mar 8, 2017 at 8:46 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Yes, I agree they should be functionally equivalent, in the sense that
> all aspects of the operation and issuance are validated, and that one
> entity is ultimately responsible for the actions of the others.
>
> The distinction I am making is that the entity named as ultimately
> responsible ("the CA") needs an audit report that covers all the
> requirements with some requirements possibly audited in the form of
> auditing the presence of valid audit report from the other entities
> involved.
>
Except that, from discussions with a number of WebTrust auditors, there is
an issue accepting such evidence. So the scenario you describe further is
not what actually happens in practice - and this is part of the motivation
for the Policy suggestion I provided, so that theory and practice can align.
For example, an auditor will not necessarily examine the audits of other
parties - this is true whether the other party is, for example, a
datacenter operator (which relates to physical security principles), a
"Cloud HSM" provider (which relates to key security principles), or what
we've identified as a Delegated Third Party.
If the function is not at all performed by the CA, then as Peter has noted,
the auditor will not report on it - and as a consequence, be unable to
produce a seal.
If the function is _partially_ performed by the CA, then the auditor will
report to the extent that function is provided by the CA.
So the disconnect here is your assertion that auditors are examining these
reports - whether they be sub-CA or DTPs. The extent of the reporting an
auditor performs during such an engagement is to report on the controls
relative to the principles - e.g. does the CA have a documented process to
review such audits, does the auditor have an opinion that such controls
provide sufficient evidence to the criteria and principles, and were they,
to the extent for the period in question, performed as such.
So we end up in a situation where such audits are not required to be
disclosed (at present), such audits may not conform to the expected
standards (and the audits Symantec has provided amply demonstrate this),
and for which the auditor of the 'issuing CA' may provide a clean opinion,
because their opinion was scoped to the specific activities of those
provided by Symantec Corporation (notably, in its omission, excluding that
of delegated third parties). This does not seem a desirable outcome,
particularly because it conflicts with Mozilla's many improvements towards
transparency.
Each of the Policy proposals Gerv has mentioned ends up in this scenario of
insufficiently controlling for and disclosing the concerns related to
issuance.
So now we circle back to the provision of delegated third party services by
reforming it such that it's treated as an externally operated sub-CA. As
Peter has noted, the extent of such audits would need to include the full
activities of that sub-CA in some form - you don't get to carve that up. In
practice, I'm suggesting that the "Issuing CA", during their annual audit
cycle, would have all the relevant controls and policies examined for that
sub-CA as part of the audit engagement and scope, and would perform some
form of 'site visit' to examine the set of controls and procedures relative
to the function they provide. This is, I assert, functionally similar to
the site audits a number of auditors already perform with respect to
third-party datacenter operations (fairly common) or more complex cases
such as managed key material (rare, but done).
It has the benefit, however, of aligning the practice of what an audit
opinion covers (e.g. there's no carve-out for the DTP operations), when the
audit is disclosed (publicly), and the technical capability for distinctive
issuance. I further suggest that anything less is to undermine the goal and
intent of Mozilla policy, which is quite reasonable - know who can issue
certs and what their policies are.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
