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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
