[Servercert-wg] Draft Ballot: Precertificates and OCSP

[Rob Stradling]

Thanks Ryan.  Your proposed rule works for me.  I'd just like to suggest a little bit of grammarsmithing...

-- PROPOSED RULE
If the OCSP responder receives a an OCSP request for status of a certificate that it but has no record of ever having issued a any certificate with the certificate serial number in the that request, using any current or previous issuing key for the CA subject, then the responder SHOULD NOT respond with a "good" status. OCSP responders for CAs which that are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates.
-- END PROPOSED RULE

________________________________
From: Ryan Sleevi <sleevi at google.com>
Sent: 23 September 2019 15:35
To: Rob Stradling <rob at sectigo.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Draft Ballot: Precertificates and OCSP



On Mon, Sep 23, 2019 at 10:23 AM Rob Stradling <rob at sectigo.com<mailto:rob at sectigo.com>> wrote:
On 23/09/2019 13:45, Ryan Sleevi via Servercert-wg wrote:
> On Mon, Sep 23, 2019 at 6:11 AM Rob Stradling via Servercert-wg
> <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org> <mailto:servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>> wrote:
>
>     It makes no difference whether you regard `P` to be a certificate or
>     not-a-certificate.  `C` may be due to be issued, but until it has
>     actually been issued, `C` is by definition 'a certificate that has not
>     been issued'.
>
>
> I mean, I'm all for accepting specs have bugs in language, and it's
> certainly true that we need to design our language adversarially (i.e.
> against a CA that will argue a bad outcome is actually OK, because of
> the language), but I'm not sure that follows with RFC 6960's discussion
> of not-issued, as also mentioned on m.d.s.p.
>
> Namely, from 2.2
>     This state MAY also be returned if the associated CA
>     has no record of ever having issued a certificate with the
>     certificate serial number in the request, using any current or
>     previous issuing key (referred to as a "non-issued" certificate in
>     this document).

It is BR-compliant for a CA to implement OCSP in a manner that conforms
only to RFC5019; so, whilst this "non-issued" language from RFC6960 is
certainly interesting, I don't see how (with the current BR text) it
would be reasonable to regard it as normative.

Perhaps this could be resolved by updating the BRs (and the "problematic
sentence") to explicitly incorporate this "non-issued" definition?  (If
so, then maybe the rest of this reply becomes redundant).

Right. There's an implicit algorithm here that needs to be made explicit: What is the process for issuing:

1) Generate sufficiently robust serial?
  a) Check it does not conflict with any existing serials? If it goes, go to 1
2) Record in the database that this serial has been issued
3) Sign a pre-certificate with this serial
4) Distribute pre-certificate to sufficient logs to gain SCTs
5) (Optional) sign certificate with SCTs

If that step is followed, then the RFC 6960 responder can definitively respond from point 3 onwards, because the "CA has a record of issuing a certificate". It might have been "we recorded it's not yet completed" or "we recorded it resulted in error", but no matter what an error happens, the CA will never reuse the serial with the above flow.

I suspect that some CAs have instead been doing

1) Generate sufficiently robust serial
2) Sign a pre-certificate with this serial
3) Distribute pre-certificate to sufficient logs to gain SCTs
4) sign certificate with SCTs
5) Record in database that this serial has been issued

And this leads to pain?

Even if the CA did

1) Generate sufficiently robust serial
2) Sign a pre-certificate with this serial
3) Record in database that this serial has been issued
4) Distribute pre-certificate to sufficient logs to gain SCTs
5) Sign certificate with SCTs

Then they'd still be fine, even under 6960, because it wouldn't be a "non-issued" certificate.

So is the language then, incorporating from 6960 (and setting aside Jacob's changes, which are also good and should be integrated as well, but are for a separate section"

-- PROPOSED RULE
If the OCSP responder receives a request for status of a certificate that it has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key for the CA subject, then the responder SHOULD NOT respond with a "good" status. OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates.
-- END PROPOSED RULE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190923/d6890c97/attachment.html>