Revoking Trust in one ANSSI Certificate

[Kathleen Wilson]

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/actualites/suppression-d-une-branche-de-l-igc-a.html
http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.html


Kathleen

[Kathleen Wilson]

Microsoft's security advisory:
http://technet.microsoft.com/en-us/security/advisory/2916652

Opera's security blog post:
http://blogs.opera.com/security/2013/12/certificate-update/

[Jan Schejbal]

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 Google, and when the CA revoked the certificate.

>From what I understood, the hierarchy was as follows:

ANSSI
+-Treasury Sub-CA
+-MitM-CA (installed on MitM device)
+-Fake endpoint certificates

Is this assumption correct? If so:
Was the "Treasury Sub-CA" revoked, or only the "MitM-CA"?
Which of these certs are the ones blacklisted by Mozilla?

The publicly available information about this is currently quite
limited. Having a meaningful debate on that basis is difficult.


We already had a similar case once - Trustwave. The differences are that
they admitted it before getting caught, and that since that incident,
everyone remotely involved in PKI management should know that this is
something you don't do.

I would really love to see the explanation how someone accidentally
issues and deploys a MitM Sub-CA...

Kind regards,
Jan

[Eddy Nigg]

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-improving-digital-certificate.html
>>
>>
>>
>> The CA's public statement:
>> http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html
>>
>>
>> http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.html
>>
>>
>

> Microsoft's security advisory:
> http://technet.microsoft.com/en-us/security/advisory/2916652
>
> Opera's security blog post:
> http://blogs.opera.com/security/2013/12/certificate-update/
>
>

Well well....any actions applied upon the CA to improve controls in
order to prevent another such occurrence? Is this CA compliant to the BR
and Mozilla's CA policy and requirements? Any bug to track that?

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Ryan Sleevi]

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/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/actualites/suppression-d-une-branche-de-l-igc-a.html
> >>
> >>
> >> http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.html
> >>
> >>
> >

> > Microsoft's security advisory:
> > http://technet.microsoft.com/en-us/security/advisory/2916652
> >
> > Opera's security blog post:
> > http://blogs.opera.com/security/2013/12/certificate-update/
> >
> >
>

> Well well....any actions applied upon the CA to improve controls in
> order to prevent another such occurrence? Is this CA compliant to the BR
> and Mozilla's CA policy and requirements? Any bug to track that?
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>

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 Policy until Dec 2015/January 2016.

[Jan Schejbal]

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 detailed reports of what happened
and answers to the questions in my last mail.

Kind regards,
Jan

--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...

[Eddy Nigg]

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 Policy until Dec 2015/January 2016.

Thanks Ryan - then we probably should understand what Mozilla does or
intends to do in such cases. Maybe this shows that something must be
done (when we are assuming that by today every CA is compliant already
and this should not be possible according to BR AND Mozilla's requirements).

[Tim Moses]

>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" <eddy...@startcom.org> wrote:
>
> 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 Policy until Dec 2015/January 2016.
>

> Thanks Ryan - then we probably should understand what Mozilla does or intends to do in such cases. Maybe this shows that something must be done (when we are assuming that by today every CA is compliant already and this should not be possible according to BR AND Mozilla's requirements).
>

> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Brian Smith]

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 wonder how much the ANSSI root is
actually used by public websites. Having a list of domains that use
certs that chain to ANSSI root is likely to have some significant
bearing on the decisions about what to do. But, it will be a while
before I would have time to compile such a list.

I think it would also help to document in this thread the ways we know
that ANSSI is not complying with our CA program. Lack of OCSP AIA URI
in the certificates is one example. Are there other ways that ANSSI is
non-compliant?

Cheers,
Brian

On Mon, Dec 9, 2013 at 1:18 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> 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 Policy until Dec 2015/January 2016.
>
>

> Thanks Ryan - then we probably should understand what Mozilla does or
> intends to do in such cases. Maybe this shows that something must be done
> (when we are assuming that by today every CA is compliant already and this
> should not be possible according to BR AND Mozilla's requirements).
>
>

> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[fhw...@gmail.com]

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?

[fhw...@gmail.com]

‎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's fair to ask this of any CA that behaves badly.

From: Brian Smith Sent: Monday, December 9, 2013 4:15 PM To: Eddy Nigg Cc: mozilla-dev-s...@lists.mozilla.org Subject: Re: Revoking Trust in one ANSSI Certificate

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 wonder how much the ANSSI root is
actually used by public websites. Having a list of domains that use
certs that chain to ANSSI root is likely to have some significant
bearing on the decisions about what to do. But, it will be a while
before I would have time to compile such a list.

I think it would also help to document in this thread the ways we know
that ANSSI is not complying with our CA program. Lack of OCSP AIA URI
in the certificates is one example. Are there other ways that ANSSI is
non-compliant?

Cheers,
Brian

On Mon, Dec 9, 2013 at 1:18 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> 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 Policy until Dec 2015/January 2016.
>
>

> Thanks Ryan - then we probably should understand what Mozilla does or
> intends to do in such cases. Maybe this shows that something must be done
> (when we are assuming that by today every CA is compliant already and this
> should not be possible according to BR AND Mozilla's requirements).
>
>

> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> XMPP: star...@startcom.org
> Blog: http://blog.startcom.org/
> Twitter: http://twitter.com/eddy_nigg
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Brian Smith]

See https://www.imperialviolet.org/binary/anssi-chain.txt.

This is the part of the chain that Google is releasing.

On Mon, Dec 9, 2013 at 2:39 PM, <fhw...@gmail.com> wrote:

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

> *From: *Jan Schejbal
> *Sent: *Monday, December 9, 2013 1:19 PM
> *To: *mozilla-dev-s...@lists.mozilla.org
> *Reply To: *jan.sche...@gmx.de
> *Subject: *Re: Revoking Trust in one ANSSI Certificate

>
> 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 Google, and when the CA revoked the certificate.
>
> From what I understood, the hierarchy was as follows:
>
> ANSSI
> +-Treasury Sub-CA
> +-MitM-CA (installed on MitM device)
> +-Fake endpoint certificates
>
> Is this assumption correct? If so:
> Was the "Treasury Sub-CA" revoked, or only the "MitM-CA"?
> Which of these certs are the ones blacklisted by Mozilla?
>
> The publicly available information about this is currently quite
> limited. Having a meaningful debate on that basis is difficult.
>
>
> We already had a similar case once - Trustwave. The differences are that
> they admitted it before getting caught, and that since that incident,
> everyone remotely involved in PKI management should know that this is
> something you don't do.
>
> I would really love to see the explanation how someone accidentally
> issues and deploys a MitM Sub-CA...
>
> Kind regards,
> Jan

[David E. Ross]

See bug #948175 at <https://bugzilla.mozilla.org/show_bug.cgi?id=948175>.

--
David E. Ross
<http://www.rossde.com/>

Where does your elected official stand? Which
politicians refuse to tell us where they stand?
See the non-partisan Project Vote Smart at
<http://votesmart.org/>.

[Erwann Abalea]

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 actually use certificates that chain to a
> different CA. That has led me to wonder how much the ANSSI root is
> actually used by public websites. Having a list of domains that use
> certs that chain to ANSSI root is likely to have some significant
> bearing on the decisions about what to do. But, it will be a while
> before I would have time to compile such a list.

Working on such a list on my spare time. Unfortunately, it's not a small hierarchy.

> I think it would also help to document in this thread the ways we know
> that ANSSI is not complying with our CA program. Lack of OCSP AIA URI
> in the certificates is one example. Are there other ways that ANSSI is
> non-compliant?

1024bits TLS certs (still recently), sequential serial numbers+SHA1. Some first-level sub-CAs (i.e. just under the root) don't have a valid CRLDP URI pointing to a downloadable, non-expired CRL.

As Kathleen mentioned in bug 948175, governments need to vote budgets.

[Jan Schejbal]

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 Policy until Dec 2015/January 2016.

Until this, I was willing to give them the benefit of doubt and hear the
explanation for the misissuance. However, given that this CA is unable
to fulfill basic requirements and doesn't intend to be able to do so for
two more years, despite the announcement already being a year old, I
think this is neither necessary nor appropriate. The recent events have
demonstrated that this CA has much more serious issues than some paperwork.

The cert chain <https://www.imperialviolet.org/binary/anssi-chain.txt>
published recently convinces me further that this CA needs to go ASAP.
One important change in the inclusion policy is that SubCAs need to be
technically constrained or publicly disclosed and audited. This is to
prevent exactly what happened here. We have now discovered a chain of
*four* unconstrained Sub-CAs, and the CA has only requested blocking of
the last one. We don't know how many other unconstrained Sub-CAs this CA
has created, and they are obviously not being handled well.

Erwann has pointed out other egregious examples of non-compliance.

The number of sites using the CA could be an argument in favor of
removal if it is low (since that would mean the CA provides little
benefit to our users), but I think the reasons mentioned above are
already much more than we need.

The level of usage should absolutely not be an argument against removal.
It certainly isn't "too big to fail" (i.e. it won't "break the web" for
the regular user), and the violations are egregious enough that we
cannot tolerate them.



Also, we may want to set hard deadline in future CA communications,
which will lead to removal of the CA if ignored. This should also be
applied to the already announced policy upgrade. Does six months from
the announcement that there is now a hard deadline sound reasonable for
compliance (not for compliance and audit)? The ones that did specify a
date would stay within the range except for:

- IGC/A (the CA being discussed here, end 2015)
- Hongkong Post (mid 2015)
- RSA ValiCert (end 2014)

I suspect that one of the reasons why the transition is taking so long
is because we tolerate it. If the CAs *had* to, I think they would
manage to do it in an acceptable timeframe.

[Eddy Nigg]

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.

[Erwann Abalea]

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 BR compliance, budgets etc.

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

But budgets are needed to change all the procedures, perform internal audits, change software, run training programs, etc. I think it's what ANSSI expressed in their response to Mozilla. There's at least 12 first-level sub-CAs each attributed to a different public entity (MINEFI is one of them), and who knows how many sub-CAs each one of them has...
I think ANSSI knows the duties associated to running a public CA, I'm pretty sure the different ministries don't.

[Eddy Nigg]

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 deviation. But
> budgets are needed to change all the procedures, perform internal
> audits, change software, run training programs, etc.

From
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

for a certificate to be used for SSL-enabled servers, the CA takes
reasonable measures to verify that the entity submitting the
certificate signing request has registered the domain(s) referenced
in the certificate /or/ has been authorized by the domain registrant
to act on the registrant’s behalf;


It's been there for how many years now? It's not about MITM, it's really
about doing the bare minimum - if a CA does that it never lets a
certificate be used knowingly for MITM purpose. If hasn't done that up
to now due to budget constraints or whatever other reasons, I suggest to
take measures accordingly.

[Jan Schejbal]

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 have issued them Sub-CA certs, since they are
unable to run one correctly.

What else does a CA need to do in order to be removed?

This CA:

1. Has stated that it does not intend to comply with current policies
for another two years, making it a total of three years for compliance.
This is by far the longest of all CAs in the program.

2. Is not just having trouble with some minor details of the policy,
but is violating several important requirements (e.g. 1024 bit certs,
randomness for SHA-1 as per Erwann's mail) including ones critical to
prevent issues like the one that happened now (audit/disclosure of Sub-CAs).

3. Has had a Sub-CA misissue for MitM purposes. This had to be detected
and reported by a third party, not the CA itself.

4. Is organizationally unable to implement requirements in a timely
manner. This is not an excuse, it is a reason not to be a CA. If they
cannot operate a CA properly, then they cannot operate a CA.

5. Appears unable to operate a CA properly as per Erwann's mail (e.g.
no valid CRLs).

I'd say that once a second person has verified the issues reported by
Erwann, we should remove the trust bits.

[fhw...@gmail.com]

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 the CA's that are "less diligent" do not deserve the same treatment as those who are. As a collective I think we do a decent job on this.

2) Establish and maintain trust. This means going beyond strict compliance and behaving in ways that demonstrate a commitment to security and privacy and respect for individual liberties. (Yes, I ask for a lot.). Obviously this one is very difficult in light of NSA, GCHQ, etc. bully tactics but it's important nonetheless. I imagine this is an area we'll be spending more time on. 

3) Financial impact to "the Internet". I don't know if anyone talks about this or has performed any studies? Basically, this mistake by ANSSI just cost untold millions of dollars of Mozilla, the other browser vendors, cert users, and the individual users and IT departments who must upgrade their browsers (to say nothing of all non-browser applications that are affected, too). I think Mozilla rightfully has a responsibility to itself and the broader Internet to protect and limit the financial costs of mistakes like this, and can place tighter controls ‎on participating CA's accordingly. 

Plus, I would argue that "upgrade your browser because someone made a mistake" hardly counts as a "best practice".

From: Jan Schejbal Sent: Tuesday, December 10, 2013 5:10 AM To: mozilla-dev-s...@lists.mozilla.org Reply To: jan.sche...@gmx.de

Subject: Re: Revoking Trust in one ANSSI Certificate

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.

[Jan Schejbal]

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 which provides a CRL issued by
the root, valid from 2013-12-01 through 2014-01-08. This CRL contains
one certificate with a revocation date in 2008.

The second sub-ca cert (Subject AC Racine DGTPE) includes a CRL DP for a
CRL issued by sub-ca 1, validity 2013-06-04 to 2015-06-04. The CRL is empty.

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.

The fourth and final sub-ca cert (Subject AC DG Trï¿œsor SSL), does not
contain a CRL DP.

Thus, if I understand it correctly, the CA cannot effectively revoke the
"Trï¿œsor" Sub-CA without revoking other Sub-CAs. Further, any revocation
will have limited effectiveness for at least one month, since signed
CRLs valid until then already exist for the entire chain. Even then, the
CA would need to revoke the MINEFI Sub-CA - otherwise, the revocation
will have limited effectiveness for many more months.

No OCSP responders are specified in the certificates.

Am I correct in the assumption that this means that the only way this CA
can deal with Sub-CA compromises effectively is asking for an emergency
update of all software relying on the certificates?
(Even under the assumption that software does check CRLs, that is.)


By the way, CAs were informed in February 2012 that they will need to
comply with v1 of the CAB BR by July 2012. These requirements already
state that OCSP is mandatory effective January 2013. They also
explicitly prohibit CRLs with nextUpdate values more than 12 months from
the thisUpdate value. Such a CRL was issued in 2013, i.e. long after the
effective date of the BR.

The 2011 audit statement
<https://bug666771.bugzilla.mozilla.org/attachment.cgi?id=661038>
appears to claim that they fulfill the 1.0 BR, however, they seem to
have audited themselves?!?

[Rob Stradling]

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 French public
>> government websites actually use certificates that chain to a
>> different CA. That has led me to wonder how much the ANSSI root is
>> actually used by public websites. Having a list of domains that use
>> certs that chain to ANSSI root is likely to have some significant
>> bearing on the decisions about what to do. But, it will be a while
>> before I would have time to compile such a list.
>
> Working on such a list on my spare time. Unfortunately, it's not a small hierarchy.

Attached is a list of server identities (SAN->dNSNames, SAN->iPAddresses
and Subject->CNs) from all the certs I can find that chain only to the
"CN = IGC/A" Root and that would be trusted for server authentication by
browsers.

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. Hopefully it
won't reject this .zip file...

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Rob Stradling]

On 10/12/13 14:46, Rob Stradling wrote:
<snip>

> Hopefully it won't reject this .zip file...

Oh, it did. Maybe if I change the file extension from .zip to .txt...

[Rob Stradling]

On 10/12/13 14:46, Rob Stradling wrote:
<snip>

> 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)
Column 2: Entry ID in the Google CT Pilot Log
Column 3: Issuer Name
Column 4: Server Identity (SAN->dNSName, SAN->iPAddress or Subject->CN)

[Phillip Hallam-Baker]

On Mon, Dec 9, 2013 at 2:17 PM, Jan Schejbal <jan.sche...@gmx.de>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 organization has PKI expertise does not mean that it is
evenly shared in the organization or that everyone understands what the
constraints are.

The organization does not have managing crypto as its primary goal so the
processes that manage the CA do not include awareness of current crypto
affairs as a requirement.

I have similar concerns about DANE. The expectations that are placed on the
registries and registrars are quite interesting.

--
Website: http://hallambaker.com/

[Jan Schejbal]

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 043 015, CN=AC
Infrastructures
your.server.address.com

899ec6db4ad070052aee3311de924e3dd3e995df
1973335
C=FR, O=Ministere education nationale (MENESR), OU=110 043 015, CN=AC
Infrastructures
your.server.address.com

For some reason, I have doubts about the quality of domain validation
performed in these cases...

I don't have a Certificate Transparency client set up - does anyone want
to check if these have already been revoked?

[Rob Stradling]

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=FR, O=Ministere education nationale (MENESR), OU=110 043 015, CN=AC
> Infrastructures
> your.server.address.com
>
> 899ec6db4ad070052aee3311de924e3dd3e995df
> 1973335
> C=FR, O=Ministere education nationale (MENESR), OU=110 043 015, CN=AC
> Infrastructures
> your.server.address.com
>
> For some reason, I have doubts about the quality of domain validation
> performed in these cases...
>
> I don't have a Certificate Transparency client set up - does anyone want
> to check if these have already been revoked?

Those 2 certs are below. Neither of them are listed on the CRL. No
OCSP service is available.

-----BEGIN CERTIFICATE-----
MIIGLDCCBBSgAwIBAgIRAKY79mv3iHdDwZFAYXkqPXEwDQYJKoZIhvcNAQEFBQAw
cTELMAkGA1UEBhMCRlIxLzAtBgNVBAoTJk1pbmlzdGVyZSBlZHVjYXRpb24gbmF0
aW9uYWxlIChNRU5FU1IpMRQwEgYDVQQLEwsxMTAgMDQzIDAxNTEbMBkGA1UEAxMS
QUMgSW5mcmFzdHJ1Y3R1cmVzMB4XDTEyMDkxMzE1MzEyNFoXDTE0MDkxMzE1MzEy
NFowgYkxCzAJBgNVBAYTAkZSMS8wLQYDVQQKEyZNaW5pc3RlcmUgRWR1Y2F0aW9u
IE5hdGlvbmFsZSAoTUVORVNSKTEUMBIGA1UECxMLMTEwIDA0MyAwMTUxEzARBgNV
BAsTCmFjLWNyZXRlaWwxHjAcBgNVBAMTFXBhc3RldXIuYWMtY3JldGVpbC5mcjCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOXR36l7XukmNXJentWgPbkQ
8cmjFLo9W2cX4rHoSqlZVs17MMZuqjHV/uNEPZ7mBS6KEn1mcES59UR9OjwM2bqV
PO+MBoOF3X1NMvWZxk5rz7+seDbRhA2vLX7TWO0hGYydRncnMAvuaEyG4xW/B5ls
kH0H5MvDgoR0nEbs97Pq8TVMxJzouCcIYZkFy+voIWy4LmYbBGdMjjlrythU07bh
P8aA+VRTV/sE/66qpfbhPAfTJ5ObTSwyBfwklYOVxTUCcNNkSexyxXxvypzVwswf
XMWbdoVJD0nH0ZXmOfUjcoACjfwll2Tbi9lAqGEn+2htaM5NPUgYzUnz165uhY0C
AwEAAaOCAaQwggGgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA8GA1UdDwEB/wQFAwMH
oAAwIgYDVR0RBBswGYIXeW91ci5zZXJ2ZXIuYWRkcmVzcy5jb20wSwYIKwYBBQUH
AQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vd3d3LmlnYy5lZHVjYXRpb24uZnIv
SW5mcmFzdHJ1Y3R1cmVzLmNydDAfBgNVHSMEGDAWgBS+OCJ/ckap1oQVn9XIKH9c
swIgyzAaBgNVHSAEEzARMA8GDSsGAQQBgZ5mRQEBBAEwgaoGA1UdHwSBojCBnzCB
nKCBmaCBloYwaHR0cDovL2NybDEuaWdjLmVkdWNhdGlvbi5mci9JbmZyYXN0cnVj
dHVyZXMuY3JshjBodHRwOi8vY3JsMi5pZ2MuZWR1Y2F0aW9uLmZyL0luZnJhc3Ry
dWN0dXJlcy5jcmyGMGh0dHA6Ly9jcmwzLmlnYy5lZHVjYXRpb24uZnIvSW5mcmFz
dHJ1Y3R1cmVzLmNybDAdBgNVHQ4EFgQUokigRWpet5us9VhSm0zEHlJV41swDQYJ
KoZIhvcNAQEFBQADggIBAI3WB2CB+AUMIiCIcHo1c5pwwqW7cDVe/rkkNkaAdu7G
r6uLWEVAiolN3UnMgljEb121RLdUx8Tmnt55B7V+YyIeugdoix9P4O0ZvNHBRJQS
mEJAlX72Qnjy4JwY/fG0PIqyStEDpk+qg2ydxt5e3mm9URpWpfpgQ82oKWaWhIIK
1MSc2kJGeXEj+TnqLEWRWjt+3NzUpiRrXHCVB70pjZDmb9B6rD/8Fi52UufEMBZa
HDVDKL1CQ18UDRyQfwQMP0Y0rl3RXzzDlHDNZoYXOnQBCN1EeIXYP48DJChVGgtt
UgY9vPtE5fKzjJHDN04PP2CvG/KxbjWI3Zh3LH7+4pPVkBrTqLUK/yVbV5gM+w1d
7IlL8VofC/zo9vkRB8In/8+lVpQpY5cXMMrIdKU07kTAz2FRZ1zzqjYRJd4kDOlV
umYCMOSqN/EyUVbSRyP8ABnhHhDShAF7gVBwv+hJsRNKZIAbOPuoaHIPALqvDWJq
JbzVdqkiJFgbiKDSk7PG8/OCMme2kRjLzdAlcTByQLKC/6Rl4Xk9iM94l5PmYbAA
6+38UNwWi89jnoPLjgIqnVpF0cRGiqy4heGCZ2LoPR5Yodjj8g8sYwnqKqbfJ6bP
ShOfO0YQe+NOfhrxhNY5JxzSwrh4gkVIVxdGx8a3FOXAN3tdhHzfqECJ/Vh2o+PN
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIGLjCCBBagAwIBAgIRAKW7AnXELc3/2P8z6/f75hUwDQYJKoZIhvcNAQEFBQAw
cTELMAkGA1UEBhMCRlIxLzAtBgNVBAoTJk1pbmlzdGVyZSBlZHVjYXRpb24gbmF0
aW9uYWxlIChNRU5FU1IpMRQwEgYDVQQLEwsxMTAgMDQzIDAxNTEbMBkGA1UEAxMS
QUMgSW5mcmFzdHJ1Y3R1cmVzMB4XDTEyMDkwNTE1NTYyMVoXDTE0MDkwNTE1NTYy
MVowgYsxCzAJBgNVBAYTAkZSMS8wLQYDVQQKEyZNaW5pc3RlcmUgRWR1Y2F0aW9u
IE5hdGlvbmFsZSAoTUVORVNSKTEUMBIGA1UECxMLMTEwIDA0MyAwMTUxETAPBgNV
BAsTCGFjLXJlaW1zMSIwIAYDVQQDExllbnQuY2xnLWR1cnV5LmFjLXJlaW1zLmZy
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwwdCuYad1Vx67GzmmGTj
kx5F2aLiwpwnDEVNZp8r+zRq+TlaQ5U6tXDNAegQTMfTLvvk8y87Ar7PynJ/3KJM
MNnkJB58MMvu/i+dkXgQxaoGsvqbaaNDdNahLHIwNDYdCVi9EjlVLowv3KX5tENL
Ji0QMEKyelxJpNCpfzTt+NwOmgg7Jw1hfQdSHqWRqut/hwq+e8Zrb/GodCY8I+AK
TZKX3rnajAAB5GonpmVejeBgOtijywYfVKl2F5NbuT/3uTHRO6CKb5aQyXX1S5Zf
HQwXQUocBo9gVm99wzocfuuhXDl/0lqmKqfZhHXSqO3WbADFDUfViLj/kiQF+pxv
mQIDAQABo4IBpDCCAaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDwYDVR0PAQH/BAUD
AwegADAiBgNVHREEGzAZghd5b3VyLnNlcnZlci5hZGRyZXNzLmNvbTBLBggrBgEF
BQcBAQQ/MD0wOwYIKwYBBQUHMAKGL2h0dHA6Ly93d3cuaWdjLmVkdWNhdGlvbi5m
ci9JbmZyYXN0cnVjdHVyZXMuY3J0MB8GA1UdIwQYMBaAFL44In9yRqnWhBWf1cgo
f1yzAiDLMBoGA1UdIAQTMBEwDwYNKwYBBAGBnmZFAQEEATCBqgYDVR0fBIGiMIGf
MIGcoIGZoIGWhjBodHRwOi8vY3JsMS5pZ2MuZWR1Y2F0aW9uLmZyL0luZnJhc3Ry
dWN0dXJlcy5jcmyGMGh0dHA6Ly9jcmwyLmlnYy5lZHVjYXRpb24uZnIvSW5mcmFz
dHJ1Y3R1cmVzLmNybIYwaHR0cDovL2NybDMuaWdjLmVkdWNhdGlvbi5mci9JbmZy
YXN0cnVjdHVyZXMuY3JsMB0GA1UdDgQWBBT7TSQQv4Nh8CPco5QlwO20BRTE2DAN
BgkqhkiG9w0BAQUFAAOCAgEAIkmjAGsLHYOD0onfspxPE/mh9rkyekpTI53vkCKM
GdeIFcp18eXq4APQOy+LKsgvjupcRQFwNP9sbbVm54caDwYScYJ6tUkuISTkpBzI
KXnkSG3FlGJG+ABeLe8qhRbRjE0W7xc6pQ2rUnEY0snVwFDIeU1PwkErfrJX2ZW3
5WP0e7Mh2AzGKdS+l58urWq9XuANFFHV5+wvxNXXxphMvDUo0ugl/EvCwmSnjAgt
+V2l8VyqblQEDT8XFj9l4Znqs3ZaaMKfzKaua0dtsfDTwoz226p+stAodY77dglf
x++BqfEI/TVaPDtJ068BrXqISSjcUD86ittdIyUkpbLO9CuyST8dkIkuYEbdN66D
5O4hnxMsWEmtKNLyd/8TVqFJRfh9aObPiRhhOpQ6mnP+dXwPi2zQkhX7cqPaEB/w
rqqQKoKDeHvoyJoO36K1RHXdcGu3gXuyMKL14uG/A0rl0kBoHNw6I82H3yMS2X4c
c4IR0UFIB/UqbgBsjFXaMBDINdNEHPTKvN/49ZMlKJcnXYe8rTDNvtAX0bWdY9zl
/zsHr/MZ6nRGdB5rBvd7VYKcrNE9WLq4vhYKYiiETob73bmzijfr6sUZ9XAcJqaz
sYg3hAdI6+1cPLpBwKG7ojXszh4sC9bfLDIYgK47WmSosxkD9x7XuPZB2NkG1c1S
IEQ=
-----END CERTIFICATE-----

[end...@gmail.com]

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_Authentification.cer
This certificate is signed by:
http://crl2.dgtpe.fr/AC_Racine_DGTPE.cer
Itself signed by:
http://crl2.dgtpe.fr/MINEFI_AUTORITE_DE_CERTIFICATION_RACINE.cer
Which is used to pay taxes online among other things.

The associated CRL can be found on the same site:
http://crl2.dgtpe.fr/AC_DGTPE_Signature_Authentification.crl

You will see that two dozens certificates have been revoked since the Google announcement.

[Charles Reiss]

On 12/10/13 7:18 , Rob Stradling wrote:
> On 10/12/13 14:46, Rob Stradling wrote:
> <snip>
>> 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)
> Column 2: Entry ID in the Google CT Pilot Log
> Column 3: Issuer Name
> Column 4: Server Identity (SAN->dNSName, SAN->iPAddress or Subject->CN)
>

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 what I think is this root; see the private IPs
under "problematic practices" section).

[Erwann Abalea]

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”
- “AC Ministère de la Justice” (expired since Nov 2011)
- “AC Direction Générale de l’Aviation Civile (DGAC)” (expired since Sep 2013)
- “AC Port autonome de Marseille (PAM)” (expired since Sep 2013)

One points to an unreachable CRL: “AC racine Gendarmerie nationale” (unresolved FQDN).

And one points to an expired CRL: “AC racine Pm-SGDN” (nearly 1 year old).

Looking into University of Michigan data (https://scans.io) reveals:
- 60 TLS certificates under “AC racine Agriculture”
- 1 since-long expired TLS certificate under “AC Ministère de la Justice”
- no certificate under “AC Direction Générale de l’Aviation Civile (DGAC)”
- 31 TLS certificates under “AC Port autonome de Marseille (PAM)”
- 2 TLS certificates under “AC racine Gendarmerie nationale”
- no certificate under “AC racine Pm-SGDN”

I haven’t checked those TLS certificates for compliance yet (key size, OCSP, CRLDP, presence and content of SAN, …), will do it soon. At first sight, a lot of them have CRLDP but no OCSP, some have a wellformed SAN, some have URI SAN, and many have no SAN at all.

[Charles Reiss]

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
> C=FR, O=Ministere education nationale (MENESR), OU=110 043 015, CN=AC
> Infrastructures
> your.server.address.com
>
> 899ec6db4ad070052aee3311de924e3dd3e995df
> 1973335
> C=FR, O=Ministere education nationale (MENESR), OU=110 043 015, CN=AC
> Infrastructures
> your.server.address.com
>
> For some reason, I have doubts about the quality of domain validation
> performed in these cases...
>
> I don't have a Certificate Transparency client set up - does anyone want
> to check if these have already been revoked?

There are also some truncated domain name mistakes:

364364fb7b2d4f226362452e82126079a87fa935 2675891 C=FR, O=Ministere education
nationale (MENESR), OU=110 043 015, CN=AC Infrastructures sympav6.ac-rouen.

cc81b6f89f913d961bf100b877f76285f9f8256c 1981947 C=FR, O=Ministere education

nationale (MENESR), OU=110 043 015, CN=AC Infrastructures

espacecollaboratif.in.orion.education.f

cc81b6f89f913d961bf100b877f76285f9f8256c 1981947 C=FR, O=Ministere education

nationale (MENESR), OU=110 043 015, CN=AC Infrastructures

espacecollaboratif.orion.education.f

In addition there's an entry for a .cp name ('cp' is not in ISO 3166):

8a42df4a54aa0e047c470f03122438c2499d9855 C=FR, O=MINEFI, OU=TELEPROCEDURES,
CN=MINEFI-AC TELEPROCEDURES irasso69.appli.cp

There's also an entry for 'bv', which might be an internal name or might be
truncated (there are several certs with names of the form bv.ac-<academie
name?>.fr):

07fbc1b38557311c0008d6e363a040a7e7fba628 1890993 C=FR, O=Ministere education
nationale (MENESR), OU=110 043 015, CN=AC Infrastructures bv

[Kathleen Wilson]

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 Baseline Requirements and version 2.1 of Mozilla's CA Certificate
Policy[2]. This incident is a good example of why we should do this.

I would like to propose the following course of action for this CA, and
also propose that we take a similar course of action for other CAs who
are not able to meet the timelines[2].

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.

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

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.

Thanks,
Kathleen

[1] https://wiki.mozilla.org/CA:Communications#January_2013_Responses

[2]
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=693450

[Brian Smith]

On Tue, Dec 10, 2013 at 4:08 PM, Kathleen Wilson <kwi...@mozilla.com> 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 run by the French government and *.gouv.fr are government
websites. Thus, restricting ANSSI to issuing certificates under
*.gouv.fr limits the negative impact of any mis-issuance to French
government websites--i.e. they could only harm themselves if so
restricted.

Also, enabling *.gouv.fr sites that use ANSSI-issued certificates to
continue working would minimize disruption to essential government
services, like tax collecting, etc. Removing ANSSI completely may be
too disruptive to these essential services.

My personal opinion is that it is unlikely that all other browsers
would follow us if we completely removed ANSSI, but I think it would
be reasonable to expect other browsers to add constraints to
*.gouv.fr.

In case it isn't obvious, I support this proposal.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Jan Schejbal]

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 on users of this CA while at the same time
protecting all other users.

The CA has all three trust bits. We definitely should remove the code
signing trust bit. Will this restriction also apply for S-MIME? If so, I
think we can keep the S-MIME one.


I'm not so sure if this should also be the long-term solution:

We require all CAs to "provide public attestation of their conformance
to the stated verification requirements and other operational criteria
by a competent independent party or parties with access to details of
the CA’s internal operations."

I assume that this is supposed to be read as "competent independent
(party or parties) with access to details of the CA’s internal
operations" and not "(competent independent party) or (parties with
access to details of the CA’s internal operations)", because the latter
would not make any sense.

I was unable to locate any (semi-current) audit documents for this CA by
independent parties. The only thing I found - which is also linked from
the CA spreadsheet - is this:
<https://bug666771.bugzilla.mozilla.org/attachment.cgi?id=661038> -
which seems to be a document by the director of the ANSSI, not an
independent party. This requirement was already in place since v1.0 of
the policy (November 2005).

Also, the audit is from 2011 - how often do we require audits?

If the CA doesn't have a current audit report from an *independent*
party, I don't think we should keep it in the CA store in the long term
in *any* form, not even constrained.

> Based on the list that Rob provided, there may be other domains that we
> might consider including.

This would basically mean that Mozilla would be performing CA duties -
checking dozens or hundreds of domain names and verifying if it is a
good idea to let the CA manage those. I think this would be excessive.

[Martin Rublik]

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 what I think is this root; see the private IPs
> under "problematic practices" section).

Moreover, there are some unqualified names as well ...

Martin

[Samuel L]

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 of education (the "ac-"
prefix is for "academy"), I feel obliged to point out the following :

http://www.education.gouv.fr/cid3/les-rectorats-et-services-departementaux-de-l-education-nationale.html

According to this page (from the french national education
administration, which is one of the biggest, if not the biggest
administrative body in France), there are actually 30 academies
(regional bodies of the ministry of education), whose domains are :

*.ac-aix-marseille.fr
*.ac-amiens.fr
*.ac-besancon.fr
*.ac-bordeaux.fr
*.ac-caen.fr
*.ac-clermont.fr
*.ac-corse.fr
*.ac-creteil.fr
*.ac-dijon.fr
*.ac-grenoble.fr
*.ac-guadeloupe.fr
*.ac-guyane.fr
*.ac-lille.fr
*.ac-limoges.fr
*.ac-lyon.fr
*.ac-martinique.fr
*.ac-mayotte.fr
*.ac-montpellier.fr
*.ac-nancy-metz.fr
*.ac-nantes.fr
*.ac-nice.fr
*.ac-orleans-tours.fr
*.ac-noumea.nc
*.ac-paris.fr (and *.sorbonne.fr as well ?)
*.ac-poitiers.fr
*.ac-polynesie.pf
*.ac-reims.fr
*.ac-rennes.fr
*.ac-reunion.fr
*.ac-rouen.fr
*.ac-spm.fr
*.ac-strasbourg.fr
*.ac-toulouse.fr
*.ac-versailles.fr
*.ac-wf.wf

Or maybe they all should be put under *.education.fr ?

S.

[Brian Smith]

On Tue, Dec 10, 2013 at 5:48 PM, Jan Schejbal <jan.sche...@gmx.de> 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 am guessing that it
might need to be both a constraint on the email address (restricting
to *.gouv.fr) and on the DN (restricting to what, exactly)? I am not
quite sure how much harder that would be to implement than the dNSName
constraint for SSL, since most of my study of name constraints is
specifically for SSL. If someone gives a more specific proposal for
the name constraint for S/MIME, I can evaluate the practicality of
implementing it.

But, first, we should ask ANSSI if they have issued S/MIME
certificates to people in *.gouv.fr that are still in active use.
Maybe they are not using their S/MIME capability.

> If the CA doesn't have a current audit report from an *independent*
> party, I don't think we should keep it in the CA store in the long term
> in *any* form, not even constrained.

I agree, but I think for practical reasons we'd need to have a longer
grace period for this than we'd need for constraining the CA to
*.gouv.fr. The name constraint to *.gouv.fr is something that could
likely be done in the next release or the release after that.

>> Based on the list that Rob provided, there may be other domains that we
>> might consider including.
>

> This would basically mean that Mozilla would be performing CA duties -
> checking dozens or hundreds of domain names and verifying if it is a
> good idea to let the CA manage those. I think this would be excessive.

I think the idea is that we'd add the constraint once, and then we'd
not modify it. I don't think we should process requests to broaden the
constraint after we've imposed the initial one. Like you said, we
don't want to get into that business.

[Brian Smith]

On Wed, Dec 11, 2013 at 1:49 AM, Samuel L <samuel...@sealweb.eu> 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.fr
>> *.ac-poitiers.fr

[snip]

> According to this page (from the french national education administration,
> which is one of the biggest, if not the biggest administrative body in
> France), there are actually 30 academies (regional bodies of the ministry of
> education), whose domains are :

<snip>

Thanks for the very helpful information. I think we should first ask
ANSSI to help those academies migrate to a different CA. My
understanding is that the French government already has used
certificates from other CAs:

Entrust: https://www.amendes.gouv.fr/portail/index.jsp?lang=en
Certplus/Certinomis:
https://www.tresor.economie.gouv.fr/autorisations-prealables-des-investissements-etrangers-en-france

So, it seems reasonable to think we could work with ANSSI to
coordinate the migration of websites that aren't serving critical
government functions to the other CAs that the French government is
already using, in a reasonably fast timeframe. I'd like us to try that
first.

[Gervase Markham]

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

It would be interesting to know by what process this happened. Were
these certs revoked in the past but the CRL not updated due to some
technical issue? Or have they just decided to do a blanket revocation of
every cert issued? Or something else?

> Am I correct in the assumption that this means that the only way this CA
> can deal with Sub-CA compromises effectively is asking for an emergency
> update of all software relying on the certificates?

AIUI, yes.

Gerv

[Jan Schejbal]

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 (empty)
http://crl1.dgtpe.fr/AC_Racine_DGTPE.crl (empty)

These are the CRL DPs in the first, second and third sub-ca cert,
respectively (containing the revocations for the root, first SubCA and
second SubCA).

The CRL for the third Sub-CA has 1110 certificates, but there is no CRL
DP pointing to it in the fourth cert - you need to manually get it from
http://crl1.dgtpe.fr/AC_DGTPE_Signature_Authentification.crl

According to that CRL, the fourth Sub-CA is indeed revoked.

The first revoked serial is 0x0313DC, the last one is 0x031F90. That's a
range of ~3000 certificates. That's a lot of revocations, but that
doesn't need to mean much.

432 are "Key compromise"
323 are "Superseded"
268 are "Cessation Of Operation"
42 are "Affiliation Changed"
and I think the rest is without a reason extension.

[Henri Sivonen]

On Wed, Dec 11, 2013 at 2:08 AM, Kathleen Wilson <kwi...@mozilla.com> 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, Brian Smith <br...@briansmith.org> wrote:
> Also, enabling *.gouv.fr sites that use ANSSI-issued certificates to
> continue working would minimize disruption to essential government
> services, like tax collecting, etc. Removing ANSSI completely may be
> too disruptive to these essential services.
>
> My personal opinion is that it is unlikely that all other browsers
> would follow us if we completely removed ANSSI

If removing the root now would be too disruptive, doesn't it follow
that not renewing the root would also be too disruptive and, hence,
one shouldn't assume that the renewal process can force BR compliance,
either?

> In case it isn't obvious, I support this proposal.

Indeed, it seems that the necessary *minimum* action is restricting
the root to *.gouv.fr, *.education.fr and *.ac-*.fr. (And it would
seem prudent to keep the restriction in place after the potential root
renewal as well.)

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/