On 2019-08-30 12:14, Jakob Bohm wrote:
On 30/08/2019 01:36, 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.
For CAs affected by OCSP misbehavior in this particular scenario (Pre-
Cert issued and submitted to CT, actual cert not issued), they should
take a look at those error cases and subdivide them into:
1. No intent to actually issue the actual cert. Best handling is to
treat as revoked in all revocation protocols and logs, but with audit
and incident systems reporting that the cert wasn't actually issued.
( *Most common case* ).
2. Intent to actually issue later, if/when something happens that just
takes longer than usual. Here it makes sense for OCSP and other such
mechanisms to return "good", due to the ban on reporting "certificate
hold" or otherwise exiting a revoked state. It of cause remains
possible to later revoke such a half-issued cert if there is a reason
to do so.
3. Intent to issue in a few minutes, somehow OCSP was queried during the
short processing delay between CT submission and actual issuing of
cert with embedded CT proofs. Because inserting the CT proofs in the
OCSP responses probably awaits the same technical condition as the
cert issuing, it makes sense to return "unknown" for those few
minutes, as when delivery of the cert status to the OCSP servers is
itself delayed by a few minutes (up to whatever limit policies set
for updating revocation servers with knowledge of new certs).
It's not obvious for me why such cases exist, and I think it would at
least be useful to have an actual list of why a pre-certificate was
issued and the real certificate was not.
If the pre-certificate was issued, it means all validation should
already have happened, and there is no reason not to issue the real
certificate other than some problems preventing it. But the difference
between 3) and 1) and 2) seems to be someone manually moved it from 3)
to one of the other 2.
Examples of reasons for me are things like:
- There is some technical problem with a server, it will be issued when
the server works again, or it's redirected to some other server. (like
can't get enough SCTs.)
- You lint the pre certificate and see an issue (and should revoke it)
I think there shouldn't exist pre-certificates that are valid without
the real certificate, after some delay. For instance, if you can't issue
the real certificate within 24 hours, revoke the pre-certificate.
Kurt
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
