[Servercert-wg] Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”
Ryan Dickson
ryandickson at google.com
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>
More information about the Servercert-wg
mailing list