On Wed, August 13, 2014 12:41 pm, Peter Bowen wrote: > On Wed, Aug 13, 2014 at 11:16 AM, Kathleen Wilson <kwil...@mozilla.com> > 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: > > 1) They didn't know about the BRs. In this case, it would seem > possible that only having a PITRA is due to previously not following > the BRs or at least not having auditable processes defined that > required them to follow the BRs. > > 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 1, for a new CA, I don't see this as something desirable for inclusion. It means that there's an untold number of certs that would be usuable by a publicly trusted anchor but which don't conform to any particular set of (acceptable) technical requirements. I feel like the ONLY suitable answer to this is that they should be (2) (spinning up a new CA). But I suspect that's more controversial :) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
