Public Discussion of D-Trust TLS CA Inclusion Request

629 views
Skip to first unread message

Ryan Dickson

unread,
Sep 12, 2024, 9:15:51 AMSep 12
to public

All,


This email commences a six-week public discussion of D-Trust’s request to include the following certificates as publicly trusted root certificates in one or more CCADB Root Store Member’s program. This discussion period is scheduled to close on October 24, 2024.


The purpose of this public discussion process is to promote openness and transparency. However, each Root Store makes its inclusion decisions independently, on its own timelines, and based on its own inclusion criteria. Successful completion of this public discussion process does not guarantee any favorable action by any root store.  


Anyone with concerns or questions is urged to raise them on this CCADB Public list by replying directly in this discussion thread. Likewise, a representative of the applicant must promptly respond directly in the discussion thread to all questions that are posted.

CCADB Case Number: 00001362 and 00001363

Organization Background Information (listed in the CCADB):

Certificates Requesting Inclusion:


  1. D-TRUST EV Root CA 2 2023:


  1. D-TRUST BR Root CA 2 2023:


Existing Publicly Trusted Root CAs from D-Trust:

  1. D-TRUST BR Root CA 1 2020:

  • Server Authentication (TLS) 1.3.6.1.5.5.7.3.1

  • Client Authentication 1.3.6.1.5.5.7.3.2

  • Certificate corpus: here (Censys login required)

  • Included in: Google Chrome, Mozilla

  1. D-Trust SBR Root CA 1 2022:

    • Certificate download links: (CA Repository / crt.sh)

    • Use cases served/EKUs: 

      • Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4;

      • Client Authentication 1.3.6.1.5.5.7.3.2;

      • Document Signing AATL 1.2.840.113583.1.1.5;

      • Document Signing MS 1.3.6.1.4.1.311.10.3.12

    • Certificate corpus: N/A

    • Included in: Mozilla

  2. D-Trust SBR Root CA 2 2022:

    • Certificate download links: (CA Repository / crt.sh)

    • Use cases served/EKUs: 

      • Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4;

      • Client Authentication 1.3.6.1.5.5.7.3.2;

      • Document Signing AATL 1.2.840.113583.1.1.5;

      • Document Signing MS 1.3.6.1.4.1.311.10.3.12

    • Certificate corpus: N/A

    • Included in: Mozilla

  3. D-TRUST EV Root CA 1 2020:

  • Server Authentication (TLS) 1.3.6.1.5.5.7.3.1

  • Client Authentication 1.3.6.1.5.5.7.3.2

  • Certificate corpus: here (Censys login required)

  • Included in: Google Chrome, Mozilla


  1. D-TRUST Root CA 3 2013:

  • Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4;

  • Client Authentication 1.3.6.1.5.5.7.3.2;

  • Document Signing AATL 1.2.840.113583.1.1.5;

  • Document Signing MS 1.3.6.1.4.1.311.10.3.12

  • Certificate corpus: N/A

  • Included in: Apple, Microsoft, Mozilla


  1. D-TRUST Root Class 3 CA 2 2009:

  • Server Authentication (TLS) 1.3.6.1.5.5.7.3.1;

  • Client Authentication 1.3.6.1.5.5.7.3.2

  • Certificate corpus: here (Censys login required)

  • Included in: Apple, Google Chrome, Microsoft, Mozilla


  1. D-TRUST Root Class 3 CA 2 EV 2009:

  • Server Authentication (TLS) 1.3.6.1.5.5.7.3.1;

  • Client Authentication 1.3.6.1.5.5.7.3.2

  • Certificate corpus: here (Censys login required)

  • Included in: Apple, Google Chrome, Microsoft, Mozilla


Relevant Policy and Practices Documentation: 

Most Recent Self-Assessment:

Audit Statements:

  • Auditor: TÜViT - TÜV Informationstechnik GmbH

  • Audit Criteria: ETSI

  • Recent Audit Statement(s): 

Incident Summary (Bugzilla incidents from previous 24 months):

  • 1682270: D-TRUST: Private Key Disclosed by Customer as Part of CSR

  • 1691117: D-TRUST: Certificate with RSA key where modulus is not divisible by 8

  • 1756122: D-TRUST: Wrong key usage (Key Agreement)

  • 1793440: D-TRUST: CRL not DER-encoded

  • 1861069: D-Trust: Issuance of 15 DV certificates containing ‘serialNumber’ field within subject

  • 1862082: D-Trust: Delay beyond 5 days in revoking misissued certificate

  • 1879529: D-Trust: "unknown" OCSP response for issued certificates

  • 1884714: D-Trust: LDAP-URL in Subscriber Certificate Authority Information Access field

  • 1891225: D-Trust: Issuance of 15 certificates with incorrect subject attribute order

  • 1893610: D-Trust: Notice to affected Subscriber and person filing CPR not sent within 24 hours

  • 1896190: D-Trust: Issuance of an EV certificate containing a mixup of the Subject's postalCode and localityName

  • 1913310: D-Trust: CRL-Entries without required CRL Reason Code


Thank you,

Ryan, on behalf of the CCADB Steering Committee


Amir Omidi

unread,
Sep 12, 2024, 10:17:14 AMSep 12
to Ryan Dickson, public
The CPR process (
https://www.d-trust.net/en/support/reporting-certificate-problem) seems quite annoying. Downloading and editing a PDF just to send a CPR is a bit too much.

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CADEW5O-BWJreka1U2n5Xk20aEcYK8cp8-yp1jTFOfTT-ef9L1g%40mail.gmail.com.

Sahin, Leyla

unread,
Sep 13, 2024, 6:17:01 AMSep 13
to Amir Omidi, public, Ryan Dickson

Dear Amir,

 

Thank you for your comment. We will review this and come back to you by the end of next week.

 

Greetings,

Leyla

 

Von: 'Amir Omidi' via CCADB Public <pub...@ccadb.org>
Gesendet: Donnerstag, 12. September 2024 16:17
An: Ryan Dickson <ryand...@google.com>
Cc: public <pub...@ccadb.org>
Betreff: Re: Public Discussion of D-Trust TLS CA Inclusion Request

 

The CPR process (

https://www.d-trust.net/en/support/reporting-certificate-problem) seems quite annoying. Downloading and editing a PDF just to send a CPR is a bit too much.

On Thu, Sep 12, 2024 at 09:15 'Ryan Dickson' via CCADB Public <pub...@ccadb.org> wrote:

All,

 

This email commences a six-week public discussion of D-Trust’s request to include the following certificates as publicly trusted root certificates in one or more CCADB Root Store Member’s program. This discussion period is scheduled to close on October 24, 2024.

 

The purpose of this public discussion process is to promote openness and transparency. However, each Root Store makes its inclusion decisions independently, on its own timelines, and based on its own inclusion criteria. Successful completion of this public discussion process does not guarantee any favorable action by any root store.  

 

Anyone with concerns or questions is urged to raise them on this CCADB Public list by replying directly in this discussion thread. Likewise, a representative of the applicant must promptly respond directly in the discussion thread to all questions that are posted.

CCADB Case Number: 00001362 and 00001363

Organization Background Information (listed in the CCADB):

·  CA Owner Name: D-Trust

·  Website: https://www.d-trust.net/en

·  Address: Kommandantenstr. 15, Berlin, 10969, Germany

·  Problem Reporting Mechanisms: https://www.d-trust.net/en/support/reporting-certificate-problem

·  Organization Type: Government Agency

·  Repository URL: https://www.bundesdruckerei.de/en/Repository

Certificates Requesting Inclusion:

 

1.    D-TRUST EV Root CA 2 2023:

o    Certificate download links: CA Repository / crt.sh

o    Use cases served/EKUs: 

§  Server Authentication (TLS) 1.3.6.1.5.5.7.3.1

§  Client Authentication 1.3.6.1.5.5.7.3.2

o    Test websites:

o    Replacement notice: D-Trust has communicated intent to use this applicant root to replace D-TRUST Root Class 3 CA 2 EV 2009 in some root stores, with the replacement taking place approximately on September 1, 2026.

 

2.       D-TRUST BR Root CA 2 2023:

o Certificate download links: CA Repository / crt.sh

o Use cases served/EKUs: 

§ Server Authentication (TLS) 1.3.6.1.5.5.7.3.1

§ Client Authentication 1.3.6.1.5.5.7.3.2

o Test websites:

o Replacement notice: D-Trust has communicated intent to use this applicant root to replace D-TRUST Root Class 3 CA 2 2009 in some root stores, with the replacement taking place approximately on September 1, 2026.

 

Existing Publicly Trusted Root CAs from D-Trust:

1.    D-TRUST BR Root CA 1 2020:

o Certificate download links: (CA Repository /crt.sh)

o Use cases served/EKUs: 

§  Server Authentication (TLS) 1.3.6.1.5.5.7.3.1

§  Client Authentication 1.3.6.1.5.5.7.3.2

o    Certificate corpus: here (Censys login required)

o    Included in: Google Chrome, Mozilla

2.       D-Trust SBR Root CA 1 2022:

o Certificate download links: (CA Repository / crt.sh)

o Use cases served/EKUs: 

§ Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4;

§ Client Authentication 1.3.6.1.5.5.7.3.2;

§ Document Signing AATL 1.2.840.113583.1.1.5;

§ Document Signing MS 1.3.6.1.4.1.311.10.3.12

o Certificate corpus: N/A

o Included in: Mozilla

3.       D-Trust SBR Root CA 2 2022:

o Certificate download links: (CA Repository / crt.sh)

o Use cases served/EKUs: 

§ Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4;

§ Client Authentication 1.3.6.1.5.5.7.3.2;

§ Document Signing AATL 1.2.840.113583.1.1.5;

§ Document Signing MS 1.3.6.1.4.1.311.10.3.12

o Certificate corpus: N/A

o Included in: Mozilla

4.       D-TRUST EV Root CA 1 2020:

o Certificate download links: (CA Repository / crt.sh)

o Use cases served/EKUs: 

§  Server Authentication (TLS) 1.3.6.1.5.5.7.3.1

§  Client Authentication 1.3.6.1.5.5.7.3.2

o    Certificate corpus: here (Censys login required)

o    Included in: Google Chrome, Mozilla

 

5.       D-TRUST Root CA 3 2013:

o Certificate download links: (CA Repository / crt.sh)

o Use cases served/EKUs: 

§  Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4;

§  Client Authentication 1.3.6.1.5.5.7.3.2;

§  Document Signing AATL 1.2.840.113583.1.1.5;

§  Document Signing MS 1.3.6.1.4.1.311.10.3.12

o    Certificate corpus: N/A

o    Included in: Apple, Microsoft, Mozilla

 

6.       D-TRUST Root Class 3 CA 2 2009:

o Certificate download links: (CA Repository / crt.sh)

o Use cases served/EKUs: 

§  Server Authentication (TLS) 1.3.6.1.5.5.7.3.1;

§  Client Authentication 1.3.6.1.5.5.7.3.2

o    Certificate corpus: here (Censys login required)

o    Included in: Apple, Google Chrome, Microsoft, Mozilla

 

7.       D-TRUST Root Class 3 CA 2 EV 2009:

o Certificate download links: (CA Repository / crt.sh)

o Use cases served/EKUs: 

§  Server Authentication (TLS) 1.3.6.1.5.5.7.3.1;

§  Client Authentication 1.3.6.1.5.5.7.3.2

o    Certificate corpus: here (Censys login required)

o    Included in: Apple, Google Chrome, Microsoft, Mozilla

 

Relevant Policy and Practices Documentation: 

·  CP: http://www.d-trust.net/internet/files/D-TRUST_CP.pdf

·  CPS: http://www.d-trust.net/internet/files/D-TRUST_CSM_PKI_CPS.pdf

·  TSPS: https://www.d-trust.net/internet/files/D-TRUST_TSPS.pdf

Most Recent Self-Assessment:

·  https://bugzilla.mozilla.org/attachment.cgi?id=9361619 (completed 10/30/2023)

Audit Statements:

·  Auditor: TÜViT - TÜV Informationstechnik GmbH

·  Audit Criteria: ETSI

·  Recent Audit Statement(s): 

o Key Generation (May 9, 2023)

o Standard Audit (Period: October 8, 2022 to October 7, 2023)

o TLS BR Audit (Period: October 8, 2022 to October 7, 2023)

o TLS EVG Audit (Period: October 8, 2022 to October 7, 2023)

Incident Summary (Bugzilla incidents from previous 24 months):

·  1682270: D-TRUST: Private Key Disclosed by Customer as Part of CSR

·  1691117: D-TRUST: Certificate with RSA key where modulus is not divisible by 8

·  1756122: D-TRUST: Wrong key usage (Key Agreement)

·  1793440: D-TRUST: CRL not DER-encoded

·  1861069: D-Trust: Issuance of 15 DV certificates containing ‘serialNumber’ field within subject

·  1862082: D-Trust: Delay beyond 5 days in revoking misissued certificate

·  1879529: D-Trust: "unknown" OCSP response for issued certificates

·  1884714: D-Trust: LDAP-URL in Subscriber Certificate Authority Information Access field

·  1891225: D-Trust: Issuance of 15 certificates with incorrect subject attribute order

·  1893610: D-Trust: Notice to affected Subscriber and person filing CPR not sent within 24 hours

·  1896190: D-Trust: Issuance of an EV certificate containing a mixup of the Subject's postalCode and localityName

·  1913310: D-Trust: CRL-Entries without required CRL Reason Code

 

Thank you,

Ryan, on behalf of the CCADB Steering Committee

 

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CADEW5O-BWJreka1U2n5Xk20aEcYK8cp8-yp1jTFOfTT-ef9L1g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

Amir Omidi

unread,
Oct 4, 2024, 7:28:08 PM (2 days ago) Oct 4
to Sahin, Leyla, public, Ryan Dickson
So, it’s been definitely more than a week. 

Not remembering your public commitments does not inspire confidence. I think if you’re having these types of mistakes this early on, root programs should not welcome you into their trust stores. 

Entschew, Enrico

unread,
Oct 5, 2024, 12:46:47 PM (2 days ago) Oct 5
to 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Amir Omidi, Ryan Dickson

Hi Amir,

 

Leyla is on sick leave. Therefore I’ll take over for her. 

 

We understand that the current CPR process is not convenient but it fulfills all requirements and worked so far as needed. 

 

We are in the process of creating an improved version of the CPR process which will be introduced as a web form by the end of the year.

 

Thanks,

Enrico




Von: 'Amir Omidi' via CCADB Public <pub...@ccadb.org>
Gesendet: Samstag, 5. Oktober 2024 01:27
An: Sahin, Leyla (D-Trust) <L.S...@d-trust.net>
Cc: public <pub...@ccadb.org>; Ryan Dickson <ryand...@google.com>

Amir Omidi

unread,
Oct 5, 2024, 12:54:25 PM (2 days ago) Oct 5
to Entschew, Enrico, 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Ryan Dickson
Hope she feels better soon. 

Why was this correspondence still missed though?

I’m glad to hear you’ll improve your CPR process.

How do you measure that it worked so far as needed? I guess if the goal is to discourage people from reporting issues, it does a great job with that. 

George

unread,
Oct 5, 2024, 1:32:12 PM (2 days ago) Oct 5
to Entschew, Enrico, 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Amir Omidi, Ryan Dickson
Hi Enrico,

If someone reported a certificate problem to the relevant email address without also including the PDF form, would D-Trust still investigate the issue?

I don't see how the PDF provides much more value than other CAs who simply provide an email address on its own.

Thanks, George.

Mike Shaver

unread,
Oct 5, 2024, 1:44:38 PM (2 days ago) Oct 5
to George, Entschew, Enrico, 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Amir Omidi, Ryan Dickson
Yeah, this raises a point that I think should perhaps be explicit in the BRs: how onerous is a CA allowed to make the CPR process, and do they have a responsibility to respond to CPRs submitted in other “generally acceptable” ways? If they become aware of an issue with certificates through other means, should they treat it equally in terms of incident response? For example, if a CA was validating CAA records in ways that contradicted the language of their CPS, and was informed of this through informal back-channels, should they still open an incident report for the benefit of the community?

Put another way: should the CPR process be optimized for the ease of the CA, or the ease of the reporter (who acts IMO on behalf of relying parties)?

My opinion on this is probably not hard to guess.

Mike

Amir Omidi (aaomidi)

unread,
Oct 5, 2024, 2:19:44 PM (2 days ago) Oct 5
to CCADB Public, Mike Shaver, Entschew, Enrico, 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Amir Omidi, Ryan Dickson, George
Probably should split this off to its own thread, but I'm also of the opinion that these various methods for submitting CPRs are also nearly impossible to audit. For example, Google Trust Services maintains a contact form at https://pki.goog/contact/. Even though this contact form is significantly better than uploading a PDF, I still think it removes a lot of auditability on the behalf of the sender, and transparency in process.

Beyond that, nearly all of these "form" based solutions also transparently force you to agree to "Privacy & Terms" for using that form. When I'm reporting a problem I don't want to be getting into a weird legal agreement with a CA. That's silly, and adds friction in my ability to report a problem.

IMO CAs should be required to keep at least an email endpoint available for CPRs. I understand that spam can get through, but setup your email servers in such a way that it fails emails that don't pass SPF/DKIM checks - that should cut down on spam considerably.
Reply all
Reply to author
Forward
0 new messages