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

[Ryan Sleevi]

On Fri, Oct 18, 2019 at 11:44 AM Jeremy Rowley <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/423cdb7a/attachment.html>