Feedback 113: Requirements for OCSP stapling and caching

[CDR-Register-Stream]

We would like to collate the conversations in OCSP stapling and caching into this issue and ask the community how these concepts add value to their build.

Requirements:

To maintain integrity of the CDR ecosystem and to protect sensitive information, there is an expectation that participants will follow standard certificate practice to validate certificates and immediately prevent certificate authentication when a revoked certificate is presented within the CDR ecosystem.

OCSP Stapling

Using OCSP stapling to move the responsibility for OCSP lookups to the owner of the certificate, are we adding any value to the regime? If we have an Mutual TLS handshake and the client and server certificates are OCSP stapled, then there is still the same number of OCSP lookups and each party still has a part to play. Is there benefit to be had from this optimisation?

OCSP Caching

Current guidelines for caching has been as follows:

As for caching, the CA provides real-time checking capability. and has a service uptime of 99.9%. It is a requirement for all participants to perform real-time checking of the OCSP. In the instances where the service is not available, participants must revert to the CRL as a backup. The applications can look into the certificate to know where to verify the CRL or OCSP.

What is the real impact here for participants. Are the number of SSL sessions in play proportional to the number of Data Holders / Data Recipients (brands) as opposed to the number of consumers? If so, is the volume of clients actually significant enough to warrant mandating a caching model?

[perlboy]

The Register specifications only mention of OCSP is in the Certificate Authority Unavailable Availability section. There is nothing in this CDR Register specification that requires OCSP to be implemented.

The DSB Standards have zero references to OCSP. This was highlighted by @commbankoss in July 2019.

Neither documents have a reference to RFC6960.

The last discussion on this within the DSB indicated it was an ACCC decision. There is another open ticket where @commbankoss mentioned it both in July 2019 and October 2019. Further it was asked again in August 2019 by @fahadbinrahat.

So from my perspective from a formal specification standpoint there is no expectation for OCSP. That's not to say OCSP isn't a good idea (it is and I support it) but since it's not in the spec there's limited reason to think it's actually been implemented.

Fundamentally, the OCSP caching component comes down to a combination of the SLA being 99.9% which would mean that a once a year outage of 8hrs and 45 mins would need to be considered and, based on the quoted item, which I assume is in some ticket somewhere cause it isn't in the published spec, would mean the CRL is cached regularly as well.

I guess the summary for me is: There's no specification that states OCSP is required in the first place so why are you asking about caching?

[CDR-Register-Stream]

This issue is currently associated with Project 1.3 targeting completion by February/March 2021.

We are seeking feedback from the community on where this issue sits in terms of priority and the potential impact for deferring addressing this post February/March 2021.

Feedback has been requested in this and other forums and will be considered until 1st September 2020

[CDR-Register-Stream]

We are extending the request for feedback until 6th September to give collaborators greater opportunity to contribute

[WestpacOpenBanking]

There are both technical and security impacts to participants if their certificate management implementation is altered to use OCSP stapling and/or caching of OCSP responses. In particular there is a risk that a revoked certificate would still be considered valid for the lifetime of any cached or stapled certificate validity statuses. Westpac is likely able to support either of these by reconfiguring our infrastructure but this change may be more impactful for other participants.

OCSP stapling and response caching provide similar performance benefits by not requiring the validation of the TLS certificate with the OCSP responder for every connection. The number of entities that need to perform OCSP lookups would remain similar within the eco-system (driven by the number of Data Holders and Recipients) as stapled or cached OCSP results still need to be refreshed on a regular basis.

We note that there is currently a requirement to cache OCSP responses in the event that the ACCC’s OCSP responder is unavailable. If stapling and/or caching are adopted then the behaviours in the case of outages should be specified.

We expect that the number of SSL connections that this decision affects is proportional to the total number of data holders and data recipients. Although the volume of usage is proportional to then number of customers accessing ADR apps. We also note we do not expect the customer connections to ADR apps to be affected by this decision as they will be using public certificates from a variety of CAs.

At present we would argue that the volume of clients is not yet significant enough to mandate a stapling or caching model but it is likely that the ecosystem will eventually grow to a size where there is significant benefit. We are supportive of including this issue in the March v1.3.0 release or later. We note that the implementation complexity of stapling may be higher for many participants and this may drive the decision one way or the other.

The simplest change is caching because it is already a requirement for when the OCSP responder is unavailable. We suggest the most appropriate change to the registry specifications until volumes increase is to add the statement that certificates should be validated using OCSP, with a reference to RFC6960. In particular, participants:

• May or may not use cached OCSP responses when the OCSP responder is available.
• Must use cached responses when the responder is not available.
• Must honour the cache expiry times set by the register.

[CDR-Register-Stream]

For OCSP functionality, please refer to the Certificate Practice Statement in the Certificate Management section of the CDR Register design.

Keeping this ticket open to revisit early 2021

[CDR-Register-Stream]

We are seeking data points on the best practice for OCSP caching, handling OCSP service outages and fall back to CRLs.

It would be beneficial to understand what security requirements other organisations impose.

[CDR-Register-Stream]

The ACCC has published an article on certificate validation to help articulate how participants should validate whether ACCC CA issued certs are to be trusted.

Regarding OCSP caching and handling outages of OCSP services, I've extracted following guidance from the published article:

Unavailability
While certificate status services are designed to be available 24x7 without interruption, there may be times when the certificate status services are unavailable.

Relying Parties are bound to their obligations and the stipulations of the Relaying Parties, Certificate Policy and the Certification Practice Statement irrespective of the availability of the certificate status service.

Certificate status services are available 24x7 without interruption. However, there may be times when the certificate status services are unavailable.

Relying Parties are bound to their obligations and the stipulations of the Relying Party Agreement, Certificate Policy and the Certification Practice Statement irrespective of the availability of the certificate status service.

The Register Design Reference outlines that data sharing cannot proceed if the authenticating certificate(s) revocation status checking is not possible, either in 'real time' or cached mode.

NOTE: CRL and OCSP revocation checking responses have a set validity period.

Participants may decide to use CRL as a fallback mechanism when OCSP is unavailable and some infrastructure products and services support this configuration. Participants are encouraged to consult product documentation for their particular situation.

Additionally, we can confirm that OCSP stapling is not currently a requirement within the ecosystem