693450 - Add IGC/A RSA4096 SHA256 root certificate

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[igca_anssi]

Attachment: Recommandations for roots compliance

General information about the CA’s associated organization 
CA Company Name : ANSSI (Agence nationale de la sécurité des systèmes d'information)
Website URL : http://www.ssi.gouv.fr/
Organizational type : ANSSI is a part of the French Government.

Primark Market / Customer Base : IGC/A root CA issues certificates to French ministries CA. These CA issue certificates both for their agents and for websites which are used by the public.
Primary geographical area(s) served : France, French embassies and consulates, French companies abroad and French people abroad, in particular in Europe for cross-border application. There is a growing number of e-services set up in France by French Administration (for people in France and French people abroad, but also for cross-border applications). They require more and more electronic certificates. In this perspective, the IGC/A certificate should not be only available in France.

Impact to Mozilla Users : The Mozilla users impacted will be French Government employees and citizens or companies (national ou international) using an e-service ; for instance french people abroad may use electronic vote system in 2012 whereever there are located in the world (https servers doing SSL/TLS). It concerns also national and international contacts of the french governemental employees which sign e-mails.

CA Contact Information :
CA Email Alias:[e-mail] 
CA Phone Number:[phone]
Title / Department:SGDSN/ANSSI/ACE/BAC

Technical information about each root certificate 
Certificate Name : IGC/A AC racine Etat français
Certificate Issuer Field : 
CN = IGC/A AC racine Etat francais
OU = 0002 130007669
O = ANSSI
C = FR
Certificate Summary : 
This is the RSA4096-SHA256 root certificate of the French Government CA. The IGC/A root issues a subordinate CA for government or administrative organization only. Each of these subordinate CAs may issue end-entity certificates or additional subordinate CAs to be used for divisions within that organization. Each organization is required to follow the CP and the Government RGS, and be audited. This root certificate is used for certificate signature and CRL signature.

Root Cert URL : http://www.ssi.gouv.fr/IMG/crt/igcaRSA4096-072011.crt
SHA1 Fingerprint : 1A:C9:2F:09:EA:89:E2 :8B :12 :6D :FA :C5 :1E :3A :F7 :EA :90 :95 :A3 :EE
Valid From : 2011-07-08
Valid To : 2028-04-15
Certificate Version : 3
Certificate Signature Algorithm : SHA-256 whith RSA
Signing key parameters : RSA 4096 bits
Test Website URL (SSL) : https://test4096.igc.agriculture.gouv.fr/
Example Certificate (non-SSL) : see attached certificate
CRL URL : http://www.ssi.gouv.fr/fr/sigelec/igca/revocation/igca4096.crl
URL NextUpdate for CRLs of end-entity certs, both actual  Value and what’s documented in CP/CPS.  : 
Next update : once a month for the root CA ; see CP of the root CA IGC/A,http://www.ssi.gouv.fr/IMG/pdf/IGCA_PC_v2-1.pdf,  chapter 2.3 page 23, chapter 4.9 pages 35-38. At least 72h for end entity CRL (see http://www.ssi.gouv.fr/IMG/pdf/RGS_Variables_de_temps_V2-3.pdf. page 5 : F_PUB_LCR = Minimal frequency of publication of the CRL = 72 hours or 24h). 
Test: Results of importing into Firefox browser 
OCSP URL : Not Applicable because there is no OCSP service deployed.
Requested Trust Bits : Websites (SSL/TLS), Email (S/MIME), Code signing.
SSL Validation Type : OV
Justification : see OV_justify.pdf attached

CA Hierarchy information for each root certificate 
CA Hierarchy : see attached file Mozilla_IGCA_rootCA_map.png
This root CA actually sign this internally-operated sub-CA :
- AC racine Gendarmerie nationale : Direction générale de la Gendarmerie nationale - 
15/04/2010 - OID : 1.2.250.1.223.1.1.1 
- AC racine Diplomatie : Ministère des Affaires étrangères et européennes - 
21/07/2010 - V1.0 - OID : 1.2.250.1.223.1.1.1 
- AC racine ministère en charge de l’agriculture : Ministère de l’agriculture - 
08/12/2010 - OID : 1.2.250.1.223.1.1.1 

Externally Operated SubCAs : Non applicable - All subCA are operated by french governemental IT services and controled by ISS services. 
Cross-Signing : Non applicable
Technical contraints : the subCA must (legal obligation) be compliant with the "référentiel général de sécurité" or "RGS" - the national IT security reference book. It defines certificates profiles and both technical and organizational constraints. http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/liste-des-documents-constitutifs-du-rgs-v1-0.html

Verification Policies and Practices 
Policy Documentation : 
Language(s) that the documents are in: French
CP: http://www.ssi.gouv.fr/IMG/pdf/IGCA_PC_v2-1.pdf
CPS: A set of restricted documents (instructions for use) for administrators, auditors and operators. CP ought to be detailed enough.
Relying Party Agreement: http://www.ssi.gouv.fr/fr/menu/pied-de-page/aide-et-accessibilite/foire-aux-questions/faq-igc-a.html
Audits :
Audit Type: ETSI TS 102042 and compliance with IGC/A CP 
Auditor: ANSSI
Auditor Website: 
URL to Audit Report and Management’s Assertions: http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.html
Date of completion of last audit: 2010-12-20
SSL Verification Procedures : see http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Authentification_Serveur_V2-3.pdf ; this CP is dedicated to SSL authentication and indicates verification procedures that must be used by all french administrative CA issuing SSL certificates.

Organization Verification Procedures : see IGC/A CP and RGS typical CP
Email Address Verification Procedures : See RGS typical CP ; as far as end entities are administrative agents, the e-mail adresses are stored in Active or e-mail servers directories. PKI referes to these directories for a technical verification. An organizational verification is lead also by the subscriber hierarchy, which validates the certification request, and by the RA wich is often the IT service.
Code Signing Subscriber Verification Procedures : No code-signing use for the moment. Nevertheless, the code signing subscriber verification procedure must be compliant with the procedure in the RGS :  http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2-3.pdf, page 25 to 32.It is mandatory for the RA to verify informations, there is no automatic process but a human verification.

Response to Mozilla's CA Recommended PrPublicly Available CP and CPS
PC et DPC disponibles publiquement / publicly disclosed
Format en PDF, ou autre format non modifiable
Documents disponibles en anglais
CA Hierarchy
CA:recommandations_for_Roots.
Graphical or textual description of the hierarchie
indicate general type of certificates
Audit Criteria
The CA should indicate exactly which criteria they are being evaluated against
all documents supplied as evidence should be publicly available
Documents purporting to be from the CA's auditor should be available from the auditor.
Document Handling of IDNs in CP/CPS
Revocation of Compromised Certificates
Verifying Domain Name Ownership
Verifying Email Address Control
Verifying Identity of Code Signing Certificate Subscriber
DNS names go in SAN
Domain owned by a Natural Person
OCSP
Multi-factor Authentication : all administrators or operators use a multifactor authentication (smart cards or USB token).
Network security : all governmental PKIs are hosted in secured networks, without any direct access to Internet. These networks are monitored, and ANSSI make regular inspections/technical audits testing weakness and ensuring IDS and other monitoring software are up-to-date, and best practices are in place.
As far as root and first level subCA are off line, and RGS imposes revocation in case of suspiscion of compromission, we can confirm to be able to shut down certificate issuance quickly if alerted of intrusion. 

Response to Mozilla's CA Recommended PrPublicly Available CP and CPS
CP publicly issued for IGC/A and CA Diplomatie ; CA Gendarmerie nationale and CA ministere en charge de l'agriculture CP are disclosed for administratives only. Not available in English.
CA Hierarchy : see attached file :Recommendations for Roots.pdf and comments in blue caracters. see the file : Mozilla_IGCA_rootCA_map.htm
Audit Criteria : see http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.html

Document Handling of IDNs in CP/CPS : non applicable
Revocation of Compromised Certificates :OK. Revocation is mandatory ; see IGC/A root CA CP, page 34, and PC-type Authentification (RGS, annexe7) pages 38-42
Verifying Domain Name Ownership :see http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-type_Authentification_Serveur_V2-3.pdf ; for the minimum rules imposed to all subCA, see :
page 25 : "the recording of a server to which a certificate must be delivered is made via the recording of the corresponding RCAS (i.e. personn responsible for the use of the certificate).
The RCAS will have to demonstrate that the name of the domain included in the FQDN of the server belongs really to the entity represented by the RCAS.
A RCAS can be brought to change during the current validity of the SSL certificate of the corresponding server. In that case, every new RCAS also has to be the object of a recording procedure.
The recording of a RCAS, and a corresponding IT server, can be made either directly with the registration authority (RA), or via a representative of certification of the entity (called MC). In the last case the MC must be beforehand recorded by the RA."
See also pages 26 and 27, discribing all the information needed for a certification request to be accepted : 
"- a written certificate request, dated less than 3 months, signed by a legal representativ of the entity, mentionning FQDN concerned ;
- a mandate dated less than 3 months, appointing the future RCAS as being authorized to be RCAS for the one or many machines on which will be deployed the SSL certificate. This mandate must be signed by a legal representative of the entity and signed jointly, for acceptance, by the future RCAS ;
- a document, valid the day of recording, mentioning delegation or subdelegation of the authority responsible for the administrative entity ;
- an official document of identity (id card or passport) of current validity, of the future RCAS, containing a photo, which is presented to the RA which keeps a copy ;
- a proof of ownership by the entity of the FQDN of the server ;
- the e-mail adress allowing the RA to contact the RCAS ;
- the general conditions of use signed.
In addition, french governemental servers must have .gouv.fr domain names, and these domain names are given through a restricted manual procedure. Then there is at least a double control of the hability of a RCAS to manage SSL certificate.
Verifying Email Address Control : See for instance http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Agent_V1.5.pdf chapter 3.1.2 page 21 : adresse obligatory : [e-mail] ; page 25 - 4,1,2 : e-mail adress needed in the certification request ; 4,2,1 : formal validation by the database AROBAS, containing all agents e-mail adresses. For people of another ministry or organization working with the french foreign office, the certification request is send by paper or electronic mail to a representative of certification of the entity (called MC), who knows the e-mail adress of the requestor. MC controls e-mail adress, and send the request to the RA. See also http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Externe_V1.3.pdf, page 27 : the scheme show that the requestor receive a pkcs#12 encrypted with a password. This password is send to the MC, who sends it then to the requestor. 
Verifying Identity of Code Signing Certificate Subscriber : No code-signing use for the moment.
DNS names go in SAN : see http://www.ssi.gouv.fr/IMG/pdf/RGS_Profils_Certificat_LCR_OCSP_V2-3.pdf, page 19 : "il a DNS is present in the CommonName, RFC1123 section 2,1 must be fulfilled, in addition to be compliant with RFC1034. 
Domain owned by a Natural Person : Not allowed
OCSP :Recommanded in the RGS but not implemented for the moment.

Response to Mozilla's list of Potentially Problematic Practices (https://wiki.mozilla.org/CA:Problematic_Practices)
Long-lived DV certificates : maximum life time : 3 years
Wildcard DV SSL certificates :no wildcards DV server alowed.
Email Address Prefixes for DV Certs : There is no risk of issuing a certificate to a subscriber who does not own/control the domain, because the certification request must be verified and justified in compliance witth the rules of the RGS : see http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-type_Authentification_Serveur_V2-3.pdf :
page 25 : "the recording of a server to which a certificate must be delivered is made via the recording of the corresponding RCAS (i.e. personn responsible for the use of the certificate).
The RCAS will have to demonstrate that the name of the domain included in the FQDN of the server belongs really to the entity represented by the RCAS.
A RCAS can be brought to change during the current validity of the SSL certificate of the corresponding server. In that case, every new RCAS also has to be the object of a recording procedure.
The recording of a RCAS, and a corresponding IT server, can be made either directly with the registration authority (RA), or via a representative of certification of the entity (called MC). In the last case the MC must be beforehand recorded by the RA."
See also pages 26 and 27, discribing all the information needed for a certification request to be accepted : 
"- a written certificate request, dated less than 3 months, signed by a legal representativ of the entity, mentionning FQDN concerned ;
- a mandate dated less than 3 months, appointing the future RCAS as being authorized to be RCAS for the one or many machines on which will be deployed the SSL certificate. This mandate must be signed by a legal representative of the entity and signed jointly, for acceptance, by the future RCAS ;
- a document, valid the day of recording, mentioning delegation or subdelegation of the authority responsible for the administrative entity ;
- an official document of identity (id card or passport) of current validity, of the future RCAS, containing a photo, which is presented to the RA which keeps a copy ;
- a proof of ownership by the entity of the FQDN of the server ;
- the e-mail adress allowing the RA to contact the RCAS ;
- the general conditions of use signed.
In addition, french governemental servers must have .gouv.fr domain names, and these domain names are given through a restricted manual procedure (only one department is allowed to open new domains .gouv.fr, and validate the requests of all the ministries. Then there is at least a double control of the hability of a RCAS to manage SSL certificate.
Delegation of Domain / Email validation to third parties :In the french governemental pkis, the IT services or ISS agents validate each SSL certificate request.
Issuing end entity certificates directly from roots :absolutly forbidden ; verified in each audit.
Allowing external entities to operate subordinate Cas : All subCA are operated by french governemental IT services and controled by ISS services, audited by independent party or by ANSSI' auditors. 
Distributing generated private keys in PKCS#12 files : The Foreign office is the only department which delivers PKCS#12. The delivery is made through the private network of the ministry. The PKCS#12 has a secured password, and can be uploaded on the intranet server only. 
Certificates referencing hostnames or private IP addresses : not allowed (see RGS annexe 13)
Issuing SSL Certificates for Internal Domains : no .int domain
OCSP Responses signed by a certificateunder a different root : no OCSP service
CRL with critical CIDP Extension : There is no partitioned CRL implemented.
Generic names for CAs : forbiden (see http://www.ssi.gouv.fr/IMG/pdf/RGS_Profils_Certificat_LCR_OCSP_V2-3.pdf, page 17.)
Lack of Communication With End Users : [e-mail] is used for complaints or questions.

Comment 1

[igca_anssi]

Attachment: Overview of IGC/A root and sub CA

Comment 2

[igca_anssi]

Attachment: Justification of OV SSL type

Comment 3

[igca_anssi]

Attachment: End user Certificate Example

Comment 4

[Kathleen Wilson]

I hope to begin Information Verification soon, and I will update this bug again at that time.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 5

[Kathleen Wilson]

I'm not able to browse to the following URLs. Please correct.

http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.html

http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2-3.pdf

http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Agent_V1.5.pdf

http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Externe_V1.3.pdf

Comment 6

[igca_anssi]

For the following links, you just have to right clic and "save the target" on your computer.
The links are direct links to PDF files.
http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2-3.pdf
http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Agent_V1.5.pdf
http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Externe_V1.3.pdf

I check why you cannot access to http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.html and i'll inform you as soon as the link is available.

Comment 7

[Kathleen Wilson]

(In reply to igca_anssi from comment #6)

Here's what I get when I try to browse to these urls:

> http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2-3.pdf

The requested URL /IMG/pdf/RGS_PC-Type_Cachet_V2-3.pdf was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. 


> http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Agent_V1.5.pdf

The requested URL /AC-UTILISATEURS_PC_Signature_Agent_V1.5.pdf was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.


> http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Externe_V1.3.pdf

The requested URL /AC-UTILISATEURS_PC_Signature_Externe_V1.3.pdf was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.


> http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.
> html 

This link works for me now.

Comment 8

[igca_anssi]

Hello Kathleen,
Apologies for these mistakes and the inaccurate answer which was sent to you ; please find the following right links :
> > wrong : http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2-3.pdf
http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2_3.pdf
 
> > wrong : http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Agent_V1.5.pdf
http://crl.diplomatie.gouv.fr/AC_Utilisateurs/AC_UTILISATEURS_PC_Signature_Agent_V1.5.pdf

> > wrong : http://crl.diplomatie.gouv.fr/AC-UTILISATEURS_PC_Signature_Externe_V1.3.pdf
http://crl.diplomatie.gouv.fr/AC_Utilisateurs/AC_UTILISATEURS_PC_Signature_Externe_V1.3.pdf

All the CPs issued concerning "IGC Diplomatie" can be loaded here : http://crl.diplomatie.gouv.fr/

Regards
F.E.

Comment 9

[igca_anssi]

Please notice an incorrect value in :
attachment 566035 [details]
Recommandations for roots compliance

Page 2, wrong value : "PathLen=0"
real value : pathLenConstraint is unlimitted - of course !

Regards
F.E.

Comment 10

[igca_anssi]

Notice :
This request concerns in fact the Renewed IGC/A root certificate, included in 2009 https://bugzilla.mozilla.org/show_bug.cgi?id=477147  
(original root-inclusion bug number : 368970 - https://bugzilla.mozilla.org/show_bug.cgi?id=368970 )

The CA Company name has changed (old : DCSSI, now named ANSSI) but the PKI ressources remain the same, and the CP has been upgraded.

Comment 11

[Kathleen Wilson]

I am having difficulty with the machine translations from French to English.

Please explain what each of the following documents is, and what types of certificates each document covers.

http://www.ssi.gouv.fr/IMG/pdf/IGCA_PC_v2-1.pdf

http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Authentification_Serveur_V2-3.pdf

http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2_3.pdf

http://crl.diplomatie.gouv.fr/AC_Utilisateurs/AC_UTILISATEURS_PC_Signature_Agent_V1.5.pdf

http://crl.diplomatie.gouv.fr/AC_Utilisateurs/AC_UTILISATEURS_PC_Signature_Externe_V1.3.pdf

Comment 12

[igca_anssi]

Hello Kathleen,
Please find information required : 
http://www.ssi.gouv.fr/IMG/pdf/IGCA_PC_v2-1.pdf
: explains how the root and sub CA certificates are generated. Also explains wich type of end-users certificates can be issued by subCA.
see chap.1.5.1 pages 18-19 : IGC/A (root CA) delivers CA certificates and CRL only. All IGC/A's subCA must be governemental CA. Any CA that do not belong to the french Administration is not allowed in the IGC/A trust domain.
CP/CPS dédicated to some subCA must precise the CA is allowed to deliver certificates to french Administration CA, or people working on behalf of Administration, or servers operated under the Administration responsibility.

N.B. : Certificates types can be one of the following, mentionned in the "RGS" wich is mandatory for Administration CA :
- "authentification" = authentication (human)
- "signature" = e-signature (human) - (e-mail signature or any other type of document)
- "confidentialité" = enciphering (human) - (e-mail encryption or any other data encryption)
- "authentification serveur" = SSL/TLS authentication
- "cachet serveur" = e-sign for servers


http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Authentification_Serveur_V2-3.pdf
: explains rules for CA issuing SSL/TLS authentication certificates.

http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2_3.pdf
: explains rules for CA issuing e-sign certificates for servers.

http://crl.diplomatie.gouv.fr/AC_Utilisateurs/AC_UTILISATEURS_PC_Signature_Agent_V1.5.pdf
: explains rules for the Foreign Affairs Ministry subCA issuing e-mail signing certificates for people working for the Foreign Affairs ministry.

http://crl.diplomatie.gouv.fr/AC_Utilisateurs/AC_UTILISATEURS_PC_Signature_Externe_V1.3.pdf :
explains rules the Foreign Affairs Ministry subCA issuing e-mail signing certificates for people working for another French Administration in order to exchange with the Foreign affairs ministry.

Hoping that'll help.
Regards
F.E.

Comment 13

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 14

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 15

[Kathleen Wilson]

Please provide a more recent audit statement. The one I have is:
https://bug666771.bugzilla.mozilla.org/attachment.cgi?id=557633 (2010.12.20)

Also, when do you expect the ssi.gouv.fr page to be updated to reflect the 2011 surveillance audit?
http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.html

Comment 16

[igca_anssi]

Hello Kathleen,
This must be updated in a couple of weeks. We are going to publish many new information about CA pratices(http://www.ssi.gouv.fr/fr/menu/actualites/l-anssi-prepare-la-seconde-version-du-rgs.html).
As you may notice on the site, the ANSSI has been reorganized (http://www.ssi.gouv.fr/fr/menu/actualites/la-nouvelle-organisation-de-l-anssi.html). This may impact our audit programm for 2012.
Best reg
F.E.

Comment 17

[igca_anssi]

As mentionned above, http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.html has been updated.
Best regards

Comment 18

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Please confirm that the information in the attached document is current and correct.

Comment 19

[igca_anssi]

Attachment: Last subCA created

Upgrade 566036 with last subCA created.

Comment 20

[igca_anssi]

(In reply to Kathleen Wilson from comment #18)
> Created attachment 663162 [details]
> Completed Information Gathering Document
> 
> Please confirm that the information in the attached document is current and
> correct.

See https://bugzilla.mozilla.org/attachment.cgi?id=667041 for last SubCa created. Similar uses than the orther one (SSL Servers, OCSP responder, e-signature and authentication).

Please note changes :
1 - CA hierarchy : AC racine Ministère de l'Intérieur : Ministère de l'Intérieur - 22/12/2011 - OID : 1.2.250.1.223.1.1.1

2 - CA contact information :
Title/department : SGDSN/ANSSI/RELEC/MRR 

Thanks
F.E.
2

Comment 21

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 22

[Kathleen Wilson]

I am now opening the first public discussion period for this request from ANSSI to add the SHA256-RSA4096 root certificate of the French Government CA, “IGC/A AC racine Etat francais” and turn on all three trust bits. The SHA1-RSA2048 root certificate of the French Government CA is currently included in NSS.

For a description of the public discussion phase, see 
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “ANSSI Root Inclusion Request for Renewed Root”

Please actively review, respond, and contribute to the discussion.

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.

Comment 23

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #22)
> I am now opening the first public discussion period for this request from
> ANSSI to add the SHA256-RSA4096 root certificate of the French Government
> CA, “IGC/A AC racine Etat francais” and turn on all three trust bits. The
> SHA1-RSA2048 root certificate of the French Government CA is currently
> included in NSS.
> 

I have closed the first discussion for this root inclusion request. The following items will need to be addressed before starting the second discussion.

1) Complete responses to Mozilla’ CA Communication that was sent on January 10, 2013. https://wiki.mozilla.org/CA:Communications

2) Either resolve the issue of certificates not having at least 20 bits of unpredictable random data, or add documentation to the CP/CPS to prohibit issuance of SHA1 certs in the CA hierarchy.

3) Resolve the concern that was raised about certificatePolicies chaining.

Thanks,
Kathleen

Comment 24

[Fabio Pietrosanti (naif)]

Hi, i would like to note this issue:

The French Government ANSSI made a MITM against Google SSL/TLS:
http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html

Google does not mention who's ANSSI.

ANSSI is the French CyberSecurity agency, closely working with defense
and intelligence agencies:
http://www.ssi.gouv.fr/

ANSSI declare that an intermediate CA is generating fake-certificate for the purpose
to inspect SSL traffic:
"ANSSI has found that the intermediate CA certificate was used in a
commercial device, on a private network, to inspect encrypted traffic
with the knowledge of the users on that network. "

Google Detected the MITM and Blocked it:
https://code.google.com/p/chromium/issues/detail?id=326787

ANSSI issued a statement that it was a "Human Error" from someone from
the Finance Ministry:
http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.html

A recent law proposal, see Art. 246, is giving power to governmental agencies to act with massive interception capabilities:
http://translate.google.com/translate?depth=1&ie=UTF8&prev=_t&rurl=translate.google.com&tl=en&u=http://www.assemblee-nationale.fr/14/projets/pl1473.asp

I am wondering if, given this incident and the upcoming change in the regulation, this CA is still compliant with Mozilla policy for Root's CA inclusions.

Comment 25

[David E. Ross]

In any case, this should not be approved until ANSSI (PM/SGDN) is in compliance with Mozilla policies and CA/Browser Forum's Baseline Requirements.

Comment 26

[Kathleen Wilson]

I haven't recorded a response from ANSSI/DCSSI regarding the recent CA Communication:
https://wiki.mozilla.org/CA:Communications#May_13.2C_2014 

Please respond ASAP. Either respond in this bug, or send me email.

Comment 27

[Yuhong Bao]

And do we want to apply the same domain name restrictions to the new ANSSI roots?

Comment 28

[Kathleen Wilson]

Attachment: 693450-CAInformation.pdf

I have entered the data for this request into SalesForce. Please review the attached document and comment in this bug regarding updates/corrections to it.

Status of this request – Need:
- Resolution to Bug #1017136
- OCSP URI in the AIA of end-entity certs
- BR Audit Statement; https://wiki.mozilla.org/CA:BaselineRequirements#ETSI_BR_Audit_Statement.2FCertificate
- BR Commitment to Comply; https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
- Certificates need to have at least 20 bits of unpredictable random data
- Resolve the concern that was raised during the first discussion about certificatePolicies chaining.
- Respond to https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates

The first discussion about this request is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/VOg5nHVQ-Yc/IbtMULCjDUMJ

Mozilla Security Blog regarding comment #24: https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/

Comment #27 is referring to Bug #952572 and Bug #1030204. The answer is yes, we want to apply the same constraints to the new root if it is approved for inclusion.

Comment 29

[Kathleen Wilson]

I received email from the CA representative that said that the decision to include this root IGC/A 4096 SHA2 is discontinued (reason is the complexity of the operation and the associated costs).

Comment 30

[Yuhong Bao]

So I guess that the DCSSI CAs are being phased out?

Comment 31

[Ratul]

Attachment: tabzilla.png

Comment 32

[Ratul]

Attachment: GoDaddyRootCertificateAuthority-G2.crt