Draft Language for SC-XXX: CA Resource Availability

[Dustin Hollenback]

Dear SC WG Members,

Following our discussion on CA resource availability during the last SC WG call, this topic is scheduled for the upcoming F2F 67 meeting.

To facilitate this discussion, I've drafted some proposed language for review here:

https://github.com/cabforum/servercert/compare/main...dustinhollenback-apple:servercert:patch-3

Background:

The current TLS Baseline Requirements (BRs) mandate CAs publish various resources (e.g., CP/CPS documents, CRLs, and OCSP responders) at URLs embedded in issued certificates and related infrastructure. However, the TLS BRs do not explicitly require these URLs to be programmatically accessible to automated clients such as relying parties, auditors, and root programs. In practice, some CAs have implemented access controls (e.g., User-Agent filtering, JavaScript requirements, CAPTCHAs) that prevent automated access to these essential resources.

Proposed Changes:

This draft proposes new requirements for TLS BR-mandated CA resources (CP/CPS documents, CRLs, OCSP responders):

• Accessibility: Requires programmatic access for automated clients. Explicitly prohibits barriers like User-Agent filtering, JavaScript, cookies, or CAPTCHAs, unless a documented alternative access method is provided.
• Disclosure: CAs must detail their availability, access, and rate-limiting policies in their CPS, including any documented exceptions and their provided alternative access methods.
• Failures: Persistent inaccessibility will be treated as Certificate Problem Reports.
• Effective Date: These requirements are scheduled to become effective on March 15, 2027.

My goal in sharing this draft proactively is to provide a concrete starting point for our discussion at the F2F 67 meeting regarding a potential change to the TLS BRs.

Thank you,

Dustin

[大野 文彰]

Dear Dustin-san,

 

Thank you for circulating the proposed language ahead of the F2F discussion.

 

As written, Section 2.2.1 appears to target the accessibility of BR‑mandated published resources such as CP/CPS documents, CRLs, and OCSP responders, which are commonly accessed in an automated manner by relying parties, auditors, and root programs.

 

I would appreciate clarification on the intended scope of this section: specifically, whether the accessibility constraints in 2.2.1 are limited to these repository‑style, programmatically consumed resources, or whether they are also intended to apply to operational processes such as the 24x7 revocation request and Certificate Problem Report channels described in BR 4.9.3.

 

In practice, certain operational models involve 24x7 contact mechanisms that immediately notify on‑call personnel (for example, via phone or paging systems). Treating these operational channels as equivalent to repository resources from an accessibility standpoint could substantially increase unsolicited or automated traffic, which in turn risks delaying the handling of legitimate revocation or incident reports—the opposite of the outcome BR 4.9.3 is intended to ensure.

 

Understanding whether such operational contact processes are within the intended scope of 2.2.1 would help frame a more precise and practical discussion at the F2F meeting.

 

Best regards,

 

ONO Fumiaki / 大野 文彰

(Japanese name order: family name first, in uppercase)

SECOM Trust Systems CO., LTD.

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/861290A3-151E-4489-996D-E50A3464219F%40apple.com.

[Aaron Gable]

Ono-san,

Thank you, I had the exact same question. But I also approached it from the opposite direction: I would like to get rid of the various "24x7" requirements in the BRs because they make it sound like even the tiniest downtime is a compliance incident, which is not a realistic or reasonable reflection of how software systems operate in practice. I like this draft's language around general availability and third-party service interruptions, and I wonder if we could use that same language for the other "24x7" requirements.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/OSOP286MB76482AD27379FBC70204287EAE7AA%40OSOP286MB7648.JPNP286.PROD.OUTLOOK.COM.