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

[Ryan Sleevi]

On Wed, Oct 23, 2019 at 9:07 AM Mike Reilly (GRC) <Mike.Reilly at microsoft.com>
wrote:

> Hi all.  I think we should be looking more at what Jeremy stated earlier
> in this thread:   "To be honest, I’d rather just correct the mistake the
> CAB Forum made and clarify that a pre-cert is really just a cert and should
> be treated just like a cert minus the duplicate serial number. That’s a
> much simpler fix."  It sounds like we need to clarify what a precert is and
> whether it's in scope or not under the BRs as a cert.  7.1.2.5 clearly
> states a precert is not a cert.  Seems that is what we should be discussing
> in as simple terms as possible.
>

That's what I would call the "long term goal". I think there's clear
consensus from the thread that we want things to end up being simple, but
as currently structured and how Ballot 134 interacts with things, it's
actually quite complex to get at the "simple" approach. The end result,
however, is absolutely that: to be clear, understandable, and simple about
what is expected, throughout the process and lifetime of a Certificate
and/or a Precertificate.


> Given we have CAs from across the globe, many of which use English as a
> second language and probably don't regularly read the large amount of mail
> traffic on this forum, the simpler the better.  As a native English speaker
> I'm still not completely following this discussion and the nuances of the
> language proposed in this ballot.  It's still not clear how we are defining
> a precert and if it's even in scope for the BRs.
>

There's clear agreement here, and the concern is the 134 language has led
to understandable, but unfortunate, confusion.

Reducing that confusion is important. That will take time to get right, so
it's not as a quick fix, but a necessary fix.


> Is the goal that we treat precerts as certificates and we have OCSP
> services prepared upon the creation and posting of the precert to CT logs?
>

In the BRs? That's not the goal right now. The "Long term" goal is to make
it clear and unambiguous the expectations that various Root Programs may
have, and to make sure they are captured in the BRs, so that CAs can read
and understand those expectations.

The "near term" goal is to make it clear and unambiguous in Root Program
policy, and to avoid confusion that might arise if the CA complying with
Root Program policy thinks the Root Program is asking them to violate the
BRs. Put differently, it's trying to make the BRs "more permissive", even
under the strictest possible reading, so that no conflict is seen. The
"long term" goal is to make the BRs more restrictive, in that it's exactly
clear what is expected. The long-term needs phase in, while hopefully we
can find a short-term permissiveness that doesn't break anything anyone is
doing now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/e7a594ed/attachment-0001.html>