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

Wed May 3 20:43:31 UTC 2023

Ryan,

Thanks for the PR with proposed ballot updates! I've left more comments
directly on it, some tiny and some slightly more substantive continuations
of the conversations here and on the other thread.

Aaron

On Wed, May 3, 2023 at 10:38 AM Ryan Dickson <ryandickson at google.com> wrote:

> Hi Paul,
>
>
> I appreciate that perspective and will take it under continued
> consideration.
>
>
> That same perspective was carefully considered while drafting the Ballot
> and in discussions with community members since introducing the proposal at
> F2F 56.
>
>
> However, I see all of these efforts tightly commingled and splitting the
> Ballot into smaller pieces:
>
>    - Increases ambiguity.
>    - Causes unnecessary administrative burden. It takes a meaningful
>    amount of effort and time to propose, discuss, vote, and adopt updates to
>    the BRs. Consolidating and/or reducing that effort should be prioritized
>    when possible.
>    - Commits the group to future review/comment periods that, in my
>    opinion, ultimately hold us back from pursuing other important ballot work
>    (like what we hope to accomplish with Multi-Perspective Domain Validation,
>    refreshing the EVGs, etc.)
>
>
> Given that the group successfully navigated the complexity of SC-62, I'm
> hopeful we can continue working together to do the same with this
> Ballot. If it becomes clear that this is not possible, I'll re-evaluate
> this approach and change course.
>
>
> Thanks again for your feedback.
>
>
> - Ryan
>
>
>
> On Wed, May 3, 2023 at 11:54 AM Paul van Brouwershaven <
> Paul.vanBrouwershaven at entrust.com> wrote:
>
>> 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.
>>
>> Paul
>>
>>
>> ------------------------------
>> *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,
>>
>> 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.
>>
>> *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/a6762eef/attachment-0001.html>