On Mon, Oct 30, 2017 at 5:39 PM, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > Importantly, > > within 17065 and 17021, the way of ensuring continued compliance is done > > based on contracts and reporting - that is, the client is responsible for > > reporting changes to their conformity assessment body, and the CAB may > > determine to revoke the certification or indicate corrective actions > should > > be taken (see ISO/IEC 17065:2012(E) 4.1.2.2, ISO/IEC 17021:2006(E) > 8.6.3). > > ISO/IEC 17065:2012(E), Section 7.7 describes the general reporting: the > > name of the CAB, the date the certification is granted, the name and > > address of the client, the scope of the certification, the validity > > period/expiration date of the certificate, and anything else required by > > the certification scheme (319 411-1). > > > If I am understanding correctly... an ETSI auditor performs a > point-in-time audit and then relies on the CA to notify the auditor of > material changes. > That is my understanding as well. > Wish I could say that I believe that would work. Unfortunately, based on > my experience with CAs I do not believe the CAs will be pro-active in this > way. And I think the only way to really know what a CA is doing is to look > at their data -- look at the actual certs they are issuing, and their > documentation regarding such certs/issuance. > 17065 and 17021 do specify that there is review of historic data - largely, to determine whether or not the specified control was operating correctly. However, 17065/17021 do not specify how far back the CAB needs to look - that's left for the specific criteria being applied (e.g. EN 319 411-1, 319 401, and 319 403) The best way to explain how the ETSI audits work that I can think is to have a read on Section 7.4.5 of EN 319 403 v2.2.2 (the latest version at https://portal.etsi.org/tbsitemap/esi/trustserviceproviders.aspx ). The audit is done in two stages. In the first stage, the TSP provides documentation to the CAB about their systems and practices and the CAB works with the TSP to gather documentation. After this, there's a site visit - Stage 2 - in which the auditor attempts to confirm the TSP is adhering to its practices. As you can read, these are about evaluating processes going forward. There is retrospective analysis - such as document review and the Stage 2 evidence collection - but not the period-of-time analysis as done within WebTrust-based audits. Further, if you look at Section 7.6, it's worth noting that: """ a TSP audit may be passed with pending nonconformities provided that these do not impact the ability of the TSP to meet the the intended service. This certification decision is conditional upon to the implementation of corrective actions within 3 months after conclusion of the audit (depending on the type and criticality of the correction(s)) """ > > The challenge is in determining whether this is a correct understanding > of > > the respective differences, > > > How do we verify that this is correct? > I would expect that it would be incumbent on the CABs and the CAs providing EN 319 411-1 certificates to help the community better understand the level of assurance provided. That is, I think those supporting the continued recognition of ETSI should attempt to demonstrate where either the understanding of WebTrust-based audits or EN 319 411-1 certificates is incorrect or inaccurate. Otherwise, I think your conclusions - about no longer recognizing such schemes - are reasonable. > Based on what I've seen with CAs over the past several years, I do not > believe the 'forward-looking' approach with self-reporting is sufficient. > Agreed > I think we have to (and we do!) require the backward-looking approach. > As noted, there is some retrospective analysis - document review and evidence gathering - but the fundamental process of a 319 411-1 audit seems to be with such a different objective and way of measuring that WebTrust to ETSI is like comparing apples to oranges. > CAs can make all the "future promises" they want, but the proof is in the > resulting data -- the certs that they issue. > > Based on the above information, I do not think the ETSI audits meet the > requirements of Mozilla's Root Store Policy or the CA/Browser Forum > Baseline Requirements. Maybe that's the real problem here. > > Am I missing something? I've been increasingly thinking the same thing. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
