On Mon, Sep 2, 2019 at 1:36 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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:
> >
> > 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.

Withholding certificates for four days would be a huge competitive
disadvantage for a CA. If I were a CA relying on OCSP delivery of SCTs, I
would try to make absolutely sure my OCSP responders could be updated with
SCTs in a timely manner after initial issuance. Since this SCT delivery
method relies on OCSP stapling to work, I could even tell my customers to
configure their web servers with a special OCSP server URL (using, e.g.,
nginx's ssl_stapling_responder directive) that would block until a response
with embedded SCTs could be created.

> > 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" .

Where is this prohibition in the BRs? The only relevant section I could
find is 4.9.13, which prohibits suspension of certificates. This isn't
suspension of a certificate; the certificate doesn't exist.

dev-security-policy mailing list

Reply via email to