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). Scenario 2 can be subdivided in two sub-cases for compliance purposes: 2A: Pre-cert (and thus cert) has a "valid from" date equal or near the CT submission time. Here the CT logged pre-cert provides proof that this is not backdating, even though cert usage won't start until later. 2B: Pre-cert (and thus cert) has a "valid from" date closer to the intended issuing date for the final cert. Here the CT logged pre-cert provides proof that certain issuance decisions happened earlier, thus affecting when some of the validity time limits are reached. Note that for some cert types (such as certs for S/MIME SubCAs), it is trivially possible for a subscriber to use the validity before the cert actually exists, while in other cases it is not possible, except for the difficulty in proving that the cert doesn't exist. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
