[Servercert-wg] Draft Ballot: Precertificates and OCSP

[Ryan Sleevi]

On Mon, Sep 23, 2019 at 10:23 AM Rob Stradling <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>> 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/e686b53f/attachment.html>