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! On Sat, Oct 19, 2024 at 05:08 '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/CAOG%3DJUJ5EYWXRwMw2X0B0fkVUYm4wJ7ZObwK%2BcQMuj4rkrxUyQ%40mail.gmail.com.
