[Servercert-wg] Profiles, Precertificates, and OCSP

[Ryan Dickson]

Hi Aaron,

Thanks for raising this opportunity for improvement.

My preference is that we add this as an issue tracked in GitHub, and we
look to address it in a follow-up cleanup to the profiles ballot.

I suspect that despite everyone's best effort in their review of SC-062,
given the sheer number of changes covered by the ballot's existing scope,
we will find minor nits and other improvements like this that should be
incorporated into the BRs. To help avoid scope creep (and end the three
year saga of initial updates), we agreed at the Validation Subcommittee
meeting a few weeks ago that we should prevent expanding the existing
ballot scope to ensure the ecosystem can benefit from the current set of
changes. All the while, we recognized there is continued opportunity for
improvement in the future.

As an alternative, I can stage the proposed change in our proposal to "Make
OCSP Optional <https://github.com/cabforum/servercert/pull/414>" - which
lightly touches 4.9.10 (no guarantee this potential ballot will pass a
vote, though).

If others think the profiles ballot should instead address the issue, I'm
happy to help get the changes into the existing PR
<https://github.com/cabforum/servercert/pull/373>.

- Ryan

On Wed, Feb 15, 2023 at 12:16 PM Aaron Gable via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi Servercert folks,
>
> The Profiles ballot updates Section 7.1.2.9
> <https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7129-precertificate-profile>
> to say:
>
> > Once a Precertificate is signed, relying parties are permitted to treat
> this as a binding committment from the CA of the intent to issue a
> corresponding Certificate, or more commonly, that a corresponding
> Certificate exists.
>
> This language is, to my understanding, just a reification of the common
> position that has been taken by root programs for a number of years now.
> For example, the MRSP says:
>
> > The logging of a precertificate in a Certificate Transparency log is
> considered by Mozilla to be a binding intent to issue a final certificate[.]
>
> There is a slight difference between the current Mozilla policy and the
> proposed Profiles language: Mozilla says that "logging to CT" is a binding
> intent to issue, while the Profiles ballot says that just "signing" is a
> binding intent to issue. To be honest, I prefer the new language, but it
> introduces some weirdness regarding OCSP.
>
> Section 4.9.10
> <https://github.com/cabforum/servercert/blob/2c63814/docs/BR.md#4910-on-line-revocation-checking-requirements> of
> the BRs says:
>
> > A certificate serial number within an OCSP request is...
> > - "assigned" if a Certificate with that serial number has been issued by
> the Issuing CA
> > - "reserved" if a Precertificate [RFC6962] with that serial number has
> been issued[...].
>
> It also says:
>
> > The OCSP responder MAY provide definitive responses about "reserved"
> certificate serial numbers, as if there was a corresponding Certificate
> that matches the Precertificate [RFC6962].
>
> But if, as the Profiles ballot text says, a "Precertificate is... a
> binding commitment... that a corresponding Certificate exists", then
> there's no actual difference between "reserved" and "assigned". All serials
> which are "reserved" may be treated by relying parties as actually
> "assigned", and therefore the OCSP responder MUST provide a definitive
> response for them.
>
> This isn't a huge deal: as noted above, the new Profiles language largely
> just carries forward existing Mozilla language, so most publicly trusted
> CAs are already in this state today. But I think it would be worthwhile to
> clean up Section 4.9.10 to only list two categories of serials, to make the
> requirements clearer.
>
> Does the ServerCert WG think that this should be addressed as part of the
> profiles ballot? As a follow-up cleanup? Not addressed at all, as it isn't
> a meaningful change from the current state of affairs?
>
> Thanks!
> Aaron
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230215/ca9494be/attachment-0001.html>