2012511 - D-Trust: CRL HTTP Media Type

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Ana Laura Martorano]

Preliminary Incident Report

Summary

• Incident description: D-Trust received an external report indicating that our HTTP CRL distribution endpoints currently serve CRLs using the media type x-pkcs7-crl instead of application/pkix-crl as specified in RFC 5280, Section 4.2.1.13 (CRL Distribution Points). Because RFC 5280 is treated as a normative reference, this is a deviation from RFC 5280 expectations for CRL publication. At this stage, the potential impact of changing the media type is under active investigation, including any potential interoperability effects. We are disclosing this issue proactively to ensure transparency while our analysis continue.
• Relevant policies: RFC 5280, Section 4.2.1.13 (CRL Distribution Points)
• Source of incident disclosure: Third Party Reported

Comment 1

[Jaime Hablutzel]

I might be wrong here (didn't check further), but the need for application/pkix-crl in the content-type is just a recommendation (note the "SHOULD"):

HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-crl in the content-type header field of the response.

Comment 2

[Peter Cooper Jr.]

Yes, but "SHOULD" means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." And so, if the CA didn't intentionally choose and carefully weigh whether to follow the recommendation or not, it may be helpful to the community and to other CAs to describe how a different media type came to be used. That is, it sounds (from the fact that this is being disclosed at all) that the fact that this didn't comply with the "SHOULD" in the RFC may have been a surprise, and so it may be valuable to follow the incident reporting process even if the resulting behavior itself isn't necessarily "wrong".

Comment 3

[Ana Laura Martorano]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description: CRLs were served via HTTP using the media type application/x-pkcs7-crl instead of the recommended media type application/pkix-crl as specified in RFC 5280, Section 4.2.1.13. While the RFC defines this requirement as a SHOULD, D-Trust determined—following review—that no current technical or operational justification existed for deviating from the recommendation. The configuration was therefore updated to align with RFC 5280.
• Timeline summary:
  • Non-compliance start date: N/A
  • Non-compliance identified date: 2026-01-23 
  • Non-compliance end date: 2026-02-05
• Relevant policies: RFC 5280, Section 4.2.1.13
• Source of incident disclosure: Third-party reported

Impact

• Total number of certificates: N/A
• Total number of "remaining valid" certificates: N/A
• Affected certificate types: N/A
• Incident heuristic: (2) No certificates affected
• Was issuance stopped in response to this incident, and why or why not?: No
• Analysis: N/A
• Additional considerations:

Timeline

Before 2008: CRL distribution initially configured using application/x-pkcs7-crl
2026-01-23, 21:31: External notification received referencing CRL Watch by sslmate
2026-01-24, 18:28: Response to the reporter, that we received the request and will start our investigation
2026-01-26, 08:30: Internal investigation and review of CRL delivery configuration started
2026-02-04, 13:00: Internal investigation ended; Determination that no current justification for deviation existed
2026-02-05: CRL delivery configuration updated to application/pkix-crl

Related Incidents

Bug	Date	Description
None	-	No directly related incidents identified

Root Cause Analysis

Contributing Factor #: Legacy MIME type retained

• Description: The CRL distribution endpoints were configured to serve CRLs using the media type application/x-pkcs7-crl. This configuration originated from early PKI deployment practices, where non-registered, PKCS#7-based media types were commonly used as informal conventions to support interoperability across heterogeneous client environments. Over time, the configuration remained in place
  Following an external notification referencing CRL Watch (https://sslmate.com/labs/crl_watch/), D-Trust reviewed the configuration in the context of its current client landscape and concluded that the original interoperability considerations no longer applied. No technical or operational reasons to continue deviating from the RFC 5280 recommendation were identified.
• Timeline: Before 2008 – 2026-02-05
• Detection: Third-party reported
• Interaction with other factors:
• Root Cause Analysis methodology used: 5 whys analysis

Lessons Learned

• What went well: The issue was promptly acknowledged following the external notification. A targeted technical review was performed, and the configuration was updated once it was confirmed that no valid justification for deviation remained.
• What didn’t go well: The reasoning behind the deviation from a SHOULD-requirement in RFC 5280 was not questioned for too long.
• Where we got lucky: The deviation was limited to HTTP delivery metadata and did not affect CRL correctness, availability, or revocation processing.
• Additional:

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Serve CRLs with application/pkix-crl	Corrective	Root Cause # 1	Correct Content-Type (externally verifible)	2025-02-05	Completed
Integrate CRL Watch (https://sslmate.com/labs/crl_watch/) monitoring	Prevent	Root Cause # 1	Continuous, automated “CRL Watch” monitoring integrated into internal alerting. Effectiveness measured by absence of unresolved “CRL Watch” findings over time, supported by periodic (6 months) qualitative reviews.	2025-03-02	Planned

Appendix

Comment 4

[Enrico Entschew]

We started with the implementation of “Integrate CRL Watch (https://sslmate.com/labs/crl_watch/) monitoring”. D-Trust continues to monitor this ticket.

Comment 5

[Ana Laura Martorano]

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket

Comment 6

[Enrico Entschew]

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket

Comment 7

[Ana Laura Martorano]

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.

Comment 8

[Ana Laura Martorano]

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.

Comment 9

[Ana Laura Martorano]

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.