On Wed, Aug 13, 2014 at 1:44 PM, Ryan Sleevi <[email protected]> wrote: > On Wed, August 13, 2014 12:41 pm, Peter Bowen wrote: >> On Wed, Aug 13, 2014 at 11:16 AM, Kathleen Wilson <[email protected]> >> wrote: >> > 2) BR point-in-time audits may not be sufficient. >> > >> > https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy >> > "Any Certificate Authority being considered for root inclusion after >> > February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA >> > Certificate Policy. This includes having a Baseline Requirements audit >> > performed if the websites trust bit is to be enabled. *Note that the >> > CA's >> > first Baseline Requirements audit may be a Point in Time audit.* " >> > >> > We could change that to say that the first BR audit may be performed >> > over a >> > minimum of 3 months, and include testing of issuance and infrastructure. >> > i.e. If it is the CA's first BR audit (because they were not in the >> > program >> > and did not know about the BRs) then the audit should cover 3 months, >> > and >> > the certificates/CRLs/OCSP-responses issued during that time must be >> > evaluated against the BRs. >> > >> > Would this help? i.e. Is it needed in addition to proposal #1? >> >> It seems there two reasons that CAs might get a point in time >> readiness assessment (PITRA) rather than a period of time audit: >> >> 2) They don't yet issue certificates. If an organization is creating >> a brand new CA, there is no history of operation to be audited, so the >> only thing an auditor can perform is a PITRA. It is very possible >> that the CA will not start issuing certificates until they are >> accepted into the Mozilla program. I think AffirmTrust's application >> a couple of years ago demonstrated this scenario. >> >> It seems reasonable to continue to accept the PITRA for CAs that are >> not yet issuing certificates. This should be different than handling a >> CA that has issued certificate which do not follow the BR. >> >> Thanks, >> Peter > > For 2, it seems a PITRA prior to the inclusion request, but that there may > need to be some monitoring phase after the request, and then an audit, > like Kathleen proposed. > > For example, to ensure that OCSP responses are being handled properly > (e.g. not returning Good, etc), that the infrastructure is correct. A > PITRA, in an ideal world, would be performing these basic RFC 5280 and BR > compliance checks, but I suspect auditors may not be fully assessing the > conformance to technical requirements, and instead assessing assertions of > conformance to technical requirements (assertions which are, > unfortunately, more false than not)
For the second case, would it make sense to formalize that all three audits (WebTrust for CA, WebTrust for BR, WebTrust for EV) can be a point in time readiness assessment initially and require that the CA have a period of time audit after operating for N months/days? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
