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.

dev-security-policy mailing list

Reply via email to