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

Fri Nov 4 11:50:32 UTC 2022

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.

•••••••

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

6.
7.
8.      Requires CAs include the corresponding HTTP URI for either the full and complete or partitioned/sharded CRL in
9.      the CRL Distribution Point extension of subscriber certificates (i.e., TLS server certificates), with an exception for Short-lived Subscriber Certificates (see below).
10.

11.
12.
13.     Makes OCSP services
14.     optional
15.     for CAs. If a CA continues supporting OCSP, the same requirements apply as they do today.
16.

17.
18.
19.     Re-visits the concept of a Short-lived Subscriber Certificate - an
20.     optional
21.     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
22.     optionally
23.     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).
24.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20221104/a70f109f/attachment-0001.html>