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.
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 <
> firstname.lastname@example.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
> > email@example.com
> > https://lists.mozilla.org/listinfo/dev-security-policy
dev-security-policy mailing list