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 On Sat, Oct 19, 2024 at 5:08 AM 'Dimitris Zacharopoulos (HARICA)' via CCADB Public <[email protected]> wrote: > 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 > <https://docs.google.com/document/d/19ALqEvHtTE6OUTz2FaOXrU9gruIdvia5EDh3hXeGpZA/edit?tab=t.0#heading=h.cumc0pgd1s7c> > 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 > <https://docs.google.com/document/d/19ALqEvHtTE6OUTz2FaOXrU9gruIdvia5EDh3hXeGpZA/edit?tab=t.0#heading=h.cumc0pgd1s7c> > . > > I hope I am not the only one who sees these issues as problematic. > > > Thank you, > Dimitris. > > > > > On 18/10/2024 11:45 μ.μ., 'Amir Omidi' via CCADB Public wrote: > > 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 > > > On Fri, Oct 18, 2024 at 15:36 'Entschew, Enrico' via CCADB Public < > [email protected]> wrote: > >> 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:* [email protected] <[email protected]> *Im Auftrag von *Mike Shaver >> *Gesendet:* Dienstag, 15. Oktober 2024 03:38 >> *An:* Entschew, Enrico <[email protected]> <[email protected]> >> >> *Cc:* Ryan Dickson <[email protected]>; public <[email protected]> >> *Betreff:* Re: Public Discussion of D-Trust TLS CA Inclusion Request >> >> >> >> 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 >> >> >> >> On Mon, Oct 14, 2024 at 9:05 PM Entschew, Enrico <[email protected]> >> wrote: >> >> 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:* [email protected] <[email protected]> im Auftrag von Mike Shaver < >> [email protected]> >> *Gesendet:* Donnerstag, Oktober 10, 2024 11:55 AM >> >> >> *An:* Ryan Dickson <[email protected]> >> *Cc:* public <[email protected]> >> *Betreff:* Re: Public Discussion of D-Trust TLS CA Inclusion Request >> >> >> >> 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. >> >> >> >> ( >> https://www.bundeskartellamt.de/SharedDocs/Entscheidung/EN/Fallberichte/Missbrauchsaufsicht/2022/B7-250-19.html >> on page 7) >> >> >> >> 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.) >> >> >> >> >> https://www.european-signature-dialog.eu/ESD_experts_support_trilogue_Art.45_results-6nov2023.pdf >> (page 1) >> >> >> >> 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 >> >> >> >> >> >> On Thu, Sep 12, 2024 at 9:15 AM 'Ryan Dickson' via CCADB Public < >> [email protected]> 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 >> <https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=00001362> >> and 00001363 >> <https://ccadb.my.salesforce-sites.com/mozilla/PrintViewForCase?CaseNumber=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 >> >> <https://www.google.com/maps/search/Kommandantenstr.+15,+Berlin,+10969,+Germany?entry=gmail&source=g> >> - *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 >> <https://www.d-trust.net/cgi-bin/D-TRUST_EV_Root_CA_2_2023.crt> / crt.sh >> <https://crt.sh/?q=8E8221B2E7D4007836A1672F0DCC299C33BC07D316F132FA1A206D587150F1CE> >> >> 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:* >> >> § Valid: https://certdemo-ev-valid-rsa.tls.d-trust.net/ >> >> § Revoked: https://certdemo-ev-revoked-rsa.tls.d-trust.net/ >> >> § Expired: https://certdemo-ev-expired-rsa.tls.d-trust.net/ >> >> o *Replacement notice:* D-Trust has communicated intent to use this >> applicant root to replace D-TRUST Root Class 3 CA 2 EV 2009 >> <https://crt.sh/?q=EEC5496B988CE98625B934092EEC2908BED0B0F316C2D4730C84EAF1F3D34881> >> in some root stores, with the replacement taking place approximately on >> September 1, 2026. >> >> >> >> *2. **D-TRUST BR Root CA 2 2023:* >> >> - *Certificate download links:* CA Repository >> <https://www.d-trust.net/cgi-bin/D-TRUST_BR_Root_CA_2_2023.crt> / >> crt.sh >> >> <https://crt.sh/?q=0552E6F83FDF65E8FA9670E666DF28A4E21340B510CBE52566F97C4FB94B2BD1> >> - *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 >> >> >> - *Test websites:* >> >> >> - Valid: https://certdemo-dv-valid-rsa.tls.d-trust.net/ >> - Revoked: https://certdemo-dv-revoked-rsa.tls.d-trust.net/ >> - Expired: https://certdemo-dv-expired-rsa.tls.d-trust.net/ >> >> >> - *Replacement notice:* D-Trust has communicated intent to use this >> applicant root to replace D-TRUST Root Class 3 CA 2 2009 >> >> <https://crt.sh/?q=49e7a442acf0ea6287050054b52564b650e4f49e42e348d6aa38e039e957b1c1> >> 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:* >> >> >> - *Certificate download links:* (CA Repository >> <https://www.d-trust.net/cgi-bin/D-TRUST_BR_Root_CA_1_2020.crt> / >> crt.sh >> >> <https://crt.sh/?q=E59AAA816009C22BFF5B25BAD37DF306F049797C1F81D85AB089E657BD8F0044> >> ) >> - *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 >> <https://search.censys.io/search?resource=certificates&q=E59AAA816009C22BFF5B25BAD37DF306F049797C1F81D85AB089E657BD8F0044%09+and+labels%3Dever-trusted> >> (Censys login required) >> >> o *Included in:* Google Chrome, Mozilla >> >> *2. **D-Trust SBR Root CA 1 2022:* >> >> - *Certificate download links:* (CA Repository >> <http://www.d-trust.net/cgi-bin/D-Trust_SBR_Root_CA_1_2022.crt> / >> crt.sh >> >> <https://crt.sh/?q=D92C171F5CF890BA428019292927FE22F3207FD2B54449CB6F675AF4922146E2> >> ) >> - *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 SBR Root CA 2 2022:* >> >> - *Certificate download links:* (CA Repository >> <http://www.d-trust.net/cgi-bin/D-Trust_SBR_Root_CA_2_2022.crt> / >> crt.sh >> >> <https://crt.sh/?q=DBA84DD7EF622D485463A90137EA4D574DF8550928F6AFA03B4D8B1141E636CC> >> ) >> - *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 >> >> *4. **D-TRUST EV Root CA 1 2020:* >> >> - *Certificate download links:* (CA Repository >> <https://www.d-trust.net/cgi-bin/D-TRUST_EV_Root_CA_1_2020.crt> / >> crt.sh >> >> <https://crt.sh/?q=08170D1AA36453901A2F959245E347DB0C8D37ABAABC56B81AA100DC958970DB> >> ) >> - *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 >> <https://search.censys.io/search?resource=certificates&q=08170D1AA36453901A2F959245E347DB0C8D37ABAABC56B81AA100DC958970DB+and+labels%3Dever-trusted> >> (Censys login required) >> >> o *Included in:* Google Chrome, Mozilla >> >> >> >> *5. **D-TRUST Root CA 3 2013:* >> >> - *Certificate download links:* (CA Repository >> <https://www.d-trust.net/cgi-bin/D-TRUST_Root_CA_3_2013.crt> / crt.sh >> >> <https://crt.sh/?q=A1A86D04121EB87F027C66F53303C28E5739F943FC84B38AD6AF009035DD9457> >> ) >> - *Use cases served/EKUs: * >> >> § Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4; >> >> § >> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqs2LNSRKsg1vf1M8CqDw913BmcbZ%2BrkQoJzZj3Mg1bXng%40mail.gmail.com.
