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

[Ryan Sleevi]

On Tue, Oct 15, 2019 at 7:38 PM Wayne Thayer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> The difference, at least in theory, is that CAs are committed to comply
> with the latest version of the BRs, and hence, any CA that fails to comply
> by the effective date of this ballot should report the compliance issue to
> their auditor, who should in turn consider that incident in their next
> audit. This is regardless of any leeway offered by root programs.


Isn't that a good thing? Isn't disclosure, verified by an independent third
party, useful to browsers, whether or not they offer leeway on their
policies? Absent something like that, you're simply relying on the CA
self-reporting, which I think fits in to the overall bucket of changes that
can be overlooked or misunderstood, because they don't have any independent
evaluation?

I mean, it's a valid approach, but I do worry it gives to much credence
that incidents are inherently disqualifying for a CA, and it loses a degree
of transparency both with respect to the auditor and the CA.

While this proposal has merit on its own, I don't see how this solves the
> current problem. It takes us back to defining a precertificate as "not a
> certificate", which solves the duplicate serial number issue in a way that
> doesn't override RFC 5280. Then section 4.9.10 would need to be modified to
> permit "good" OCSP responses for precertificates.
>

I think your existing 4.9.10 modifications would cover this?


> However, no other BR requirements would be imposed on precertificates,
> leaving that up to root store policies like [1]. Is that the intent? If so,
> I'm open to that approach, but I don't see the need to enumerate the things
> a CA private key can sign to accomplish it.
>
> [1]
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
>

Well, the reason to enumerate is to ensure it's an exhaustive closed set.
Anything signed must fit within one of those labels. The risk of calling
them not-a-Certificate alone, without making it an explicitly closed set,
is that any issues would be declared to be both not-a-Certificate and
not-a-Precertificate. For example, signing junk with SHA-1, which would be
a Bad Thing. This is what we've currently seen with the Ballot 134 language.

The substantive change in Peter's earlier proposal would be that by scoping
it to "Everything a CA signs must fit in one of these four buckets" helps
make it clearer that everything must conform to one of those
relevant/applicable standards (5280, 5019/6960, 6962). It can also solve
the "Do I need to issue the cert" question, by providing guidance on what
signing a Precertificate may mean, allow, or imply (e.g. a presumption of
an equivalent Certificate without requiring the issuance of such a
certificate, which would also tackle your 4.9.10 issue)

The downside with the present partial modification to 7.1.2.5 is that, from
an adversarial reading, this makes a Precert a Certificate all the time.
This then gets messy with Precert Signing CAs, and whether it's a violation
that the Issuer in a precert from a Precert Signing CA doesn't match the
Precert Signing CA's issuer name, but the "actual" issuer for the matching
Certificate. Is that another thing we'd have to carve out as an exception
to the BRs, if calling Precerts Certs? I don't think that's the intent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191016/ff76f0f3/attachment.html>