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

[Jeremy Rowley]

Wait – how did it conclude that from the language? The language says it applies to all certs containing a serverauth EKU. I’ll go review since I guess I missed that conclusion.

From: Ryan Sleevi <sleevi at google.com>
Sent: Monday, October 28, 2019 11:21 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates



On Mon, Oct 28, 2019 at 10:53 AM Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
One other point is the Mozilla root policy already encompasses pre-certs as certificates. All certs containing a server-auth EKU are considered certificates under that policy – there’s no exception for pre-certs.

Jeremy, this is not correct.

It's statements like these that add to the confusion, which is part of the problem.

Full stop: Mozilla Policy does not treat Precertificates as Certificates. The m.d.s.p. discussion concluded as much.

Rather than discuss how they are treated, which I worry will add more confusion, I'll simply point the conclusion. Making this easier and clearer for CAs is the "second problem", which, for clarity, it seems we should decouple.

So you already have the case where at least one browser policy treats pre-certificates = certificates…. Although the application of Mozilla policy is not as clear cur as you’d think since 2.3 of the policy says it applies to all SSL certs. A pre-cert is not really a SSL cert with the poison extension so the BR application is carved out even if all other requirements still apply.

Note: This coda is not correct either, but we don't need to get into it, because it's premised on something incorrect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191028/ea7c784b/attachment.html>