On Fri, Nov 2, 2018 at 1:31 PM clemens.wanko--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> II. Assessment and certification statements: > - ETSI requires the auditing of the past period as well as of the current > operations status: > o In chapter 7.9 of the ETSI EN 319 403, it is clearly stated that the > operation records shall be audited (that will be detailed within a future > updated version of ETSI EN 319 403. On top of that it is planned to make > the ETSI TS 319 403-2 binding in order to have an even better definition > what is required to be audits for the past period). > However, as has been privately noted in the past, a CAB may achieve this requirement by examining a single operational record or issued certificate, without regard to any other actions. Or they may not consider any certificates at all, and merely consider other operational aspects; for example, that the policy management authority met to review the policy documentation. While you may argue that a well-behaved CAB would not undertake such a limited examination, I hope you can provide a citation if this is, in fact, not permitted within the scheme. I do not believe that having 119 403-2 binding will, in and of itself, improve this situation. This is perhaps a difference in fundamental approach with regards to the framework used by ISO/IEC 17065 and the necessary and desired output. More work would be needed to resolve this in a satisfactory way. However, independent of whatever normative requirements may existing within the framing of 119 403-2, 319 403, or more broadly, ISO/IEC 17065, we must separately assess whether or not the result is meeting that of community expectations. As we've seen, there are auditors who have found ways to achieve the necessary transparency and assurance despite 319 403 not formally requiring this. Similarly, in the context of WebTrust, we've seen there are auditors who meet not just the letter, but the spirit, and there are auditors that ostensibly fail to meet both. With regards to past activities - or those of assessing for future - I hope we can agree that repeated failures by a TSP demonstrate a failure of the CAB to appropriately review and supervise. As the CAB and Supervisory Body (in the context of qualified services, as that is the only place it operates ex ante) both serve to review those changes, output which is non-conforming demonstrates not just a failure by the TSP, but also that of the CAB. > Let’s keep in mind - please! - we are all pulling the same rope for more > security more confidence and reliability. We should take extra care to pull > in the same direction - all together - and invest our precious energy in > improving the ecosystem rather than blaming each other with the high risk > of damaging it. While this is a compelling call, within the context of CABs, a CAB that does not "pull their weight" is in fact a CAB that "drags everyone down"; whether you prefer to think of that, in the context of this metaphor, as pulling in the opposite direction or, perhaps more clearly compared, 'getting in the way,' the role of CABs in the CA ecosystem is not one of receiving participation stickers for showing up. They perform a necessary and critical function, and the failure to adhere to those expectations is reason to have meaningful discussion and take steps to correct the issue. In the CA and auditor ecosystem, those steps include matters like distrusting CAs or disqualifying auditors. It is not acceptable, nor has it ever been, to suggest that there are no consequences for misissuance or dereliction of duty, whether on behalf of the CA or the auditor. When an entity poses or introduces risk to the ecosystem, the ecosystem appropriately responds by cutting that risk out. That is not to say there are not opportunities to improve, but it would be irresponsible to suggest that we ignore the active damage being caused in the name of comity and camaraderie - to do so is foolishness. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
