On Tue, Feb 4, 2020 at 6:59 PM Kathleen Wilson via dev-security-policy < [email protected]> wrote:
> All, > > https://wiki.mozilla.org/CA/Audit_Letter_Validation > currently says: > "" > Acceptable remediation for an intermediate certificate missing BR audits > may include one or more of the following: > > - Have your auditor issue a revised report that includes the > intermediate certificate. Note that if the certificate has been in > existence for multiple past audit periods, this will not be considered a > full remediation unless new reports are supplied for all of those > periods in which the certificate did not appear on the original reports. > > - Revoke the intermediate certificate in accordance with BR section > 4.9. If your CA decides not to revoke the certificate within the > timeline specified by the BRs, then that is another incident, which must > be addressed in a separate Incident Report. > > - If the intermediate certificate is technically capable but not > intended for TLS issuance, and revocation is not imminent, you may > request that Mozilla add it to OneCRL by adding a comment to the > Bugzilla bug with the request and sending email to Mozilla. Note: While > adding the certificate to OneCRL satisfies Mozilla's expectations for > remediation, it may not satisfy other root store programs. You are > advised to seek their guidance on this issue. > "" > > Questions: > > 1) Should we require a revised audit statement when it is missing the > SHA256 fingerprint of a cert that has the same Subject + SPKI as other > cert(s) listed in the audit statement? > For this situation, we have been requiring CAs to have their auditor > revise their current audit statements. But the question has come up > about when that is necessary, e.g. what if the CA is about to get their > next audit statement? Do they still need to get their previous audit > statement updated? If not, what would be the cut-off for not requiring > that the current audit statement get updated? Or is it only necessary > that future audit statements list the forgotten certs that have the same > Subject + SPKI as other audited certs? This is a tricky one. In theory, all of the key controls regarding issuance should be applied to all variants (“doppelgangers”). That is, a certificate issued by one version, even if not included in scope, would still exercise the same private key as the in-scope CA. There are some tortured readings, however, that an auditor may be convinced to sign-off on: For example, if the auditor did not examine or reconcile the HSM logs with the logs of the in-scope issued certificates, then it’s possible that one or more invalid certificates will not be detected, even though they’re valid and chain to the in-scope CA. In this model, we’re assuming the CA software and logs treat the two certificates, despite sharing the same subject and SPKI, as distinct, and the auditor only examines the logs of the in-scope version. Another example would be if the CA disclosed to the auditor that the certificate is expired, and thus the CA doesn’t examine issuance practices or acknowledges no certs issued for “that” CA, while the doppelganger is unexpired and the auditor doesn’t examine this. The detailed control reports from WebTrust would help with this, but only if they’d been used for the problematic audit, which no CA has done. A restated report would in theory help, but it still leaves it ambiguous where the auditor actually considered all of these edge cases, and it was just a clerical mistake, or if they failed to consider. The only sure way is to require revocation, not just of the doppelgänger, but of all variations of it, given the risk of historical certs still being valid. However, that’s also a huge disruption, and may require invalidating every single certificate from that CA! While I think we should be more regularly requiring CAs to create new clean hierarchies every few years, ALV is probably not the best trigger for that. My recommendation is that, for audit periods ending within the next 30 or so days (meaning, effectively, for reports provided over the next 4 months, given the three month window before reporting), such situations are accepted despite the limited assurance they provide. Following that - that is, for any audit afterwards, there is zero exception, and revocation is required. This places the onus on the CA to ensure their audit reports will meet Mozilla’s requirements. 2) Should we accept a revised audit statement to include the SHA256 > fingerprint of a certificate that was not previously listed and does not > have the same Subject + SPKI as other cert(s) listed in the audit > statement? Believe it or not, this is actually remarkably similar to “should we grant exceptions for revocation”. If the answer is “Yes”, CAs will pressure their auditors to do so. Auditors have significant professional guidelines making that difficult, at least within WebTrust and IFAC, which is a good thing. Restating (“revising”) a report is a significant affair that has serious professional implications. Despite the fact that the CA is responsible for defining the scope, and making sure such certificates are included, they may pressure their auditor to restate/revise the report. Auditors that don’t do so, because they value their professional standards and the independence from the client, may find they lose clients to those auditors who will happily cover for the CAs mistake (or for the auditor’s mistake, if the auditor made a clerical error). This is similar to the revocation exception problem, in that it creates negative penalties for those who do the right thing (in revocation, the CAs that actually revoke on time), which encourages customers to seek out the ones who do the wrong thing (in revocation, customers love the CAs that will ignore the rules for them). For our European auditors, while I wish they had the same professional integrity and standards, by and large they don’t. The ETSI criteria do not impose the same professional concerns, and the process of accreditation of the CAB by the NAB can be done against a variety of standards. As a consequence of this apathy, which is often misrepresented as a strength by supporting a variety of accreditation schemes, each with their own requirements, a revised report from an ETSI-using auditor has zero pressure for the CAB to improve or examine their processes that lead to needing to restate. This is even more pronounced if the report being used is not also used by the Supervisory Body, as there is limited to no professional misconduct that can be pointed back at the NAB, because the reporting is treated separately from the accreditation process, as I understand it, and has played out in past complaints to NABs. While I realize that’s a giant alphabet soup with very strong sentiments being expressed, particularly regarding the quality of ETSI-derived audit schemes, the overall conclusion is simpler: no exceptions, revocation is required. I realize Mozilla uses OneCRL to address the gap there, but ostensibly this is a straight BR violation regarding providing continuous audits. The proposed revisions will make this unambiguously clearer, but either way, the best path to protect the most users is to require the CA to revoke such certificates. This also hopefully has the desired effect of forcing CAs to pay closer attention to the requirements placed on them, and ensure that the negotiate and scope their audits to ensure they’re actually meeting those requirements. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
