[Servercert-wg] Following up: Proposal to make OCSP optional (introduced at Face-to-Face 57)
ryandickson at google.com
Tue Nov 1 12:50:01 UTC 2022
I am following up on our discussions from last week’s Face-to-Face meeting
During the SCWG, I shared this
link that describes a proposal for a future ballot
Requires CAs generate and publish either:
a full and complete CRL, or
partitioned CRLs (sometimes called “sharded” CRLs) that, when
aggregated, represent the equivalent of a full and complete CRL.
Requires CRLs are updated and reissued at least once daily.
Requires CAs include the corresponding HTTP URI for either the full and
complete or partitioned/sharded CRL in the CRL Distribution Point extension
of subscriber certificates (i.e., TLS server certificates), with an
exception for Short-lived Subscriber Certificates (see below).
Makes OCSP services optional for CAs. If a CA continues supporting OCSP,
the same requirements apply as they do today.
Re-visits the concept of a Short-lived Subscriber Certificate - an
optional 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 optionally support revocation for short-lived
certificates - but they would still be responsible for blocking future
issuance to confirmed compromised keys (defined in 220.127.116.11).
Justification for combining both the proposed revocation changes and the
Short-lived Subscriber Certificate discussion into a single ballot is
reduce administrative burden in the ballot review, discussion, and
approval process; and
use of Short-lived Subscriber Certificates reduces CRL sizes, and due to
the proposal requiring CRLs - this opportunity seemed beneficial to both CA
Owners and certificate consumers.
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,
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Servercert-wg