On 03/09/2019 00:54, Ryan Sleevi wrote: > 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. >
I was not advising either cause of action, I was trying to explore conflicting requirements between the BRs, PKIX and the CT spec, which has apparently lead to confusion as to the what OCSP should return for soon-to-be-issued and not-yet-issued certificates. This particular CT requirement contradicted a common Google practice across its services, which made me suspect it might be a specification oversight rather than intentional. > >> >> 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. > That was my interpretation too. > (Are any CAs even using the OCSP SCT delivery option? I haven't come across >> this technique in the wild) > > > Yes, several are. > 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
