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

[Wayne Thayer]

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

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/LC_y8yPDI9Q/eftWIVCcAgAJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191016/bcd7af37/attachment.html>