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

[Tim Hollebeek]

Agree with Ryan, treating Precertificates as Certificates is thorny, and probably has some unfortunate interactions and consequences that we probably haven’t noticed yet.  It’s a good long term goal, but I wouldn’t try to go there now.

 

-Tim

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Wednesday, October 23, 2019 10:27 AM
To: Mike Reilly (GRC) <Mike.Reilly at microsoft.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 Wed, Oct 23, 2019 at 9:07 AM Mike Reilly (GRC) <Mike.Reilly at microsoft.com <mailto: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/20191024/b794c400/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/b794c400/attachment-0001.p7s>