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
