On Thu, Nov 15, 2018 at 1:51 PM Ryan Sleevi <[email protected]> wrote: > > 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. > > I thought you were focused on the current T-Systems issues. I do see value in that "case study" approach, but now it sounds like you're asking TUViT to describe some of their methodology? Have you posed specific questions in this area to TUViT? I just reviewed this thread but didn't notice that.
TUViT posted an incident report to the bug that does describe the testing and sampling performed for the T-Systems audit: https://bugzilla.mozilla.org/show_bug.cgi?id=1507376#c2 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. > > I am not sensing much support for taking a punitive approach, but I continue to support the creation of more program requirements around audits and audit reporting. Do you have any suggestions for how we can make progress on that? 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. > In either case, I think we're missing normative guidance to objectively distinguish poor judgement from policy violations. To that end, I think Nick's request for us to better define root program expectations is a reasonable one. Analyzing current and past issues can certainly help us to define these requirements. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
