[Servercert-wg] Ballot SC23: Precertificates

[Ryan Sleevi]

Thanks for the suggestion, Kirk!

Unfortunately, I think there's some confusion about the goal of correcting
the Ballot 134 language, and that means your suggestion would still have
that unfortunate problem.

First, it's important to understand, SC23 is solving two different
problems. They're related, but they're also different problems, and it's
important that we find a solution that solves both of them, and not just
one or the other.

The first problem is that the language in Section 7.1.2.5, as written, has
caused some CAs concern that they would have to be out of compliance with
the Baseline Requirements in order to comply with various root programs
existing or potentially new expectations that they treat precertificates as
proof of equivalent certificate. There's a lot of technical nuance in that
discussion, and it's quite subtle, but that's what the change in SC23's
4.9.10 is trying to fix.

Now, the second problem is actually a two-parter (but one root problem of
confusion), and is one we've known about ever since Ballot 134 was
introduced. However, we've seen it cause some confusion, as predicted, and
it would be good to make sure we fix this issue too, since both issues are
caused by how Ballot 134 worded things. Multiple root programs treat the
existence of a precertificate as a proof that an equivalent certificate
exists (not that a precertificate is a cert; just that, from the point of
view of compliance, they treat it as if there is a matching cert). The way
Ballot 134 is worded, some CAs have misinterpreted and thought there are no
rules on precertificates, and as long as they don't sign a matching
certificate, there's no compliance issues. That's not the intent of RFC
6962, and not how root programs behave, but the wording of 7.1.2.5
suggestion things aren't subject to the BRs leaves it quite confusing!

The other part, which we also knew about when discussing Ballot 134, is a
variant of the above. What happens if a CA signs a precertificate, with
serial number 1234, for domain "foo.example", and then signs another
certificate, with serial number 1234, for a domain "bar.comexample. A CA
reading 7.1.2.5 might think that's totally ok - after all, the precert is
not a duplicate serial! However, this doesn't align with how multiple root
programs would treat this: that the precertificate is proof that there is
(somewhere) a matching certificate with serial 1234, domain foo.example,
and there's a known certificate with serial 1234, domain bar.example - aka
duplicate serials! In fact, a CA could issue dozens of precertificates with
the same serial, for different domains, and the CA totally think that
browsers are OK with this, because of how 7.1.2.5 is worded.

We can try to fix both variations of that second problem by rewording
Section 7.1.2.5. We still keep the thing that some CAs wanted: which is
clear communication that it's not treated as duplicate serials if they sign
a precertificate and then later issue a matching certificate. But the
reworded 7.1.2.5 makes it clear that's only the case if they match, as
defined in RFC 6962. If they don't match, then that's not the desired
result.

Hopefully that makes it clearer why leaving 7.1.2.5 alone is just making it
harder for new and existing CAs to comply, and why it's important to try to
make sure the BRs are precise and clear. As I mentioned on the original
thread, 7.1.2.5 is not trying to make revocation required; that's being
addressed by root programs. It is trying to close some loopholes and
confusion, which we've seen CAs run in to or try to use, since that doesn't
align with what's expected. If you're a root program that doesn't use CT,
this has no impact. But if you are, it hopefully makes it easier for CAs,
and that's a good thing!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191011/d3f5d9b4/attachment.html>