[Servercert-wg] Draft Ballot: Precertificates and OCSP

[Rob Stradling]

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

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

Let me check I'm understanding correctly: I'm saying the distinction 
between `P` and `C` matters, but you're saying I can't be right because 
this distinction only mattered once before?  How does that follow?

>     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`).

RFC6962 says "intent to issue", not "proof of issuance".  Future vs past 
tense.  That's what it says.

However, I do believe that this "implication" is what the RFC6962 
authors had in mind, and so I want to ensure that the BR language is 
consistent with this "implication".

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

Good point.

> 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,

I am worried about the (`P` && !`C`) case, because I interpret what the 
BRs actually say to be at odds with what we agree the BRs should say.

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

There will always be a period of time inbetween issuance of `P` and 
issuance of `C`, even if issuance of `C` is required by policy.  Often 
that period of time will be only a few seconds, but it may sometimes be 
much longer than that (e.g., if one or more log servers is temporarily 
offline, the CA may not be able to obtain a sufficient number of SCTs to 
embed in `C`).

So whilst I would not be opposed to forcing the issuance of `C`, I don't 
think it solves the (`P` && !`C`) conundrum, because !`C` is still 'a 
certificate that has not been issued'.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited