"auditing standards that underlie the accepted audit schemes found in Section 8.1"
This is obviously a error in the BRs. That language is taken from Section 8.1 and there is no list of schemes in 8.1. 8.4 does have a list of schemes: 1. WebTrust for Certification Authorities v2.0; 2. A national scheme that audits conformance to ETSI TS 102 042/ ETSI EN 319 411-1; 3. A scheme that audits conformance to ISO 21188:2006; or 4. If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either (a) encompasses all requirements of one of the above schemes or (b) consists of comparable criteria that are available for public review. 1. is slight problematic as no scheme exists by that name, but "Trust Service Principles and Criteria for Certification Authorities Version 2.0" does exist, which is what I assume is meant. If we assume that audit scheme, my understanding is that the "auditing standards that underlie" the scheme is one of the following (which one depends on the date of the audit and the licensure of the auditor): (1) AT sec. 101 from SSAE No. 10/11/12 (AICPA) (2) AT-C sec. 205 from SSAE No. 18 (AICPA) (3) Section 5025 (CPA Canada) (4) CSAE 3000 (CPA Canada) (5) ISAE 3000 (IFAC) There should be no lack of auditing standards that underlie the Trust Service Principles and Criteria for Certification Authorities Version 2.0 audit scheme found in section 8.4. Thanks, Peter On Thu, Feb 23, 2017 at 1:19 AM, Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > I'm sorry, I'm still a little confused about how to understand your > response. > > I can't tell if you're discussing in the abstract - as in, you don't know > how an Delegated Third Party would ever meet that definition, due to the > absence of "auditing standards that underlie the accepted audit schemes > found in Section 8.1" therefore you don't think what Symantec has been > doing since 2010 is permitted by the Baseline Requirements at all, and they > should have stopped five years ago. That implies you read through the links > provided by Symantec so far of the four RAs that they assert were operating > as Delegated Third Parties (which is the only way this could have been > acceptable to begin with), but that you disagree that they're evidence of > compliance with the restrictions on the Delegated Third Parties. Is this > what you meant? > > Or if you mean something concrete - that is, that you literally are > interested and curious, without any subtext. In that case, it implies you > may not have checked the links in the message you were replying to yet, and > this was more of an aside, rather than a direct question. If this was the > case, do you think it's reasonably clear the question I'd asked of Steve? > > Or am I completely off the mark? I just want to make sure that the question > I asked is clear and unambiguous, as well as making sure I'm not > misunderstanding anything. > > On Wed, Feb 22, 2017 at 9:21 PM, Jeremy Rowley <jeremy.row...@digicert.com> > wrote: > >> I am aware of the requirements but am interested in seeing how an RA that >> doesn't have their own issuing cert structures the audit report. It >> probably looks the same, but I've never seen one (unless that is the case >> with the previously provided audit report). >> >> On Feb 22, 2017, at 8:48 PM, Ryan Sleevi <r...@sleevi.com> wrote: >> >> >> >> On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley <jeremy.row...@digicert.com >> > wrote: >> >>> Webtrust doesn't have audit criteria for RAs so the audit request may >>> produce interesting results. Or are you asking for the audit statement >>> covering the root that the RA used to issue from? That should all be public >>> in the Mozilla database at this point. >> >> >> Hi Jeremy, >> >> I believe the previous questions already addressed this, but perhaps I've >> misunderstood your concern. >> >> "Webtrust doesn't have audit criteria for RAs so the audit request may >> produce interesting results." >> >> Quoting the Baseline Requirements, v.1.4.2 [1] , Section 8.4 >> "If the CA is not using one of the above procedures and the Delegated >> Third Party is not an Enterprise RA, then the >> CA SHALL obtain an audit report, issued under the auditing standards that >> underlie the accepted audit schemes >> found in Section 8.1, that provides an opinion whether the Delegated Third >> Party’s performance complies with >> either the Delegated Third Party’s practice statement or the CA’s >> Certificate Policy and/or Certification Practice >> Statement. If the opinion is that the Delegated Third Party does not >> comply, then the CA SHALL not allow the >> Delegated Third Party to continue performing delegated functions. " >> >> Note that Symantec has already provided this data for the four RA partners >> involved for the 2015/2016 (varies) period, at [2]. Specifically, see the >> response to Question 5 at [3]. >> >> "Or are you asking for the audit statement covering the root that the RA >> used to issue from? That should all be public in the Mozilla database at >> this point." >> >> Again, referencing Question 5 at [3], and the overall topic of the thread, >> no, I am not asking for the audit statement covering the root that the RA >> used to issue from. I'm asking for the audit report, issued under the >> auditing standards that underlie the accepted audit schemes found in >> Section 8.1, that provides an opinion whether the Delegated Third Party's >> performance complies with either the Delegated Third Party's practice >> statement or the CA's Certificate Policy and/or Certification Practice >> Statement. >> >> [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf >> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1334377 >> [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 >> >> > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
