Re: TunRootCA2 root inclusion request

[Wayne Thayer via dev-security-policy]

I think this discussion has made it clear that the request for inclusion of
the TunRootCA2 root should be denied.

CAs inherently must be trusted, and trust must be earned. A CA can't simply
fix one problem after another as we find them during the inclusion process
and expect to be rewarded for their reactive efforts, nor can they ignore
program requirements until the time comes to get their inclusion request
approved. Recurrences of the same issue that the CA claimed to have fixed
are especially damaging.

As Ryan mentioned, section 7.1 of the Root Store Policy states that "We
will determine which CA certificates are included in Mozilla's root program
based on the benefits and risks of such inclusion to typical users of our
products." While I believe the decision to deny this request is fully
supported by that policy statement, I would be interested to know if anyone
thinks there are ways we could make our expectations clearer in this regard.

Regarding next steps, the Tunisian Government is welcome to submit a new
root (using a newly generated key pair) for inclusion. The current bug may
be reopened and used for the new request, but it will still need to go
through the entire process. The only real "shortcut" in the inclusion
process - as has been demonstrated by a few CAs recently who completed the
process in 9-18 months) - is to have all the requirements fully met before
the request is reviewed. Tests that are performed during the information
verification process are documented [1], and every previous inclusion
request is publicly accessible in Bugzilla and archives of this list, so
this really shouldn't be as difficult as it seems to be.

I agree with the comments Hans made on the desire to rapidly move through
the process with the new request. Establishing confidence in a CA takes
time, and attempts to move too quickly to regain trust can be extremely
counterproductive (e.g. StartCom).

Regarding the choice of auditor, Mozilla has not disqualified LSTI and so
will not require a different auditor to be selected if/when a new root is
submitted. However, given the concerns that have been raised with the
current audits, choosing a different auditor may help to gain the
confidence of the community in the new root and in the Tunisian Government
CA.

- Wayne

[1] https://wiki.mozilla.org/CA:TestErrors

On Thu, Mar 15, 2018 at 5:44 AM, okaphone.elektronika--- via
dev-security-policy  wrote:

> On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com  wrote:
> > Dear Wayne,
> > Based on the long discussion regarding our request, I would appreciate
> having your opinion on the following:
> > Move to a new root based on EJBCA (Enterprise License) and conduct a new
> audit with a new auditor as required by Mozilla and the BR.
> > We are ready and we do commit to do these steps in 6 months. As we hope
> that you would accept to resume the inclusion process from this point.
> > We are looking forward to hearing from you.
> >
> > Syrine.
>
> Do consider that it only makes sense to start with a new root (and do the
> required audits etc.) when you are sure that all problems have been fixed,
> in such a way that they (and others like them) will not happen again.
>
> Because if that isn't the case, the new root will soon be as useless as
> trust-anchor as the old one. The fastest way forward is probably to not try
> to do it quickly.
>
> CU Hans
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com  wrote:
> Dear Wayne,
> Based on the long discussion regarding our request, I would appreciate having 
> your opinion on the following:
> Move to a new root based on EJBCA (Enterprise License) and conduct a new 
> audit with a new auditor as required by Mozilla and the BR.
> We are ready and we do commit to do these steps in 6 months. As we hope that 
> you would accept to resume the inclusion process from this point.
> We are looking forward to hearing from you.
> 
> Syrine.

Do consider that it only makes sense to start with a new root (and do the 
required audits etc.) when you are sure that all problems have been fixed, in 
such a way that they (and others like them) will not happen again.

Because if that isn't the case, the new root will soon be as useless as 
trust-anchor as the old one. The fastest way forward is probably to not try to 
do it quickly.

CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[syrine.tl--- via dev-security-policy]

Dear Wayne,
Based on the long discussion regarding our request, I would appreciate having 
your opinion on the following:
Move to a new root based on EJBCA (Enterprise License) and conduct a new audit 
with a new auditor as required by Mozilla and the BR.
We are ready and we do commit to do these steps in 6 months. As we hope that 
you would accept to resume the inclusion process from this point.
We are looking forward to hearing from you.

Syrine.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Ryan Sleevi via dev-security-policy]

On Mon, Mar 12, 2018 at 10:53 PM, taher.mestiri--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 think very few members of this community would see the time it takes to
get a publicly trusted CA included as a problem. Indeed, it's actually
rather quite the opposite - the time to get a CA included is likely not
long enough, the time to get a CA removed is likely not fast enough, and
the time for certificates to expire is not short enough.


> 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.
>

I shared a number of recommendations, based on the specific incidents
highlighted, and the risks they posed. Restarting the whole process is
something that has been requested of other CAs with similar deficiencies,
because in a large part, this whole ecosystem is based on trust. For a CA
to request inclusion, but not demonstrate sufficient technical
understanding on how to manage that trust, is reasonable grounds to not
trust them. Trust is not automatically granted and then slowly removed -
rather, it's slowly earned, based on the quality of character and continued
display of trustworthiness. In the case of this inclusion request, both the
practices and the policies demonstrated significant gaps from what would be
expected.

An alternative answer might be to deny inclusion for 2 or more years, since
that is often how long it can take to build an organization with both the
technical expertise and the implementation to support it, as even the
'best' CAs can attest. However, I tried to offer a more targeted set of
suggestions, based on the specific deficiencies that caused trust to be
undermined here. While these are only my suggestions, it highlights the
problematic patterns on display.

In the end, I'm not sure why the Tunisian Government feels it should run a
publicly trusted CA, so I don't know if there are other alternatives to
suggest that might offer a more expedient, more secure, more reliable basis
for trust. If that was to be shared, perhaps there are other solutions that
may work. In the absence of that, the failures at the basic and core
competencies of being a publicly trusted CA should be concerning.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: TunRootCA2 root inclusion request

[Tim Hollebeek via dev-security-policy]

My reaction was primarily based on the following suggestion:

"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."

The answer is, and must be, no.

-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 10:54 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: TunRootCA2 root inclusion request
> 
> 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

Re: TunRootCA2 root inclusion request

[taher.mestiri--- via dev-security-policy]

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 impa

RE: TunRootCA2 root inclusion request

[Tim Hollebeek via dev-security-policy]

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 &

Re: TunRootCA2 root inclusion request

[taher.mestiri--- via dev-security-policy]

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://lists.mozilla.org/listinfo/dev-security-policy
> >

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Ryan Sleevi via dev-security-policy]

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://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Anis via dev-security-policy]

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://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Ryan Sleevi via dev-security-policy]

On Sat, Mar 10, 2018 at 7:03 PM, syrine.tl--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > Trusting a CA is like that. Operating a CA requires a high degree of
> > competence and excellence, and each CA applying for inclusion should be
> as
> > or more competent, as or more skilled, and as or more valuable, as they
> > otherwise bring the ecosystem down rather than lifting it up.
>
> your effort lifting up CA ecosystem will not pay off by rejecting new CA
> application.
>

Sure it is, when the CA has a pattern of misissuance.


> You should also consider rejecting trusted CAs that still have
> miss-issuance concerns despite their well-established certificate issuance
> process and this is  a fact. You have much more renewal request than new
> inclusion
>

That has happened as well - if you look at PROCert for example.


> If you do have a list of unacceptable auditors, it should be clearly
> stated in Mozilla Policy so that all CAs will be informed.
> Running through the archives is not considered  an appropriate way of
> information for a selection process as demanding as this.
>

This is covered in Section 2.3 of the Policy.


> Having a fair and objective process requires applying the same acceptance
> or rejection criteria to all CAs.
> Otherwise it will be a double standards process.
>

Section 7.1 of the policy covers this.

""We will determine which CA certificates are included in Mozilla's root
program based on the benefits and risks of such inclusion to typical users
of our products. ""

Inclusions are not guaranteed - they are a balancing act of risk.

""We will make such decisions through a public process, based on objective
and verifiable criteria."

It is objective and verified that the Tunisian Government has had a
problematic series of misissuances, up to and including this past month,
and has consistently failed to ensure proper controls are in place.
Further, it is objective and verifiable, these were readily detectable by
the Tunisian Government, but weren't noticed as such until the issue was
raised. These included issues after the Tunisian Government reported them
remediated.

Further, based on does not mean limited to.

""We reserve the right to not include certificates from a particular CA in
our root program.""

Any root request can be rejected, for any reason, or not reason at all, at
any time.


> Anyway, we are looking forward to get the official outcome of Mozilla, and
> we will spare no effort to be listed among Mozilla Trusted CA


Can you explain your motivations for this? Such a globally trusted root
carries with it profound security risk to the ecosystem. What is the
overall goal for such trust, given that it does not in any way reduce risk
of distrust. If anything, it increases the risk for all Subscribers and
Relying Parties, given the pattern of misissuances shown and the apparent
lack of technical expertise to support and protect that infrastructure.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Ryan Sleevi via dev-security-policy]

On Sat, Mar 10, 2018 at 2:55 PM, Anis via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan
>
> just I want to remind you of these discussion and your opinion below
> in some was different than you say here !!!
>
> https://groups.google.com/forum/#!topic/mozilla.dev.
> security.policy/CfyeeybBz9c
> https://groups.google.com/forum/#!topic/mozilla.dev.
> security.policy/K3sk5ZMv2DE
>
> and
> https://misissued.com/batch/1/
>
> can you explain please
> Anis


I already have, but it seems you don't understand how a pattern of
misissuance is problematic. I'm glad you agree that there's a pattern of
misissuance, though - it does make it much easier to argue that the CA
should not be trusted when there's agreement that they're not able to
adhere to the Baseline Requirements.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Anis via dev-security-policy]

Hi Ryan

just I want to remind you of these discussion and your opinion below
in some was different than you say here !!!

https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/CfyeeybBz9c
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/K3sk5ZMv2DE

and
https://misissued.com/batch/1/

can you explain please
Anis
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[syrine.tl--- via dev-security-policy]

On Saturday, March 10, 2018 at 4:57:43 PM UTC+1, Ryan Sleevi wrote:
> On Fri, Mar 9, 2018 at 6:51 PM, syrine.tl--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> >
> >
> > We do use another CA's tool to check the validity of CSR. As we do use the
> > cr.sh tool developed also by another CA to check pre-certificate before
> > issuance. So why is using a tool for checking CSR is problematic whereas
> > using the crt.sh is approved ? The point here is to use an efficient tool
> > to perform certificate checks regardless of the CA that owns it. Besides,
> > given that the Tunisian government  does not have a Mozilla trusted CA,  we
> > are forced to buy SSL certificates for Tunisian e-commerce websites from
> > the CA who owns the CSR check tool that we use.
> > In order to have a consistent  RA process, we use the CSR check tool to by
> > from that trusted CA and also to check our own certificates
> >
> 
> It is important to highlight here not that it's intrinsically bad to use
> another tool - indeed, open-source and information sharing are good. The
> point is that your own examination of your software and practices was so
> deficient and lacking that you were unable to do even the most basic
> operations of a CA correctly, and having misrepresented to Mozilla what
> degree of checking you were doing.
> 
> A CSR, however, is such a basic check that even limited technical
> competency can do this. That this is relying on an online check is deeply
> disappointing and highlights a lack of technical competency - which the
> issues bore out - including the OCSP failures that seemingly still persist.
> 
> Recall - the tool was written by a recently added CA, because they simply
> read the specifications and wanted to ensure their systems followed them.
> It would appear TunRootCA2 either did not read the specifications, or could
> not be bothered to read them, or simply relies on off-the-shelf software to
> be a CA - when so much more is expected.
> 
> 
> > > Yet, at the same time, there are still-trusted CAs that have demonstrated
> > > similar issues - although perhaps not to the same degree of becoming a
> > > problematic pattern or an insufficient response - and they still remain
> > > trusted. A recommendation to instill trust in such a new CA, one that has
> > > demonstrated problematic patterns already, suggests that CAs may continue
> > > to display such patterns without risk of distrust - which would overall
> > be
> > > harmful. Yet, if the recommendation is not to trust, what should the
> > > remediation steps be to find a positive path forward?
> >
> >
> > Since there are other still-trusted CAs that has the same problems, why is
> > that the Tunisian CA treated with presumption of untrustworthiness  . The
> > decision-making process should be objective and fair for all CAs.
> >
> 
> You can see I specifically addressed that. To repeat:
> 1) The Tunisian CA has demonstrated a problematic pattern of misissuance
> and misconfiguration that has not, even until 2018-02-22, the most recent
> review, stopped.
> 2) If we believe in a fair and objective process, then the Tunisian CA will
> make the ecosystem worse by accepting, by setting a new low bar of
> competency and correctness.
> 
> So, the fair and objective basis is to look at the pattern and trends - one
> which would reasonably start a discussion of possible distrust - and simply
> say the risk is not worth it.
> 
> 
> > > I do not believe this CA should be trusted, given these patterns. I do
> > not
> > > feel the evidence supports a confident understanding of the critical role
> > > that CAs play, nor an understanding of the technical risks and
> > mitigations.
> > > While it is good that TunRootCA2 has adopted practices such as linting,
> > it
> > > simply moves the problem to be more opaque - how many certificates fail
> > > that check will not be known, nor will it be known how many failures are
> > > now for policy reasons, rather than technical reasons. The community
> > > largely relies on the information provided in audits - with the
> > > expectations that CAs will self-report and self-disclose these issues -
> > and
> > > yet the audits not calling this information out is deeply worrying, both
> > as
> > > to quality and to completeness.
> >
> > During  all the Mozilla review process, our team showed a willingness and
> > a seriousness in the treatment of these incidents. We have implemented all
> > the technical checks required to prevent the occurrence of other miss-
> > issued certificates (pre-issuance linting). We have also reported all
> > missiussed certificates  of our root CA since its creation. There are in
> > total 15 mississued certificates as listed Olfa's last message
> > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/
> > fFcZ3SepAQAJ
> 
> 
> Disclosure is not something that is exceptional - it is the minimum
> required of a CA. The fact that new misissued 

Re: TunRootCA2 root inclusion request

[Ryan Sleevi via dev-security-policy]

On Fri, Mar 9, 2018 at 6:51 PM, syrine.tl--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> We do use another CA's tool to check the validity of CSR. As we do use the
> cr.sh tool developed also by another CA to check pre-certificate before
> issuance. So why is using a tool for checking CSR is problematic whereas
> using the crt.sh is approved ? The point here is to use an efficient tool
> to perform certificate checks regardless of the CA that owns it. Besides,
> given that the Tunisian government  does not have a Mozilla trusted CA,  we
> are forced to buy SSL certificates for Tunisian e-commerce websites from
> the CA who owns the CSR check tool that we use.
> In order to have a consistent  RA process, we use the CSR check tool to by
> from that trusted CA and also to check our own certificates
>

It is important to highlight here not that it's intrinsically bad to use
another tool - indeed, open-source and information sharing are good. The
point is that your own examination of your software and practices was so
deficient and lacking that you were unable to do even the most basic
operations of a CA correctly, and having misrepresented to Mozilla what
degree of checking you were doing.

A CSR, however, is such a basic check that even limited technical
competency can do this. That this is relying on an online check is deeply
disappointing and highlights a lack of technical competency - which the
issues bore out - including the OCSP failures that seemingly still persist.

Recall - the tool was written by a recently added CA, because they simply
read the specifications and wanted to ensure their systems followed them.
It would appear TunRootCA2 either did not read the specifications, or could
not be bothered to read them, or simply relies on off-the-shelf software to
be a CA - when so much more is expected.


> > Yet, at the same time, there are still-trusted CAs that have demonstrated
> > similar issues - although perhaps not to the same degree of becoming a
> > problematic pattern or an insufficient response - and they still remain
> > trusted. A recommendation to instill trust in such a new CA, one that has
> > demonstrated problematic patterns already, suggests that CAs may continue
> > to display such patterns without risk of distrust - which would overall
> be
> > harmful. Yet, if the recommendation is not to trust, what should the
> > remediation steps be to find a positive path forward?
>
>
> Since there are other still-trusted CAs that has the same problems, why is
> that the Tunisian CA treated with presumption of untrustworthiness  . The
> decision-making process should be objective and fair for all CAs.
>

You can see I specifically addressed that. To repeat:
1) The Tunisian CA has demonstrated a problematic pattern of misissuance
and misconfiguration that has not, even until 2018-02-22, the most recent
review, stopped.
2) If we believe in a fair and objective process, then the Tunisian CA will
make the ecosystem worse by accepting, by setting a new low bar of
competency and correctness.

So, the fair and objective basis is to look at the pattern and trends - one
which would reasonably start a discussion of possible distrust - and simply
say the risk is not worth it.


> > I do not believe this CA should be trusted, given these patterns. I do
> not
> > feel the evidence supports a confident understanding of the critical role
> > that CAs play, nor an understanding of the technical risks and
> mitigations.
> > While it is good that TunRootCA2 has adopted practices such as linting,
> it
> > simply moves the problem to be more opaque - how many certificates fail
> > that check will not be known, nor will it be known how many failures are
> > now for policy reasons, rather than technical reasons. The community
> > largely relies on the information provided in audits - with the
> > expectations that CAs will self-report and self-disclose these issues -
> and
> > yet the audits not calling this information out is deeply worrying, both
> as
> > to quality and to completeness.
>
> During  all the Mozilla review process, our team showed a willingness and
> a seriousness in the treatment of these incidents. We have implemented all
> the technical checks required to prevent the occurrence of other miss-
> issued certificates (pre-issuance linting). We have also reported all
> missiussed certificates  of our root CA since its creation. There are in
> total 15 mississued certificates as listed Olfa's last message
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/
> fFcZ3SepAQAJ


Disclosure is not something that is exceptional - it is the minimum
required of a CA. The fact that new misissued certificates continued to be
issued throughout the process, since its inception, shows a problem. That
Baseline Requirements dates continued to be missed is equally problematic -
and shows a process failure at an organization that is not mature enough
yet to 

Re: TunRootCA2 root inclusion request

[syrine.tl--- via dev-security-policy]

On Friday, March 9, 2018 at 10:30:18 PM UTC+1, Ryan Sleevi wrote:
> On Tue, Feb 27, 2018 at 4:17 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > This request has been in public discussion for more than 6 months, so I
> > would like to make a decision soon. If you have comments or concerns with
> > this request, please post them here by 6-March 2018.
> 
> 
> Wayne,
> 
> Thanks for encouraging this discussion and making sure it reaches a timely
> conclusion.
> 
> To assist in the review, I've tried to summarize the issues to date:
> Incident 1:
> - 2016-01-04: As part of the initial Information Gathering, Kathleen Wilson
> noted incomplete reply to the list of Mozilla Problematic Practices
> regarding DNS names appearing within the subjectAltName. In response, on
> 2016-01-20, TunRootCA 2 replies -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1233645#c5 - stating that they
> only use the subjectAlternativeName.
> - 2017-02-28: TunRootCA2 violates this requirement -
> https://crt.sh/?id=99182607
> - 2017-03-03: TunRootCA2 revokes this certificate -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ
> - 2017-07-19: Charles Reiss raises this issue -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ
> 
> Incident 2:
> - 2016-01-04: TunRootCA2 states their validation practices
> - 2016-03-11: TunRootCA2 violates those - https://crt.sh/?id=15126121
> - 2016-03-21: TunRootCA2 revokes that certificate -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ
> - 2017-07-19: Charles Reiss raises this issue -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ
> 
> Incident 3:
> - 2012-07-01: Baseline Requirements effective date, with restrictions on
> reserved IPs and internal server names.
> - 2015-10-23: TunRootCA2 issues a certificate with a reserved IP address
> with a validity period later than 2015-11-1.
> - 2016-12-14: TunRootCA2 replaces the certificate
> - 2017-07-19: Charles Reiss raises this issue -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ
> 
> Incident 4:
> - 2012-07-01: Baseline Requirements effective date, with restrictions on
> reserved IPs and internal server names.
> - 2017-01-09: TunRootCA2 issues a certificate for an internal server name
> - 2017-07-19: Charles Reiss raises this issue -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ
> - 2017-07-28: TunRootCA2 revokes this certificate
> 
> During the discussion of these incidents, TunRootCA2 disclosed that RAs
> handled domain name validation, and they used another CA's tools to check
> the validity of CSRs. RAs were then empowered to issue the domain
> information directly to cause issuance. This suggests a strong lack of
> technical controls and understanding by RAs. In response, TunRootCA2
> indicated they were deploying a new PKI platform.
> 

We do use another CA's tool to check the validity of CSR. As we do use the 
cr.sh tool developed also by another CA to check pre-certificate before 
issuance. So why is using a tool for checking CSR is problematic whereas using 
the crt.sh is approved ? The point here is to use an efficient tool to perform 
certificate checks regardless of the CA that owns it. Besides, given that the 
Tunisian government  does not have a Mozilla trusted CA,  we are forced to buy 
SSL certificates for Tunisian e-commerce websites from the CA who owns the CSR 
check tool that we use. 
In order to have a consistent  RA process, we use the CSR check tool to by from 
that trusted CA and also to check our own certificates

> On 2018-02-27, TunRootCA2 claims they no longer use DTPs for domain
> validation, as per
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ
> 
> 
> Incident 5:
> - 2017-10-23: TunRootCA2 misissues again -
> https://crt.sh/?id=242366304=cablint
> - 2018-02-22: Wayne Thayer raises this issue -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ
> - 2018-02-27: TunRootCA2 revokes the certificate -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ
> 
> Incident 6:
> - 2018-02-22: Wayne Thayer completes initial review -
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ
> - 2018-02-23: TunRootCA2 misissues again -
> https://crt.sh/?id=346579818=cablint
> - 2018-02-28: TunRootCA2 revokes the certificate
> 
> 
> Like Jonathan, I am concerned about the technical controls instituted. From
> this thread, it does not give the impression of a technically competent
> organization. While the requirements for more detailed. While a number of
> these incidents predate the normalized Mozilla Incident Report template (
> https://groups.google.com/d/msg/mozilla.dev.security.policy/Y392OBvDvr8/Pf4VCG_-BQAJ
> ), it 

Re: TunRootCA2 root inclusion request

[Paul Kehrer via dev-security-policy]

In addition to the issues Ryan has listed, during the root inclusion
process multiple issues with their OCSP responder and CRL endpoints were
observed and fixed only after the flaws were documented in the bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=1233645).

I believe any CA seeking inclusion should be capable of doing the sorts of
checks the Mozilla community performs long prior to seeking root inclusion.
Failures like this inspire no confidence in the technical acumen of the
administrators and I do not believe this root inclusion request should be
accepted.

-Paul
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Ryan Sleevi via dev-security-policy]

On Tue, Feb 27, 2018 at 4:17 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This request has been in public discussion for more than 6 months, so I
> would like to make a decision soon. If you have comments or concerns with
> this request, please post them here by 6-March 2018.


Wayne,

Thanks for encouraging this discussion and making sure it reaches a timely
conclusion.

To assist in the review, I've tried to summarize the issues to date:
Incident 1:
- 2016-01-04: As part of the initial Information Gathering, Kathleen Wilson
noted incomplete reply to the list of Mozilla Problematic Practices
regarding DNS names appearing within the subjectAltName. In response, on
2016-01-20, TunRootCA 2 replies -
https://bugzilla.mozilla.org/show_bug.cgi?id=1233645#c5 - stating that they
only use the subjectAlternativeName.
- 2017-02-28: TunRootCA2 violates this requirement -
https://crt.sh/?id=99182607
- 2017-03-03: TunRootCA2 revokes this certificate -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ
- 2017-07-19: Charles Reiss raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ

Incident 2:
- 2016-01-04: TunRootCA2 states their validation practices
- 2016-03-11: TunRootCA2 violates those - https://crt.sh/?id=15126121
- 2016-03-21: TunRootCA2 revokes that certificate -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ
- 2017-07-19: Charles Reiss raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ

Incident 3:
- 2012-07-01: Baseline Requirements effective date, with restrictions on
reserved IPs and internal server names.
- 2015-10-23: TunRootCA2 issues a certificate with a reserved IP address
with a validity period later than 2015-11-1.
- 2016-12-14: TunRootCA2 replaces the certificate
- 2017-07-19: Charles Reiss raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ

Incident 4:
- 2012-07-01: Baseline Requirements effective date, with restrictions on
reserved IPs and internal server names.
- 2017-01-09: TunRootCA2 issues a certificate for an internal server name
- 2017-07-19: Charles Reiss raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ
- 2017-07-28: TunRootCA2 revokes this certificate

During the discussion of these incidents, TunRootCA2 disclosed that RAs
handled domain name validation, and they used another CA's tools to check
the validity of CSRs. RAs were then empowered to issue the domain
information directly to cause issuance. This suggests a strong lack of
technical controls and understanding by RAs. In response, TunRootCA2
indicated they were deploying a new PKI platform.

On 2018-02-27, TunRootCA2 claims they no longer use DTPs for domain
validation, as per
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ


Incident 5:
- 2017-10-23: TunRootCA2 misissues again -
https://crt.sh/?id=242366304=cablint
- 2018-02-22: Wayne Thayer raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ
- 2018-02-27: TunRootCA2 revokes the certificate -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ

Incident 6:
- 2018-02-22: Wayne Thayer completes initial review -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ
- 2018-02-23: TunRootCA2 misissues again -
https://crt.sh/?id=346579818=cablint
- 2018-02-28: TunRootCA2 revokes the certificate


Like Jonathan, I am concerned about the technical controls instituted. From
this thread, it does not give the impression of a technically competent
organization. While the requirements for more detailed. While a number of
these incidents predate the normalized Mozilla Incident Report template (
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y392OBvDvr8/Pf4VCG_-BQAJ
), it was designed precisely to address these issues, and the more recent
replies do not provide particular reassurance that these incidents have
been fully understood.

The failures Wayne raised, particularly around documentation, are
troubling. Equally troubling is that in the course of audits, these issues
were not disclosed - or, if they were, the revocation of the certificate in
response to these incidents was not disclosed to the broader community.

Yet, at the same time, there are still-trusted CAs that have demonstrated
similar issues - although perhaps not to the same degree of becoming a
problematic pattern or an insufficient response - and they still remain
trusted. A recommendation to instill trust in such a new CA, one that has
demonstrated problematic patterns already, suggests that CAs may continue
to display such patterns without risk of distrust - which would overall be
harmful. Yet, if the recommendation is not to trust, 

Re: TunRootCA2 root inclusion request

[Anis via dev-security-policy]

Le mercredi 19 juillet 2017 10:10:19 UTC+1, Aaron Wu a écrit :
> This request from the Government of Tunisia is to include the “Tunisian Root 
> Certificate Authority - TunRootCA2” root certificate, and enable the Websites 
> trust bit.
> 
> The request is documented in the following bug: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1233645
> 
> BR Self Assessment is here:
> https://bugzilla.mozilla.org/attachment.cgi?id=8865381
> 
> Summary of Information Gathered and Verified: 
> https://bugzilla.mozilla.org/attachment.cgi?id=8884764
> 
> * Root Certificate Download URL: 
> http://www.certification.tn/pub/TunRootCA2.crt
> 
> * Documents are in French, translated in English
> CP/CPS in French: 
> http://www.certification.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-05.pdf
> 
> CP/CPS in English: 
> http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf
> 
> 
> * CA Hierarchy: 
> This root will have internally-operated subordinate CAs. 
> Currently it has one internally-operated subordinate CA:
> - Tunisian Server Certificate Authority - TunServerCA2
> 
> * This request is to turn on the Websites trust bit. EV treatment is not 
> requested.
> 
> * CP/CPS of the Tunisian Server Certificate Authority PTC BR:
> 
> ** Section 1.3.4: 
> “In the context of this CP / CPS, a Server Certificate Responsible (SCR) is a 
> natural person who is responsible for using the certificate of the server or 
> computer device identified in the certificate and the private key 
> corresponding to this certificate, on behalf of the entity identified in that 
> certificate. The SCR is contractually, hierarchically or legally bound to 
> this entity.”
> 
> ** Section 3.2.2:
> “Authentication of a client organization is done by checking the following 
> documents:
> The certificate application form duly completed and signed by the applicant, 
> acting as a certificate request, containing in particular the postal address, 
> the professional e-mail address and the telephone number enabling the NDCA to 
> contact the future bearer;
> • A copy of the National Identity Card, passport or residence card of the 
> applicant and the SCR;
> • An extract from the trade register not exceeding three months;
> The bearer must be informed that the personal identity information he has 
> provided for the registration file will be retained.
> The verification and validation of the request are carried out in accordance 
> with the provisions described in section 4.2.”
> 
> ** Section 4.2.1:
> "For the purpose of verifying the identities of the applicants, the RA, 
> performs the following operations:
> check the consistency of the registration dossier and the supporting 
> documents submitted;
> verify the accuracy of the purchase order and payment;
> verify that the organization holds the domain name by consulting the official 
> databases of AFRINIC or INTERNIC domain names, and 
> ensure that the SCR is aware of the terms and conditions applicable to the 
> use of the certificate.
> Upon completion of these transactions, the RA sends the request to the CA 
> components responsible for certificate production. The RA then retains a copy 
> of the proof of identity submitted in paper or electronic form having a legal 
> value.”
> 
> 
> * EV Policy OID: Not Requesting EV treatment 
> 
> * Test Websites
> Valid certificate: https://valid-ov.certification.tn
> Revoked certificate: https://revoked-ov.certification.tn
> Expired certificate: https://expired-ov.certification.tn
> 
> * CRL URLs: 
> http://crl.certification.tn/TunRootCA2.crl
> http://crl.certification.tn/TunServerCA2.crl 
> CP/CPS section 2.3: A new CRL is published every 24 hours
> 
> * OCSP URLs:
> http://ocsp.certification.tn
> OCSP responses have a maximum expiration time of 10 days.
> 
> * Audit: Annual audits are performed by LSTI according to the ETSI TS 102 042 
> for CA and BR audit criteria.
> https://bug1233645.bmoattachments.org/attachment.cgi?id=8879910
> 
> 
> * Forbidden or Problematic Practices 
> (https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices)
> None Noted
> 
> This begins the discussion of the request from the Government of Tunisia is 
> to include the “Tunisian Root Certificate Authority - TunRootCA2” root 
> certificate, and enable the Websites trust bit.
> 
> I will greatly appreciate your constructive and thoughtful feedback on this 
> request.
> 
> Aaron

the inclusion of the certification authority in Mozilla is a challenge for the 
Tunisian government, efforts of more than 4 years of massive work, 
international audits, the improvement of this authority does not stop to prove 
the seriousness of the team that works day and night to succeed this challenge, 
despite the errors we read in this group, but I do not think they are so fatal 
compared to other errors of other certification authorities, I wish you give 
this authority a chance as you gave it to others. I found the responsiveness to 
answer you while 

Re: TunRootCA2 root inclusion request

[Olfa Kaddachi via dev-security-policy]

Dear Jonathan,
Given the misissued certificates in CT under the existing root, I believe this 
request should be rejected, and a new clean root with audits should be required 
before moving forward.

==>All the misissued certificates have been revoked by the NDCA and new correct 
ones were substituted to the clients. The TunServerCA2 has been audited yearly 
by a qualified auditor (LSTI, France) since 2015. A new root will not resolve 
these problems because all of these issues are a part of the validation process 
in the RA. That’s why we implemented new technical controls in the TunServerCA2 
RA to reject all the CSR that contain any problem of this kind. 
  The errors in the issued certificates indicate a lack of technical controls 
in addition to improperly implemented certificate profiles. Given this, an 
explanation should also be provided of what changes have been made to the 
issuance environment to ensure these types of mistakes will not happen under 
the new root.
==>Two technical controls have been implemented:
1.  In the RA of the TunServerCA2, a specific coding has been done on the 
RA scripts. The Common Name specified in the CSR is, from now on, automatically 
included in the SAN entries. In addition to that, a control that ensures that 
the SAN entries contain the Common Name has been implemented.
2.  An automatic check of TBS certificates using TBSCertificate crt.sh API 
has been added today and integrated into the issuance 
processes. Actually, we followed the suggestion of Rob Stradling Senior 
Research & Development Scientist COMODO - Creating Trust Online published in 
https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/oTQ9OYgS8D4).
  
 

There are a bunch of warnings, but these jumped out at me as being very serious:

These certificates have a commonName that is not included as a dNSName SAN:

- https://crt.sh/?id=99182607=cablint
==>We investigated on the error of this case:  The TunServerCA2 RA included 
only the SAN declared in the CSR. This problem has been resolved since last 
week by implementing a code that includes automatically the Common Name in the 
SAN entries. Moreover, all the domain names declared in the certificate (CN and 
Subject Alternative Names) are checked by the RA according to the 3.2.2.4 of 
the CAB/Forum.  

- https://crt.sh/?id=242366304=cablint
==>We investigated on the error of this case:  The TunServerCA2 RA included 
only the SAN declared in the CSR. This problem has been resolved since last 
week by implementing a coding that includes automatically the Common Name in 
the SAN entries.
This certificate has a SAN with a domain ending in .local, which is a reserved 
special-use TLD:

- https://crt.sh/?id=79470561=cablint
=> We investigated on the error of this case:  The TunServerCA2 RA included 
only the SAN declared in the CSR. This problem has been resolved by updating 
our CSR checker to include the inspection of all the SAN entries declared in 
the CSR that contain a “.local” in CN or in any of the SAN entries. All of 
these cases are automatically rejected by the TunServerCA2 RA and the RSC has 
to generate a new correct CSR.

It’s important to remember that these are only the certificates that we know 
about via CT. There may be certificates with similar or other issues that are 
not logged.
==> We have checked all the issued certificates by a daemon which 
integrates the crt.sh API. This daemon checked the issued certificates one by 
one in the RA database: There are 15 misissued certificates since the issuance 
of the TunServerCA2. You find below the serial number of each one, the Error 
reported by cablint, x509lint and zlint:

41591505131605113993BB051309A9A8

cablint WARNING Certificate Policies should not contain notice references
cablint INFOTLS Server certificate identified
x509lintWARNING explicitText is not using a UTF8String
x509lintWARNING Policy information has qualifier other than CPS URI
x509lintINFOSubject has a deprecated CommonName
x509lintINFOUnknown validation policy
zlint   ERROR   CAs must include keyIdentifer field of AKI in all 
non-self-issued certificates
zlint   ERROR   CAs must support key identifiers and include them in all 
certificates
zlint   WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint   WARNING Compliant certificates should use the utf8string encoding for 
explicitText
zlint   WARNING Sub certificates SHOULD include Subject Key Identifier in end 
entity certs
zlint   NOTICE  Subscriber Certificate: commonName is deprecated.

==> This issue has been fixed after the first audit in august 2015.

41591509041609025C4CD135DDB18DDD

cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Name has deprecated attribute emailAddress
cablint WARNING Special name in SAN
cablint INFOTLS Server certificate identified
x509lintWARNING explicitText is not using a UTF8String

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:47, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg 
> wrote:
> 
>> 
>>> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> 
 On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
 
 This request has been in public discussion for more than 6 months, so I
 would like to make a decision soon. If you have comments or concerns
>> with
 this request, please post them here by 6-March 2018.
>>> 
>>> Given the misissued certificates in CT under the existing root, I
>> believe this request should be rejected, and a new clean root with audits
>> should be required before moving forward.
>>> 
>> 
> This course of action doesn't seem consistent with our treatment of the
> many included CAs that have experienced these problems.

Given that revocation checking doesn’t work, and CT doesn’t provide a complete 
picture, especially without browser enforcement, accepting this root would have 
the result of exposing Mozilla's users to certificates that are known to be 
misissued.

I realize that some inclusion requests have been accepted in the past despite 
existing misissued certificates, but I don’t think that is sufficient 
justification for continuing to do so. Why shouldn’t we require CAs to cut a 
new root when the data indicates that accepting the existing root will put 
users at risk?

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Wayne Thayer via dev-security-policy]

On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg 
wrote:

>
> > On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> >> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >> This request has been in public discussion for more than 6 months, so I
> >> would like to make a decision soon. If you have comments or concerns
> with
> >> this request, please post them here by 6-March 2018.
> >
> > Given the misissued certificates in CT under the existing root, I
> believe this request should be rejected, and a new clean root with audits
> should be required before moving forward.
> >
>
This course of action doesn't seem consistent with our treatment of the
many included CAs that have experienced these problems.


> > The errors in the issued certificates indicate a lack of technical
> controls in addition to improperly implemented certificate profiles. Given
> this, an explanation should also be provided of what changes have been made
> to the issuance environment to ensure these types of mistakes will not
> happen under the new root.
>
> I just took a closer look at the thread, and it appears that some
> misissuance was pointed out in July and most of the controls that were
> suggested as a solution relied on humans. These controls appear to have
> predictably failed, as multiple misissued certificates are from this fall,
> well after the fixes should have been in place.
>
> Olfa's most recent response indicates that additional/technical controls
were added this week. However, I'm not convinced that they are adequate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> 
>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy 
>>  wrote:
>> 
>> This request has been in public discussion for more than 6 months, so I
>> would like to make a decision soon. If you have comments or concerns with
>> this request, please post them here by 6-March 2018.
> 
> Given the misissued certificates in CT under the existing root, I believe 
> this request should be rejected, and a new clean root with audits should be 
> required before moving forward.
> 
> The errors in the issued certificates indicate a lack of technical controls 
> in addition to improperly implemented certificate profiles. Given this, an 
> explanation should also be provided of what changes have been made to the 
> issuance environment to ensure these types of mistakes will not happen under 
> the new root.

I just took a closer look at the thread, and it appears that some misissuance 
was pointed out in July and most of the controls that were suggested as a 
solution relied on humans. These controls appear to have predictably failed, as 
multiple misissued certificates are from this fall, well after the fixes should 
have been in place.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> This request has been in public discussion for more than 6 months, so I
> would like to make a decision soon. If you have comments or concerns with
> this request, please post them here by 6-March 2018.

Given the misissued certificates in CT under the existing root, I believe this 
request should be rejected, and a new clean root with audits should be required 
before moving forward.

The errors in the issued certificates indicate a lack of technical controls in 
addition to improperly implemented certificate profiles. Given this, an 
explanation should also be provided of what changes have been made to the 
issuance environment to ensure these types of mistakes will not happen under 
the new root.

There are a bunch of warnings, but these jumped out at me as being very serious:

These certificates have a commonName that is not included as a dNSName SAN:

- https://crt.sh/?id=99182607=cablint
- https://crt.sh/?id=242366304=cablint

This certificate has a SAN with a domain ending in .local, which is a reserved 
special-use TLD:

- https://crt.sh/?id=79470561=cablint

It’s important to remember that these are only the certificates that we know 
about via CT. There may be certificates with similar or other issues that are 
not logged.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Wayne Thayer via dev-security-policy]

This request has been in public discussion for more than 6 months, so I
would like to make a decision soon. If you have comments or concerns with
this request, please post them here by 6-March 2018.

On Tue, Feb 27, 2018 at 7:33 AM, Olfa Kaddachi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear Wayne,
>
> The TunRootCA2 root CA operates under the following CPS:
> http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf
> ==> The TunRootCA2 operates under a new version of the CP/CPS: :
> http://www.certification.tn/sites/default/files/documents/
> CPCPS-NG-EN-02.pdf
>
> The TunserverCA2 subordinate CA operates under a different CPS:
> http://www.certification.tn/sites/default/files/documents/
> CPCPS-PTC-BR-EN-05.pdf
> ==> The TunServerCA2’s subordinate CA operates under a new version of
> the CP/CPS : http://www.certification.tn/sites/default/files/documents/
> CPCPS-PTC-BR-EN-07.pdf
>
> These updated documents address the concerns I raised below.

>
> ==Good==
> * Misissued certificates reported earlier in this thread have been revoked
> ==> Yes. The RA of the TunServerCA2 has revoked all the misissued
> certificates and issued new ones for its clients.
>
> ==Meh==
> * Numerous warning level lint errors in issued certificates:
> https://crt.sh/?caid=5680=cablint,zlint,x509lint;
> minNotBefore=2017-01-01
> ==> 99182607 : The certificate has been issued on the 28th Feburary
> 2017 and was revoked the 03rd of March 2017.
> ==> 242366304 : The certificate has been issued on 25th October 2017
> and was revoked on the 02nd of November 2017.
> ==>201192937 : This is the certificate of the OCSP server which checks
> the status of the TLS/SSL certificates issued under TunServerCA2.
> * From the US, the server is returning an error or taking more than one
> minute to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl
> (crt.sh is also timing out).
> ==> This problem has been resolved. The reason of this slowness was
> that during the last two weeks, we migrated to our new backup site.
> * The great majority of certificates issued by this CA fall under the .tn
> TLD; however, the Government of Tunisia has not requested that the root be
> constrained to issuance for .tn names.
> ==> Yes the great majority of certificates issued by this CA fall
> under the .tn TLD. However, this CA also issues certificates under others
> TLD like .com, .net and .org.
> * The subordinate CA certificate contains no EKU extension so is not
> constrained to issuing certain types of certificates.
> ==> Yes, the subordinate CA certificate doesn’t contain a EKU
> extension. TunServerCA2 signs SSL certificate, CRL and OCSP certificate.
> This subordinate contains Certificate Sign and CRL Sign key usage.
>
> * Delegated 3rd parties are permitted. The CPS does not clearly state the
> BR requirement that domain validation may not be performed by a delegated
> third party.
> ==> Yes the delegated 3rd parties are permitted. But, the domain
> validation is only performed by the CRA of TunServerCA2 (see section
> 1.3.2.2 of the new version of the CP/CPS).
> * The only method of domain validation specified in the BR Self Assessment
> is the now deprecated 3.2.2.4.5. How and when will the Government of
> Tunisia comply with CA/Browser Forum ballot 218?
> ==> See section 3.2.2 of the new version http://www.certification.tn/
> sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf.
> * The Government of Tunisia’s answer for wildcard domain validation in
> their BR Self Assessment implies the use of method 3.2.2.4.1, but they
> claim not to use that method in the same document.
> ==> See section 3.2.2 of the new version http://www.certification.tn/
> sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf.
> * CPS section 4.9.2 does not permit a person who controls a domain name
> contained in a certificate to request revocation unless they are the
> Subscriber or the Subscriber's legal representative.
> ==> Yes we confirm that TunServerCA2 does not permit that the person
> who controls the domain name to request revocation. Only the subscriber and
> the subscriber’s legal representative are allowed to request revocation.
>
> ==Bad==
> * Missing SAN entries: https://crt.sh/?cablint=25;
> iCAID=5680=2017-01-01 This CA continues to misissue
> certificates, so the manual controls described earlier in this thread are
> inadequate.
> ==> To resolve the missing SAN entries, a specific coding has been
> done this week on the RA scripts. The common name specified in the CSR is,
> from now on, automatically included in the SAN entries. In addition to
> that, a check of the issued certificate using the lintcert will be done by
> the operators before delivering the certificate to the RSC.
>

I think you meant "SCR" (i.e. Subscriber) not "RSC". Please be aware that
finding errors after a certificate is issued but before it is delivered to
the SCR/Subscriber is still 

Re: TunRootCA2 root inclusion request

[Olfa Kaddachi via dev-security-policy]

Dear Wayne,

The TunRootCA2 root CA operates under the following CPS: 
http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf 
==> The TunRootCA2 operates under a new version of the CP/CPS: : 
http://www.certification.tn/sites/default/files/documents/CPCPS-NG-EN-02.pdf 

The TunserverCA2 subordinate CA operates under a different CPS: 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf
 
==> The TunServerCA2’s subordinate CA operates under a new version of the 
CP/CPS : 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf


==Good== 
* Misissued certificates reported earlier in this thread have been revoked 
==> Yes. The RA of the TunServerCA2 has revoked all the misissued 
certificates and issued new ones for its clients.

==Meh== 
* Numerous warning level lint errors in issued certificates: 
https://crt.sh/?caid=5680=cablint,zlint,x509lint=2017-01-01 
==> 99182607 : The certificate has been issued on the 28th Feburary 2017 
and was revoked the 03rd of March 2017. 
==> 242366304 : The certificate has been issued on 25th October 2017 and 
was revoked on the 02nd of November 2017.
==>201192937 : This is the certificate of the OCSP server which checks the 
status of the TLS/SSL certificates issued under TunServerCA2. 
* From the US, the server is returning an error or taking more than one minute 
to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl (crt.sh is 
also timing out). 
==> This problem has been resolved. The reason of this slowness was that 
during the last two weeks, we migrated to our new backup site.
* The great majority of certificates issued by this CA fall under the .tn TLD; 
however, the Government of Tunisia has not requested that the root be 
constrained to issuance for .tn names. 
==> Yes the great majority of certificates issued by this CA fall under the 
.tn TLD. However, this CA also issues certificates under others TLD like .com, 
.net and .org.
* The subordinate CA certificate contains no EKU extension so is not 
constrained to issuing certain types of certificates. 
==> Yes, the subordinate CA certificate doesn’t contain a EKU extension. 
TunServerCA2 signs SSL certificate, CRL and OCSP certificate. This subordinate 
contains Certificate Sign and CRL Sign key usage.

* Delegated 3rd parties are permitted. The CPS does not clearly state the BR 
requirement that domain validation may not be performed by a delegated third 
party. 
==> Yes the delegated 3rd parties are permitted. But, the domain validation 
is only performed by the CRA of TunServerCA2 (see section 1.3.2.2 of the new 
version of the CP/CPS).
* The only method of domain validation specified in the BR Self Assessment is 
the now deprecated 3.2.2.4.5. How and when will the Government of Tunisia 
comply with CA/Browser Forum ballot 218? 
==> See section 3.2.2 of the new version 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf.
* The Government of Tunisia’s answer for wildcard domain validation in their BR 
Self Assessment implies the use of method 3.2.2.4.1, but they claim not to use 
that method in the same document. 
==> See section 3.2.2 of the new version 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf.
* CPS section 4.9.2 does not permit a person who controls a domain name 
contained in a certificate to request revocation unless they are the Subscriber 
or the Subscriber's legal representative. 
==> Yes we confirm that TunServerCA2 does not permit that the person who 
controls the domain name to request revocation. Only the subscriber and the 
subscriber’s legal representative are allowed to request revocation.

==Bad== 
* Missing SAN entries: 
https://crt.sh/?cablint=25=5680=2017-01-01 This CA continues 
to misissue certificates, so the manual controls described earlier in this 
thread are inadequate. 
==> To resolve the missing SAN entries, a specific coding has been done 
this week on the RA scripts. The common name specified in the CSR is, from now 
on, automatically included in the SAN entries. In addition to that, a check of 
the issued certificate using the lintcert will be done by the operators before 
delivering the certificate to the RSC.
==> * The current subordinate CA CPS is dated October-2016. The current 
root CPS is dated July-2015. Mozilla policy requires annual CPS updates.
==> The revision dates of the subordinate CA CPS are: the 26th of June 
2015, 28th of July 2015, 21st of  October 2015, 21st of January 2016, 12th of 
February 2016, 18th of October 2016, 27th of  November 2017 and 27th of 
February 2018. 
==> The revision dates of the root CPS are : 01st of june 2015, 28th of 
july 2015 and 27th of November 2017.
In the future, both of the TunRootCA2 and TunServerCA2 CPSs  will be reviewed 
at least once a year to meet the requirement of the Mozilla policy.  

* The CPS does not comply 

Re: TunRootCA2 root inclusion request

[Wayne Thayer via dev-security-policy]

The TunrootCA2 root operates under the following CPS: 
http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf

The TunserverCA2 subordinate CA operates under a different CPS: 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf

I have reviewed the supplied BR Self Assessment, the CPSes, and related 
information, and have the following comments:

==Good==
* Misissued certificates reported earlier in this thread have been revoked

==Meh==
* Numerous warning level lint errors in issued certificates: 
https://crt.sh/?caid=5680=cablint,zlint,x509lint=2017-01-01
* From the US, the server is returning an error or taking more than one minute 
to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl (crt.sh is 
also timing out)
* The great majority of certificates issued by this CA fall under the .tn TLD; 
however, the Government of Tunisia has not requested that the root be 
constrained to issuance for .tn names.
* The subordinate CA certificate contains no EKU extension so is not 
constrained to issuing certain types of certificates.
* Delegated 3rd parties are permitted. The CPS does not clearly state the BR 
requirement that domain validation may not be performed by a delegated third 
party.
* The only method of domain validation specified in the BR Self Assessment is 
the now deprecated 3.2.2.4.5. How and when will the Government of Tunisia 
comply with CA/Browser Forum ballot 218?
* The Government of Tunisia’s answer for wildcard domain validation in their BR 
Self Assessment implies the use of method 3.2.2.4.1, but they claim not to use 
that method in the same document.
* CPS section 4.9.2 does not permit a person who controls a domain name 
contained in a certificate to request revocation unless they are the Subscriber 
or the Subscriber's legal representative.

==Bad==
* Missing SAN entries: 
https://crt.sh/?cablint=25=5680=2017-01-01 This CA continues 
to misissue certificates, so the manual controls described earlier in this 
thread are inadequate.
* The current subordinate CA CPS is dated October-2016. The current root CPS is 
dated July-2015. Mozilla policy requires annual CPS updates.
* The CPS does not comply with the BR requirement to document support for 
Certificate Authority Authorization (CAA). Has CAA been implemented?
* The CPS does not describe how domain validation is performed and which of the 
BR methods are utilized as required by Mozilla policy section 2.2.
* The CPS claims in section 4.2.1 that the databases of regional IP address 
registries are used to verify domain control. Please explain how this is 
possible.

Next steps:
1. I would ask a representative of the Government of Tunisia to answer the 
above questions.
2. The CPS issues need to be corrected and new versions published.
3. Given the ongoing misissuance, I would not recommend approval of this 
request until pre-issuance linting has been implemented.

Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Fotis Loukos via dev-security-policy]

Hello,
I started reading your CP/CPS and I noticed that you do not use the
standard CA/B Forum terminology. Is this on purpose? Is it just a
translation issue?

Furthermore, I believe that the English Root CA CP/CPS should be added
to the bug, I can only find the translation of the SSL SubCA CP/CPS.

And just a final note, I can't seem to be able to access the mail sent
by Gerv the 15th of August (the one I'm replying to) at the google
groups thread
(https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wCZsVq7AtUY).
Maybe it got lost somehow and the CA contacts are using google groups to
get an update on their discussion.

Regards,
Fotis

On 15/08/2017 03:41 μμ, Gervase Markham via dev-security-policy wrote:
> On 03/08/17 08:01, Olfa Kaddachi wrote:
>> ==> Some of these controls are already in place (such as the field CN and 
>> Subject Alternative Name that does not contain a private IP address). 
> 
> That doesn't quite answer my question.
> 
> Let me ask another way: for how long has the Government of Tunisia CA
> been aware of the Baseline Requirements? From what date do you assert
> that you have been compliant with these requirements?
> 
>> 4-   Validation of the technical data included in the CSR: The RA operator 
>> checks :
>>
>> Digital Signature Algorithm: SHA256
>> Key Algorithm: RSA
>> Key Size: 2048
> 
> Why can such things not be checked programmatically? It seems you are
> opening yourselves up to the possibility of human error.
> 
>> Moreover, the NDCA is now implementing a new Managed PKI platform which will 
>> be in production by the end of September 2017.  For the moment, the only 
>> improvement done, is the printing of all the subject alternative names in 
>> the certificate for the RA operators, in addition to the other fields (CN, 
>> O, OU, mail) in such a way that they can visually check all the fields 
>> before the delivery of the certificate.
> 
> A visual check may not catch every problem. For example, would it catch
> a trailing space?
> 
>> >From what date would you say that your CA has been compliant with the CAB 
>> >Forum Baseline Requirements? 
>> ==> The TunRootCA2 and TunServerCA2 passed two successive external audit 
>> performed by LSTI. The last audit took place from 27th to 30th September 
>> 2016 in applying the relevant ETSI Technical Specifications ETSI TS 
>> 102042v2.4.1. 
> 
> And that audit includes a BR audit?
> 
> Did the audit report have any qualifications?
> 
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Gervase Markham via dev-security-policy]

On 03/08/17 08:01, Olfa Kaddachi wrote:
> ==> Some of these controls are already in place (such as the field CN and 
> Subject Alternative Name that does not contain a private IP address). 

That doesn't quite answer my question.

Let me ask another way: for how long has the Government of Tunisia CA
been aware of the Baseline Requirements? From what date do you assert
that you have been compliant with these requirements?

> 4-Validation of the technical data included in the CSR: The RA operator 
> checks :
> 
> Digital Signature Algorithm: SHA256
> Key Algorithm: RSA
> Key Size: 2048

Why can such things not be checked programmatically? It seems you are
opening yourselves up to the possibility of human error.

> Moreover, the NDCA is now implementing a new Managed PKI platform which will 
> be in production by the end of September 2017.  For the moment, the only 
> improvement done, is the printing of all the subject alternative names in the 
> certificate for the RA operators, in addition to the other fields (CN, O, OU, 
> mail) in such a way that they can visually check all the fields before the 
> delivery of the certificate.

A visual check may not catch every problem. For example, would it catch
a trailing space?

>>From what date would you say that your CA has been compliant with the CAB 
>>Forum Baseline Requirements? 
> ==> The TunRootCA2 and TunServerCA2 passed two successive external audit 
> performed by LSTI. The last audit took place from 27th to 30th September 2016 
> in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1. 

And that audit includes a BR audit?

Did the audit report have any qualifications?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Olfa Kaddachi via dev-security-policy]

Dear Gerv,
Given that some of these are BR requirements, why were these controls not in 
place already? 
==> Some of these controls are already in place (such as the field CN and 
Subject Alternative Name that does not contain a private IP address). 
In addition to that NDCA has implemented a procedure for the RA operators which 
include these sections:
1-  Validation of the Organization  

-   In case of a commercial  and private organization: The RA operator 
checks the web site http://www.registre-commerce.tn. Then, he inserts the Tax 
Identification Number to verify the existence of the organization.

-   In the case of a public organization : The RA operator checks the web 
site http://www.infojort.com. Then, he inserts the Tax Identification Number to 
verify the existence of the organization.
2-  Domain Validation :
For the National domains, the RA operator checks the web site of the Tunisian 
Internet Agency which is responsible of the management of the national domain 
".tn" and the IP addressing in Tunisia ( http://whois.ati.tn ).
For the international domains, the RA operator checks the international whois.
In both cases, the RA operator checks if the domain name is the property of the 
applicant.
3-  CSR Validation
The RA operator checks the CSR with this URL  
https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp





4-  Validation of the technical data included in the CSR: The RA operator 
checks :

Digital Signature Algorithm: SHA256
Key Algorithm: RSA
Key Size: 2048

5-  Validation of the data inserted in the CSR against the data filled in 
the form  :
Common name:
Organization:
Organizational unit:
City/locality:
State/province:
Country:
6-  Validation of the email : The RA operator checks if the email is in 
this form:
ad...@domaine.com
postmas...@domaine.com
administra...@domaine.com
webmas...@domaine.com
7-  Validation of the information related to the legal person and the 
subscriber  
8-  Phone Call to the webmaster of the server
Moreover, the NDCA is now implementing a new Managed PKI platform which will be 
in production by the end of September 2017.  For the moment, the only 
improvement done, is the printing of all the subject alternative names in the 
certificate for the RA operators, in addition to the other fields (CN, O, OU, 
mail) in such a way that they can visually check all the fields before the 
delivery of the certificate.

From what date would you say that your CA has been compliant with the CAB Forum 
Baseline Requirements? 
==> The TunRootCA2 and TunServerCA2 passed two successive external audit 
performed by LSTI. The last audit took place from 27th to 30th September 2016 
in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1. 
The audit was performed by LSTI as a full audit. This audit confirms the 
validity of the certificate N° 11140 issued on November 2015 and valid until 
November 2018. The next full audit will be performed from 11th to 15th of 
September 2017.

When will these improvements be implemented? And, given that these are only 
four possible ways a certificate can be messed up, what other checks are going 
to be implemented at the same time? 
==> These improvements have already been implemented by our service provider 
during this week. The tests will be done from 14th to 25th of August 2017.  The 
beginning of production is planned for the end of September after the audit.
We already have other checks besides those four in our information system such 
as checking the fields in the CSR. These checks are already implemented.
Olfa
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Gervase Markham via dev-security-policy]

Hi Olfa,

On 31/07/17 11:55, Olfa Kaddachi wrote:
> 2) The deficiencies identified in those controls after the misissuance of 
> each of these certificates are essentially:
> •controls on the field subject alternative names :
> o this field must not contains private addresses
> o this filed must not contain 127.0.0.1 address
> o this filed must not contain a  local FQDN
> o this field must at least contain the CN

Given that some of these are BR requirements, why were these controls
not in place already?

From what date would you say that your CA has been compliant with the
CAB Forum Baseline Requirements?

> 3) The implemented and planned improvements to the technical controls to 
> prevent these errors from happening again:

When will these improvements be implemented? And, given that these are
only four possible ways a certificate can be messed up, what other
checks are going to be implemented at the same time?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Olfa Kaddachi via dev-security-policy]

Hi Jonathan, 

Please find below the description of the technical and organizational controls 
required:

1) The currently process of certificates issuance is composed by 4 steps:
step 1: Registration process: 
This step consists of the verification of the following items:
•the subscriber identify   
•the accuracy of the certificate requests (RA is using currently this URL to 
check the CSR 
https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp)
•the possession of the domain names (who is, organization, validation 
phone,...) 
•
After that, the RA operator insert all the required data in the RA interface, 
theses controls are implemented:
•control of the syntax of the server name
•control of the email of the server administrator
•control of the identifier of the administrator
•check of the CSR

step2: Validation process:
In this step, another registration operator (different of the first one), check 
all the inserted data. This check consists of  the verification of inserted 
data against paper data. 
step3: Issuance of the certificate:
In this step, the only control consists of the check of the data in the CSR 
against the inserted data.  In the event of any error, the request is rejected.
step4: Check of the issued certificate:
In this step, another registration operator check the issued certificate before 
its delivery.

2) The deficiencies identified in those controls after the misissuance of each 
of these certificates are essentially:
•controls on the field subject alternative names :
o this field must not contains private addresses
o this filed must not contain 127.0.0.1 address
o this filed must not contain a  local FQDN
o this field must at least contain the CN

3) The implemented and planned improvements to the technical controls to 
prevent these errors from happening again:
The NDCA is implementing a new system (Managed PKI solution) which includes 
such controls in different fields (CN, mail of administrator, check of CSR, 
check of subject alternative names, ...).

Thanks
Olfa
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

For reference, I’ve added crt.sh links for the replacement certificates below.

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy 
>  wrote:
> 
> https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; 
> notAfter March 2017) issued by this CA which has a wildcard name in the 
> common name while the SAN contains specific domain names that would be 
> covered by the wildcard only. 
> 
> ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 
> 2016-03-21 when the CA discover the mistake in the SAN extension. A new 
> certificate is issued on the same day (2016-03-21) with the right SAN 
> (*.sonede.com.tn). See the certificate below:
> 

https://crt.sh/?id=15597407

> https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 
> 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 
> 127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name 
> certs with validity past November 2015.) 
> 
> ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an 
> IPAddress SAN of 127.0.0.1. The new certificate for the end entity 
> (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See 
> certificate below:

https://crt.sh/?id=180718609

> https://crt.sh/?id=79470561=cablint is a certificate for the internal 
> name 'adv-ail.calladvance.local' issued by this CA with a not Before of 2017. 
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=79470561=cablint. The certificate is revoked on 
> 28/07/2017 and replaced by a new certificate which does not contain  in SAN 
> extension the internal name "adv-mail.calladvance.local". See ertificate 
> below:

https://crt.sh/?id=180718608
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy 
>  wrote:
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new 
> certificate is issued by TunServerCA2.to this end entity.
> 
> ==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on 
> 2017-03-03 and issue a new one for the end entity 
> https://crt.sh/?id=99462700. The new certificate contains both names in SAN 
> (DNS=vpn.tunisieclearing.com and Nom DNS=vpn.tunisieclearing.tn). The CA, at 
> the time of issuance, has  verified that the Applicant had the right to use 
> and had the control of the both Domain Names.
> 
> ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 
> 2016-03-21 when the CA discover the mistake in the SAN extension. A new 
> certificate is issued on the same day (2016-03-21) with the right SAN 
> (*.sonede.com.tn). See the certificate below:
> 
> ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an 
> IPAddress SAN of 127.0.0.1. The new certificate for the end entity 
> (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See 
> certificate below:
> 
> ==> The CA proceeded to notify the end entity of the certificate 
> https://crt.sh/?id=79470561=cablint. The certificate is revoked on 
> 28/07/2017 and replaced by a new certificate which does not contain  in SAN 
> extension the internal name "adv-mail.calladvance.local". See ertificate 
> below:
> 
> Olfa Kaddachi

These incidents appear to demonstrate a lack of sufficient technical controls 
to prevent certificates from being issued with unvalidated and invalid data. 
Would you please describe:

1) the technical controls currently implemented in the issuance process;
2) the deficiencies identified in those controls after the misissuance of each 
of these certificates;
3) the implemented and planned improvements to the technical controls to 
prevent these errors from happening again.

Thanks,

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[kaddachi olfa via dev-security-policy]

https://crt.sh/?id=21813439 is a certificate issued by this CA which has a 
domain name in the common name but only an email address in the SAN. (The 
certificate has TLS server/client usage EKUs.) 

==> The CA proceeded to notify the end entity of the certificate 
https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new 
certificate is issued by TunServerCA2.to this end entity.


https://crt.sh/?id=99182607 is a revoked certificate issued by this CA which 
has a domain name in the common name which does not match the domain name in 
the SAN, which is for a different TLD. (A new certificate with both names in 
SANs, https://crt.sh/?id=99462700 , has a notBefore which appears to have 
around the same timestamp as the revocation.) 


==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on 
2017-03-03 and issue a new one for the end entity https://crt.sh/?id=99462700. 
The new certificate contains both names in SAN (DNS=vpn.tunisieclearing.com and 
Nom DNS=vpn.tunisieclearing.tn). The CA, at the time of issuance, has  verified 
that the Applicant had the right to use and had the control of the both Domain 
Names.

*

https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; 
notAfter March 2017) issued by this CA which has a wildcard name in the common 
name while the SAN contains specific domain names that would be covered by the 
wildcard only. 

==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 
2016-03-21 when the CA discover the mistake in the SAN extension. A new 
certificate is issued on the same day (2016-03-21) with the right SAN 
(*.sonede.com.tn). See the certificate below:

-BEGIN CERTIFICATE-
MIIGuTCCBKGgAwIBAgIQQVkWAyEXAyAwgwPw3/OEojANBgkqhkiG9w0BAQsFADB8
MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp
Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj
YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNjAzMjEwMDAwMDBaFw0x
NzAzMjAyMzU5NTlaMIHMMQswCQYDVQQGEwJUTjFBMD8GA1UECgw4U1RFIE5BVElP
TkFMRSBEIEVYUExPSVRBVElPTiBFVCBERSBESVNUUklCVVRJT04gREVTIEVBVVgx
KDAmBgNVBAsMH0RJUkVDVElPTiBDRU5UUkFMRSBJTkZPUk1BVElRVUUxGDAWBgNV
BAMMDyouc29uZWRlLmNvbS50bjEmMCQGCSqGSIb3DQEJARYXd2VibWFzdGVyQHNv
bmVkZS5jb20udG4xDjAMBgNVBAcMBVRVTklTMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAtUqxkjJGrnLQ+fx4vif+PV9FlwTByGoQ5F/2Kc67u9iM0zBt
ttkcUHzdwoSkPLaYKezT3FQhuE7c1BKRBfne95zmDJ6kKbvoehUG6niJP6qOQ5p2
aT3oHPI87e20SQPFvvZMSbDftDq9/cH/69d+NkSlfAvihks7hp/zZv9QDdxaZh/O
SfA12SRUy0/Q2n7VKnJrUPBK3Ydyl0KOS5p6LNxOUG4faJ9Fil3OO2b54etyMMcc
QTiDqwDUXMohR3KzCQpUD9RGba41Stqwj7PO25YtNJbSSfCq5Sn9nZn8K9iapIDQ
1uwLO+VJf2SwEZl4iZulAhmXLieq/lv+oZreWQIDAQABo4IB5DCCAeAwDAYDVR0T
AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMBoGA1UdEQQTMBGCDyouc29uZWRlLmNvbS50bjAfBgNVHSMEGDAWgBSH
q/dpS1D2YVf/P1uOHXDGomyqxjA9BgNVHR8ENjA0MDKgMKAuhixodHRwOi8vY3Js
LmNlcnRpZmljYXRpb24udG4vVHVuU2VydmVyQ0EyLmNybDB7BggrBgEFBQcBAQRv
MG0wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmNlcnRpZmljYXRpb24udG46ODA4
MDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL3B1Yi9U
dW5TZXJ2ZXJDQTIuY3J0MIGnBgNVHSAEgZ8wgZwwgZkGCGCGFAECBgEIMIGMMCwG
CCsGAQUFBwIBFiBodHRwczovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL2NwczBcBggr
BgEFBQcCAjBQMCwWJU5hdGlvbmFsIERpZ2l0YWwgQ2VydGlmaWNhdGlvbiBBZ2Vu
Y3kwAwIBARogaHR0cHM6Ly93d3cuY2VydGlmaWNhdGlvbi50bi9ycGEwDQYJKoZI
hvcNAQELBQADggIBABUXwoV4YIrF4SVRUsb/dPhCO0uxcyVylVGz2y+OIDIsuy+d
7yJl4gCeLsMIIexWVqupnx1qzX8LR6ZMpVWbTeie0EFOppBU6S1OcFvf+6kQ9FNa
RwCUn+fcYr5+NQRZD2OmfIeiqJ/vo0yNKQ2j5KENG1JZ8AgyeJ1RBK8IxAHNe9oE
sdqjxXL54fh6t4zxfgavaRv9dZo+Ph4udEq1Ea/dKXg0pfsM1/bVpO+V1yaiL+lk
fH/diGWUVV5HTlmtPCXU3idUKZytOWsP+NljHxQAmVzv38aAvvC9r2Dgc/MScCHP
b7iBDDfwZRVj78MIAjHlf5cOAUCAJUmEC0lXnBNSRKAmYThCr+SVuKrqcwGcq5+X
yNo46/ba6y/M/Q3TPCgDlFzgpxJ2Ox3jntSuA6qhLgJagC1HJce0wqAfCy4rAYuD
WpsGr0rm65DSYgr+MZlcp4UNE1M+plKl7rXClYg5lRVX1c4glYr9+Do05z49ZRHq
1C8LpHbBYkDVbz/EsuDLZ+Y1wpo4Nec+PEfKm/Tc6Cyfr8JmHOhJ/YmaRg2UBh2q
1PE3gKyb5SZmmLmFBgwO5G91EvQOCSyuI/s7bzP5ra392q7Z9iFzadETjGjflWEq
pMMUmphu3cCez871AUvDhMKKDlEdGob8Xw3RTwz485FuUdL8qb2vw36Jhhki
-END CERTIFICATE-


**

https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 
2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 
127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name 
certs with validity past November 2015.) 

==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an 
IPAddress SAN of 127.0.0.1. The new certificate for the end entity 
(mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See 
certificate below:

-BEGIN CERTIFICATE-
MIIGqTCCBJGgAwIBAgIQQVkWEhQXEhOUxb2pudH/dDANBgkqhkiG9w0BAQsFADB8
MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp
Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj
YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNjEyMTQwMDAwMDBaFw0x
NzEyMTMyMzU5NTlaMIGkMQswCQYDVQQGEwJUTjEOMAwGA1UEChMFQ0VQRVgxHzAd

Re: TunRootCA2 root inclusion request

[Charles Reiss via dev-security-policy]

On 07/19/2017 05:10 AM, Aaron Wu wrote:

- Tunisian Server Certificate Authority - TunServerCA2


https://crt.sh/?id=79470561=cablint is a certificate for the 
internal name 'adv-mail.calladvance.local' issued by this CA with a 
notBefore of 2017.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Charles Reiss via dev-security-policy]

On 07/19/17 05:10, Aaron Wu wrote:

- Tunisian Server Certificate Authority - TunServerCA2



https://crt.sh/?id=21813439 is a certificate issued by this CA which has 
a domain name in the common name but only an email address in the SAN. 
(The certificate has TLS server/client usage EKUs.)



https://crt.sh/?id=99182607 is a revoked certificate issued by this CA 
which has a domain name in the common name which does not match the 
domain name in the SAN, which is for a different TLD. (A new certificate 
with both names in SANs, https://crt.sh/?id=99462700 , has a notBefore 
which appears to have around the same timestamp as the revocation.)



https://crt.sh/?id=15126121 is an expired certificate (notBefore March 
2016; notAfter March 2017) issued by this CA which has a wildcard name 
in the common name while the SAN contains specific domain names that 
would be covered by the wildcard only.



https://crt.sh/?id=10975511 is an expired certificate with a notBefore 
of Oct 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress 
SAN of 127.0.0.1. (I believe that by 2014, the BRs prohibited issuing 
internal name certs with validity past November 2015.)

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy