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

> 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

Reply via email to