Thanks Tim and Ryan for the information on WebTrust Root Key Generation Ceremony audit reports. Can anyone say if an equivalent public-facing report exists for ETSI audits? If so, I think we should require CAs to provide these reports with their root inclusion requests.
Regarding the issue of requiring audits from the time of first issuance, here's a specific proposal: In section 2.3 (Baseline Requirements Conformance), add a new bullet that states "Before being included, CAs MUST provide evidence that their root certificates have continually, from the time of creation, complied with the then current Mozilla Root Store Policy and CA/Browser Forum Baseline Requirements." - Wayne On Fri, Mar 30, 2018 at 6:45 AM, crawfordtimj--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, March 29, 2018 at 10:59:10 AM UTC-5, Ryan Sleevi wrote: > > On Mon, Mar 26, 2018 at 3:06 PM, Wayne Thayer via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > Mozilla began requiring BR audits for roots in our program in 2013 > [1], but > > > we have a vague policy statement in section 3.1 regarding audit > > > requirements prior to inclusion: > > > > > > Before being included and periodically thereafter, CAs MUST obtain > certain > > > > audits… > > > > > > > > > > BR section 8.1 contains the following paragraph: > > > > > > If the CA does not have a currently valid Audit Report indicating > > > > compliance with one of the audit schemes listed in Section 8.1, then, > > > > before issuing Publicly-Trusted Certificates, the CA SHALL > successfully > > > > complete a point-in-time readiness assessment performed in accordance > > > with > > > > applicable standards under one of the audit schemes listed in Section > > > 8.1. > > > > The point-in-time readiness assessment SHALL be completed no earlier > than > > > > twelve (12) months prior to issuing Publicly-Trusted Certificates and > > > SHALL > > > > be followed by a complete audit under such scheme within ninety (90) > days > > > > of issuing the first Publicly-Trusted Certificate. > > > > > > > > > > Unfortunately, the definition of Publicly-Trusted Certificates exempts > > > newly created roots from this requirement, and in practice we have seen > > > that violating this requirement does not prevent roots from receiving > BR > > > audit statements. We continue to see inclusion requests for roots that > do > > > not have an unbroken chain of BR audits back to first issuance. > > > > > > I propose that we add a requirement to Mozilla policy section 3.1.3 for > > > roots to have contiguous audits beginning within 90 days of issuing the > > > first certificate. I chose 90 days to allow some time for issuing > > > subordinate CA certificates and test certificates in preparation for > the > > > audit. > > > . > > > This is: https://github.com/mozilla/pkipolicy/issues/113 > > > > > > [1] https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria > > > [2] > > > https://groups.google.com/d/msg/mozilla.dev.security. > policy/Mezqdljjerc/ > > > nIirftRqAgAJ > > > > > > > > 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. > > > > Does that match your intent? Assuming I did not botch the audit timing > > issues here > > The standard audit cycle, we normally see for a brand new CA, is as > follows: > > 1. Draft CP/CPS > 2. Perform RKGC, observed and reported on by auditor > 3. Point in time reporting > 4. Period of time reporting > > Most CAs elect to perform a RKGC before a point in time engagement, > because without any CA activities in place most of the WebTrust criteria > would not be applicable at the point time of reporting. As an example, > much of the following sections would not be applicable: > > 4.0 – CA Key Lifecycle Management Controls > 6.0 – Certificate Lifecycle Management > > These sections represent a substantial portion of the WebTrust Principles > and Criteria. > _______________________________________________ > 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
