[Servercert-wg] Profiles, Precertificates, and OCSP

Wed Feb 15 20:38:42 UTC 2023

I agree with Ryan that the most expedient approach is to record Aaron’s finding as a future improvement and proceed with the profiles ballot without any changes to 4.9.10.

Thanks,

Corey

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Dickson via Servercert-wg
Sent: Wednesday, February 15, 2023 3:25 PM
To: Aaron Gable <aaron at letsencrypt.org>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Profiles, Precertificates, and OCSP

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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/414___.YXAzOmRpZ2ljZXJ0OmE6bzowZmZjM2ZlYTA1ODcyMDRlMzhjN2YwZWM5ZDFmNDE2Mzo2OjJjODg6ZWU1OTNiYzg5MmU3NGViMTRmMzZkMWNmNDFiY2IwY2MxNjgwNDU1ZDE5NGZlNGVmYjE0OTBmNDFkYmI4ODEyMzpoOkY> " - 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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/373___.YXAzOmRpZ2ljZXJ0OmE6bzowZmZjM2ZlYTA1ODcyMDRlMzhjN2YwZWM5ZDFmNDE2Mzo2OjVlY2Y6YTRlZTU3YmJlMTgyNGFmZTUwYjZhMzgzMjMxMmQyZWVkNmZkNWVlMWZhNTNmNjY2YjYzNGE0OTAxZTA5ZjNlMzpoOkY> .

- Ryan

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

Hi Servercert folks,

The Profiles ballot updates Section 7.1.2.9 <https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/profiles/docs/BR.md%237129-precertificate-profile___.YXAzOmRpZ2ljZXJ0OmE6bzowZmZjM2ZlYTA1ODcyMDRlMzhjN2YwZWM5ZDFmNDE2Mzo2OjgwZjk6YzgzN2Y2MGU0MzU5NDgzMDQzNzA5ZDhlZTE1MGNmNDMyODdkNWIyMDdmMjE5ZWUwNzZjMTdmMTMwMzA1OTg3MzpoOkY>  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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/2c63814/docs/BR.md%234910-on-line-revocation-checking-requirements___.YXAzOmRpZ2ljZXJ0OmE6bzowZmZjM2ZlYTA1ODcyMDRlMzhjN2YwZWM5ZDFmNDE2Mzo2OjlmMzM6MDk1YmUzOWNiZWYyY2ExNjQ5YjkyNmU4ZjVlZDNiMzY2NDdlM2RlNjJlMzYxYmRiZTZjOTU5OGRjNzBlZGJjZjpoOkY>  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 <mailto:Servercert-wg at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzowZmZjM2ZlYTA1ODcyMDRlMzhjN2YwZWM5ZDFmNDE2Mzo2OmQ2NjQ6OTNjNzBiNTkwZTc5ZjJlNjEyYzRlMmNmNjk5MmI1NzM1OTQ2YmU1Y2U2OWZiMGU2YjU4ZWQxMTdlNDJiYzAzZTpoOkY> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230215/d967743c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230215/d967743c/attachment-0001.p7s>