On Tue, Nov 6, 2018 at 4:48 AM Wiedenhorst, Matthias via
dev-security-policy <[email protected]> wrote:
> Section 4.5 of ISO/IEC 17065 states that in general all non-public
> information shall be regarded as confidential. However, that section also
> allows that CAB and TSP can agree between each other about information not
> to be regarded as confidential.
> Our interpretation (which we think is aligned with current interpretation
> of general data protection legislation informally stated as “everything
> which is not explicitly required/allowed is forbidden”), indeed follows a
> minimum principle. So you are right, with consent of the TSP it is possible
> and we are willing to request such consent in future.
> We suggest the establishment of general rules / requirements valid for all
> auditors instead of individual / different commitments. These rules could
> be on the content of public audit reports and on the roles of audits during
> security incidents including reporting and should allow browsers and the
> interested community to obtain the necessary information to get a good
> picture on the incident and the assessment of the auditor.
>
I fundamentally disagree with this approach, and believe that rather than
creating a common baseline, this would lower the bars for security and
reliability. This is because auditors, such as TUVIT is doing so here,
would argue "We were only doing what we required" - without recognizing
fundamentally that things evolve, and auditors need to evolve with them.
Consider the examples given of other auditors that have found ways to
disclose more information to relying parties and browsers. They've shown
that there's the ability and necessity to step up to meet community
expectations. All auditors should be encouraged to do so - to constantly
improve. To the extent we specify a common baseline, it will forever be
that - the lowest bar, but not reflective of expectation or need.
A CAB wishing to provide high assurance to the users of its reports, and to
the TSP-using ecosystem, would constantly be looking for ways to improve
the assurance, and to publicize those best practices, so that other CABs
may learn and integrate such practices.
> 3. The argument that T-Systems has 3-months to revoke these certificates -
> while I understand that under ETSI TSPs have 3 months to correct minor
> non-conformities, using that as an excuse to ignore CAB Forum revocation
> requirements is unacceptable, and perhaps explains why we see such poor
> compliance with this requirement. If this is indeed the accepted
> interpretation (please confirm), then I will look for ways to fix this via
> Mozilla policy.
>
> - Wayne
>
> From the ETSI certification point of view, this is the interpretation.
> Failure to revoke within the required timeframe is clearly a
> non-conformity. Nevertheless, if the non-conformity has been rated as minor
> non-conformity (due to the individual circumstances), there would be a
> period of 3 month before the corresponding ETSI certification would be
> withdrawn.
> However, we do see your concern and it is a very reasonable one. Using
> this construct to deliberately delay revocation is not at all desired. How
> could we deal with it?
>
One is to reconsider how you're classifying minor non-conformities. It
certainly does not align with industry best practice - as reflected through
the Root Program agreements that exist, so how do you, as the CAB, defend
those classifications?
Another is to recognize that the CAB (and/or SB, depending) must be
notified of anything the TSP changes that may affect the conformity, and
there is a public interest in making that information available. Having the
CAB notify the program of any non-conformities found, both those that
affect certification and those that do not ("minor" non-conformities),
would help ensure the necessary public confidence in ETSI, and be a step
above what WebTrust provides.
> One possibility would be for the CAB to mandatorily require the TSP to
> publish the failure to adhere to the certificate revocation timeline
> requirement as bug in the Bugzilla (as already required from the TSP by
> Mozilla Policy) before the rating as minor non-conformity is possible.
> Without publication, it has to be rated as major non-conformity and hence
> an existing ETSI certificate will be withdrawn. This would facilitate the
> interest of transparency and would allow Mozilla, if regarded necessary, to
> take further action regardless of a still existing ETSI certificate. In the
> past, the ETSI certificate was not regarded as the primary audit
> deliverable by root store operators; this is the audit attestation letter.
> Combined with number 2 above, in such the case the next audit attestation
> letter would also state the failed revocation deadline as non-conformity.
>
This is somewhat self-contradictory. For years, we've been told by ETSI
CABs and audited CAs that the value is in the certification, and the
certification has consistently been what has been provided to Root Store
Operators. As Root Store Operators have begun pointing out the
certification alone is deficient in the information, we've seen CABs say
start using 'this' report instead - even though the whole assurance of the
audit is based on the certification and the auditor's accreditation thereof.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
