On Thu, Mar 29, 2018 at 4:57 PM, Wayne Thayer <wtha...@mozilla.com> wrote:
> On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi <r...@sleevi.com> wrote: > >> >> I'm not fully sure I understand the proposal here. >> >> I would think that, for all roots created since 2012, the expectation >> > is that there is an unbroken series of audits, going from a Point in Time >> audit (of the policies and infrastructure) to a Root Key Generation >> Ceremony attestation (under the policies and practices) to a Period of Time >> audit, with the issuance of any supporting infrastructure appearing between >> the RKGC and the PoT and covered by the PoT audit. >> >> This expectation apparently isn't clear given the numerous inclusion > requests - for roots created before and after 2012 - we're seen that are > lacking historic audits - Japan GPKI and ComSign for instance. > > I wasn't thinking about requiring the RKGC audit report as part of our > inclusion process, but we probably should (assuming those reports aren't > confidential). > I'm not sure the extent for an equivalent under ETSI, but under the WebTrust side, practitioner guidance and illustrative reports have been provided at http://www.webtrust.org/practitioner-qualifications/item64422.aspx Under the US Reporting - SSAE 18 guidance [1], an illustrative report conforming to AT-C205 is provided on page 61. Under the Canada Reporting - CSAE 3000 - 3001 [2], an illustrative report as an independent assurance attestation engagement is provided on Page 85 Under the International Reporting - ISAE 3000 [3], an illustrative report conforming to ISAE 3000 is provided on page 68. My understanding is that these reports, and the international standards they adhere to, are designed for public reporting. [1] http://www.webtrust.org/practitioner-qualifications/docs/item85115.pdf [2] http://www.webtrust.org/practitioner-qualifications/docs/item85114.pdf [3] http://www.webtrust.org/practitioner-qualifications/docs/item85204.pdf > > Does that match your intent? Assuming I did not botch the audit timing >> issues here >> >> I think so. My intent is to make it clear that roots must meet our audit > requirements even before they are included, and I'm open to suggestions on > the best way to achieve that in our policy. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
