On Tue, Sep 3, 2019 at 2:18 PM Santhan via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Thursday, August 29, 2019 at 4:37:04 PM UTC-7, Jacob Hoffman-Andrews > wrote: > > Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652 > > > > On 2019.08.28 we read Apple’s bug report at > https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s > OCSP responder returning incorrect results for a precertificate. This > prompted us to run our own investigation. We found in an initial review > that for 35 of our precertificates, we were serving incorrect OCSP results > (“unauthorized” instead of “good”). Like DigiCert, this happened when a > precertificate was issued, but the corresponding certificate was not issued > due to an error. > > > > We’re taking these additional steps to ensure a robust fix: > > - For each precertificate issued according to our audit logs, verify > that we are serving a corresponding OCSP response (if the precertificate is > currently valid). > > - Configure alerting for the conditions that create this problem, so > we can fix any instances that arise in the short term. > > - Deploy a code change to Boulder to ensure that we serve OCSP even if > an error occurs after precertificate issuance. > > Out of curiosity, what software is checking OCSP for a pre-cert and why? > Why does any software need the OCSP status of a pre-cert when it doesn't > have the corresponding final cert? It's a good question, and worth asking, although when framing, it might be useful to think/explore why *shouldn't* software be able to do so. There's no requirement to log the corresponding final certificate to CT Logs, and some CAs may choose to not do so in order to minimize the rate limits or the baseline growth rate of CT Logs, especially if those final certificates are functionally short-lived (e.g. some CAs issuing at 8 hour intervals). Yet those examining CT Logs for compliance issues have a reasonable basis for examining whether or not an associated pre-certificate is revoked, regardless of its overall compliance status with the requirements. That is, it's useful not only to know what's bad and is/isn't revoked, but also what is good, and is/isn't revoked. The latter is useful, for example, when examining impact to the ecosystem for changes, such as changes in a trust status for CAs, by examining whether or not the associated certificate(s) are still valid or have been revoked. Another reason is for revocation systems that try to comprehensively determine the status of published certificates, since CRLs are not inherently required to be used (example: CRLlite) In terms of process/flow though, my earlier point is that CT Logs define their incorporation timelines in terms of Maximum Merge Delay, rather than Minimum. It's entirely possible for a CT Log to incorporate (and publicize) a pre-cert within seconds, allowing CT Log Monitors to pick it up. If those Monitors then query the status information, it's possible that they could cause one or more intermediaries to return that cached information, even after the 'final' certificate has been issued. This was part of the operational complexity I was mentioning and mentioned on the associated bug. By ensuring publication of the 'correct'/'expected' information prior to the publication of the pre-cert (if pre-certs are used) or the final cert, this minimizes the risk of getting into an intermittent bad state. Is it possible to defer publishing and still get the correct result? Absolutely. It just requires much more care, and given situations like "Default City" and "Some State" in certificates, perhaps it's better to be safe by default. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
