[Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

[Jeremy Rowley]

>> Under the combined reading of 4.9.10 and 7.1.2.5, they MUST NOT respond "Good".
But this is where I disagree because a pre-cert does not fall under the BRs by default because it is not intended for TLS by virtue of the poison extension. The BRs then further remove applicability by calling a pre-cert not a cert. Therefore neither 4.9.10 and 7.1.2.5 apply and a CA can reply “Good” because of the RFC.  Looking at it another way – either the pre-cert is a cert and I should respond good since I issued it (which means the BRs are wrong about the pre-cert not being a cert) or the pre-cert is not a cert (and the BRs are lying about their scope). Either way the BRs are wrong about something so some portion is a lie I have to ignore to make it work.


  1.  If this is part of the normal issuance flow, in between the CA gathering the Precertificate and creating the Certificate, what is the expected response?
Per the Mozilla discussion – I don’t know!  This is why I really want this ballot. Currently I respond “Good” because I don’t think the BRs apply, but I think almost any response is okay. Because I can see the argument for any response expect “Revoked”.

2) If there is an issue, and the CA only creates a Precertificate, but does not create a Certificate, what is the expected response?
Same as above. I can’t tell what it should be because I can’t tell if the BRs are supposed to apply to OCSP for pre-certs. I think any response but revoked is okay (which is why I really want this ballot). The language you proposed is great (same with Waynes). I wouldn’t mind language that said simply “CAs MUST provide OCSP for services for pre-certificates and MUST respond “good” for issued pre-certificates unless the underlying certificate is revoked or the pre-certificate is revoked”.  Something very clear.


From: Ryan Sleevi <sleevi at google.com>
Sent: Friday, October 18, 2019 9:58 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates



On Fri, Oct 18, 2019 at 11:44 AM Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
For Problem 1 – One issue I’ve always had is if a pre-certificate is not considered a certificate, then how is it governed by the baseline requirements? It no longer qualifies as a certificate intended for TLS authentication in that case and thus the CA should be following the RFC instead, meaning the only thing that controls is Mozilla policy and the RFC. I don’t see a conflict because the BRs no longer apply since they remove themselves by calling a pre-cert not a cert.

Your response here is actually about Problem 2, not Problem 1 :)

Problem 1 is stating that because it "no longer qualifies as a certificate", the CA cannot provide a "Good" response unless they also issued a matching certificate. That is, if they issued a pre-certificate and a certificate, then under the combined reading of 4.9.10 and 7.1.2.5, they MUST NOT respond "Good".

1) If this is part of the normal issuance flow, in between the CA gathering the Precertificate and creating the Certificate, what is the expected response?
2) If there is an issue, and the CA only creates a Precertificate, but does not create a Certificate, what is the expected response?

(Now, these also apply to CRLs, but there's latency involved in pushing those and they only contain negative responses, not positive, so it's less complicated)

If a Root Policy attempts to answer these, for example, by requiring status be provided for a Precertificate regardless of whether or not a Certificate was issued (on the presumption that a Precertificate means there's a matching cert), then it would be read as conflicting with the MUST NOT in 4.9.10, because 7.1.2.5 says Precertificates don't count.

Problem 2 – This one seems pretty well established from the Mozilla forum and related incident reports. Is there still confusion? Is the only objection SC23 related to problem 1 or is problem 2 still an objection?

Much of your original response for Problem 1 is actually about Problem 2. So, collectively, it's all about Problem 2 ;)

The understandable problem with precedent is we know that all CAs are not following the discussions, like they're required to, just the same way that CAs are violating Policy 2.6.1, despite ample communication. Similarly, for new CAs, that's a whole lot of historical precedent to ingest to understand what's expected. That's the benefit of cleaning up Problem 2, reducing the confusion and being clearer the expectations by formalizing the (many) historical precedents in the place that it seems CAs look (the BRs), rather than the place (some) CAs ignore - the Policy Requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191018/25e135ab/attachment-0001.html>