Dear Tim, Not sure your penguin-related example would make the picture sharper or ideas clearer.
I asked about fast tracks because it's taking long time to get things processed related to the fact that all this is running by a community and I think it can be great to brainstorm ways to handle maybe work overloads even through paid assessments for example. I don't think it's worth to answer either your comments about special treatment, as no one has asked for it apart of speeding the process which is not special treatment but respect for users and community, or about how special we feel we are, etc. I am not a member of the government, I consider myself member of an open global IT community, including but not limited to mozilla, that shares same values of respect and mutual help. I find your answer a bit aggressive but, anyway, maybe I was wrong about something that made you answer the way you did... That was not my intention. I hope that you guys can give us a list of major corrections or verifications to do within a certain limited time to give us the opportunity to get our CA approved without restarting the whole process. I hope this is not considered as special treatment as maybe I don't know what kind of support you provide in such cases. At the end, I would reiterate that I shared personal opinions and I am not member of the government as this is a public open discussion and I don't want that my opinion impacts negaively the decision taking. Best, Taher. On Tuesday, 13 March 2018 03:06:40 UTC+1, Tim Hollebeek wrote: > Nobody is blocking any country from advancing. There are no Mozilla rules > that prevent any country from having the best CA on the planet. If a bunch > of penguins at McMurdo station run an awesome CA, I'll ask some hard > questions about how they meet the OCSP requirements with their limited > bandwidth, but if they have good answers, I'm fine with internet security > now being penguins all the way down. > > If you want your certificates to be accepted everywhere on the planet, you > need to follow the same rules as everyone else on the planet. No fast > tracks > or special rules for anyone, no matter how special they feel they are. > > The same rules for everyone is the only sane route forward. Governments > often believe they deserve special treatment, and they may have the ability > to force that to be true within their own country, but that doesn't make it > a good idea for Mozilla. > > -Tim > > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of > > taher.mestiri--- via dev-security-policy > > Sent: Monday, March 12, 2018 7:31 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: TunRootCA2 root inclusion request > > > > Dear All, > > > > Thank you for your detailed description of your concerns with the Tunisian > CA. > > > > I have been one of those guys that developped IT communities for more than > 7 > > years in Tunisia, starting by Tunandroid (Tunisian Android Community), > Google > > Developers Groups, organized the best Software Freedom Day in 2012, > > supported local Mozilla Community 2013-2014, GDG Country Champion in > > Tunisia 2012-2014 and represented the IT community in law projects to help > > developing the local ecosystem since 2013 and still. > > > > The reason why I am telling you this is to assure you that I perfectly > understand > > what a community is about: helping each others, making things better and > > sharing knowledge. Things have always been inclusive. > > > > The Tunisian national digital certification agency has been under pressure > for > > more then 3 years to have its CA certificates recognized by Mozilla and > they did > > all which is possible to do to have the best security standards when they > got > > audited and criticized and they have alwyas been very reactive. > > > > I would highlight that we are speaking here about a national CA which is > > completely different from any other type of agencies. We are speaking > about > > blocking a whole country from advancing. > > > > It's already unacceptable to have such long process for country CA, if we > have > > to fail and restart we have to fail quickly because time is very valuable. > We > > can't afford restarting the process if the Tunisian CA gets rejected but > instead I > > think anything can be corrected and updated this is how I.T. works. > > > > Generally speaking I would insist on the fact that for country CAs, some > kind of > > fast tracks should be established because the impact of time losing at > country > > level is highly expensive. > > > > I have no doubt about your support and hope you can help my country move > > forward and I am sure that the team in our national digital certification > agency > > will do its best to assure you about how seriously we are working to make > > users globally trusting our CA protected. > > > > Best regards, > > > > Taher Mestiri > > > > > > > > On Monday, 12 March 2018 15:59:55 UTC+1, Ryan Sleevi wrote: > > > These responses demonstrate why the request is troubling. They attempt > > > to paint it as "other people do it" > > > > > > The risk of removing an included CA must balance the ecosystem > > > disruption to those non-erroneous certs, while the risk to ecosystem > > > inclusion needs to balance both the aggregate harm to the ecosystem > > > (through lowered > > > standards) and the risk to the ecosystem of rejecting the request (of > > > which, until inclusion is accepted, is low) > > > > > > The pattern of issues - particularly for a new CA - is equally > problematic. > > > A CA, especially in light of the public discussions, should not be > > > having these issues in 2018, and yet, here we are. > > > > > > We are in agreement on the objective facts - namely, that there is a > > > prolonged pattern of issues - and the criteria - namely, that CAs > > > should adhere to the policy in requesting inclusion. A strict > > > adherence to those objectives would be to fully deny the request. It > > > sounds like where we disagree, then, is not in the objective facts and > > > criteria, but rather, where the evaluation of that leaves relative to > risk. > > > > > > The position I am advocating is that, even if these individual matters > > > might be seen as less risky, especially, as has been mentioned, this > > > CA is "only" intended for .tn for the most case, the existence of such > > > a pattern (and the means of acknowledging-but-not-resolving-completely > > > these issues) is indicative that there will continue to be serious > > > issues, and that the risk is not simply limited to .tn, but threatens > > > global Internet stability and security. Given that the number of > > > certificates being issued are, from your own descriptions, aimed to be > > > measured in the hundreds, further highlights that the risk is rather > > substantial. > > > > > > On Mon, Mar 12, 2018 at 2:14 AM, Anis via dev-security-policy < > > > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > Hi Ryan > > > > I am so sorry but is the same error. > > > > CN NAME NOT INCLUDE IN THE SAN > > > > Local IP ADRESS > > > > Policy not upto date .... > > > > Is clear for me and i understand. > > > > All this error became from approuved authority. Is the risk no. > > > > Then The ecosystem is not protected!!!!! > > > > ANIS > > > > _______________________________________________ > > > > dev-security-policy mailing list > > > > dev-security-policy@lists.mozilla.org > > > > > > https://clicktime.symantec.com/a/1/SIE5l2_N73ITS6JLILauNCMnmHnZxaKgs > > > > > > B01Two7VeY=?d=_v7KIjMsihDpLSiLJBAouCL3n_o9AK9VmyEb8nG9Z6gdhNh7Je > > RjHh > > > > 4qQ- > > OkZhRzqc_LUyI5vA9nghhhxTQxpmNGZCpSdBDmXod6aFvNzmG8ktYaF2q- > > Qmwfb_ > > > > > > hdD5G7WxIEEJYkOVWJtCVGnyYl4DYpItqhBt0_Spz4X3UrDsaE6fDsXoeWpIrAn2 > > qtCx > > > > IGVYGc88xGz0AavDxY-Kk0dOryc8KT6eeUumJHpgi-- > > TH7yOuC30DzNBDRR0DQ4OkLgL > > > > blPHsYqV9AyzTt51I8fipD7X-_VDXq-pBCO9ThUQKAy3HofPSZWmSYwzlT- > > okF7gL-83 > > > > V1pdtjN1Zv-eJjBDGaUiulNrIXzrrD_zsO2mpWSnZw_cXUFHx- > > dEMC9hteXMj9MuVDQR > > > > 8xNV- > > b9wLkiki2ABTG5srScX9qnFYdkQyEJ2uAIgg8l5p6LenynXdVYGqZPbQORbkf&u > > > > =https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy > > > > > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://clicktime.symantec.com/a/1/SIE5l2_N73ITS6JLILauNCMnmHnZxaKgsB > > 01Two7VeY=?d=_v7KIjMsihDpLSiLJBAouCL3n_o9AK9VmyEb8nG9Z6gdhNh7JeR > > jHh4qQ- > > OkZhRzqc_LUyI5vA9nghhhxTQxpmNGZCpSdBDmXod6aFvNzmG8ktYaF2q- > > Qmwfb_hdD5G7WxIEEJYkOVWJtCVGnyYl4DYpItqhBt0_Spz4X3UrDsaE6fDsXoe > > WpIrAn2qtCxIGVYGc88xGz0AavDxY-Kk0dOryc8KT6eeUumJHpgi-- > > TH7yOuC30DzNBDRR0DQ4OkLgLblPHsYqV9AyzTt51I8fipD7X-_VDXq- > > pBCO9ThUQKAy3HofPSZWmSYwzlT-okF7gL-83V1pdtjN1Zv- > > eJjBDGaUiulNrIXzrrD_zsO2mpWSnZw_cXUFHx-dEMC9hteXMj9MuVDQR8xNV- > > b9wLkiki2ABTG5srScX9qnFYdkQyEJ2uAIgg8l5p6LenynXdVYGqZPbQORbkf&u=h > > ttps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
