On Mon, Sep 2, 2019 at 2:14 PM Alex Cohn via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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? Correct. Which is why I recommend CAs ignore Jakob Bohm’s advice here, as it can lead to a host of complications for CAs, Subscribers, and Relying Parties. > > 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. The BRs explicitly prohibit this. You cannot unrevoke or suspend. (Are any CAs even using the OCSP SCT delivery option? I haven't come across > this technique in the wild) Yes, several are. > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
