[Servercert-wg] Following up: Proposal to make OCSP optional (introduced at Face-to-Face 57)

[Ryan Dickson]

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://docs.google.com/document/d/180T6cDSWPy54Rb5d6R4zN7MuLEMShaZ4IRLQgdPqE98/edit>
link that describes a proposal for a future ballot
<https://github.com/cabforum/servercert/compare/profiles...ryancdickson:staging:profiles>
that:


   1.

   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.


   1.

   Requires CRLs are updated and reissued at least once daily.
   2.

   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).
   3.

   Makes OCSP services optional for CAs. If a CA continues supporting OCSP,
   the same requirements apply as they do today.
   4.

   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 6.1.1.3).


Justification for combining both the proposed revocation changes and the
Short-lived Subscriber Certificate discussion into a single ballot is
two-fold:

   1.

   reduce administrative burden in the ballot review, discussion, and
   approval process; and
   2.

   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,
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20221101/442daf37/attachment.html>