On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> Here's some suggested wording for the last paragraph:
>> This means, for example, that (i) a CA must provide OCSP services
>> and responses in accordance with Mozilla policy for all certificates
>> presumed to exist based on the presence of a Precertificate, even if the
>> certificate does not actually exist, and (ii) a CA must be able to revoke
>> a certificate presumed to exist, if revocation of the certificate is required
>> under Mozilla policy, even if the certificate does not actually exist.

[Speaking only for myself]

Wayne, Andrew,

Please treat this message as a sincere attempt both to understand what 
the current requirements actually are and to seek to clarify what the 
requirements should be.

ISTM that this "certificate presumed to exist" concept doesn't play 
nicely with the current wording of BR 4.9.10:
   'If the OCSP responder receives a request for status of a certificate
    that has not been issued, then the responder SHOULD NOT respond with
    a "good" status.'

If a certificate (with embedded SCTs and no CT poison extension) is 
"presumed to exist" but the CA has not actually issued it, then to my 
mind that's a "certificate that has not been issued"; and therefore, the 
OCSP 'responder SHOULD NOT respond with a "good" status'.

However, this is Schrödinger's "certificate that has not been issued", 
because a Precertificate has been issued that has the same serial number 
(as the "certificate presumed to exist" that doesn't actually exist).

And so at this point ISTM that the OCSP responder is expected to 
implement two conflicting requirements for the serial number in question:
   (1) MUST respond "good", because an unrevoked/unexpired 
precertificate exists (and because BR 4.9.9 mandates a signed OCSP 
   (2) SHOULD NOT respond "good" (see BR 4.9.10).

Clearly that's impossible, which leads to the question: Which of these 
two conflicting requirements should a CA ignore in order to be as 
un-non-compliant as possible?  Which leads me to BR
   'For purposes of clarification, a Precertificate, as described in RFC
    6962 – Certificate Transparency, shall not be considered to be a
    “certificate” subject to the requirements of RFC 5280'

Since the first mention of "certificates" in the OCSP Protocol Overview 
(RFC6960 section 2) cross-references RFC5280, I believe that this 'shall 
not be considered to be a "certificate"' declaration can be assumed to 
extend to the OCSP requirements too.  And therefore, the balance tilts 
in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST 
respond "good"'.

I can't say I like this conclusion, but nonetheless it is the conclusion 
that my reading of the BRs forces me to reach.  I realize that what the 
BRs actually say may not reflect precisely what was intended by 
CABForum; nonetheless, CAs are measured by what the BRs actually say.


   - In CT v2 (6962-bis), precertificates are not X.509 certificates, 
which removes Schrödinger from the equation.  :-)

   - I think BR, as written, is decidedly unhelpful and should 
be revised to have a much smaller scope.  Surely only the serial number 
uniqueness requirement (RFC5280 section needs to be relaxed, 
not the entirety of RFC5280?
   - I would also like to see BR 4.9.10 revised to say something roughly 
along these lines:
   'If the OCSP responder receives a status request for a serial number
    that has not been allocated by the CA, then the responder SHOULD NOT
    respond with a "good" status.'

P.S. Full disclosure: Sectigo currently provides an (unsigned) 
"unauthorized" OCSP response when a precert exists but the corresponding 
cert doesn't, but in all honesty I'm not currently persuaded that an 
Incident Report is warranted.

Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

dev-security-policy mailing list

Reply via email to