On Wed, Nov 14, 2018 at 10:39 PM Wayne Thayer via dev-security-policy < [email protected]> wrote:
> While I see some small steps being made toward a common understanding of > the issue, there is still fundamental and subjective disagreement on the > severity, and it's not clear to me that this thread is headed toward any > sort of a constructive conclusion. > I think one area that I've been trying to focus on, independent of the past issues that Jakob is exploring, is a better understanding of TUViT's processes with respect to compliance. While it's certainly true that they've acknowledged that they have not and did not develop tools to check compliance of certificates against the published ASN.1 modules, I think it would benefit the community to better understand TUViT's approach to auditing and ensuring compliance. For example, how many processes rely on human review? Is sampling employed, how are sample sizes selected, what is tested within the sample, etc. These are matters that can be discussed and explored without the retrospective analysis, and provide insight into the current issue. The benefit of the retrospective analysis is that we can then also explore and understand if and how these processes were changed due to past oversights, and whether or not past oversights should have been caught by the described processes. This helps ensure that future issues can be detected more timely. Separate from that discussion - of the present issue - is a question about whether or not TUViT's adherence to the minimum amount required represents a sufficient level of assurance going forward. If, as a community, the approach TUViT is taking is not acceptably transparent, next steps can be explored. These next steps may include suspending TUViT's recognition until process changes to achieve the necessary transparency are met, or may involve clarifying more generally the degree of transparency required for audits within the program. This may be accompanied by a further exploration of the ETSI accreditation standards with regards to best practices. Put differently, the demonstration of more transparent reports from other auditors accredited under ETSI-developed standards may indicate that TUViT is failing to meet industry best practices, or it may serve as an opportunity to codify those best practices as program requirements. Obviously from the discussion, I believe disagree with Jakob on the best approach to achieving these goals. I think it's far more important and relevant to make sure we have a comprehensive understanding of the /current/ issue with respect to competence and transparency before comparing and contrasting that with past issues. I think if we can spend our energies focused on this specific issue, then we can make some forward progress. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
