[Servercert-wg] Following up: Proposal to make OCSP optional (introduced at Face-to-Face 57)
Ryan Dickson
ryandickson at google.com
Wed Feb 1 20:50:53 UTC 2023
I appreciate the continued discussion, and look forward to hearing
additional opinions from the community.
A few thoughts below:
Thank you Aaron, this is very useful information. First off, I am not
> convinced that the poor adoption of the must-staple extension by Let's
> Encrypt Subscribers correlates to poor adoption of OCSP stapling in general
> given that some web servers and many CDNs enable stapling by default. I did
> find some data to support my assertion: roughly 1/3 of connections made by
> clients to Fastly's CDN include the TLS Certificate Status Request
> extension <https://datatracker.ietf.org/doc/html/rfc6066#page-14>,
> meaning that a stapled OCSP response is desired.
Poor adoption of the “must-staple” extension does not seem limited to any
particular issuer’s subscriber population.
I queried the Censys.io dataset to understand usage of the “must-staple”
extension across the ecosystem. Based on my interpretation of the results
<https://docs.google.com/document/d/1C0i0pOaI84gNccGzREPOrr5kMfpYkUEr87cBMZ09q_4/edit?usp=sharing>,
the “must-staple” extension is only present in approximately .0622% of
time-valid TLS server certificates that assert a CA/Browser Forum policy
OID (if we assume all pre-certificates have a corresponding certificate).
Suggestions are welcome if these queries can be improved to produce more
accurate results.
The fact that Let's Encrypt continues to see high volumes of OCSP requests
> - despite my assumption that the most popular browsers have moved away from
> OCSP checking - is informative and makes me concerned about the effect this
> ballot will have on Relying Parties (RPs). One might reasonably conclude
> that OCSP is still heavily used by some clients today and that if this
> ballot passes some CAs will shut down their OCSP services due to the cost
> and operational burden. RPs can choose their browser, but not the server
> certificate for a website they wish to visit. So as a RP, if a website
> operator decides to use a CA that doesn't support OCSP, the RP would be
> forced to either (1) download CRLs, (2) switch to a client that supports a
> non-standardized revocation mechanism, or (3) forego revocation checking.
> Moving a significant quantity of status queries from OCSP back to
> traditional CRLs is not a net win for anyone, nor do the other two outcomes
> seem desirable from the perspective of a RP.
> There are clear benefits to moving away from [non-stapled] OCSP, but it
> may be premature to allow CAs to stop operating a service that is still
> apparently in high demand by RPs when those RPs can't simply choose another
> CA.
It’s my understanding that today, at least Firefox and Apple products
perform “online” (sometimes called "live") OCSP checks by default. Chrome
and some other Chromium-based browsers support enabling an optional enterprise
policy
<https://chromeenterprise.google/policies/#EnableOnlineRevocationChecks> to
offer similar functionality. These configurations, and others like them,
might account for the high volume of requests observed by some CAs.
However, user privacy concerns have led to some browsers that actively rely
on online OCSP checks to express intent to change future behavior (e.g., slide
7
<https://cabforum.org/wp-content/uploads/1-3-2022-October-Mozilla-Update-for-CABF-Berlin-F2F.pdf>)
- meaning existing request volume should drop if all else remains the same.
Regardless, despite online OCSP checks being made by some browsers (or
other products) today, there’s no guarantee these checks are "used" or
provide security value to relying parties (for example, where products
soft-fail if OCSP responses are not received within defined time thresholds
or return unexpected values).
Stapled responses address online checks’ privacy concerns, allow for "hard
failure", and should be considered positive. Looking at existing publicly
available data sources, Firefox telemetry
<https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2023-01-24&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F110&measure=SSL_OCSP_STAPLING&min_channel_version=beta%252F104&processType=*&product=Firefox&sanitize=0&sort_by_value=0&sort_keys=submissions&start_date=2023-01-16&table=0&trim=0&use_submission_date=0>
suggests that approximately 8% of connections in Firefox 110 Beta serve a
stapled response. I’m unaware of anything that would suggest telemetry from
Beta would be significantly different than Stable - or that Firefox user
browsing habits are significantly different than those of other browser
users.
Independent of usage statistics, relying parties can’t consistently depend
on OCSP stapling for security unless responses are stapled on all
connections. Further, even if the web server ecosystem had improved support
for OCSP-stapling and we could require the use of the “must-staple”
extension, we’d remain dependent upon robust and highly-reliable OCSP
services, which have been an ongoing ecosystem challenge (1
<https://bugzilla.mozilla.org/buglist.cgi?list_id=16246368&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&product=CA%20Program&query_format=advanced&component=CA%20Certificate%20Compliance&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=INACTIVE&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&resolution=MOVED&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&classification=Graveyard&short_desc=OCSP&short_desc_type=allwordssubstr>
and 2 <https://sslmate.com/labs/ocsp_watch/>).
In my opinion, prioritizing the transition to short-lived TLS server
certificates (incentivized in this ballot) is a better use of ecosystem
participant (i.e., server platforms, site owners, CAs, and certificate
consumers) effort and resources with security benefits that go beyond
improved certificate status checking (e.g., improved agility, continuous
improvement as standards and best practices evolve, improved incident
response, etc.).
My opinion aside, giving CA owners the option of choosing whether they
continue supporting OCSP beyond the required period described in the ballot
may instead present them with the opportunity to pursue other initiatives
that improve the security, reliability, and agility of the Web PKI and/or
better serve their subscriber community needs -- without constraining CAs
who wish to continue supporting OCSP from also doing the same.
On Thu, Jan 19, 2023 at 1:29 PM Wayne Thayer <wthayer at gmail.com> wrote:
> Thank you Aaron, this is very useful information. First off, I am not
> convinced that the poor adoption of the must-staple extension by Let's
> Encrypt Subscribers correlates to poor adoption of OCSP stapling in general
> given that some web servers and many CDNs enable stapling by default. I did
> find some data to support my assertion: roughly 1/3 of connections made by
> clients to Fastly's CDN include the TLS Certificate Status Request
> extension <https://datatracker.ietf.org/doc/html/rfc6066#page-14>,
> meaning that a stapled OCSP response is desired.
>
> The fact that Let's Encrypt continues to see high volumes of OCSP requests
> - despite my assumption that the most popular browsers have moved away from
> OCSP checking - is informative and makes me concerned about the effect this
> ballot will have on Relying Parties (RPs). One might reasonably conclude
> that OCSP is still heavily used by some clients today and that if this
> ballot passes some CAs will shut down their OCSP services due to the cost
> and operational burden. RPs can choose their browser, but not the server
> certificate for a website they wish to visit. So as a RP, if a website
> operator decides to use a CA that doesn't support OCSP, the RP would be
> forced to either (1) download CRLs, (2) switch to a client that supports a
> non-standardized revocation mechanism, or (3) forego revocation checking.
> Moving a significant quantity of status queries from OCSP back to
> traditional CRLs is not a net win for anyone, nor do the other two outcomes
> seem desirable from the perspective of a RP.
>
> There are clear benefits to moving away from [non-stapled] OCSP, but it
> may be premature to allow CAs to stop operating a service that is still
> apparently in high demand by RPs when those RPs can't simply choose another
> CA.
>
> Wayne
>
> On Wed, Jan 18, 2023 at 12:31 PM Aaron Gable <aaron at letsencrypt.org>
> wrote:
>
>> Apologies for resurrecting a two-month-old thread, but I think it's
>> valuable to address Wayne's questions here about current usage of OCSP.
>>
>> For Let's Encrypt, OCSP is easily our greatest cost. We receive
>> approximately an order of magnitude more requests for OCSP than we do for
>> *all ACME endpoints combined*. And that's after using a CDN to aggressively
>> cache OCSP responses, too. We spent a significant amount of engineering
>> time last year completely rearchitecting our OCSP serving infrastructure in
>> order to scale beyond 200M simultaneously active certificates.
>>
>> At the same time, stapling is incredibly rare. We obviously can't tell
>> how many of our OCSP requests come from servers for the purpose of
>> stapling, rather than from clients. But we can look at what percentage of
>> certificates are issued with the "must-staple" extension: over the last 30
>> days, 0.11% of Let's Encrypt certs have been issued with the must-staple
>> extension. That's not indicative of any kind of widespread adoption, even
>> though the must-staple RFC is over 7 years old at this point.
>>
>> I hope this data helps others consider whether allowing OCSP to fall by
>> the wayside will benefit or harm the Web PKI ecosystem.
>>
>> Aaron
>>
>> On Fri, Nov 11, 2022 at 9:54 AM Wayne Thayer via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>>> I raised this concern on yesterday's SCWG call and want to mention it
>>> here as well: OCSP stapling, when enabled, is a standardized approach to
>>> delivering revocation information that is performant, scalable, and privacy
>>> preserving. Stapling of course requires CAs to support OCSP, but this
>>> ballot combined with the costs and challenges of operating OCSP services
>>> disincentivizes CAs from doing so. It was pointed out that this ballot
>>> doesn't prevent CAs from offering OCSP and that is a fair point. But it
>>> does mean that clients can't depend on it being there, and seems likely to
>>> move the ecosystem further down the path of relying on proprietary
>>> revocation mechanisms or none at all.
>>>
>>> I would find it very helpful to have some data from CAs* on current OCSP
>>> usage levels, and how much of that is stapling. I'd be more comfortable
>>> with this change if I knew that OCSP was already essentially "dead".
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> * Yes I represent a CA, but our services are too new to constitute a
>>> meaningful sample.
>>>
>>> On Tue, Nov 8, 2022 at 6:56 PM Ryan Dickson via Servercert-wg <
>>> servercert-wg at cabforum.org> wrote:
>>>
>>>> Hi Martijn,
>>>>
>>>>
>>>>
>>>> Thank you for opening up the conversation (and my apologies for the
>>>> delay in my response)! Responses are inline, below.
>>>>
>>>> Would you be able to make this into a draft pull request already? That
>>>>> may aid in discussing and adding suggestions directly int GitHub.
>>>>
>>>>
>>>> Done <https://github.com/cabforum/servercert/pull/402>!
>>>>
>>>>
>>>> At the moment, the one item that caught my attention is the proposed
>>>>> removal of having to revoke short-lived subscriber certificates.
>>>>>
>>>>> As I understand it, the proposal on the one hand removes the needs for
>>>>> adding an OCSP Pointer and CRLDP into Short-lived subscriber certificates.
>>>>> With the current requirement from several root store operators to disclose
>>>>> CRLs into CCADB (even when not actually included in the subscriber
>>>>> certificates) however, CAs still need to generate and publish CRLs, even
>>>>> for Short-lived Subscriber Certificates.
>>>>
>>>>
>>>> Correct. As currently presented in the draft and discussed further
>>>> below:
>>>>
>>>>
>>>> -
>>>>
>>>> CAs may optionally issue Short-lived Subscriber Certificates
>>>> -
>>>>
>>>> CAs may optionally revoke Short-lived Subscriber Certificates
>>>> -
>>>>
>>>> X.509/RFC 5280
>>>> <https://www.rfc-editor.org/rfc/rfc5280#section-3.3:~:text=A%20CRL%20is%20a%20time%2Dstamped%20list%0A%20%20%20identifying%20revoked%20certificates%20that%20is%20signed%20by%20a%20CA%20or%20CRL%20issuer%0A%20%20%20and%20made%20freely%20available%20in%20a%20public%20repository.>
>>>> describes a CRL as “a time-stamped list identifying revoked
>>>> certificates that is signed by a CA or CRL issuer and made freely available
>>>> in a public repository.”
>>>>
>>>>
>>>> Consequently, if a Short-lived Subscriber Certificate is not revoked,
>>>> we should not expect it to appear on a CRL disclosed to CCADB.
>>>>
>>>> Regardless of whether a CA issues Short-lived Subscriber Certificates,
>>>> it does not change the expectation of root program policies related to CRL
>>>> generation and publication. As an aside, it seems reasonable to expect that
>>>> a CA that only issues Short-lived Subscriber Certificates would sign a CRL
>>>> with no revoked serial numbers represented.
>>>>
>>>> I do not interpret the failure to revoke a Short-lived Subscriber
>>>> Certificate to conflict with Apple
>>>> <https://www.apple.com/certificateauthority/ca_program.html#:~:text=Effective%20October%201,Apple%20Root%20Program.>
>>>> or Mozilla’s
>>>> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#:~:text=Effective%20October%201,Partitioned%20CRLs%22%3B%20and>
>>>> requirements for CRL publication. However, those program representatives
>>>> are encouraged to share their interpretations to avoid assumptions.
>>>>
>>>> The proposal to remove the 24 hour and 5 day rules for revocation on
>>>>> these certificates seems to make it completely impossible to revoke these
>>>>> certificates, which seems like another security boundary is being removed.
>>>>>
>>>>>
>>>>
>>>>
>>>> More below, but minor clarification - the proposal expresses revocation
>>>> for Short-lived Subscriber Certificates is optional.
>>>>
>>>> I can’t help but think the contrast is very big on this. Are we ready
>>>>> to allow for potential subscriber key compromises and the inability to
>>>>> revoke at all for up to 10 days vs required revocation within 24 hours at
>>>>> this moment?
>>>>
>>>>
>>>> Thanks for calling attention to this.
>>>>
>>>>
>>>>
>>>> In my last message, I highlighted that one of the update’s goals was to
>>>> align the BRs with browser behavior. The proposed changes related to
>>>> Short-lived Subscriber Certificates are consistent with today’s default
>>>> behavior of many, but not all, of the browsers represented in this Forum.
>>>>
>>>>
>>>>
>>>> [Disclaimer: I cannot and do not intend to speak authoritatively for
>>>> any of the products represented in the list below other than Chrome. Please
>>>> call out anything that is inaccurate or misrepresents existing
>>>> functionality!]
>>>>
>>>>
>>>>
>>>> For example:
>>>>
>>>>
>>>>
>>>> -
>>>>
>>>> By default, regardless of validity, Chrome does not perform online
>>>> OCSP or CRL checks for TLS server certificates. Chrome will honor stapled
>>>> OCSP responses and communicates some status information via CRLSets, a
>>>> feature primarily intended to communicate the status of CA certificates.
>>>> -
>>>>
>>>> Edge’s behavior is similar
>>>> <https://textslashplain.com/2022/08/01/certificate-revocation-in-microsoft-edge/>
>>>> to Chrome’s (Chromium-based).
>>>> -
>>>>
>>>> Mozilla’s Wiki
>>>> <https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#:~:text=Firefox%20does%20not%20perform%20any%20form%20of%20revocation%20checking%20for%20certificates%20with%20a%20validity%20period%20of%20less%20than%2010%20days.%20That%20period%20is%20configurable%20via%20the%20security.pki.cert_short_lifetime_in_days%20preference.>
>>>> states Firefox “does not perform revocation checking for certificates with
>>>> a validity of less than 10 days.”
>>>>
>>>>
>>>>
>>>> We know the above behavior is only true for some user agents. For
>>>> example, Apple’s default status-checking behavior currently relies on OCSP
>>>> checks (online and cached). Some user agents offer policies that change the
>>>> default behavior to enable online revocation checks (e.g., “
>>>> EnableOnlineRevocationChecks
>>>> <https://chromeenterprise.google/policies/#EnableOnlineRevocationChecks>”
>>>> in Chrome). For context, across clients where this policy is supported and
>>>> measurable, Chrome sees it enabled for less than .1% of stable users.
>>>>
>>>>
>>>>
>>>> Regardless of certificate validity, when online checks are performed by
>>>> default, it is not clear to what extent these checks result in soft
>>>> failures because:
>>>>
>>>>
>>>>
>>>> -
>>>>
>>>> Response timeouts (e.g., the response is not received within 2
>>>> seconds - possibly due to client networking issues or CA-side errors)
>>>> -
>>>>
>>>> Requesting host is compromised or under active attack (e.g., status
>>>> request is intentionally misrouted or the response is blocked - and in this
>>>> case, limiting the corresponding certificate validity could improve
>>>> users’ security compared to a 398-day certificate)
>>>>
>>>>
>>>>
>>>> The maximum 10-day certificate validity is aligned with the existing
>>>> maximum values for CRL nextUpdate and OCSP response validity allowed by the
>>>> BRs today. It’s possible, through these discussions, we realize the desire
>>>> to re-evaluate these permitted thresholds (e.g., the CRL requirements have
>>>> existed since Version 1
>>>> <https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf>
>>>> of the BRs). It seems reasonable to correlate the validity of a Short-lived
>>>> Subscriber Certificate with the nextUpdate / response validity periods -
>>>> but I am open to other perspectives.
>>>>
>>>>
>>>>
>>>> It might be compelling to better understand the impact of this proposed
>>>> change by studying historical data (though imperfect, it might allow us to
>>>> better imagine future impacts). For example, knowing how often, on average,
>>>> we see certificates revoked within ten days of issuance - and what
>>>> percentage of those are marked with a reasonCode of keyCompromise. Given
>>>> the dynamic nature of CRLs (e.g., revoked certificates falling off lists),
>>>> this analysis might best be accomplished by CAs.
>>>>
>>>>
>>>>
>>>> In any event, I’m happy to see this conversation beginning and am
>>>> hopeful we’ll hear from additional participants (either on the thread or on
>>>> GitHub) soon.
>>>>
>>>>
>>>>
>>>> - Ryan
>>>>
>>>>
>>>>
>>>> On Fri, Nov 4, 2022 at 7:50 AM Martijn Katerbarg <
>>>> martijn.katerbarg at sectigo.com> wrote:
>>>>
>>>>> Ryan,
>>>>>
>>>>> Would you be able to make this into a draft pull request already? That
>>>>> may aid in discussing and adding suggestions directly int GitHub.
>>>>>
>>>>>
>>>>>
>>>>> At the moment, the one item that caught my attention is the proposed
>>>>> removal of having to revoke short-lived subscriber certificates.
>>>>>
>>>>>
>>>>>
>>>>> As I understand it, the proposal on the one hand removes the needs for
>>>>> adding an OCSP Pointer and CRLDP into Short-lived subscriber certificates.
>>>>> With the current requirement from several root store operators to disclose
>>>>> CRLs into CCADB (even when not actually included in the subscriber
>>>>> certificates) however, CAs still need to generate and publish CRLs, even
>>>>> for Short-lived Subscriber Certificates.
>>>>>
>>>>>
>>>>>
>>>>> The proposal to remove the 24 hour and 5 day rules for revocation on
>>>>> these certificates seems to make it completely impossible to revoke these
>>>>> certificates, which seems like another security boundary is being removed.
>>>>>
>>>>>
>>>>>
>>>>> I can’t help but think the contrast is very big on this. Are we ready
>>>>> to allow for potential subscriber key compromises and the inability to
>>>>> revoke at all for up to 10 days vs required revocation within 24 hours at
>>>>> this moment?
>>>>>
>>>>>
>>>>> Martijn
>>>>>
>>>>>
>>>>>
>>>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
>>>>> Of *Ryan Dickson via Servercert-wg
>>>>> *Sent:* Tuesday, 1 November 2022 13:51
>>>>> *To:* ServerCert CA/BF <servercert-wg at cabforum.org>
>>>>> *Subject:* [Servercert-wg] Following up: Proposal to make OCSP
>>>>> optional (introduced at Face-to-Face 57)
>>>>>
>>>>>
>>>>>
>>>>> CAUTION: This email originated from outside of the organization. Do
>>>>> not click links or open attachments unless you recognize the sender and
>>>>> know the content is safe.
>>>>>
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> I am following up on our discussions from last week’s Face-to-Face
>>>>> meeting in Berlin.
>>>>>
>>>>>
>>>>>
>>>>> During the SCWG, I shared this
>>>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F180T6cDSWPy54Rb5d6R4zN7MuLEMShaZ4IRLQgdPqE98%2Fedit&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cfb8f20d33c014483310508dabc07b273%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638029038496783843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IxGeR8SIaBoejzGxWJ9wt3QyEGIdkNwLmvDvrN%2F9ni4%3D&reserved=0>
>>>>> link that describes a proposal for a future ballot
>>>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2Fprofiles...ryancdickson%3Astaging%3Aprofiles&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cfb8f20d33c014483310508dabc07b273%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638029038496783843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eqcrkqO1V9KOyRP1Bk3bNRhNih4OUq4sYcQ6jLSuxH4%3D&reserved=0>
>>>>> that:
>>>>>
>>>>>
>>>>>
>>>>> 1.
>>>>> 2.
>>>>> 3. Requires CAs generate and publish either:
>>>>> 4.
>>>>>
>>>>> ·
>>>>>
>>>>> ·
>>>>>
>>>>> · a full and complete CRL, or
>>>>>
>>>>> ·
>>>>>
>>>>> ·
>>>>>
>>>>> ·
>>>>>
>>>>> · partitioned CRLs (sometimes called “sharded” CRLs) that, when
>>>>> aggregated, represent the equivalent of a full and
>>>>>
>>>>> · complete CRL.
>>>>>
>>>>> ·
>>>>>
>>>>> 1.
>>>>> 2.
>>>>> 3. Requires CRLs are updated and reissued at least once daily.
>>>>> 4.
>>>>>
>>>>>
>>>>> 1.
>>>>> 2.
>>>>> 3. Requires CAs include the corresponding HTTP URI for either the
>>>>> full and complete or partitioned/sharded CRL in
>>>>> 4. the CRL Distribution Point extension of subscriber certificates
>>>>> (i.e., TLS server certificates), with an exception for Short-lived
>>>>> Subscriber Certificates (see below).
>>>>> 5.
>>>>>
>>>>>
>>>>> 1.
>>>>> 2.
>>>>> 3. Makes OCSP services
>>>>> 4. optional
>>>>> 5. for CAs. If a CA continues supporting OCSP, the same
>>>>> requirements apply as they do today.
>>>>> 6.
>>>>>
>>>>>
>>>>> 1.
>>>>> 2.
>>>>> 3. Re-visits the concept of a Short-lived Subscriber Certificate -
>>>>> an
>>>>> 4. optional
>>>>> 5. certificate offering with a validity less than ten days that is
>>>>> not required to contain either a CRLDP or OCSP Pointer. As currently
>>>>> written, CAs may
>>>>> 6. optionally
>>>>> 7. support revocation for short-lived certificates - but they
>>>>> would still be responsible for blocking future issuance to confirmed
>>>>> compromised keys (defined in 6.1.1.3).
>>>>> 8.
>>>>>
>>>>>
>>>>>
>>>>> Justification for combining both the proposed revocation changes and
>>>>> the Short-lived Subscriber Certificate discussion into a single ballot is
>>>>> two-fold:
>>>>>
>>>>> 1.
>>>>> 2.
>>>>> 3. reduce administrative burden in the ballot review, discussion,
>>>>> and approval process; and
>>>>> 4.
>>>>> 5.
>>>>> 6.
>>>>> 7. use of Short-lived Subscriber Certificates reduces CRL sizes,
>>>>> and due to the proposal requiring CRLs - this opportunity
>>>>> 8. seemed beneficial to both CA Owners and certificate consumers.
>>>>> 9.
>>>>>
>>>>>
>>>>>
>>>>> Discussion at the Face-to-Face focused on:
>>>>>
>>>>> -
>>>>> -
>>>>> - how the proposal impacts offline intermediates that are only
>>>>> brought online to issue test certificates as required
>>>>> - by the BRs;
>>>>> -
>>>>> -
>>>>> -
>>>>> - concern regarding delays in user agents consuming certificate
>>>>> status information (i.e., comparing the speed by
>>>>> - which changes can be conveyed via OCSP versus daily CRLs); and
>>>>> -
>>>>> -
>>>>> -
>>>>> - the corresponding implementation timeline (currently sharing the
>>>>> same effective date included in the profile work).
>>>>> -
>>>>>
>>>>>
>>>>>
>>>>> The doc linked above also contains additional considerations worth
>>>>> exploring (e.g., impact on CT log operators, impacts on other user agents,
>>>>> etc.).
>>>>>
>>>>>
>>>>>
>>>>> Beyond the goals and justification described in the doc linked above
>>>>> (e.g., privacy concerns with OCSP, the volume of OCSP-related incidents,
>>>>> and operational costs of running secure, highly available, and resilient
>>>>> OCSP services), we see an opportunity to align requirements defined in the
>>>>> BRs with browser implementations (both current and planned). The
>>>>> consideration for Short-lived Subscriber Certificates also presents an
>>>>> opportunity to incentivize the use of automation and the issuance of
>>>>> certificates with a reduced validity without requiring either behavior in
>>>>> the BRs.
>>>>>
>>>>>
>>>>>
>>>>> Comments, concerns, and volunteers for endorsers are welcome.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ryan
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>> Servercert-wg mailing list
>>>> Servercert-wg at cabforum.org
>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>>
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230201/93b75518/attachment-0001.html>
More information about the Servercert-wg
mailing list