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 the
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
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 s
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 t
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:
y-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
>
.@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 Tun
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 Free
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 e
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
_
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
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.
>
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://mis
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 devel
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 usin
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 decisio
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 inclusi
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 th
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:
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 substitu
> 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
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.mozil
> 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
> 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 mi
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.
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
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 Se
Hi,
please find at this URL the translation of the root CP/CPS.
http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf
Best regards
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-
Hello,
It is mentioned in the page 9 section 1.1 that :
The CA servers complies with the current version of the "Baseline Requirements
for the Issuance and Management of Publicly-Trusted Certificates" (BR)
published at http://www.cabforum.org.
In the event of inconsistency between this document
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
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 C
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 proce
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
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
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 wildc
> 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.
>
> ==>
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
On 07/19/2017 05:10 AM, Aaron Wu wrote:
- Tunisian Server Certificate Authority - TunServerCA2
https://crt.sh/?id=79470561&opt=cablint is a certificate for the
internal name 'adv-mail.calladvance.local' issued by this CA with a
notBefore of 2017.
_
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.)
htt
39 matches
Mail list logo
