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

Wayne Thayer wthayer at mozilla.com
Wed Oct 16 17:55:02 MST 2019

On Tue, Oct 15, 2019 at 10:56 PM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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.
You're missing my point. Making a change to the BRs that CAs can't/won't
immediately comply with is not just a matter between them and root
programs, it also puts the CA in limbo with their auditors. CAs want to
avoid that.

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?

This ballot doesn't change the meaning of section 4.9.10, so we'd be back
in the situation that prompted the ballot in the first place [1].

Only if a precertificate is a certificate, but leaves that
ambiguous, and

> 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 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.
Rob and Jeremy - as endorsers, do either of you have an opinion on how to

- Wayne

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191016/bcd7af37/attachment.html>

More information about the Servercert-wg mailing list