[Servercert-wg] [EXTERNAL] Re: Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”

Paul van Brouwershaven Paul.vanBrouwershaven at entrust.com
Wed May 3 15:53:52 UTC 2023

Hi Ryan,

Would it be possible to split this ballot by topic into separate ballots, for example like:

  *   CRL Profiles
  *   Make OCSP Optional (require a CRL or OCSP to be included)
  *   Require CRLs
  *   Short-Lived Certificates

I think this combined ballot makes it too complicated to manage and have a fruitful discussion about the implications of each change.


From: Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of Ryan Dickson via Servercert-wg <servercert-wg at cabforum.org>
Sent: Wednesday, May 3, 2023 16:00
To: Aaron Gable <aaron at letsencrypt.org>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [EXTERNAL] Re: [Servercert-wg] Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

Hi all,

Thanks for the discussion thus far.

In hopes of making it easier for others to follow along with and contribute to the discussion, I added a summary to the ballot background and justification document<https://urldefense.com/v3/__https://docs.google.com/document/d/180T6cDSWPy54Rb5d6R4zN7MuLEMShaZ4IRLQgdPqE98/edit*bookmark=id.ceedtvdz1590__;Iw!!FJ-Y8qCqXTj2!f6JiZayyK01P2H7iQEXTI1JymI9pvfoMIwUlQ_0oCkImdAxBIbMNrJdLvvMEK1qIVaozcPbKw1hNHUvpGzEY4RitoYBE1fDgfNxN$>. I can continue to generate these summaries from time to time if they are helpful to members of our community.

If I’ve missed or misinterpreted anything in the summary, please:

  1.  accept my apologies in advance

  2.  offer clarification (feel free to comment directly on the doc and I’ll make the necessary updates)

Also, I’ve attempted to summarize unaddressed questions and comments below, adding clarification where possible.

Questions and Comments:

  1.  [Dimitris/Aaron] Should CAs not issuing certificates be required to issue (at least) daily CRLs as required in the proposed text? Why should a CA publish a new CRL if it hasn’t revoked a certificate since the last one?

  *   New Response: It seems worth exploring the “carve-out” described by Dimitris and Aaron. Alternative language proposed here<https://urldefense.com/v3/__https://github.com/ryancdickson/staging/pull/3/files__;!!FJ-Y8qCqXTj2!f6JiZayyK01P2H7iQEXTI1JymI9pvfoMIwUlQ_0oCkImdAxBIbMNrJdLvvMEK1qIVaozcPbKw1hNHUvpGzEY4RitoYBE1W5r6T1p$> attempts to specify when initial CRL publication must occur, ongoing issuance requirements, and when CAs may stop issuing CRLs. [Note, please feel welcome to offer suggested changes on the PR linked above].

  1.  [Aaron] Made some editorial comments that I’ll work on in this<https://urldefense.com/v3/__https://github.com/ryancdickson/staging/tree/make-ocsp-optional-updates__;!!FJ-Y8qCqXTj2!f6JiZayyK01P2H7iQEXTI1JymI9pvfoMIwUlQ_0oCkImdAxBIbMNrJdLvvMEK1qIVaozcPbKw1hNHUvpGzEY4RitoYBE1WizfJKr$> branch.

  1.  [Aaron] What does it mean to “support on-line revocation checking via OCSP”?

  *   New Response: Alternative language proposed here<https://urldefense.com/v3/__https://github.com/ryancdickson/staging/commit/1bc7e08cc403a25db874d4fb56af7ca46571406c__;!!FJ-Y8qCqXTj2!f6JiZayyK01P2H7iQEXTI1JymI9pvfoMIwUlQ_0oCkImdAxBIbMNrJdLvvMEK1qIVaozcPbKw1hNHUvpGzEY4RitoYBE1a-r6IpA$> attempts to clarify this language.

  1.  [Aaron] Can we discuss the motivations behind prohibiting the use of “indirect CRLs”?

  *   New Response: Though Aaron closed this issue, some final clarifications. While preparing the CRL Profile included in the proposal, we downloaded all CRLs disclosed to CCADB. We observed no instances of indirectCRLs in use today. Given our understanding of the language in SC-62 described by Corey, our opinion that indirect CRLs increase the complexity of the Web PKI, the absence of CAs relying on this practice, and given Chrome<https://urldefense.com/v3/__https://source.chromium.org/chromium/chromium/src/*/refs/heads/main:net/cert/internal/revocation_checker.cc;l=167-169;drc=e39fffa6900a679961f5992b8f24a084853b811a__;Kw!!FJ-Y8qCqXTj2!f6JiZayyK01P2H7iQEXTI1JymI9pvfoMIwUlQ_0oCkImdAxBIbMNrJdLvvMEK1qIVaozcPbKw1hNHUvpGzEY4RitoYBE1UIXJysa$> and likely other consumers do not support this practice, a clear prohibition felt in the best interest of this community to help standardize expected behavior.

  1.  [Aaron] Can CA owners share:

  *   How many certificates you have which embed a CRLDP?

     *   New Response: While not a CA, I was hoping to help offer additional context using the Censys queries outlined here<https://urldefense.com/v3/__https://docs.google.com/spreadsheets/d/1oHWJTlVuZIhOwTE9lsx4iT4UsA0C_tP7mGEHW9nfwII/edit*gid=0__;Iw!!FJ-Y8qCqXTj2!f6JiZayyK01P2H7iQEXTI1JymI9pvfoMIwUlQ_0oCkImdAxBIbMNrJdLvvMEK1qIVaozcPbKw1hNHUvpGzEY4RitoYBE1aXfOMjw$>. My interpretation of the results is that ~36% of all time-valid leafs asserting a BR certificate policy OID contain a CRLDP, and that ~88% of the CAs issuing those leafs include CRLDP by default on 100% of certs issued that assert a BR policy OID (i.e., the set of CAs capable of turning down OCSP services as described in the ballot). Feedback on the queries to offer more accurate results are welcome.

  *   How many requests-per-second you receive for that CRLDP as a result?

     *   [not yet addressed]

  1.  [Wayne] Expressed concern that the ballot does not prevent CAs from sharding CRLs to the point that individual sites are easily or exclusively identified, so even allowing cRLDPs in end-entity certificates seems to violate the purpose of this ballot.

  *   New Response: It’s unclear why a CA would be incentivized to do this, but it is a valid point. Short of authoritatively describing accepted conditions (e.g., based on certificate issuance time) and minimal thresholds for sharding (e.g., minimally 100 certificates assigned to each CRLDP), I’m unsure how we might prevent this practice. Do others share this same concern or have ideas as to how we can reduce this unintended outcome?

  1.  [Wayne] Is there some other reason to begin requiring cRLDPs if the CA chooses to operate an OCSP service after this ballot goes into effect?

  *   New Response: This is a fair point, and now it helps me better understand the perspective from Tim H. at the last SCWG meeting (sorry for misunderstanding your point at that time, Tim!). I agree - if the subscriber certificate contains an OCSP URI, it should not also be required to include CRLDP. Alternative language proposed here<https://urldefense.com/v3/__https://github.com/ryancdickson/staging/commit/2ab659ca36ab0f72318c5b9bec1121cd389f1035__;!!FJ-Y8qCqXTj2!f6JiZayyK01P2H7iQEXTI1JymI9pvfoMIwUlQ_0oCkImdAxBIbMNrJdLvvMEK1qIVaozcPbKw1hNHUvpGzEY4RitoYBE1SyJRRfP$> attempts to offer this flexibility.

Thanks again,


On Tue, May 2, 2023 at 4:44 PM Aaron Gable <aaron at letsencrypt.org<mailto:aaron at letsencrypt.org>> wrote:
Fair enough, thanks for the info! I'm convinced that explicitly disallowing indirect CRLs in this ballot is fine.


On Tue, May 2, 2023 at 2:00 AM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>> wrote:

On 27/4/2023 8:57 μ.μ., Aaron Gable via Servercert-wg wrote:
> I believe that CAs have generally found that Delegated OCSP Signers
> cause more trouble than they're worth, and the same is likely true for
> Delegated CRL Issuers

Hello Aaron,

I don't think there is evidence to support this claim about delegated
OCSP Signers. I am aware of a number of CAs that still use and prefer
the delegated OCSP responder model over the pre-signed responses model.

However, I am not aware of any CA that uses delegated CRL issuers and
perhaps it's not even supported by the existing Browsers.

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230503/03612ccf/attachment-0001.html>

More information about the Servercert-wg mailing list