On 02/09/2019 20:13, Alex Cohn 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?
This seems to be an unfortunate aspect of the CT spec that wasn't
thought through properly. In particular, it should cause unnecessary
delay if a CA updates its OCSP servers using "eventual consistency"
principles. Maybe it should be fixed in the next update of the spec.
The BRs have the following requirements that are best satisfied by
delayed update of OCSP servers:
BR4.10.2 The OCSP servers must be up 24x7 . Thus rolling out updates to
different servers at different times would be a typical best practice.
BR4.9.10 The OCSP servers only need to be updated twice a week (4 days)
.. This could only satisfy the CT requirement if issued certificates
were somehow withheld from the subscriber for up to 4 days.
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 question was if this technique would be in violation of the BRs, as
those generally prohibit the use of "certificateHold" .
(Are any CAs even using the OCSP SCT delivery option? I haven't come across
this technique in the wild)
Alex
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
