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

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:

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

Reply via email to