Public Discussion of D-Trust TLS CA Inclusion Request

2,961 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 PMOct 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 PMOct 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 PMOct 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 PMOct 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 PMOct 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 PMOct 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.

Entschew, Enrico

unread,
Oct 10, 2024, 2:03:03 PMOct 10
to Amir Omidi, 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Ryan Dickson

Hi Amir,

Thanks for the wishes. I will let her know.

 

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.

 

The process worked because we have been receiving CPRs from different parties. The goal is to avoid as much spam or misdirected support cases as possible. The PDF ensures that the user is guided to send us all relevant information.

 

Thanks,

Enrico

Entschew, Enrico

unread,
Oct 10, 2024, 2:05:38 PMOct 10
to George, 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Amir Omidi, Ryan Dickson

Hi George,

 

Of course we will in any case investigate the issue. But as I wrote to Amir it is more helpful to get structured and complete information from the sender of the CPR.

 

Thanks,

Enrico

 

 

Von: 'George' via CCADB Public <pub...@ccadb.org>

Gesendet: Samstag, 5. Oktober 2024 19:32
An: Entschew, Enrico <Enrico....@BDR.de>

Entschew, Enrico

unread,
Oct 10, 2024, 2:07:01 PMOct 10
to Mike Shaver, George, 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Amir Omidi, Ryan Dickson

Hi Mike,

 

Thanks for your statement.

 

Thanks,

Enrico

Entschew, Enrico

unread,
Oct 10, 2024, 2:08:19 PMOct 10
to Amir Omidi (aaomidi), CCADB Public, Mike Shaver, 'Amir Omidi' via CCADB Public, Sahin, Leyla (D-Trust), Ryan Dickson, George

Hi Amir,

 

Thank you for your statement. I agree with you that this topic should be split off to its own thread.

 

Thanks,

Enrico

Mike Shaver

unread,
Oct 10, 2024, 2:51:47 PMOct 10
to Ryan Dickson, public
Hi,

I was not really familiar with D-Trust, so I did some searching and asking, and I have found something that I would like to raise for consideration.

D-Trust's director, Dr. Kim Nyugen, is an expert member of the European Signature Dialog: https://www.european-signature-dialog.eu/Kim-Nguyen

The ESD has very vocally and, in my opinion, misleadingly campaigned against shorter certificate lengths, framing the 90-day proposal (initially Google's, but I supported by other root programs and CAs since then) as "anti-competitive behaviour": https://www.european-signature-dialog.eu/Google_returns_to_anti-competitive_behavior-ESD_26042023.pdf . This document is still prominent on the ESD web site, in spite of the fact that the Bundeskartellamt (Germany's antitrust agency, as I understand it) terminated its administrative proceedings against Google related to this matter, finding in the matter of reduced certificate duration that

Overall the security level of the certi-fication process was increased, from which the internet users and ultimately also the website operators benefited, as long as the reduction of the validity periods did not generally affect the purchase of certificates with a higher level of authentication [ed: OV/EV certificates], for which there is however no indi-cation.


The ESD site makes claims about this antitrust agency report that simply do not accord with a clear reading of the case summary. It is difficult to view this in a charitable light.

Additionally, in campaigning for EIDAS' possibility for mandatory inclusion of certain roots, which would eliminate browsers' ability to make their own informed trust decisions as they deem best for their users, the ESD cites Mozilla having a small market share as reason for disregarding its (opposed) position:

(Note: Mozilla is the only browser who has signed this “industry statement” – none of the other browsers are included. According to statcounter.com, Mozilla Firefox has only a 3.0% world market share, down from 30% in prior years.)


We have recently seen, and as a community considered unacceptable, CAs failing to respond appropriately to incidents until one of the "larger" browsers' representatives appeared. Votes in the CAB/F and CCADB are not weighted by market share by either CAs or browsers, and nor should they be. *That* would be ripe for abuse of market power, which is why it's imperative that CAs take all other CAs and browser members equally seriously. This statement puts into serious question how a CA that endorsed the ESD's beliefs would respond to incidents raised by Mozilla or its community. We have seen recently that such incidents and attention can be very important for detecting and reacting to CA malfeasance, and we have seen how another member of this organization (Entrust) indeed displayed this exact behaviour, to the detriment of the web PKI.

This document also states without elaboration or supporting evidence that browsers have "abused their monopoly regulatory powers in the past", and describe a 90-day lifetime limitation as being them abusing such power "again". (p4)

I have significant concerns about inclusion of a CA whose director shares the beliefs and endorses the practices of this organization. Their policies and advocacy are actively hostile to the integrity of the web PKI, and the governance of the web PKI's institutions.

Questions for D-Trust:

- does D-Trust, or its director, agree with the positions of the ESD on matters of certificate duration, and the relevance of market share to the validity of different browser positions on web PKI matters?
- if not, why does D-Trust remain a member and allow its director to be listed as endorser of this organization?
- did D-Trust endorse these positions when they were being established by the ESD, or oppose them? Please provide examples of the positions taken, if opposed.
- specifically, does D-Trust feel that reduced certificate duration represents a security hazard, or antitrust concern? What is D-Trust's position on certificate duration as a tool for reducing the impact of misissuance or certificate compromise?
- specifically, when does D-Trust feel that it is appropriate to consider browser market share when determining the validity of said browser's position (on policy or an incident)? How would its response differ between a concern raised by Chrome, versus one raised by Mozilla?

Thank you in advance for your thorough response,

Mike


Entschew, Enrico

unread,
Oct 14, 2024, 9:05:15 PMOct 14
to Mike Shaver, Ryan Dickson, public
Hi Mike, 

Thanks for your questions.
 
This CCADB thread is a routine root inclusion request from D-Trust. 
Specifically, this is a request for including roll-over CAs for already existing and already included root CAs for TLS and S/MIME. 
 
On this basis, your questions relating to ESD position papers and the eIDAS legislative process are not really related to the root inclusion request.  If you want to discuss the topics you raised, we suggest you bring them up in a new thread on CCADB, and ESD and its members can respond as appropriate.

Thanks, 
Enrico
Von: pub...@ccadb.org <pub...@ccadb.org> im Auftrag von Mike Shaver <mike....@gmail.com>
Gesendet: Donnerstag, Oktober 10, 2024 11:55 AM

An: Ryan Dickson <ryand...@google.com>
Cc: public <pub...@ccadb.org>
Betreff: Re: Public Discussion of D-Trust TLS CA Inclusion Request
 

Amir Omidi

unread,
Oct 14, 2024, 9:12:27 PMOct 14
to Entschew, Enrico, Mike Shaver, Ryan Dickson, public
Those questions are positively relevant to continuing the trust in D-Trust. It would be best if you didn't try to dodge those and answer them here. There is no reason to split this thread into two pieces.

Thanks

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/BE1P281MB219511B7BECAD6EBBF6737AA86452%40BE1P281MB2195.DEUP281.PROD.OUTLOOK.COM.

Mike Shaver

unread,
Oct 14, 2024, 9:38:23 PMOct 14
to Entschew, Enrico, Ryan Dickson, public
Thanks for the reply, Enrico.

Is it the case that roll-over “routine” inclusion requests should be subject to less scrutiny than original applications for inclusion? I couldn’t readily find anything in the CA/BF BRs or CCADB bylaws to that effect. What are the sorts of things that are appropriate to bring up for an application for continued inclusion, and what topics are only suitable for consideration during initial inclusion? If it’s impossible for behaviour (or concerns regarding behaviour arising) between initial inclusion and roll-over to cause a root to be removed from CCADB’s list, then I think it calls into question the whole purpose of the commentary period and indeed re-inclusion process. If it *is* possible for re-inclusion to be refused by the CCADB, then it’s just a matter of determining what topics are appropriate for discussion during re-inclusion evaluation. I welcome clarification on this topic from other CCADB members, of course; ideally those clarifications would be rooted, if you will permit a gentle pun, in established policy.

To be clear, I don’t have any questions about the ESD’s position papers—they are written in utterly clear ways—but rather about D-trust’s positions and what D-Trust’s advocacy and endorsement might indicate about their *own* positions with respect to the web PKI. I am asking an ESD member to reply, I suppose, but on the basis of their own positions, and not on behalf of ESD. It may well be that D-Trust no longer holds those positions itself, for example, and therefore is not endorsing ignoring of root programs based on market share, or maintaining against the reality of the anti-trust agency’s report that reduction in certificate validity period represents anti-competitive and anti-security practice. I would certainly welcome that news! It may however be the case that D-Trust holds those positions still, and that they will necessarily inform how it operates as a CA, which I confess would be less welcome news personally, but perhaps CCADB members would celebrate it? The only way to find out is to have the questions answered. These are both “live questions”, with Apple’s proposed reduction schedule and the role that the Mozilla root community played in uncovering and forcing action on Entrust’s unacceptable operations as a CA.

If the ESD were members of CCADB’s root list themselves, though, I would certainly have many concerns about them being re-included through shallow “routine” evaluation, given their recent statements on topics relevant to the web PKI. Happily, from my perspective, they are not such a member!

Mike

Entschew, Enrico

unread,
Oct 18, 2024, 3:36:48 PMOct 18
to Mike Shaver, Ryan Dickson, public

Hi Mike,

Thanks again for your comments.

 

First of all, I would like to briefly inform you that Dr Kim Nguyen is no longer Managing Director of D-Trust as of the beginning of this year. He is currently Senior Vice President Innovations at Bundesdruckerei.

 

D-Trust is a committed, loyal and active member of the web PKI community. We follow the discussions on mdsp, github (CA/B-F specific), CCADB list, Bugzilla etc. We attend the F2F CA/B Forum and WG meetings regularly. Twice D-Trust hosted a F2F CA/B Forum meeting in Berlin. We comply with the requirements of the CA/Browser Forum and the root store policies of the browsers, which is checked annually by an independent Conformity Assessment Body in a multi-day audit.

 

If we make mistakes, we openly communicate them via the Bugzilla platform of Mozilla. We analyze the errors, publish the root cause of the error, propose measures to prevent future errors and implement the measures as quickly as possible. If possible, we contribute changes to the tools that the community uses, e.g. open source linter ZLint, to help prevent other CAs from making the same mistakes as us. D-Trust has always strived to react openly and transparently to incidents, as the Web PKI community has expected us to.

 

If you have questions about these topics I’m happy to answer them here.

 

Thanks,

Enrico

 

 

Von: pub...@ccadb.org <pub...@ccadb.org> Im Auftrag von Mike Shaver


Gesendet: Dienstag, 15. Oktober 2024 03:38
An: Entschew, Enrico <Enrico....@BDR.de>

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:

      • Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
      • Client Authentication 1.3.6.1.5.5.7.3.2
    • Test websites:
    • 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:

§  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:

      • 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 SBR Root CA 2 2022:

      • 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

4.  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

o   Certificate corpus: here (Censys login required)

o   Included in: Google Chrome, Mozilla

 

5.  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

o   Certificate corpus: N/A

o   Included in: Apple, Microsoft, Mozilla

 

6.  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

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:

§  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: 

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):

--

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 18, 2024, 4:45:38 PMOct 18
to Entschew, Enrico, Mike Shaver, Ryan Dickson, public
Accidentally didn't press reply all. 

I don’t think this answer really answers the question posed by Mike. This person was still working there during their advocacy in this space. 

Given this advocacy of the director in the past, would D Trust willingly accept to issue maximum 90 day certificates?

Thanks


Dimitris Zacharopoulos (HARICA)

unread,
Oct 19, 2024, 5:08:04 AMOct 19
to public
I'm sorry for jumping-in. Speaking in a personal capacity, I feel quite uncomfortable with this line of questioning, especially during inclusion request discussions where a CA is asking for approval after having fulfilled all the listed expectations of the Root Store policies. I believe it is not in line with the community's history and values and not in line with the CoC of this list.

On one hand we see questions related to political views (by association?) of a person previously associated with a CA (based on D-TRUST's recent post, it is clear that Kim is no longer managing D-TRUST), and on the other hand we see questions about willingness to support a certain opinion about 90-day certificates. Felt to me a bit like "blackmail".

This should be a non-discriminatory forum where one's political views should not be judged or questioned. If we go down that path, what prevents people from asking if a person would vote in favor of some governmental policy or in favor of a certain politician, candidate president, ....? Does the candidate CA support Article X in candidate legislation Y? This should not be acceptable.

Same with the 90-day certificates question. There are many that disagree with the 90-day certificates for various reasons, and there is opportunity for discussion in the CA/B Forum when a ballot is officially introduced. There is currently a lot of debate on https://github.com/cabforum/servercert/pull/553 and other discussion forums, which demonstrates that this is a very controversial topic. Does that mean that any CA that doesn't agree with the 90-day certificates should not be part of the WebPKI or Public Trust? IMHO it is not reasonable to request a candidate CA to commit to support (and not object to?) 90-day certificates as prerequisite for inclusion, when it is not even a Mozilla policy.

I'm curious if the CCADB steering committee finds this line of questioning acceptable based on the CoC.

I hope I am not the only one who sees these issues as problematic.


Thank you,
Dimitris.

Dimitris Zacharopoulos (HARICA)

unread,
Oct 19, 2024, 5:11:43 AMOct 19
to pub...@ccadb.org



On 19/10/2024 12:07 μ.μ., 'Dimitris Zacharopoulos (HARICA)' via CCADB
Public wrote:
> when it is not even a Mozilla policy.
... or any other Root Program's policy for that matter.

Wayne

unread,
Oct 19, 2024, 5:39:14 AMOct 19
to CCADB Public, Dimitris Zacharopoulos (HARICA)
Given Dimitris' reply I can only presume there has been some misinterpretation on Amir's latest reply here. The question posed was:
Given this advocacy of the director in the past, would D-Trust willingly accept to issue maximum 90 day certificates?

I interpret this as whether D-Trust, in the future, would be open to lifetime reduction certificates. Presumably from Dimitris' response he believe it is some imposed condition for root inclusion at all? It would be prudent to understand what brought this interpretation that blackmail was occurring, as bringing up such a topic is not going to improve discussion in the slightest and is in itself against the CoC. It is unbecoming to put forward these opinions even in a personal capacity.

As I understand it, this discussion centers around an individual who was a prominent stakeholder in D-Trust's decision making at the time. I don't see where the issue is in finding out if D-Trust's stance going forward aligns with these public statements as they may reflect internal attitudes at the CA at the time. It should be noted that D-Trust have not raised concerns, and seem to be willing to answer questions posed but have yet to do so. I would appreciate some clarity on questions answered so far.

I look forward to any answers that D-Trust can provide on whether they, at this moment in time, perceive any changes to certificate lifespan as anti-competitive in nature. This would reflect the CA's attitude in wilful compliance with any future work done by any root program, which I'm sure would make sense to anyone involved here? Such attitudes make sense to check for root inclusion over timespans where such changes are expected.

I'm sure we can all have a civil discussion on this going forward.

- Wayne

Amir Omidi

unread,
Oct 19, 2024, 8:55:01 AMOct 19
to Dimitris Zacharopoulos (HARICA), public
Wayne covered what I was going to say. I would also add that using the word blackmail in this context would also probably be seen as a code of conduct violation.  

I do hope we can call out lines of questioning in the future without resorting to such language. 

Thanks!

Mike Shaver

unread,
Oct 19, 2024, 9:18:30 AMOct 19
to Dimitris Zacharopoulos (HARICA), public
It’s not every day that I’m accused of blackmail on a public, industry list, I have to say. I am not in any position to blackmail anyone, as I do not represent any voting or policy-making participant in the CCADB organization, but I don’t believe that I have given any indication that I would behave unethically in pursuit of my private aims to protect and strengthen the web PKI.

In addition to that, I believe that you are grossly mischaracterizing my position, Dimitris.

First, I am not asking for any commitment to 90 day certificates, or any other certificate duration limit, or anything at all. I am very specifically and explicitly asking if it is (still?) D-Trust’s *current position* that reduction in certificate duration is an anti-trust concern, or represents a degradation in security. I’m asking about those specific, limited things because they were included in the German anti-trust agency’s findings, which were themselves referenced by an *industry association* with which D-Trust is or was recently affiliated. I am not asking about any other possible reasons for objections to reduced validity, and I am not asking for a commitment to support anything in the future. I was very specific about the questions I was asking, but I am always open to feedback on how I can improve the clarity of my wording.

Second, I am asking for what I thought would be a really simple yes/no, about whether D-Trust considers browser market share to be relevant in terms of the importance or validity of positions on web PKI matters. This issue has been recent relevant in how other CAs have differentially responded to concerns, and the root community’s apparent consensus that such differential treatment was inappropriate. 

Third, I asked whether “roll-over” comment periods should be subject to less scrutiny than initial inclusion requests, as was strongly implied by D-Trust’s initial response to my questions.

I do not consider positions on matters of certificate or incident response policy, or CCADB scrutiny, to be out-of-bounds political topics (all matters of governance and policy of human institutions are political, obviously), and I do not see how my messages have contravened the linked code of conduct, but I also welcome clarification from the CCADB leadership on the matter. Also, organizations don’t have political beliefs, humans do. I’m asking about corporate position on web PKI matters, not anyone’s individual political or otherwise private belief.

If there are violations of the CoC here, I think that they are the offensive accusation of blackmail, and D-Trust’s non-responsive replies (which indeed don’t even give a reason as to why the questions about D-Trust’s positions on these matters are not germane to review of their continued inclusion in the CCADB).

I will re-ask my questions very specifically and concisely in another reply, and expect responsive answers in keeping with both the code of conduct and the terms laid out in the initial post about the discussion period.

Mike

Mike Shaver

unread,
Oct 19, 2024, 9:31:43 AMOct 19
to Ryan Dickson, public
As promised, here are my outstanding unanswered questions about D-Trust’s position on PKI-related matters:

- does D-Trust hold the position that reduction of certificate duration by a root program is anti-competitive?

- does D-Trust hold the position that reduction of certificate validity has negative impact on the security of the web PKI?

- does D-Trust hold the position that browser market share is relevant to determining the validity or importance of root program positions on matters of web PKI policy?

- does D-Trust hold the position that “roll-over” requests are or should be subject to less scrutiny than those of initial inclusion?

I would appreciate D-Trust’s responsive replies to these questions, in the absence of cogent explanation for why these questions are not suitable as part of discussion of a root’s application for (continued) inclusion. I would also appreciate the perspective of other members of this community on the relevance of the questions, as I hold the position that they will be relevant to future inclusion discussions as well.

Mike

On Thu, Sep 12, 2024 at 9:15 AM 'Ryan Dickson' via CCADB Public <pub...@ccadb.org> wrote:
--
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.

Rufus Buschart

unread,
Oct 20, 2024, 2:16:59 PMOct 20
to Mike Shaver, Ryan Dickson, public
Hello Mike,

I find this discussion very interesting, and your questions are quite thought-provoking. Could you help me understand where in the CCADB policies it is stated that a hypothetical vote by a CA on a potential upcoming ballot has any relevance to a Root Store inclusion request? Additionally, do you have any evidence suggesting that D-Trust would not comply with such a ballot if it were to pass, even if it voted against it?

With best regards and written with my purely personal hat on

Rufus

What we do in life, echoes in eternity.
===========================================
Rufus J.W. Buschart
Anna-Pirson-Weg 1c
91052 Erlangen
Phone: +49 (0)9131 - 530 15 85
Mobile: +49 (0)152 - 228 94 134


Watson Ladd

unread,
Oct 20, 2024, 7:14:07 PMOct 20
to Rufus Buschart, Mike Shaver, Ryan Dickson, public
CCAD policies are not the sole reference to how Mozilla acts or what conclusions we should draw as participants about the merits or demerits of inclusion.

I think it's very relevant and positive if a CA says "yes we like automation for shorter lines  and have put forward ballots to improve this or that aspect" or "no we have some customers with very legacy technology but have done X,Y,Z to improve it".

If I may be so bold the thrust of the questions was towards something like Entrust situations where a CA refused to revoke claiming one major browser was ok with it while Mozilla was not. Needless to say this is not an attitude calculated to endeer a CA towards Mozilla.

Dimitris Zacharopoulos (HARICA)

unread,
Oct 20, 2024, 11:29:18 PMOct 20
to Wayne, CCADB Public


On 19/10/2024 12:39 μ.μ., Wayne wrote:
Given Dimitris' reply I can only presume there has been some misinterpretation on Amir's latest reply here. The question posed was:
Given this advocacy of the director in the past, would D-Trust willingly accept to issue maximum 90 day certificates?

I read these posts multiple times because I honestly thought I was missing something and misunderstanding, but the feeling I kept having was the same. Amir's last email made it absolutely clear that it was not a misunderstanding and he demanded an answer to a hypothetical.



I interpret this as whether D-Trust, in the future, would be open to lifetime reduction certificates. Presumably from Dimitris' response he believe it is some imposed condition for root inclusion at all? It would be prudent to understand what brought this interpretation that blackmail was occurring, as bringing up such a topic is not going to improve discussion in the slightest and is in itself against the CoC. It is unbecoming to put forward these opinions even in a personal capacity.

The exact words (and symbols) I used were:

Felt to me a bit like "blackmail".

for lack of a better term when someone demands (repeatedly) an answer to a hypothetical, that will be taken into consideration for a CA's inclusion request, as in "if your answer doesn't align with the 90-day certificate supporters' opinion, you might not be accepted to Root Programs".

I understand that despite the quotes and the words "a bit" and the word "like", people still read it literally as if I accused anyone of blackmail. From my perspective I didn't intend it to get out like that. I hope the provided explanation in the previous paragraph provides more clarity of the problem I was trying to highlight.



As I understand it, this discussion centers around an individual who was a prominent stakeholder in D-Trust's decision making at the time. I don't see where the issue is in finding out if D-Trust's stance going forward aligns with these public statements as they may reflect internal attitudes at the CA at the time. It should be noted that D-Trust have not raised concerns, and seem to be willing to answer questions posed but have yet to do so. I would appreciate some clarity on questions answered so far.

I look forward to any answers that D-Trust can provide on whether they, at this moment in time, perceive any changes to certificate lifespan as anti-competitive in nature. This would reflect the CA's attitude in wilful compliance with any future work done by any root program, which I'm sure would make sense to anyone involved here? Such attitudes make sense to check for root inclusion over timespans where such changes are expected.

I'm sure we can all have a civil discussion on this going forward.

+1

Dimitris.

Dimitris Zacharopoulos (HARICA)

unread,
Oct 20, 2024, 11:33:26 PMOct 20
to Amir Omidi, public



On 19/10/2024 3:54 μ.μ., Amir Omidi wrote:
Wayne covered what I was going to say. I would also add that using the word blackmail in this context would also probably be seen as a code of conduct violation.  

I do hope we can call out lines of questioning in the future without resorting to such language.

Thanks Amir, I demonstrated how I used the word "blackmail" in my first email and what message I was trying to convey, in https://groups.google.com/a/ccadb.org/d/msgid/public/2d719f03-c988-4121-9c69-645dcf8852d8%40harica.gr.

I hope this clarifies any misunderstanding for the use of this word.


Thank you,
Dimitris.

Dimitris Zacharopoulos (HARICA)

unread,
Oct 21, 2024, 12:22:41 AMOct 21
to Mike Shaver, public



On 19/10/2024 4:18 μ.μ., Mike Shaver wrote:
It’s not every day that I’m accused of blackmail on a public, industry list, I have to say.

Dear Mike,

You have not been accused of blackmail.


I am not in any position to blackmail anyone, as I do not represent any voting or policy-making participant in the CCADB organization, but I don’t believe that I have given any indication that I would behave unethically in pursuit of my private aims to protect and strengthen the web PKI.

The beauty and ugliness of public discussion forums such as CCADB or MDSP depends on the responsibility and attitude of their participants and how well they observe the CoC. We have never met in person but I consider you an important participant and contributor in the WebPKI ecosystem. With that said, you are not the only person interested in protecting and strengthening the web PKI, and the cause doesn't justify the means.

Even if you are within the letter of the CoC, I would place the discussion about D-Trust's association with ESD close to the borderline. The sense I received as a member of this list, was negative because I felt you were asking about political views/positions.


In addition to that, I believe that you are grossly mischaracterizing my position, Dimitris.

First, I am not asking for any commitment to 90 day certificates, or any other certificate duration limit, or anything at all. I am very specifically and explicitly asking if it is (still?) D-Trust’s *current position* that reduction in certificate duration is an anti-trust concern, or represents a degradation in security. I’m asking about those specific, limited things because they were included in the German anti-trust agency’s findings, which were themselves referenced by an *industry association* with which D-Trust is or was recently affiliated. I am not asking about any other possible reasons for objections to reduced validity, and I am not asking for a commitment to support anything in the future. I was very specific about the questions I was asking, but I am always open to feedback on how I can improve the clarity of my wording.

Thank you for explaining the specific set of questions you were after, this is helpful. I am not here to debate in favor or not in favor of D-Trust but about whether political views should be part of an inclusion request.

I was invited and happened to attend one of the ESD meetings in the past because I wanted to meet its people and get a better understanding of their role and positions in the European Trust industry. In your opinion, would I also be associated with ESD's public positions and hold this against an inclusion request of my employer?



Second, I am asking for what I thought would be a really simple yes/no, about whether D-Trust considers browser market share to be relevant in terms of the importance or validity of positions on web PKI matters. This issue has been recent relevant in how other CAs have differentially responded to concerns, and the root community’s apparent consensus that such differential treatment was inappropriate.

+1



Third, I asked whether “roll-over” comment periods should be subject to less scrutiny than initial inclusion requests, as was strongly implied by D-Trust’s initial response to my questions.

+1


I do not consider positions on matters of certificate or incident response policy, or CCADB scrutiny, to be out-of-bounds political topics (all matters of governance and policy of human institutions are political, obviously), and I do not see how my messages have contravened the linked code of conduct, but I also welcome clarification from the CCADB leadership on the matter. Also, organizations don’t have political beliefs, humans do. I’m asking about corporate position on web PKI matters, not anyone’s individual political or otherwise private belief.


This is now clearer, thank you. Your previous message called out "Dr. Kim Nyugen" and immediately associated him with ESD and its public positions, which is not the same as discussing matters of "certificate or incident response policy, or CCADB scrutiny". Asking those questions separately, as you did in your last email, is totally more preferred than associating a person with a group's positions, for which it is impossible to know how their decisions are made :)

IMHO the existence of groups that oppose Root Program policies is a normal thing, like in any modern democracy. Participating or associated with "the opposition" doesn't mean one doesn't follow the Law or the rules. This is an open community. Participation in an "opposing" group should not be judged negatively. Violating the rules and expectations, certainly should.


If there are violations of the CoC here, I think that they are the offensive accusation of blackmail,

I believe I explained how this word was used and no offense or accusation was made against you, Mike.


Best regards,
Dimitris.

Ryan Dickson

unread,
Oct 21, 2024, 4:35:26 PMOct 21
to Dimitris Zacharopoulos (HARICA), Mike Shaver, public

Hi all,


This is a reminder that the public discussion period on the inclusion application of D-Trust will close on October 24, 2024 (initially communicated on September 12, 2024).


As always, the CCADB Steering Committee will provide a summary of the discussion a few days after its closure.


Thanks,

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.

Entschew, Enrico

unread,
Oct 23, 2024, 12:27:30 PMOct 23
to Mike Shaver, Ryan Dickson, public
Hi Mike,
We still think that the questions are not relevant for the process of root inclusion, but we are happy to assist. Nevertheless, we would like to make our holistic answers as comprehensive and clear as possible in order to maximise transparency. We would like to express again that we fulfil all applicable requirements and will continue to do so in the future.
 
Does D-Trust hold the position that reduction of certificate duration by a root program is anti-competitive?
We consider, a reduction in the certificate duration is not inherently anti-competitive. According to our position, the implications of such a reduction depend significantly on how it is introduced or enforced by market participants who hold market-dominant positions. If these participants leverage their influence in ways that restrict competition or create unfair advantages for themselves, this may certainly lead to anti-competitive practices. In procedures in which the interests of all market participants and the web security are sufficiently taken into account, we see no anti-competitive problems.
 
Does D-Trust hold the position that reduction of certificate validity has negative impact on the security of the web PKI?
We cannot answer this question with a clear yes or no, as the answer depends heavily on the specific circumstances of the introduction and subsequent implementation of the reduction of certificate validity. According to our opinion, factors such as the context in which the measure is implemented, the actors involved, the resources and the general framework conditions may play a decisive role and have a significant influence on the results.
 
Does D-Trust hold the position that browser market share is relevant to determining the validity or importance of root program positions on matters of web PKI policy?
Every relevant root program policy is important to us and is given equal importance. From our perspective, it needs neutral and unambiguous position.
 
Does D-Trust hold the position that “roll-over” requests are or should be subject to less scrutiny than those of initial inclusion?
D-Trust has understood from previous and current discussions that there is a strong desire among some root store operators to shorten the duration of root and SubCA certificates. Currently, root certificates are designed to be used over a longer period of 10 to 15 years. Experience shows that the root inclusion process takes between one and four years for all relevant root store operators. It is currently not possible to estimate the exact duration in advance.
Our understanding is that if root and subCA certificates are to have significantly shorter durations in the future to promote agility in cryptography, an optimised onboarding process is required. 
We welcome and understand that a very thorough review of the requesting TSP and the corresponding root certificates is necessary for the initial integration. However, we are of the opinion that the renewal of an already included root does not necessarily require an examination comparable or equal to that of an initial inclusion. The TSP and the already included roots are already subject to a strict governance regime, which ensures that the security and reliability requirements are continuously met. In addition, an application for root inclusion is only submitted to the CCADB community once it has been proven that all requirements have been met. This procedure should enable a more efficient and faster integration of root certificates in the future and at the same time ensure the necessary security and trustworthiness.
We are convinced that adapting the integration process will not only improve the competitiveness, but also promote innovation in the field of publically trusted certificates.
  
Thanks,
Enrico


Von: pub...@ccadb.org <pub...@ccadb.org> im Auftrag von Mike Shaver <mike....@gmail.com>
Gesendet: Samstag, 19. Oktober 2024 15:30
An: Ryan Dickson <ryand...@google.com>
Cc: public <pub...@ccadb.org>
Betreff: Re: Public Discussion of D-Trust TLS CA Inclusion Request
 
As promised, here are my outstanding unanswered questions about D-Trust’s position on PKI-related matters:

- does D-Trust hold the position that reduction of certificate duration by a root program is anti-competitive?

- does D-Trust hold the position that reduction of certificate validity has negative impact on the security of the web PKI?

- does D-Trust hold the position that browser market share is relevant to determining the validity or importance of root program positions on matters of web PKI policy?

- does D-Trust hold the position that “roll-over” requests are or should be subject to less scrutiny than those of initial inclusion?

I would appreciate D-Trust’s responsive replies to these questions, in the absence of cogent explanation for why these questions are not suitable as part of discussion of a root’s application for (continued) inclusion. I would also appreciate the perspective of other members of this community on the relevance of the questions, as I hold the position that they will be relevant to future inclusion discussions as well.

Mike


--
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.

Chris Clements

unread,
Nov 8, 2024, 8:17:01 AMNov 8
to Entschew, Enrico, Mike Shaver, Ryan Dickson, public

On September 12, 2024, we began a six-week, public discussion on the request from D-Trust for inclusion of its root certificates:

    • D-TRUST EV Root CA 2 2023

    • D-TRUST BR Root CA 2 2023

    The public discussion period ended on October 24, 2024. 

    ==========================

    Summary of Discussion

    Discussion item #1: Several observations related to D-Trust’s Certificate Problem Report (CPR) process were presented:

    • The CPR process, which involves downloading and editing a PDF, was described as inconvenient.

    • It was not clear how D-Trust measures the effectiveness of its CPR process and whether the process discouraged reporting.

    • It was not clear if D-Trust investigates CPRs submitted without the PDF form.

    D-Trust Response to Discussion item #1: D-Trust acknowledged the inconvenience and committed to introducing an improved web form by the end of the year. D-Trust believes the process works because they receive CPRs from various parties. They explained that the PDF form helps ensure users provide all relevant information and minimizes spam. D-Trust confirmed they would investigate regardless of the reporting format, but emphasized that the PDF form helps ensure they receive structured and complete information.

    Discussion item #2: The public raised concerns about D-Trust's potential alignment with the European Signature Dialog's (ESD) positions on certificate validity and browser market share, given the ESD's history of stances perceived as detrimental to the Web PKI ecosystem. Clarification was sought for:

    • D-Trust's stance on reducing certificate validity periods, asking if they viewed such reductions as anti-competitive or detrimental to security, and

    • whether D-Trust considers browser market share when evaluating the validity of concerns raised by different browsers.

    D-Trust Response to Discussion item #2: D-Trust clarified that the former director associated with the ESD was no longer with D-Trust. D-Trust stated that reducing certificate duration is not inherently anti-competitive and that the impact on security depends on the specific circumstances of implementation. D-Trust affirmed that they consider all relevant root program policies equally important.

    ==========================


    We thank community members for their review and consideration during this period. Root Store Programs will make final inclusion decisions independently, on their own timelines, and based on each Root Store Member’s own inclusion criteria. Further discussion may take place in the independently managed Root Store community forums (i.e., MDSP).


    Thank you

    -Chris, on behalf of the CCADB Steering Committee



    Reply all
    Reply to author
    Forward
    0 new messages