Wayne, We have discussed your concerns with EU stakeholders and offer the following responses. These concerns have been discussed with Webtrust and we believe that the proposals below are in line with existing accepted practices. Comment 1) We need standards that require consistent disclosure of all types of non-conformities in attestation statements. Response The current requirement in EN 319 403 is a TSP audit may be passed with pending non-conformities provided that these [non-conformities] do not impact the ability of the TSP to meet the intended service. If there are other non-conformities no Audit Attesttion is issued. It is proposed that ETSI extend the requirements in TS 119 403-2 to require the Audit Attestation for Publicly Trusted Certificates to include a statement on each sub-clause of the referenced requirements where there is a finding of nonconformity which does not impact the ability of the TSP to meet its intended service. Comment 2) Disclosure is required even if a CA fixes a non-conformity within an acceptable time frame (based on ETSI standards). Response As above, it is proposed that ETSI extend the requirements in TS 119 403-2 to require the Audit Attestation for Publicly Trusted Certificates to include a statement on each sub-clause of the referenced requirements where there is a finding of nonconformity noted during the audit which had been corrected prior issuing the Audit Attestation. Comment 3) Disclosure when a CA violates the BR revocation timeline requirements, even if their actions are perfectly acceptable under ETSI standards for remediation. Response It is not clear to where the BR revocation requirements differ from those of the ETSI standards which would allow violation of timeline requirements to be considered as non-conformant in a way which does do not impact the ability of the TSP to meet the intended service, and hence can come under the allowance for time to remediate. In any case such a situation would be covered by the proposed change in item 1) Comment 4) Disclosure of testing and sampling methodologies used in an audit. ETSI follows the practice it is understood is followed by Webtrust. Information on testing and sampling methodologies is available in detailed reports but is not disclosed in to the public in any detail. Nick Pope Vice Chair ETSI TC Electronic Signatures and Infrastructures
On Wednesday, November 21, 2018 at 3:20:51 PM UTC, Nick Pope wrote: > Wayne, > > We will work on how to address this within the EU audit framework based on EN > 319 403. > > TS 119 403-2 already includes some additional requirements specifically for > PTC to cover the CABF concerns for yearly audit and period of time audit > review of events since the previous audit. An update to this document to > address these concerns is an option that we will consider. > > My I ask for you patience and forbearance in the time taken to carry out this > work. > > Nick > > On Monday, November 19, 2018 at 11:01:54 PM UTC, Wayne Thayer wrote: > > Hi Nick, > > > > I had been thinking that 119 403-2 was just intended as an attestation > > statement template, similar to the WebTrust reporting guidance [1]. Now I > > understand that it can include more substantial requirements. > > > > This is certainly not a complete list, but specific to this discussion I > > would start with the following concerns: > > * Reporting on major and minor non-conformities - I have yet to ever see an > > ETSI attestation listing a major non-conformity, but I have shared several > > examples listing minor non-conformities with ETSI representatives. We need > > standards that require consistent disclosure of all types of > > non-conformities in attestation statements. Disclosure is required even if > > a CA fixes a non-conformity within an acceptable time frame (based on ETSI > > standards). > > * Disclosure when a CA violates the BR revocation timeline requirements, > > even if their actions are perfectly acceptable under ETSI standards for > > remediation. > > * Disclosure of testing and sampling methodologies used in an audit. > > > > - Wayne > > > > [1] http://www.webtrust.org/practitioner-qualifications/item64422.aspx > > > > On Mon, Nov 19, 2018 at 8:25 AM Nick Pope via dev-security-policy < > > [email protected]> wrote: > > > > > Restating my earlier offer we would welcome a clear statement of any > > > concerns or wishes resulting from the discussions, on this or other > > > related > > > threads, against the measures already proposed in TS 119 403-2 and its > > > parent standard. We can then discuss this with the European stakeholders > > > and see how we could best answer these concerns > > > > > > Nick > > > > > > On Friday, November 16, 2018 at 4:46:34 PM UTC, Wayne Thayer wrote: > > > > On Thu, Nov 15, 2018 at 1:51 PM Ryan Sleevi <[email protected]> wrote: > > > > > > > ... > > > > > > > > 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
