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

Wed May 3 13:59:44 UTC 2023

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://docs.google.com/document/d/180T6cDSWPy54Rb5d6R4zN7MuLEMShaZ4IRLQgdPqE98/edit#bookmark=id.ceedtvdz1590>.
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://github.com/ryancdickson/staging/pull/3/files> 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://github.com/ryancdickson/staging/tree/make-ocsp-optional-updates>
   branch.

   1.

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

   -

   New Response: Alternative language proposed here
   <https://github.com/ryancdickson/staging/commit/1bc7e08cc403a25db874d4fb56af7ca46571406c>
   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://source.chromium.org/chromium/chromium/src/+/refs/heads/main:net/cert/internal/revocation_checker.cc;l=167-169;drc=e39fffa6900a679961f5992b8f24a084853b811a>
   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://docs.google.com/spreadsheets/d/1oHWJTlVuZIhOwTE9lsx4iT4UsA0C_tP7mGEHW9nfwII/edit#gid=0>.
      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://github.com/ryancdickson/staging/commit/2ab659ca36ab0f72318c5b9bec1121cd389f1035>
   attempts to offer this flexibility.

Thanks again,

Ryan

On Tue, May 2, 2023 at 4:44 PM Aaron Gable <aaron at letsencrypt.org> wrote:

> Fair enough, thanks for the info! I'm convinced that explicitly
> disallowing indirect CRLs in this ballot is fine.
>
> Aaron
>
> On Tue, May 2, 2023 at 2:00 AM Dimitris Zacharopoulos (HARICA) <
> 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.
>>
>>
>> Thanks,
>> Dimitris.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230503/f33f9f09/attachment-0001.html>