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.


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

Reply via email to