368970 - Add French Government (DCSSI) CA certificate

Status: RESOLVED FIXED

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

Description

[Gervase Markham [:gerv]]

The Director General of information systems security in the Government of France has sent us a letter, requesting that we include the root certificates of the French Government CA in Mozilla.

The letter, in PDF format, contains quite a bit of ancillary information and is larger than Bugzilla's 300KB limit on non-patch attachments. So I will upload it to wiki.mozilla.org and add the URL here.

Gerv

Comment 2

[Gervase Markham [:gerv]]

There are a large number of outstanding CA requests, and it will take me some time to work through them. I can tell you that I will need the following data for each request. If some of this data is missing, the request cannot proceed. Even if all of it is already present somewhere in the bug or the materials provided, it will speed up your application if you provide it again. This means I can make everyone happier, quicker :-)

Please give data in the following format, as a *plain text comment*. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates.

CA Details
----------

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served
 - Number and type of subordinate CAs
Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):
  
Certificate Details
-------------------
(To be completed once for each certificate)
  
Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy, i.e. what you plan to do with the 
   root
Certificate HTTP URL (on CA website):
Version:
SHA1 Fingerprint:
MD5 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
CRL HTTP URL:
OCSP URL:
Class (domain-validated, identity-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code):

Thanks for your help in this matter. :-)

Gerv

Comment 3

[Gervase Markham [:gerv]]

I sent the following email to [e-mail] (the contact address given in the PDF):

Mr. Gallet/Mr. Esselin,

Re: https://bugzilla.mozilla.org/show_bug.cgi?id=368970

I apologise for writing in English; my French, she is terrible ;-)

Je fais des excuses pour écrire en anglais; mon Français, elle est terrible ;-)

You are listed as the contacts for the French Government's application for inclusion of DCSSI root certificates in the root store of Mozilla products. We have an application letter, but not all the information required is included. Please can you visit the URL given above and supply the additional information?

Thanks,

Gerv

Comment 4

[Gervase Markham [:gerv]]

I have received the following information from Mr. Esselin:

We unfortunatly failed to meet Mr NITOT to give him further information.
So we had to wait for official publication on French official site
issuing laws and arretees to give you a way to verify the IGC/A
certificates integrity : 
http://www.legifrance.gouv.fr/WAspad/UnTexteDeJorf?numjo=PRMX0710016V

CA Details
----------

CA Name: IGC/A
Website: http://www.ssi.gouv.fr/
One Paragraph Summary of CA, including the following:
 - General nature : government. The application is certification of all French government departments' root CAs, and widely public sector CAs which deliver certificates for e-government. Certificates delivered by these subordonates CAs (or their subordonates) are then used both by French government agencies and to identifiy French departments websites by citizens.
 - Primary geographical area(s) served : France, French ambassadies and PCs of French people abroad, Europe for cross-border application.
 - Number and type of subordinate CAs : government departments' root CAs, five now, at least 20, up to 60 potentially. 
Audit Type (WebTrust, ETSI etc.): WebTrust - accredited by the SGDN in 2002 
Auditor: Secretariat Général de la Défense Nationale - General Secretariat of National Defence, which acts as the French national security authority
Auditor Website: none
Audit Document URL(s): confidential (classified)

RSA Certificate Details
-------------------

Certificate Name: IGC/A
Summary Paragraph, including the following:
 - End entity certificate issuance policy : 
Signature du certificat, Signature de la liste de révocation de certificats hors connexion, Signature de la liste de révocation de certificats (06)

Certificate HTTP URL (on CA website):
RSA certificate : http://www.ssi.gouv.fr/fr/sigelec/igca/cert_igca_rsa.crt
Version:V3
SHA1 Fingerprint:60D6 8974 B5C2 659E 8A0F C188 7C88 D246 691B 182C
MD5 Fingerprint:
Modulus Length (a.k.a. "key length"):2048
Valid From (YYYY-MM-DD):friday 13 december 2002 14:29:23 GMT.
Valid To (YYYY-MM-DD):saturday 17 october 2020 14:29:22 GMT.
CRL HTTP URL:none
OCSP URL:
Class (domain-validated, identity-validated or EV): domain validated


DSA Certificate Details
-------------------

Certificate Name: IGC/A
Summary Paragraph, including the following:
 - End entity certificate issuance policy : 
Signature du certificat, Signature de la liste de révocation de certificats hors connexion, Signature de la liste de révocation de certificats (06)

Certificate HTTP URL (on CA website):
RSA certificate : http://www.ssi.gouv.fr/fr/sigelec/igca/cert_igca_dsa.crt
Version:V3
SHA1 Fingerprint:95 1E F4 DC A3 1D 5C 57 55 16 02 86 51 AB 6A BA 15 FC 4E 4B
MD5 Fingerprint:
Modulus Length (a.k.a. "key length"):1024
Valid From (YYYY-MM-DD):friday 13 december 2002 14:39:15 GMT.
Valid To (YYYY-MM-DD):saturday 17 october 2020 14:39:14 GMT.
CRL HTTP URL:none
OCSP URL:
Class (domain-validated, identity-validated or EV): domain validated

Comment 5

[Gervase Markham [:gerv]]

Some questions/points:

- Your certificates are served with the MIME type text/plain rather than application/x-x509-email-cert. This makes it rather harder to install them in Firefox. Please could you reconfigure your web server to use the correct MIME type?

- Is it correct that certificates issued from these roots contain neither CRL nor OCSP URLs?

- Are you requesting the ability to issue certificates for email and/or code signing? 

- Do you have any Certificate Policy or Certificate Practice Statements for your CA?

- The fact that your audit documents are classified may present a problem. How classified is "classified"? Do you mean that you can't make them public, or that you can't even show them to me?

Gerv

Comment 6

[IGCA Contact]

(In reply to comment #5)
Hello Gerv, 
Thank you for your quick reply.
> - Your certificates are served with the MIME type text/plain rather than
> application/x-x509-email-cert. 
This has been changed. Thanks for your remark.

> - ... certificates issued from these roots contain neither CRL nor OCSP URLs?
Indeed we don't operate any OCSP service. 
Concerning CRL, there is no CRLDP in the root CA certificates - as many other commercial root CA certificates - but CRL management is to be done for subordonated CA certificates. 

> - Are you requesting the ability to issue certificates for email and/or code
> signing? 
Not directly, but subordonated certificates may issue such certificates.
The Central Information Systems Security Division - DCSSI has developed the “IGC/A” public key management infrastructure, to meet the need to guarantee the identity of CA of ministerial cryptographic keys at the highest level of State.
 
> - Do you have any Certificate Policy or Certificate Practice Statements for
> your CA?
Yes, both a CP and a CPS, which are non-public documents (in French). 
The PC is available for signed CA and those willing to be signed, and will be soon published on our website. 
 
> - The fact that your audit documents are classified may present a problem. How
> classified is "classified"? Do you mean that you can't make them public, or
> that you can't even show them to me?
It's really classified. This context excludes an independent third party entity, as defined in the Mozilla foundation’s certification policy, auditing the IGC/A. 
The IGC/A’s accreditation was ruled by the SGDN on 21 August 2002. The SGDN (Secrétariat général de la défense nationale - General Secretariat of National Defence) acts as the French national security authority.

Best regards
F.E.

Comment 7

[Gervase Markham [:gerv]]

> This has been changed. Thanks for your remark.

You may not thank me when I tell you that I copied and pasted the wrong MIME type into my message. The correct MIME type is not
application/x-x509-email-cert
it is
application/x-x509-ca-cert
I apologise for the confusion, and the inconvenience caused by another change being needed.

Do you have a list anywhere of the different CRLs your subordinate CAs use, or is the system so decentralised that no such list exists?

> The PC is available for signed CA and those willing to be signed, and will be
> soon published on our website. 

I assume you mean "CP"? Please post the URL when it is available.

> This context excludes an independent third party
> entity, as defined in the Mozilla foundation’s certification policy, auditing
> the IGC/A. 

I understand. (Although other Government CAs have been subject to audits.) However, you will also understand that it might be somewhat difficult to change things so that millions if Firefox users all trust the French Government, without being able to see what measures they take to safeguard their keys.

I am investigating whether it would be technically possible to restrict particular government-controlled roots to signing certificates for domains under the appropriate TLD (".fr", in your case). That way, the entire world does not have to trust the French Government, only the citizens of France - who presumably already do. Would that be something you could, in principle, accept?

Gerv

Comment 8

[Gervase Markham [:gerv]]

F.E.: Have you been able to consider my question?

Thanks,

Gerv

Comment 9

[Gervase Markham [:gerv]]

Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv

Comment 10

[Gervase Markham [:gerv]]

I need answers to the questions in comment #7, or this bug will be closed.

We also require that CAs "publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement);" (policy section 6). This normally means a published CP and CPS. We would need to know what steps DCSSI plans to take to address this requirement.

Thanks,

Gerv

Comment 11

[IGCA Contact]

(In reply to comment #10)
Hello Gerv, 

We are sorry not having been able to answer you sooner. 
As you may know, the last months were of paramount importance for France. Consequently, we had to change some priorities for some months, that's why we were in a hurry at the beginning of this year to contact the Mozilla Foundation. 

To make a point, especially for those of the Mozilla community interested in this bug report: 
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 (-> comment #7). 
 
Our PKI, called IGC/A, has been designed for delivering certificates to French governmental root CAs. The governmental root CAs are ruled by PC2 or PRIS requirements - PC2 and PRIS are French CP standards fully compliant with 2527 or 3647 (and of course RFC 3280 for X509). 

Revocation isn’t dealt by IGC/A up to now, as we rely on the publication’s service of governmental root CAs. Nevertheless, as the number of certification request is increasing quickly, and because more and more applications need it, we are about to implement CRL (or more precisely ARL) in our PKI. 
This is the only point of divergence with WebTrust CA criteria, with the following point concerning third party certification. 

People can control the operation of the IGC/A through the CP (http://www.ssi.gouv.fr/fr/sigelec/igca/igca-politique_certification.pdf - sorry, it has not been translated into other European languages). 
For us, CPS is a document which describes our practices for operating IGC/A in a restricted area. It has not to be public. 
As we told you, the evaluation report is classified. Nevertheless, the IGC/A has been accredited by the ISS central director (he is the French INFOSEC authority for UE). The statement of this accreditation can be transmitted to you. Compared to the initial audit, this process implies regular audits to maintain the accreditation, giving an assurance that the level of security is maintained. 
Best regards
F.E.

Comment 12

[Gervase Markham [:gerv]]

You will be pleased to hear that we have rejected the idea of limiting some certificates to particular TLDs. However, this does mean that all CAs are required to meet our guidelines in every respect.

Firstly, as I have stated before, we require an audit to one of the acceptable standards (WebTrust or ETSI), as laid out in policy section 8. The audit report does not have to be public, but the auditor has to, at minimum, make a public statement that the audit has been done, and was passed in every respect. I'm sure you understand that we can't just take your word for it :-)

(This may cause a problem for you; as I understand it, the audit you have had done in the past was qualified - that is to say, it did not pass completely because you did not implement CRLs/ARLs. So a new one would probably be necessary.)

The audit has to be conducted by an acceptable auditor (sections 9 and 10); the SGDN would be acceptable.

We also need assurance that the CA operates according to certain minimum criteria for verification, set out in section 7, and in various other ways we deem acceptable. That is normally discerned by reading a published CP/CPS. If such documents cannot be published, then it might be possible to ascertain this information by asking you questions about your practices. However, that would be a time-consuming process, and would probably mean you'd end up at the back of the queue (currently 20 or more CAs).

Gerv

Comment 13

[Jean-Marc Desperrier]

Gerv, in theory the CP describes what policy the CA aims to implements, and the CPS describe how exactly technically it implements it. It's usual for the CPS to be confidential, and I think accessing the CP should be enough for your needs. 
Of course it would be much easier with an english translation of the CP.

Comment 14

[David E. Ross]

Note that the "WebTrust Program for Certification Authorities" clearly states (pp 27-28) that the CPS is "available to all subscribers and all potential relying parties, typically by posting on its Web site."  It also indicates the CPS is published, which means "made public".  See also the illustrative disclosure for criterion #8 in Section 1.1 of the WebTrust document.  

Comment 15

[Gervase Markham [:gerv]]

David is right. We need to know certain details of the CA's operations in order to confirm that their procedures meet the requirements of section 7 of our policy. As I said, that doesn't necessarily have to be in a document labelled "CPS", although it usually is. 

Every single CA I have approved so far has had a public CPS, so I would question whether confidential CPSes is the norm for CAs of the type who apply for inclusion in general browser software.

Gerv

Comment 16

[IGCA Contact]

First of we apologises not being very reactive on the thread.

Thanks Jean Marc for your explanations that I fully support.

Concerning public availability of the CPS, I do not agree with David Ross’ statement. WebTrust CA (pp 27-28) states that "Information regarding the CA’s business practices should be made available to all subscribers and all potential relying parties, typically by posting on its Web site.

Such disclosure may be contained in a certificate policy (CP), certification practice statement (CPS), or other informative materials that are available to users (subscribers and relying parties)". CPS is only one way to publish this information among others.

If you look at the RFC 3647 or the ETSI TS 101456, they also refer to public part of the CPS, that should be in a PDS (mainly for business activities) or in the CP.

By the way, we consider that this information is included in the CP that is published on our website. As wrote Jean Marc it is unfortunately only available in French, but 'subscribers' of this PKI are French ministries.

Comment 17

[Gervase Markham [:gerv]]

I'm afraid I'm on holiday for the next two weeks, so no more will happen here until after that. My apologies :-(

Gerv

Comment 18

[Jean-Marc Desperrier]

Gerv just informed me that Frank Hecker is taking over from him all responsabilities for handling CA requests, including this one.

I'm afraid this means an english translation of everything Franck will have to review is absolutly required.

Comment 19

[Gervase Markham [:gerv]]

I think it might be better to wait for Frank to say what he wants; I wouldn't want anyone doing unnecessary work.

Gerv

Comment 20

[Gervase Markham [:gerv]]

Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the information in this request is incomplete. 
The request is waiting for more information from the applicant.

Comment 22

[Frank Hecker]

Reassigning to Kathleen Wilson to do information gathering.

Comment 23

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

I have been asked to do the information gathering and verification for this request as per http://wiki.mozilla.org/CA:Information_checklist.  The attached document provides a summary of the information that has been gathered and verified so far. I have the following questions and request for further information:

1) Has CRL/ARL been implemented for these roots?

2) Is there a statement in the CP (or other relevant document that subordinate CAs must agree to) that specifies the frequency of update for the CRLs for the end-entity certificates chaining up to this root? Would you please translate the relevant text into English?

3) Please provide a certificate hierarchy diagram and/or description for the sub-CA’s (current or planned) for this root.

a) List or description of subordinate CAs operated by the CA organization associated with the root CA. (For example, this might include subordinate CAs created to issue different classes or types of end entity certificates: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, SSL certificates vs. email certificates, and so on.)
For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CPS, and that any audit covers them as well as the root.

b) For subordinate CAs operated by third parties, if any: 
General description of the types of third-party subordinates that exist, and what the general legal/technical arrangements are by which those subordinates are authorized, controlled, and audited.
(For example, contractual arrangements should require third-party subordinates to operate in accordance with some CPS/CP. Technical arrangements might include name constraints, not allowing them to create their own subordinates, etc.) 

c) List any other root CAs that have issued cross-signing certificates for this root CA


4) I am supposed to review the CP/CPS to ensure that procedures are in place to do the following. Would you please translate the relevant text from the latest CP into English? We are looking for text that describes exactly what information is verified, and how the information is verified.
a) For SSL, verify that the domain referenced in the certificate is owned/controlled by the certificate subscriber. 
b) Verify the email account associated with the email address in the cert is owned by the subscriber, in addition to verification of subscriber’s legal identity.
c) Verify identity information in code signing certificates is that of subscriber
d) Make sure it’s clear which checks are done for which context (cert usage)

5) For each root, would you please provide a URL whose website cert chains up to the root? The website can either be a test site or an existing site.

6) I’m supposed to review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. Since the CPS is not in English, would you please comment as to whether any of these are relevant. 
If relevant, please provide further info:
a)Long-Lived Domain-Validated SSL certs 
b)Wildcard DV SSL certs
c)Issuing end entity certs directly from root rather than using an offline root and issuing certs through a subordinate CA 
d)Allowing external entities to operate subordinate CAs – in this case need to demonstrate that the external entities are required to follow the CPS and are audited as such.

7) Please see section 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/
We need a publishable statement or letter from an auditor (who meets the policy requirements) that states that they have reviewed the practices as outlined in the CP/CPS for these roots, and that the CA does indeed follow these practices and meets the requirements of one of:
•	ETSI TS 101 456
•	ETSI TS 102 042
•	WebTrust Principles and Criteria for Certification Authorities

I can’t read French, but the letter at http://www.legifrance.gouv.fr/WAspad/UnTexteDeJorf?numjo=PRMX0710016V seems to be of the right form, however I don’t see anything referring to ETSI or WebTrust.

Note that this can be a letter/statement that is posted into bugzilla, and then I will need to do an independent verification of the authenticity of the document by contacting the auditor directly.

Thanks,
Kathleen

Comment 24

[IGCA Contact]

Hello Kathleen,

Thank you for stiring up this request.
We take into account each point you arose, and will soon give you requested information.
Regards

Florence Esselin
IGC/A Projet manager

Comment 25

[IGCA Contact]

Hello Kathleen,

Please find below information you requested. I hope they are relevant for you. If you have any occasion for traveling to Paris, we would be glad to see you.
Best regards.
Florence Esselin
IGC/A Project manager

> 1) Has CRL/ARL been implemented for these roots?
Yes. See  http://www.ssi.gouv.fr/fr/sigelec/igca/revocation/igca.crl

> 2) Is there a statement in the CP (or other relevant document that subordinate
> CAs must agree to) that specifies the frequency of update for the CRLs for the
> end-entity certificates chaining up to this root? Would you please translate
> the relevant text into English?
French law (order no.2005-1516 of 8th december 2005 – on electronic exchanges between users and administrative authorities and between administrative authorities) compels CAs delivering end-entity certificates to be compliant with the IT security general referential (référentiel général de sécurité – RGS http://www.ssi.gouv.fr/fr/RGS/index.html). It specifies rules (in annexes called “PRIS” http://www.synergies-publiques.fr/article.php?id_article=381) for end-entity certificates following ETSI TS 101 456 for digital signature (PRIS level ***), ETSI TS 102 042 (PRIS * and **), RFC3280 and RFC 3647 CP/CPS framework.
See http://www.synergies-publiques.fr/IMG/pdf/061129_PRIS_US_ENISA.pdf
for a brief presentation of the requirements and the scheme to agree trustworthy service providers (administrative authorities as well as private companies delivering certificates for exchanges between users and the french administration). 
For end-entities, the CRLs frequency update is 24h (as specified in http://www.synergies-publiques.fr/IMG/pdf/RGS_Variables_de_temps_V2.1.pdf).

> 3) Please provide a certificate hierarchy diagram and/or description for the
> sub-CA’s (current or planned) for this root.
See page 15 of the CP: http://www.ssi.gouv.fr/fr/sigelec/igca/igca-pc-v2.pdf
 
> a) List or description of subordinate CAs operated by the CA organization
> associated with the root CA. 
See IGC/A CP, ch.1.4.PKI Participants, especially p. 18, 1.4.3.End entity certificates.
In a nutshell: 
Subordinate CAs are only governmental CAs (current) and administrative authorities* CAs (planned).

* as definied in the order no.2005-1516 of 8th december 2005.

Governmental CAs must respect the following rules :
- the subscriber must be a French official
- the CA must federate all subordinated CA belonging to the administrative authority involved ; exceptions can’t be accepted without the agreement of the Defense and Security Officer of the authority involved
- CA must have an auto-signed certificate and sign ARL
- CA must be able to audit the PKI and to allow DCSSI to audit or make audit the statements.

IGC/A CP, §1.5.1 – certificate usage (short translation): 
As a condition for IGC/A issuing certificates, all CA certificates chaining up to IGC/A root CA must belong to one or more french administrative authority (AA).

Subordinate CAs must restrict certificate issuance to :
- CA of an AA ;
- person for authentication, e-signature and confidentiality in applications on the authority’s duty
- servers under the exclusive authorities’responsibility for SSL/TLS authentication, signature and timestamp ;
- authorities for code signing.
***
N.B. : Certificates are not used for commercial purposes. They are used only for administratives exchanges.

> b) For subordinate CAs operated by third parties, if any: 
> General description of the types of third-party subordinates that exist, and
> what the general legal/technical arrangements are by which those subordinates
> are authorized, controlled, and audited.
Some CA may be operated by private companies, on behalf of the French administration. The RGS compels private operators to conform to RGS/PRIS profiles and to be referenced (certified by an accredited certification body).

> c) List any other root CAs that have issued cross-signing certificates for this root CA
No root CA has issued cross-signing certificates for IGC/A CA.
 
> 4) I am supposed to review the CP/CPS to ensure that procedures are in place to do the following. Would you please translate the relevant text from the latest CP into English? We are looking for text that describes exactly what
> information is verified, and how the information is verified.
They are RGS/PRIS requirements.

> a) For SSL, verify that the domain referenced in the certificate is
> owned/controlled by the certificate subscriber. 
see PRIS v2.1, PC-Type certificats servers page 34 :
4.  Certificate Life-Cycle Operational Requirements
4.2.  Certificate Application Processing
Identities of persons are verified as described in chapter 3.2.

RA must :
- validate FQDN of the server the certificate delivered refers to
- validate identity of the person responsible for the server and for the use of its certificates (RCSI)
- check coherence of relevant documents 
- verify RCSI is aware of the certificates conditions of use 

> b) Verify the email account associated with the email address in the cert is
> owned by the subscriber, in addition to verification of subscriber’s legal
> identity.
See PRIS v2.1, PC-Type authentification page 32 :
3.2 Initial identity validation
3.2.3 Subscriber identity validation 
[...]
The subscription file sent to RA must contain at least :
- a recent (<3months) written certificate request signed by the subscriber,
- a valid official identity document of the subscriber, with photo (for example passport or national identity card) shawn to the RA – the RA keeps a copy of it.

4.  Certificate Life-Cycle Operational Requirements
4.2.  Certificate Application Processing
RA must : 
- validate identity of the subscriber 
- check coherence of relevant documents 
- verify the subscriber is aware of the certificates conditions of use 

And :
PRIS v2.1, Profiles de certificats, LCR et OCSP p21:
VII.2. Subscriber identification
The DN in the subject field of a subscriber certificate must be conforme to chapiters 3.1.2 of RFC3739 and 5.2.6 of ETSI - TS 102 280 V1.1.1 - X.509 V3 Certificate Profile for Certificates Issued to Natural Persons, 03/2004
, and to additional PRIS requirements.

> c) Verify identity information in code signing certificates is that of
> subscriber
See PRIS v2.1, PC-Type cachet serveur page 34 :
3.2 Initial identity validation
3.2.3 Subscriber identity validation
Because the subscriber represents an entity, identity of this entity must be examined in addition to the identication of the suscriber as a natural person.

4.  Certificate Life-Cycle Operational Requirements
4.2.  Certificate Application Processing 
Identities of persons are verified as described in chapter 3.2.

RA must :
- validate FQDN of the server the certificate delivered refers to
- validate identity of the person responsible for the server and for the use of its certificates (RCSI)
- check coherence of relevant documents 
- verify RCSI is aware of the certificates conditions of use 

> d) Make sure it’s clear which checks are done for which context (cert usage)
PRIS gives one profile per usage.

> 5) For each root, would you please provide a URL whose website cert chains up
> to the root? The website can either be a test site or an existing site.
https://www.journal-officiel.gouv.fr

> 6) I’m supposed to review the CP/CPS for potentially problematic practices, as
> per http://wiki.mozilla.org/CA:Problematic_Practices. Since the CPS is not in
> English, would you please comment as to whether any of these are relevant. 
> If relevant, please provide further info:
> a)Long-Lived Domain-Validated SSL certs 
not relevant
> b)Wildcard DV SSL certs
not relevant
> c)Issuing end entity certs directly from root rather than using an offline root and issuing certs through a subordinate CA 
not relevant  - IGC/A root delivers only CA certificates, on an off line plate-form. 
> d)Allowing external entities to operate subordinate CAs – in this case need to
> demonstrate that the external entities are required to follow the CPS and are
> audited as such.
This is a legal requirement (see RGS/PRIS presentation document above).

> 7) Please see section 8, 9, and 10 of
> http://www.mozilla.org/projects/security/certs/policy/
> We need a publishable statement or letter from an auditor (who meets the policy
> requirements) that states that they have reviewed the practices as outlined in
> the CP/CPS for these roots, and that the CA does indeed follow these practices
> and meets the requirements of one of:
> •    ETSI TS 101 456
> •    ETSI TS 102 042
> •    WebTrust Principles and Criteria for Certification Authorities
> 
> I can’t read French, but the letter at
> http://www.legifrance.gouv.fr/WAspad/UnTexteDeJorf?numjo=PRMX0710016V seems to
> be of the right form, however I don’t see anything referring to ETSI or
> WebTrust.
No, this is an official notification for people willing to install IGC/A certificates, that gives information about IGC/A certificates. People can compare hashes from a trusted source (the official way to issue laws in France, is the “Journal officiel de la République Française”).
 
> Note that this can be a letter/statement that is posted into bugzilla, and then
> I will need to do an independent verification of the authenticity of the
> document by contacting the auditor directly.
An official letter was send to M. Hecker in 2007, in wich our director explained compatibility of our PKI to the webtrust CA standard, except for revocation. Since this date we have set up a revocation service, ARL is freely downloadable here : http://www.ssi.gouv.fr/fr/sigelec/igca/revocation/igca.crl

The official decision for IGC/A homologation is published here : 
http://www.ssi.gouv.fr/fr/sigelec/igca/igca-homologation.pdf

IMPORTANT! 
Please close our request for the DSA certificate – the key was created for backup purpose in case of a cryptographic matter with RSA. It hasn’t be used yet, and we will soon use another key for this purpose. Then there is no need to include the DSA certificate anymore.

Thanks
Florence

Comment 26

[Kathleen Wilson]

Hi Florence,

Next time I am in Paris, I would be privileged to meet you.

Thank you for the information. 

Is the following a correct/fair summary for this root?
“This is the root certificate of the French Government CA. The IGC/A root issues a subordinate CA for each organization, which can be either a government organization or a private company. 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/PRIS, and be audited.”

> Section 7 of Mozilla CA Certificate Policy
I have been unable to download the PRIS documents as per 
http://www.synergies-publiques.fr/article.php?id_article=381 
because the website
http://synergies.modernisation.gouv.fr/
is timing out. I will have to try again another day.

Based on the information that you provided, it is clear that identity of the subscriber is checked. However, can you point me to the text that states that the email address is verified to be owned/controlled by the subscriber as per section 7b of  http://www.mozilla.org/projects/security/certs/policy/:
“for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf”

> Audit Requirements of Mozilla CA Certificate Policy
It’s not yet clear to me how the audit requirements of sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/ have been met.
We need a publishable statement or letter from an auditor (who meets the policy requirements of being independent from the CA) that states that they have reviewed the practices as outlined in the CP/CPS for these roots, and that the CA does indeed follow these practices and meets the requirements of one of:
ETSI TS 101 456
ETSI TS 102 042
WebTrust Principles and Criteria for Certification Authorities

Google translation of this document
http://www.ssi.gouv.fr/fr/sigelec/igca/igca-homologation.pdf
is: “On the favorable opinion of the Committee for approval of the IGC / A cited reference, I declare the approval of the platform project IGC / A for five years.” This doesn’t state compliance with one of the policies listed above. Also, this is signed by Patrick Pailloux who works at DCSSI?

Thanks,
Kathleen

Comment 27

[IGCA Contact]

(In reply to comment #26)
>Hi Kathleen,

> Is the following a correct/fair summary for this root?
Not really, because we do not sign CA for private company. A correct summary could be the following:
“This is the root certificate of the French Government CA. The IGC/A root
issues a subordinate CA for each organization, which can be only a government or an administrative organization. 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/PRIS, and be audited.”

> > Section 7 of Mozilla CA Certificate Policy
> I have been unable to download the PRIS documents as per 
> http://www.synergies-publiques.fr/article.php?id_article=381 
> because the website
> http://synergies.modernisation.gouv.fr/
> is timing out. I will have to try again another day.
Indeed - Sorry.
There is a link problem on the synergies-publiques.fr website. If you want to download PRIS document you have to change the beginning of the URL synergies.modernisation.gouv.fr/ by www.synergies-publiques.fr/ . For example for the CP dealing with signature the correct link is (http://www.synergies-publiques.fr/IMG/pdf/PRISv2.1_-_PC-Type_Signature.pdf)

> Based on the information that you provided, it is clear that identity of the
> subscriber is checked. However, can you point me to the text that states that
> the email address is verified to be owned/controlled by the subscriber as per
> section 7b of  http://www.mozilla.org/projects/security/certs/policy/:
The RA (AE in French) is responsible of verifying information concerning the certificate holder, then this include verifying the association with email address - see p.12 of : http://www.synergies-publiques.fr/IMG/pdf/PRISv2.1_-_PC-Type_Signature.pdf :

I.3.2. Registration Authority
RA must verify identity of the futur end-entity. To do this, RA must :
- (for certificates delivered to an end-entity belonging to a private company or a government organization) take into account and verify information about end-entity and about the organization or company the end-entity belongs to, and constitute the corresponding registration file 
- (for certificates delivered to an end-entity belonging to a private company or a government organization) if relevant, take into account and verify information about the future certification delegate and about the entity it belongs to, and constitute the corresponding registration file
- (for a citizen) take into account and verify information about end-entity, and constitute the corresponding registration file.

In addition, see p26, III.3.2.3.2 End-entity registration:
(for certificates delivered to an end-entity belonging to a private company or a government organization)
The registration file, directly given to the RA, must be composed at least by:
- a written certificate application, signed and send before 3 months by a legal representative of the entity
- a mandatory, signed and send before 3 months by a legal representative of the entity which can nominate the end-entity subject of the certificate. This mandatory must be signed by the end-entity. 

See also p32  
4.  Certificate Life-Cycle Operational Requirements
4.2.  Certificate Application Processing 
Ch.4.2.1:
RA must : 
[..]
- check coherence of relevant documents ;
[..]

I translated "vérifier la cohérence des justificatifs présentés" as "check coherence of relevant documents". These "relevant documents" are in fact all pieces of the registration file, including e-mail adress.

Consequently : 
- the RA verify e-mail adress like any other information about end-entity and about the organization or company the end-entity belongs to, 
- an end-entity submitting the request can't give an e-mail adress without the agreement of the legal representative of the organization the end-entity belongs to and vice-versa.
 
> > Audit Requirements of Mozilla CA Certificate Policy
> It’s not yet clear to me how the audit requirements of sections 8, 9, and 10 of [..]
We audit the IGC/A conformity to "WebTrust Principles and Criteria for Certification Authorities" in AICPA/CICA WebTrust Program for Certification Authorities, Version 1.0, as explained formerly to M.Hecker in an official letter (that can't be issued on bugzilla because of the phone numbers and names indicated). It mentionned in 2007 :
« Our analysis has not revealed any major points contravening the Mozilla foundation’s v1.0 certification policy, defining the conditions of use and management of certificates listed in its products. The revocation, in the “General, 33” criteria, of the “WebTrust CA” audit guide, has not been taken into account by the current IGC/A platform, which therefore does not generate a list of revoqued certificates. It will be dealt with in the framework of phase 2 of the IGC/A, which is being developped. » 
The revocation service has been developped and works for many months.

> http://www.ssi.gouv.fr/fr/sigelec/igca/igca-homologation.pdf
> is: “On the favorable opinion of the Committee for approval of the IGC / A
> cited reference, I declare the approval of the platform project IGC / A for
> five years.” This doesn’t state compliance with one of the policies listed
> above. Also, this is signed by Patrick Pailloux who works at DCSSI?

The letter is signed by the Director of the DCSSI. The DCSSI is the French National Communication Security Agency which is part of the French national security agency. That's why DCSSI is internationally recognized as competent party as defined in Mozilla requirements section 9 (see http://www.ssi.gouv.fr/en/dcssi/index.html).

Best regards
Florence

Comment 28

[Kathleen Wilson]

The website for the PRIS documents has apparently been moved.  Would you please send me the new URL for the PRIS documents?

Comment 29

[IGCA Contact]

(In reply to comment #28)
> The website for the PRIS documents has apparently been moved.  Would you please
> send me the new URL for the PRIS documents?

Hello Kathleen,

Indeed a new version of PRIS has been published (v2.2).
Please find the new URL for the PRIS documents :
Brief presentation of the PRIS : http://www.synergies-publiques.fr/IMG/pdf/061129_PRIS_US_ENISA.pdf

The page where all documents of PRIS 2.2 are now available :
http://www.synergies-publiques.fr/article.php?id_article=945

Especially 
Variables de temps (for CRL frequency update)
http://www.synergies-publiques.fr/IMG/pdf/RGS_Variables_de_temps_V2.1.pdf

PC-Type authentification servers (for SSL)
http://www.synergies-publiques.fr/IMG/pdf/RGS_Service_Authentification_Serveur_V2.2.pdf

PC-Type authentification 
http://www.synergies-publiques.fr/IMG/pdf/RGS_PC-Type_Authentification_V2.2.pdf

Profiles de certificats, LCR et OCSP
http://www.synergies-publiques.fr/IMG/pdf/RGS_Profils_Certificat_LCR_OCSP_V2_2.pdf

PC-Type cachet server
http://www.synergies-publiques.fr/IMG/pdf/RGS__PC-Type_Cachet_Serveur_V2.2.pdf

PC-type signature : http://www.synergies-publiques.fr/IMG/pdf/RGS_PC-Type_Signature_V2.2.pdf
(PRIS 2.1 documents I mentionned are still available :
http://www.synergies-publiques.fr/IMG/pdf/PRISv2.1_-_PC-Type_Signature.pdf)

Best regards

Florence

Comment 30

[Kathleen Wilson]

In the new documents, please tell me which document url and section number has the text stating that the domain name is verified to be owned/controlled by the subscriber.

Comment 31

[IGCA Contact]

(In reply to comment #30)
> In the new documents, please tell me which document url and section number has
> the text stating that the domain name is verified to be owned/controlled by the
> subscriber.
Hello Kathleen,

Sorry for the mistake about the URL.
For SSL, the following document describes how to verify that the domain referenced in the certificate is owned/controlled by the certificate subscriber. 

See : http://www.synergies-publiques.fr/IMG/pdf/RGS__PC-Type_Authentification_Serveur_V2.2.pdf
(also available at the URL http://www.references.modernisation.gouv.fr/sites/default/files/RGS_%20PC-Type_Authentification_Serveur_V2_2.pdf)
Page 26 : (In French – please look at the end of this message for a short translation – N.B. : [Server-server] means the sentense concerns SSL/TLS servers, and “RCAS” means the one responsible for the SSL certificate as mentionned page 12)

Chapter III.2 explains conditions about identity. It precises that the RCAS must prove that the server belongs to the entity the RCAS represents, and that the domain name belongs to this entity.

« III.2. Validation initiale de l'identité
L'enregistrement d'un serveur auquel un certificat doit être délivré se fait via l'enregistrement du RCAS correspondant. Le RCAS devra notamment démontrer que ce serveur appartient bien à l'entité qu'il représente.
[SERVEUR-SERVEUR] Le RCAS devra aussi démontrer que le nom de domaine inclus dans le FQDN du serveur appartient bien à l'entité qu'il représente.
[…]
III.2.3. Validation de l'identité d'un individu
III.2.3.1. Enregistrement d'un RCAS sans MC pour un certificat d’authentification serveur à émettre
L'identification du futur RCAS (personne physique) représentant une entité nécessite, d'une part, l'identification de cette entité et, d'autre part, l'identification de la personne physique. S'agissant d'un certificat d’authentification serveur, le RCAS doit de plus être habilité en tant que RCAS pour le serveur informatique considéré et justifier que ce serveur appartient bien à cette entité.

[SERVEUR-SERVEUR] Le RCAS doit justifier que son entité de rattachement détient le nom de domaine auquel le FQDN du serveur informatique est rattaché.
Le dossier d'enregistrement, déposé directement auprès de l'AE, doit au moins comprendre :
[SERVEUR-SERVEUR] une demande de certificat écrite, datée de moins de 3 mois, signée par un représentant légal de l'entité et comportant le FQDN du serveur concerné par cette demande,
[…] »

Chapter IV explains that the RA must verify identity as defined in chapter III.2, and must check the FQDN : 
« IV.2. Traitement d'une demande de certificat
IV.2.1. Exécution des processus d'identification et de validation de la demande
Les identités "personne physique" et "personne morale" sont vérifiées conformément aux exigences du chapitre III.2.
L'AE, ou le MC le cas échéant, doit effectuer les opérations suivantes :
_ [SERVEUR-SERVEUR] valider le FQDN du serveur informatique auquel le certificat doit être rattaché ; 
[…]»

Short translation :

4.  Certificate Life-Cycle Operational Requirements
4.2.  Certificate Application Processing
4.2.1.Identication and validation of application process
Identities of persons are verified as described in chapter 3.2.

RA must :
- validate FQDN of the server the certificate delivered refers to

I hope this will help you.
Merry Christmas.
Florence

Comment 32

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 33

[Kathleen Wilson]

Assigning this bug back to Frank, as this completes the information gathering
and verification phase.  

For information about the next phase (public discussion) please see
https://wiki.mozilla.org/CA:Schedule

Items of Note:
The IGC/A root does not sign sub-CAs for private companies. The IGC/A root issues a subordinate CA for each organization, which can be only a government or an administrative organization. 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/PRIS, and be audited.
Some sub-CAs may be operated on behalf of the French administration. The RGS compels private operators to conform to RGS/PRIS profiles and to be referenced (certified by an accredited certification body).

Comment 34

[Kathleen Wilson]

I am now opening the first public discussion period for this request from DCSSI to add the IGC/A CA root certificate to Mozilla.

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

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-tech-crypto

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

Comment 35

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at

  http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add a new root CA certificate for IGC/A, which is a French Government CA operated by DCSSI. 

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by DCSSI, or of instances where they have knowingly issued certificates for fraudulent use. No concerns were raised during the comment period. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. DCSSI appears to provide a service relevant to Mozilla users: It’s a national government CA offering certificates to French Government websites which are used by the general public. 

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. Most of the documents are in French. The necessary sections were translated into English and the translations were verified.

There is a Certificate Policy specific to the IGC/A root:
http://www.ssi.gouv.fr/fr/sigelec/igca/igca-pc-v2.pdf

The IGC/A root and all of it’s subordinate CAs are also required to follow the French Government’s Repository General Security guidelines and the Politique de Référencement Intersectorielle de Sécurité (PRIS). There are different PRIS documents based on certificate usage.

A high level summary of the RGS/PRIS is provided in English at
http://www.synergies-publiques.fr/IMG/pdf/061129_PRIS_US_ENISA.pdf

Additional information about the RGS/PRIS policies can be found at
http://www.ssi.gouv.fr/fr/RGS/index.html
http://www.synergies-publiques.fr/IMG/pdf/RGS_PC-Type_Signature_V2.2.pdf
http://www.synergies-publiques.fr/IMG/pdf/RGS__PC-Type_Authentification_Serveur_V2.2.pdf
http://www.synergies-publiques.fr/IMG/pdf/RGS__PC-Type_Cachet_Serveur_V2.2.pdf

Section 7 [Validation]. DCSSI appears to meet the minimum requirements for subscriber verification, as follows:

* Email: As described in section 4.2.1 of RGS_PC-Type_Signature_V2.2.pdf, the RA must verify all pieces of the registration file including e-mail address and organization. An end-entity submitting the request cannot give an e-mail address without the agreement of the legal representative of the organization the end-entity belongs to.

* SSL: As described in chapters 3 and 4 of RGS__PC-Type_Authentification_Serveur_V2.2.pdf, the RA must prove that the server belongs to the entity the RCAS (the person responsible for the SSL certificate) represents, and that the domain name belongs to this entity. The RA must verify the identity of the RCAS and the organization, and validate the FQDN of the server the certificate refers to.

* Code: For code signing certificates the RA validates the identity of the certificate applicant as described in chapters 3 and 4 of RGS__PC-Type_Cachet_Serveur_V2.2.pdf

Section 8-10 [Audit]. Section 8-10 [Audit]. DCSSI has successfully completed audits that use criteria that are equivalent to the WebTrust for CAs criteria. The audits were done by the French Secretariat Général de la Défense Nationale, which acts as the French national security authority.

Section 13 [Certificate Hierarchy]. The IGC/A root issues a subordinate CA for each organization, which can be only a government or an administrative organization. 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/PRIS, and be audited.

Other: DCSSI issues CRLs on a 24-hour schedule.

Potentially problematic practices: The only relevant potentially problematic practice is in regards to allowing external entities to operate subordinate CAs. According to the IGC/A Certificate Policy section 1.4, subordinate CAs are only governmental CAs and administrative authorities. The subordinate CAs are required to follow the IGC/A certificate policy and the Government Laws of RGS/PRIS and be audited. They are constrained such that they can only create subordinate CAs for divisions within their organization. 

Based on this assessment I recommend that Mozilla approve this request to add the IGC/A Certificate Authority root certificate to NSS.

Comment 36

[Frank Hecker]

To Kathleen: Thank you for your work on this request.

To representatives of DCSSI: Thank you for your cooperation and your
patience.

To all others who have commented on this bug: Thank you for volunteering your
time to assist in reviewing this CA request.

I have reviewed the summary and recommendation in comment #35, and on behalf of
the Mozilla project I approve this request from DCSI to add the IGC/A Certificate Authority root certificate to NSS, with the trust bits for email, SSL, and code signing enabled.

Comment 37

[Frank Hecker]

Kathleen, I'm re-assigning this bug to you for the final steps. Could you please do the following:

1. File the necessary bug against NSS.
2. Mark this bug as dependent on the NSS bug.
3. When the NSS bug is complete, change the status of this bug to RESOLVED FIXED.

Thanks in advance!

Comment 38

[Kathleen Wilson]

I have filed bug 477147 against NSS for the actual changes.

Comment 39

[Fabio Pietrosanti (naif)]

Suggest a double check to verify if today, 8 December 2013, this CA is compliant with Mozilla's CA policy as per https://bugzilla.mozilla.org/show_bug.cgi?id=693450#c24

Comment 40

[Candida Burris]

Great post ! Just to add my thoughts , people want a TN new hire reporting , my colleague used a blank document here <a href="http://pdf.ac/4HY35M" >http://pdf.ac/4HY35M</a>.