[Servercert-wg] Draft Ballot: Precertificates and OCSP

[Ryan Sleevi]

On Mon, Sep 23, 2019 at 6:11 AM Rob Stradling via Servercert-wg <
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).

I highlight this, because I think it's fundamentally flawed to approach
there being a distinction between `P` and `C`, as the only time we've seen
this distinction matter is with CAs arguing about misissuance, arguing that
`P`'s misissuance is fine, because they pinky-promise that `C` wasn't
issued, and that only `C`'s issuance matters.

So, unless this ballot also changes the wording of this problematic
> sentence, ISTM that CAs will be in the unfortunate position of having to
> choose between...
> 1. Complying with Mozilla policy, which looks set to override this
> problematic sentence (meaning that CAs are REQUIRED to provide OCSP
> status in this scenario)
> or
> 2. Complying with other browser policies, which incorporate the BRs and
> which, crucially, *don't* override this problematic sentence (meaning
> that CAs are FORBIDDEN from providing OCSP status in this scenario).
>

As mentioned in 2014, when we last beat this horse, I think this is a false
dichotomy, in as much as `P` is equivalent proof of `C`. The implication is
that whenever /any/ discussions of issued or compliance exists, a world of
RFC 6962 is one that substitutes `C` with (`C` || `P`), provided that `P` =
Precert(`C`).


> I propose rewording the problematic sentence along these lines...
>
> 'If the OCSP responder receives a request for status of a serial number
> that does not yet belong to an issued Certificate or Precertificate,
> then the responder {SHOULD or MUST} NOT respond with a "good" status.'


Concretely, the challenge with this language then implies that `P` != `C`
for sake of discussions. However, more importantly, it introduces a
loophole that can drive a mack truck through - I could stand up an in-house
CT log (which no one can see), and then log precertificates to it (that no
one can see), which returns SCTs (which no one can see). Then, when the
public encounters an unknown serial, I can state that it's not actually
unknown, but it exists (or, upon receiving the request, is made to exist)
as a Precertificate within my internal log.

The existing language doesn't suffer this loophole; it avoids confusions
around serial number uniqueness (modulo the issues Jacob highlights, which
I and Brian Smith highlighted back in 2014)

It seems much better, structurally, that if one is absolutely worried about
the (`P` && !`C`) cases, it would be better to outright forbid them. This
would force the issuance of `C`, which grants more capabilities to an
attacker than `P` but has all of the same policy obligations, since they
would be treated as if `C` did exist. This would at least avoid creating
the opportunity for CAs' creative accounting in this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190923/76b06373/attachment.html>