On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> If an OCSP server supports returning (or always returns) properties of > the actual cert, such as the CT proofs, then it really cannot do its > usual "good" responses until the process of retrieving CT proofs and > creating the final TBScertificate (and possibly signing it) has been > completed. > > Thus as a practical matter, treating a sign-CT-sign-CT in-process state > as "unknown serial, may issue in future" may often be the only practical > solution. > Waiting until CT submission of the final certificate is complete to return "good" OCSP responses is definitely wrong. OCSP should return "good" at the moment the final certificate is issued, which means in practice that there might be a "good" OCSP response that doesn't contain SCTs yet. I don't know if any log does this, but RFC6962 allows logs to check for certificate revocation before issuing a SCT; if the OCSP responder doesn't return "good" the CA might never get the needed SCTs? Also, if a CA is signing a precert, getting SCTs for that precert, then embedding the SCTs in the final cert, they are already satisfying the browsers' CT requirements. It would not be necessary for them to additionally embed SCTs for the final cert in their OCSP responses. Now depending on interpretations, I am unsure if returning "revoked" for > the general case of "unknown serial, may issue in future" would violate > the ban on unrevoking certificates. > RFC6960 section 2.2 documents a technique for indicating "unknown serial, may issue in future" that involves returning "revoked" with a revocation date of 1970-1-1 and a reason of certificateHold. I don't know if this technique is used anywhere in practice - IIRC it requires the OCSP signing key to be online and able to sign responses for arbitrary serial numbers in real time. (Are any CAs even using the OCSP SCT delivery option? I haven't come across this technique in the wild) Alex _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
