[Servercert-wg] Following up: Proposal to make OCSP optional (introduced at Face-to-Face 57)
Ryan Dickson
ryandickson at google.com
Wed Nov 9 01:56:00 UTC 2022
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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20221108/c419ea80/attachment-0001.html>
More information about the Servercert-wg
mailing list