1918427 - D-Trust: Non-compliance of issued root and intermediate S/MIME certificates

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[Luna Frankland]

Summary

Some of the d-trust root and intermediate certificates appear to have non-unique based organization identifiers based for Germany. The (2.5.4.97) OrganizationIdentifier of NTRDE-HRB74346 implies this to be a unique value where it refers to at least 6 other entities. More recent root certificates instead use the correct one of "VATDE-202620438" which is unique.
These seemingly non-compliant certificates appear to be superceeded by newer compliant roots with accompanying intermediates so I'm questioning if these older ones are complaint at all and further, if use of the incorrect OI in the DN means that these certificates are full compliance with the S/MIME requirements as set out CA/B Forum at all.

Details

I saw some of the Sectigo Mis-issuance of OV S/MIME certificates in https://bugzilla.mozilla.org/show_bug.cgi?id=1896190 and can see that the solutions provided here https://bugzilla.mozilla.org/show_bug.cgi?id=1917405#c5 set out how they should be represented to provide a way to provide uniqueness.

I must confess from there I’ve gone down a bit of a rabbit hole since this time to find out how widespread the issue was given it’s pretty important the uniqueness is upheld given these are validations of organisations and the root certificate itself has an identifier that relates to at least 6 companies by this identifier.

I do believe the identifier in some D-Trust root certificates not only doesn’t represent the D-Trust entity but should also be “HRB 74346 B” - with the B being an important part of the company identification but not a guarantee of uniqueness (https://www.northdata.com/D-Trust+GmbH,+Berlin/Amtsgericht+Charlottenburg+%28Berlin%29+HRB+74346+B)

While I was not in attendance to the F2F meeting in June of 2023, I see part of the solutions discussed https://lists.cabforum.org/pipermail/smcwg-public/2023-September/000789.html but upon looking into some of the other certificates issued within Germany, I can see a number of the D-Trust Root certificates (including those used in healthcare systems) also have this same issue and do not provide a unique identifier for some

I can see that the following root and intermediate certificates are currently using “NTRDE-HRB74346” (which can refer to many entities as set out in the original post) but it also means these root certificates might have future collisions given the identifier used is not issued at a national level. By searching here: https://crt.sh/?Identity=NTRDE-HRB74346 I’ve identified the following:
https://crt.sh/?caid=48382
https://crt.sh/?caid=48391
https://crt.sh/?caid=173790
https://crt.sh/?caid=173796
https://crt.sh/?caid=173803
https://crt.sh/?caid=173808
https://crt.sh/?caid=189565
https://crt.sh/?caid=263650

I’ve looked through a few sources to see what the entity reports is the correct ID and I’ve seen “VATDE-202620438” is the registration number based on what I believe to be their parent company’s “TrustService” list here: https://tl.bundesnetzagentur.de/TL-DE.XML

This is further noticed that since 2022-07-07, D-Trust appears to be using this identifier as found here: https://crt.sh/?q=VATDE-202620438 meaning they are already following the requirement as set out in 3.2.3.1 for the unique identifier attribute for the certificate of the baseline S/MIME requirements and follows the pattern set out in 7.1.4.2.2 for a German entity (matching the VATDE-123456789 format example) correctly but the current root certificates listed above do not follow this.

Now given this, I can also see a number of trusted certificates that have correct Root Certificates are already in use below and have been issued since 2022-07-06 which have correct child certificate OrganizationIdentifiers:
https://crt.sh/?caid=243363
https://crt.sh/?caid=243364
https://crt.sh/?caid=266682

If I’ve misunderstood any of the above, please do not hesitate to correct me but given these newer root certificates are issued correctly and we are approaching the maximum certificate operational period, would revoking the old root certificates be appropriate?

I say this as the maximum certificate operational period set out in 6.3.2 is stated as 825 days for “Strict and Multipurpose” certificates and the age of the root certificate and intermediates reaching nearly this period - 799 days at time of writing. This is to say that any S/MIME certificates issued on the newer root certificates would be coming to their maximum validity, previous root certificates that led to the issuance of S/MIME certificates would also be either nearing their validity period or no longer are valid.

Given these newer root certs are trusted and have been in place for nearly the maximum allowable validity, I feel it important to make sure that older certificates that do not meet current standards and where a suitable replacement has been in place that the incorrect ones be revoked.

There also seems to be some concerning audit attestation conducted by TUVIT for the S/MIME Audit Attestation as they also had not picked up on this on their latest audit of the Root CAs for S/MIME (https://www.tuev-nord.de/fileadmin/Content/TUEV_NORD_DE/zertifizierung/Zertifikate/en/AA2023121501_D-Trust-CAs_SMIME-BR_Audit_V1.0.pdf) that the DN also includes the non-unique OI “2.5.4.97=NTRDE-HRB74346” in this document on page 5 but given this document states v1.0.1 of the CA/B Forum requirements for S/MIME are being followed, that this might have been missed in their audit of the compliance of these to standards.

Comment 1

[Leyla Sahin]

We thank you for your comment. We are currently investigating and will come back to you by the end of next week.

Comment 2

[Leyla Sahin]

Thank you once again for your detailed investigation and for sharing your results with us.
We follow the ongoing discussion on the German NTR number and are aware NTR numbers in Germany are not unique because they are assigned on a regional level.
We have looked into the above mentioned CAs with regards to the OI and their use case and scope. None of these CAs issue S/MIME certificates or are subject to the S/MIME BRs.
Regardless, the Subject DN is sufficiently unambiguous by using the OI in combination with the organization name. Hence, why this was best practice for many years in Germany.
As you have noted, we are already in the process of adapting our products so that D-Trust’s CAs have a unique OI.
In any case your post supports the discussion about the German NTR numbers.

Comment 3

[Luna Frankland]

Thanks for getting back to me and looking into this but your statement "None of these CAs issue S/MIME certificates [...]" contradicts the audit report from your website (conducted by TUVIT) that states that these certificates are involved in issuance of S/MIME.

The specific document I refer to is the latest SMIME-BR Audit Attestation for D-Trust GmbH linked from the D-Trust website on https://www.d-trust.net/en/support/repository through the "CA/Browser Forum Audit Attestations published by the conformity assessment body TÜVIT of D-Trust" heading.

On page 5 of the document under "Table 1: Root-CA 5 in scope of the audit" it has the DN of "C=DE, O=D-Trust GmbH, CN=D-TRUST Application Certificates CA 3-2 2016,2.5.4.97=NTRDE-HRB74346" which includes the potentially misleading field in the report contents so I do find it hard to understand how it does not fall within this scope given the external auditor has previously attested to it being within scope enough to state as such.

I appreciate that D-Trust is in the process of adapting to these requirements but the attestation states you confirm to these requirements and sets out a specific version they conform to so I am trying to understand if the information stated by the auditor is incorrect on this report and if so, how this will be remediated.

Can you please outline how the root and intermediate certificates in my previous comment are used if not for S/MIME? It would be odd to have this attested for many years now on your S/MIME audits if they were not for this purpose.

If never used for S/MIME but just left dormant on audits, can we please have explicit confirmation of this.

Comment 4

[Moritz Schaal]

Thank you for quick response.

Since we would like to be as transparent as possible, we included all „Issuing CAs of our Browser integrated S/MIME Root CAs)“ in the audit report you mentioned.

Hence, we are strongly convinced that it is crucial to proof that all these „Issuing CAs“ are under a significant audit regime.
Nevertheless, we recognize the possible misinterpretation coming from the wording used in the audit report. The report might imply that all listed „Issuing CAs“ are possibly issuing S/MIME certificates. Therefore, we will work together with TUVIT (TÜV Nord) to find a better solution, to avoid similar misunderstanding in the future.

If you would like to double check, we recommend to have look into the CA Certificate. Neither the S/MIME OID nor the corresponding extended „Key Usage for Email Protection“ is included. This might be of assistance to you, to throw light on our holistic concept.

Also, in best believe, to be as transparent as possible, we publish a matching table of all our „Certified CAs“ to all products in our repository:
https://www.d-trust.net/files/dokumente/pdf/pki_structure_and_applicable_documents.pdf

Comment 5

[Enrico Entschew]

I kindly ask you to check whether this thread can be closed.

Comment 6

[Ben Wilson]

I will close this later this week, unless there are comments or questions that need to be addressed.