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. Alex _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
