On Wed, Dec 11, 2013 at 2:08 AM, Kathleen Wilson wrote:
> Additionally, this CA has a root renewal request in progress[3]. As with all
> root inclusion requests, the CA will be required to demonstrate compliance
> with the BRs before the request can be approved.
...
On Wed, Dec 11, 2013 at 2:30 AM
Am 2013-12-11 23:59, schrieb Gervase Markham:
> Look again. It seems that it now contains 1106 certificates (!), with
> widely varying revocation dates.
Can't confirm that for any of the following CRL DPs:
http://www.icp.minefi.gouv.fr/igca.crl (1 entry)
http://www.icp.minefi.gouv.fr/ac-racine.crl
On 10/12/13 06:20, Jan Schejbal wrote:
> The third sub-ca cert (Subject AC DGTPE Signature Authentification)
> includes a CRL DP for a CRL issued by sub-ca 2, validity 2011-09-09 to
> 2014-09-13. The CRL is empty.
Look again. It seems that it now contains 1106 certificates (!), with
widely varying
On Wed, Dec 11, 2013 at 1:49 AM, Samuel L wrote:
> Le 11/12/13 01:08, Kathleen Wilson a écrit :
>> Based on the list that Rob provided, there may be other domains that we
>> might consider including.
>> For example:
>> *.ac-martinique.fr
>> *.ac-creteil.fr
>> *.ac-orleans-tours.fr
>> *.education.f
On Tue, Dec 10, 2013 at 5:48 PM, Jan Schejbal wrote:
> The CA has all three trust bits. We definitely should remove the code
> signing trust bit.
I agree.
> Will this restriction also apply for S-MIME? If so, I
> think we can keep the S-MIME one.
What would the name constraint for S-MIME be? I
Le 11/12/13 01:08, Kathleen Wilson a écrit :
Based on the list that Rob provided, there may be other domains that we
might consider including.
For example:
*.ac-martinique.fr
*.ac-creteil.fr
*.ac-orleans-tours.fr
*.education.fr
*.ac-poitiers.fr
As this list includes domains from the ministry o
On 10. 12. 2013 20:29, Charles Reiss wrote:
> This list contains a bunch of RFC 1918 addresses (two under 10/8, around 111
> under 172.16/12, 9 under 192.168/16). This appears to contradict
> https://bug368970.bugzilla.mozilla.org/attachment.cgi?id=355447 (information
> gathering for inclusion of w
Am 2013-12-11 01:08, schrieb Kathleen Wilson:
> Constrain the currently-included IGC/A root certificate to a certain
> set of domains. I think the restriction needs to be along the lines
> of *.gouv.fr.
This sounds like a reasonable pragmatic approach for a short-term
solution to minimize impact o
On Tue, Dec 10, 2013 at 4:08 PM, Kathleen Wilson wrote:
> Constrain the currently-included IGC/A root certificate to a certain set of
> domains. I think the restriction needs to be along the lines of *.gouv.fr.
I think it might help to explain the rationale for the choice of *.gouv.fr:
ANSSI is
All,
I appreciate you sharing your findings and opinions about this incident
and CA.
Based on some of the CA responses noted in the January CA
Communication[1], I have thought about constraining CAs that are unable
to meet the timelines that have been provided regarding compliance with
the
On 12/10/13 8:39 , Jan Schejbal wrote:
> Am 2013-12-10 16:18, schrieb Rob Stradling:
>>
>> The larger file with more info is here...
>> https://sslanalyzer.comodoca.com/igca_server_certs.zip
>
> Thanks, very nice!
>
> These look interesting:
>
> 8f5d29f6ae0f6aa472268de463dd2e397ddd1b50
> 1972268
Starting from http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/ you can
get the CRL of the 2048bits IGC/A, and a page linking to 14 sub-CAs. Ignore the
4096bits IGC/A for now, it hasn’t been accepted by Mozilla yet.
Among those 14 sub-CAs, 4 don’t have any CRLDP:
- “AC racine Agriculture
On 12/10/13 7:18 , Rob Stradling wrote:
> On 10/12/13 14:46, Rob Stradling wrote:
>
>> I tried to send a larger file just now (with more info), but I'd
>> forgotten that this list has a 40KB limit on attachments.
>
> The larger file with more info is here...
> https://sslanalyzer.comodoca.com/igc
According to microsoft advisory
(http://technet.microsoft.com/en-us/security/advisory/2916652?altTemplate=SecurityAdvisoryPF),
the CA used to sign the rogue certificate is "AC DGTPE Signature
Authentification"
This certificate can be found here:
http://crl2.dgtpe.fr/AC_DGTPE_Signature_Authenti
Sent: Tuesday, December 10, 2013 7:10 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Revoking Trust in one ANSSI Certificate
I would suggest that there are 3 things for Mozilla to impress upon the
participants in the trusted store program:
1) Compliance with relevant specs
On 10/12/13 16:39, Jan Schejbal wrote:
Am 2013-12-10 16:18, schrieb Rob Stradling:
The larger file with more info is here...
https://sslanalyzer.comodoca.com/igca_server_certs.zip
Thanks, very nice!
Thanks. :-)
These look interesting:
8f5d29f6ae0f6aa472268de463dd2e397ddd1b50
1972268
C=F
Am 2013-12-10 16:18, schrieb Rob Stradling:
>
> The larger file with more info is here...
> https://sslanalyzer.comodoca.com/igca_server_certs.zip
Thanks, very nice!
These look interesting:
8f5d29f6ae0f6aa472268de463dd2e397ddd1b50
1972268
C=FR, O=Ministere education nationale (MENESR), OU=110 0
On Mon, Dec 9, 2013 at 2:17 PM, Jan Schejbal wrote:
>
> I would really love to see the explanation how someone accidentally
> issues and deploys a MitM Sub-CA...
>
I think it will turn out to be essentially the same reason that Microsoft
got burned with the Flame attack.
Just because an organiza
On 10/12/13 14:46, Rob Stradling wrote:
I tried to send a larger file just now (with more info), but I'd
forgotten that this list has a 40KB limit on attachments.
The larger file with more info is here...
https://sslanalyzer.comodoca.com/igca_server_certs.zip
Column 1: SHA-1(Certificate)
Colu
On 10/12/13 14:46, Rob Stradling wrote:
Hopefully it won't reject this .zip file...
Oh, it did. Maybe if I change the file extension from .zip to .txt...
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
PK u�C=�\�I ai igca_server_identit
On 10/12/13 00:48, Erwann Abalea wrote:
Le lundi 9 décembre 2013 23:15:01 UTC+1, Brian Smith a écrit :
One thing that would really help would be an attempt to document which
publicly-accessible websites are using certificates that chain (only)
to the ANSSI root. I heard the claim that most Frenc
Am 2013-12-10 12:09, schrieb Jan Schejbal:
> 5. Appears unable to operate a CA properly as per Erwann's mail (e.g.
> no valid CRLs).
I had a look at the CRLs of the certificates in the chain.
The first sub-ca cert in the chain (Subject MINEFI-AUTORITE DE
CERTIFICATION RACINE) includes a CRL DP w
I would suggest that there are 3 things for Mozilla to impress upon the participants in the trusted store program:1) Compliance with relevant specs and policies. This is important not only to ensure proper, secure interoperability but also to create a level playing field. As Tim Moses points out t
Am 2013-12-10 09:52, schrieb Erwann Abalea:
> I think ANSSI knows the duties associated to running a public CA, I'm
> pretty sure the different ministries don't.
I agree with the assumption that the ministries don't know the duties
associated with running a public CA.
Thus, ANSSI should never hav
On 12/10/2013 10:52 AM, From Erwann Abalea:
You're right, of course. Mozilla has twice expressed its concerns
about MITM certs linked to a public CA, and all public CAs including
IGC/A was told to perform some checks on the complete set of
certificates chaining to the root, reporting any deviat
Le mardi 10 décembre 2013 08:11:30 UTC+1, Eddy Nigg a écrit :
> On 12/10/2013 02:48 AM, From Erwann Abalea:
> > As Kathleen mentioned in bug 948175, governments need to vote budgets.
>
> :-) Issuing certs for google.com and other sites (assuming) without any
> validation has nothing to do with B
On 12/10/2013 02:48 AM, From Erwann Abalea:
As Kathleen mentioned in bug 948175, governments need to vote budgets.
:-) Issuing certs for google.com and other sites (assuming) without any
validation has nothing to do with BR compliance, budgets etc.
--
Regards
Signer: Eddy Nigg, StartCom Lt
Am 2013-12-09 22:12, schrieb Ryan Sleevi:
> According to https://wiki.mozilla.org/CA:Communications#January_10.2C_2013
> (see the Responses section), this CA has indicated that they do not expect
> to begin operating in full compliance to the Baseline Requirements and to
> Mozilla's 2.1 Inclusion P
Le lundi 9 décembre 2013 23:15:01 UTC+1, Brian Smith a écrit :
> One thing that would really help would be an attempt to document which
> publicly-accessible websites are using certificates that chain (only)
> to the ANSSI root. I heard the claim that most French public
> government websites actual
On 12/9/2013 9:42 AM, Kathleen Wilson wrote:
> Mozilla Security Blog post:
>
> https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/
>
> Google's blog post:
> http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certifi
any of that. Surely there
> is no reason to keep it secret, is there?
>
> *From: *Jan Schejbal
> *Sent: *Monday, December 9, 2013 1:19 PM
> *To: *mozilla-dev-security-pol...@lists.mozilla.org
> *Reply To: *jan.schejbal_n...@gmx.de
> *Subject: *Re: Revoking Trust in one ANSS
Brian, I was thinking it would be beneficial if ANSSI would provide a host:port that would have the bad chain installed. This allows for anyone to check if their browser has been updated to un-trust the intermediate. I make this suggestion in addition to the points you raise below, and I think it
Let's start with the basics: what is the cert subject, serial number, date info? None of the four browser notices provided any of that. Surely there is no reason to keep it secret, is there?
One thing that would really help would be an attempt to document which
publicly-accessible websites are using certificates that chain (only)
to the ANSSI root. I heard the claim that most French public
government websites actually use certificates that chain to a
different CA. That has led me to wo
>From the information we have to date, I think the CAs that try hard to run a
>conformant operation can be justifiably upset that this behaviour is tolerated.
All the best. Tim.
> On Dec 9, 2013, at 4:19 PM, "Eddy Nigg" wrote:
>
> On 12/09/2013 11:12 PM, From Ryan Sleevi:
>> According to https
On 12/09/2013 11:12 PM, From Ryan Sleevi:
According to
https://wiki.mozilla.org/CA:Communications#January_10.2C_2013 (see the
Responses section), this CA has indicated that they do not expect to
begin operating in full compliance to the Baseline Requirements and to
Mozilla's 2.1 Inclusion Poli
Am 2013-12-09 22:03, schrieb Eddy Nigg:
> Is this CA compliant to the BR and Mozilla's CA policy and requirements?
They didn't do a very good job at Section 14.1.1 of the BR if they
allowed anyone who would "accidentally" issue a MitM cert access to a SubCA.
Anyways, I'm looking forward to more d
On Mon, December 9, 2013 1:03 pm, Eddy Nigg wrote:
> On 12/09/2013 08:09 PM, From Kathleen Wilson:
> > On 12/9/13 9:42 AM, Kathleen Wilson wrote:
> >> Mozilla Security Blog post:
> >>
> >> https://blog.mozilla.org/security/2013/12/09/rev
On 12/09/2013 08:09 PM, From Kathleen Wilson:
On 12/9/13 9:42 AM, Kathleen Wilson wrote:
Mozilla Security Blog post:
https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/
Google's blog post:
http://googleonlinesecurity.blogspot.com/2013/12/further-impr
Hi,
could we please have the certificates/chains involved in this, and could
the corresponding bug (I assume there is one) maybe be made public?
Especially of interest would be the dates when the certificates were
issued, when they were first used for MitM, when this was reported to
the CA by Googl
On 12/9/13 9:42 AM, Kathleen Wilson wrote:
Mozilla Security Blog post:
https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/
Google's blog post:
http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certificate.html
The CA
Mozilla Security Blog post:
https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/
Google's blog post:
http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certificate.html
The CA's public statement:
http://www.ssi.gouv.fr/fr/menu/
42 matches
Mail list logo
