2084783 - D-Trust: Certificate name encodings inconsistent with TSPS section 7.1.4

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[trusten]

The Certificate Problem Report form disclosed in D-Trust's CP and in CCADB is disabled, as described in Bug 2084776.

D-Trust's TSPS section 7.1.4 states:

Die Kodierung erfolgt als UTF8-String bzw. PrintableString für das Attribut C (Country).

This sentence appears in all 23 published versions from v1.0, effective 2020-11-12, through v3.2, effective 2026-10-16. The current TSPS identifies the German text as authoritative. The natural reading is UTF8String for the general name attributes, with PrintableString specified for countryName. In particular, it does not expressly offer a choice between UTF8String and PrintableString for commonName, organizationName or stateOrProvinceName.

The following certificate has a notBefore of 2026-10-19 19:06:22 UTC and embedded SCT timestamps on 2026-10-19:
https://crt.sh/?id=29975136629

Subject CN: certdemo-ev-valid.tls.d-trust.net
SHA-256: d0cab6746efd704116bfc355aa82029555ae9919f2509b3b6b6df212b2dde9fb

Its subject commonName, organizationName and stateOrProvinceName are all encoded as ASN.1 PrintableString. Its issuer commonName and organizationName are also PrintableString.

The issuing CA certificate, D-TRUST EV CA 1-20-1 2020, has PrintableString commonName and organizationName values in both its subject and issuer:
https://crt.sh/?id=3722367180
Official copy: https://www.d-trust.net/cgi-bin/D-TRUST_EV_CA_1-20-1_2020.crt
SHA-256: 41c897473b0369fa74b1f4f9d7f89129485c1a305c0719a867dc8714e0870200
notBefore: 2020-11-24 10:21:09 UTC
First CT entry in crt.sh: 2020-12-01 09:58:24.893 UTC

The contemporaneous Root PKI CPS v3.0 section 7.1.4 refers name-format rules to the TSPS. TSPS v1.0 already contained the quoted encoding sentence. The current CSM CPS v5.5 section 7.1.4 likewise refers to the TSPS.

The leaf subject CN/O/ST values provide the clearest discrepancy: the BRs permit UTF8String for all three, so there is no BR requirement forcing PrintableString for those values. Issuer encodings also need to be assessed against the BR requirement to match the issuing CA's subject byte for byte; changing an issuer encoding in isolation would not be a compliant remedy.

Bug 2056087 comment 2 explains why compliance with the generic BR profile does not excuse issuance contrary to a CA's applicable CP/CPS:
https://bugzilla.mozilla.org/show_bug.cgi?id=2056087#c2

This discrepancy also raises questions about the requirements review reported in Bug 2029013. In comment 19, dated 2026-09-30, D-Trust reported that its systematic requirements-and-controls review, with independent third-party involvement, was complete and had found no inconsistencies between applicable requirements and implemented controls. It identified approximately 130 requirement-to-control mappings whose public documentation needed greater specificity.

In comment 21, dated 2026-10-19, D-Trust marked Action Item #3 complete, reiterated that conclusion, and identified TSPS v3.2 as part of the resulting documentation updates. It distinguished the earlier mapping count from 65 substantive document-change blocks. It also stated that the review included all technically capable issuing CAs, with independent third-party sample verification.

The encoding statement remains in TSPS v3.2, and the certificate above has a validity start and embedded SCT timestamps after that version became effective. How was the reported review conclusion reconciled with this discrepancy? In particular, did the review compare the commitments in the applicable CP/CPS with the ASN.1 encodings of actual subscriber and CA certificates?

https://bugzilla.mozilla.org/show_bug.cgi?id=2029013#c19
https://bugzilla.mozilla.org/show_bug.cgi?id=2029013#c21

Please explain how the observed subject encodings conform to the published TSPS commitment, identifying any applicable provision that permits them. If these certificates were not issued in accordance with the applicable CP/CPS, please address the subscriber-certificate revocation requirement in TLS BR section 4.9.1.1(12) and the subordinate-CA requirement in section 4.9.1.2(5).

An incident report should address:

• How the review reported in Bug 2029013 assessed CP/CPS commitments against certificate profiles and actual encoded certificates, which CAs and certificates were sampled, and why it did not identify this discrepancy.
• What evidence supported declaring the review complete, given that this discrepancy remained, and what assurance that evidence provides that other CP/CPS commitments have not similarly escaped verification against actual practice.
• The number and scope of affected subscriber and CA certificates, and the earliest and latest affected issuance.
• How the unchanged encoding statement passed review across 23 published versions without the discrepancy being identified.
• When D-Trust became aware of the discrepancy, the applicable revocation deadlines, and how it will meet those deadlines independently of any further review.

Policy sources:
https://www.d-trust.net/internet/files/D-TRUST_TSPS.pdf
https://www.d-trust.net/pdf-download/D-TRUST_TSPS_v1.0.pdf
https://www.d-trust.net/pdf-download/D-TRUST_Root_PKI_CPS_v3.0.pdf
https://www.d-trust.net/internet/files/D-TRUST_CSM_PKI_CPS.pdf
https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.3.1.pdf

Comment 1

[Ana Laura Martorano]

(In reply to trusten from comment #0)

Thank you for your report. Our review is now underway and we will respond addressing the points raised.

Comment 2

[Ana Laura Martorano]

We thank you again for this request. The analysis and the preparation of a response is in progress. We will provide you with an update at the beginning of next week

Comment 3

[trusten]

Comment 2 schedules an update for the beginning of next week, but leaves the immediate compliance and containment questions unanswered.

The CCADB Incident Reporting Guidelines require an initial report or response within 72 hours of becoming aware of an incident. That response must disclose the known impact and whether the incident is contained or ongoing. An acknowledgment that analysis is underway does not provide either. Deferring the substantive response until next week does not explain how D-Trust will meet those requirements.

Separately, TLS BR §4.9.5 requires investigation and a preliminary report of findings to the reporter and subscriber within 24 hours of receiving a Certificate Problem Report. Neither response contains preliminary findings. These obligations do not depend on completing a root-cause analysis.

Has D-Trust stopped issuance from the certificate profiles implicated by this report?

Mozilla’s incident-response guidance states:

In misissuance cases, a CA should almost always immediately cease issuance from the affected part of its PKI.

The report identifies specific issued certificates and the corresponding TSPS commitment. D-Trust has not explained whether it disputes the reported encoding, the interpretation of that commitment, or its applicability to those certificates. It has also not explained whether additional certificates with the same characteristics are being issued during the investigation.

Please provide:

• D-Trust’s preliminary assessment of the reported discrepancy, including the basis for any conclusion that the certificates comply with the applicable TSPS;
• whether affected issuance has stopped, when that decision was made, and which profiles it covers;
• if issuance continues, the justification for doing so while the compliance question remains unresolved; and
• whether additional certificates exhibiting the reported discrepancy have been issued since D-Trust received the report.

The investigation may take longer to establish the complete historical scope and root cause. That does not explain withholding the preliminary findings or the containment decision. The community needs to understand whether the potentially affected certificate population is still growing while D-Trust prepares its response.

Comment 4

[Frank Meißen]

Hi trusten,

thank you for the thorough analysis in comment 0. We appreciate the effort that
went into reviewing our TSPS history and the certificates involved.

Preliminary Incident Report

Summary

• Incident description:

  A third party reported that the ASN.1 string types used for distinguished name attributes in D-TRUST certificates may be inconsistent with Section 7.1.4 of the D-TRUST TSPS.

  Our preliminary assessment confirms that the reported ASN.1 string types are permitted under RFC 5280 and the applicable TLS Baseline Requirements. We recognize that this does not by itself resolve the question of compliance with our TSPS. We are therefore still assessing whether the wording of Section 7.1.4 of our TSPS establishes additional restrictions and whether our issuance practices fully comply with these provisions, for both subscriber and CA certificates. At this stage, we have not reached a final conclusion regarding compliance with our TSPS.

  Issuance has not been suspended while the question of compliance with our TSPS remains under investigation. We are continuing to assess whether additional containment measures or certificate revocations are required. Any revocation found to be required under TLS BR Section 4.9.1.1(12) or Section 4.9.1.2(5) will be completed within the applicable timelines.

  Our investigation also covers the scope of potentially affected certificates and the relationship to the requirements review documented in Bug 2029013.

  We will provide the detailed findings, the basis for our compliance assessment, and responses to the remaining questions in accordance with the applicable Baseline Requirements and the CCADB Incident Reporting Guidelines.

• Relevant policies: D-TRUST TSPS Section 7.1.4 (Name Formats); TLS BR Sections 4.9.1.1(12), 4.9.1.2(5) and 7.1.4; RFC 5280 Section 4.1.2.4

• Source of incident disclosure: Third Party Reported

Comment 5

[Frank Meißen]

(In reply to trusten from comment #3)

Thank you for the careful analysis; we appreciate that you raised this concern. Further to our preliminary incident report in comment 4, below we set out our assessment and answer the key open questions from comments 0 and 3.

Result: We conclude that the reported TLS subscriber and CA certificates were issued in accordance with Section 7.1.4 of the D-TRUST TSPS and with the TLS BRs. Revocation under TLS BR Section 4.9.1.1(12) or Section 4.9.1.2(5) is therefore not required, and issuance continues unchanged.

TSPS Section 7.1.4

Please note that the TSPS is the common practice statement for all D-TRUST trust services and therefore applies to different types of certificates. Publicly trusted TLS certificates are one type amongst several.

We quote the English version for the international audience and give the German wording of the general sentence below; our explanations apply to both language versions. Section 7.1.4 of TSPS v3.2 reads:

7.1.4 Name formats
In the subject (here: name of the subject/end-entity) and issuer (name of the issuer) fields, names are assigned according to [X.500] or [X.509] as DistinguishedName. The attributes described in section 3.1.4 can be assigned. Coding is carried out as UTF8 string or PrintableString for the C (Country) attribute.
The SubjectAltName (alternative subject name) and IssuerAltName (alternative issuer name) fields can contain names according to [RFC 5280], [RFC 6818] (coded as IA5String).
QEVCP-w, QNCP-w, EVCP,OVCP, DVCP
The requirements of section 7.1.4 of [TLS BR] are met.
QEVCP-w, EVCP
The specifications from section 7.1.4.2 [EVGL] apply and supersede the specifications from section 7.1.4 [TLS BR].

German wording of the general sentence, identical in all versions of the TSPS: "Die Kodierung erfolgt als UTF8-String bzw. PrintableString für das Attribut C (Country)."

Since TSPS v1.2 (effective 2021-07-09), Section 7.1.4 has additionally contained the paragraphs for the publicly trusted TLS policy levels, which commit D-TRUST to TLS BR Section 7.1.4 and, for EV, to the EV Guidelines.

Why the certificates conform

We read the general sentence in line with RFC 5280: Section 4.1.2.4 requires CAs to use either PrintableString or UTF8String for DirectoryString attributes, and Appendix A.1 defines countryName as PrintableString. The sentence names these two encodings and specifies PrintableString for countryName; it does not prohibit PrintableString for other attributes. We do not read it as an exclusive rule of "UTF8String for every attribute except countryName", for the following reasons:

(a) Required PrintableString attributes. The naming attribute serialNumber (Object Identifier 2.5.4.5, not to be confused with the certificate serial number) is a required attribute in the Subject Distinguished Name (SDN) of EV certificates. RFC 5280, Appendix A.1 defines it as PrintableString (X520SerialNumber ::= PrintableString), and TLS BR Section 7.1.4.2 requires PrintableString for serialNumber and for jurisdictionCountryName (1.3.6.1.4.1.311.60.2.1.3), which is likewise required in EV certificates. An exclusive reading of the general sentence would therefore have made compliant EV issuance impossible under any version of the TSPS. Since TLS BR v2.0.0 (effective 2023-09-15), it would moreover contradict TLS BR Section 7.1.4.2, which Section 7.1.4 of the TSPS requires to be met for these profiles.

(b) Consistency of the TSPS. Since TSPS v2.6 (effective 2025-10-08), Section 1 (Introduction) states explicitly: "It is ensured that this document does not contain provisions that contradict the regulations relevant to the products." (German: "Es wird sichergestellt, dass dieses Dokument nicht der für die Produkte relevanten Regulatorik widersprechende Vorgaben enthält."). This makes explicit what (a) shows for all versions.

Issuer names: The issuer names of the reported certificates are byte-for-byte identical with the subject names of their issuing CAs, as required by TLS BR Section 7.1.4.1 (for EV certificates also via EVGL Section 7.1.4.1). Like the subject names, they use PrintableString, consistent with the reading above.

The reported encodings therefore conform both to the general sentence and to the TLS BR and EVGL requirements that Section 7.1.4 incorporates for these profiles.

Open questions from comments 0 and 3

• Referenced certificate: The subscriber certificate referenced in comment 0 is the certificate of our test website certdemo-ev-valid.tls.d-trust.net under TLS BR Section 2.2.
• Issuance: Issuance has not been suspended, because the certificates conform to the TSPS and the TLS BRs. Certificates issued since receipt of the report use the same encodings.
• Bug 2029013: We will answer the questions regarding the method of the requirements review in Bug 2029013 itself, in accordance with the CCADB Incident Reporting Guidelines.
• Remaining questions: We will address the remaining open questions from comments 0 and 3 in our next updates, which we will post in accordance with the CCADB Incident Reporting Guidelines.

Documentation

We acknowledge that a separation between publicly trusted certificates and other certificate types makes policy documents easier to read, and a combined CP/CPS for publicly trusted TLS certificates is in preparation.

We are happy to answer any further questions.

Comment 6

[trusten]

(In reply to Frank Meißen from comment #5)

Reading of the general sentence. Comment 5 shows that RFC 5280 and the BRs permit these encodings. Comment 0 said the same. The question is whether the encodings conform to what D-Trust committed to. Where a CA commits to more than the standards require, the commitment binds: "CA Owners MUST strictly adhere to their policy document(s)" (CCADB Policy §4). "Die Kodierung erfolgt als UTF8-String bzw. PrintableString für das Attribut C (Country)" names UTF8String as the encoding and ties PrintableString to C. If PrintableString were available for any attribute RFC 5280 allows, "für das Attribut C" would serve no purpose.

(a) Agreed, serialNumber and jurisdictionCountryName must be PrintableString. That shows §7.1.4 contradicts itself for those two attributes, not that the sentence means something else. The BR paragraph is not written as an exception to the general sentence, and neither says which prevails. Comment 5 confirms that v1.0 and v1.1 had only the general sentence. A policy document that contradicts mandatory requirements is a conflict for D-Trust to report and fix (CCADB Policy §4). It does not open PrintableString for CN, O or ST, where the BRs allow either encoding and D-Trust committed to UTF8String.

(b) A statement that the document contains no contradictions does not remove one. Given (a), the v2.6 statement is inaccurate.

Issuer names. They match because the CA certificates themselves use PrintableString. D-TRUST EV CA 1-20-1 2020 (notBefore 2020-11-24) was issued under TSPS v1.0, which had only the general sentence, covering subject and issuer.

Issuance. Comment 4 left the question open, and issuance continued while it was open.

Practice. If UTF8String is the general encoding the TSPS describes, D-Trust's certificates should show it. Since TSPS v1.0 took effect, D-Trust has disclosed 43 CA certificates in CCADB. 42 encode CN and O as PrintableString. The one exception reuses a CA name from 2013.

Please answer:

1. Which D-Trust CAs, and which certificates they issue, follow the encoding that §7.1.4 describes?
2. How will D-Trust report the conflict between TSPS §7.1.4 and the PrintableString requirements for serialNumber and jurisdictionCountryName?