ANSSI Root Inclusion Request for Renewed Root

[Kathleen Wilson]

ANSSI has applied 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 (bug #368970).

ANSSI (Agence nationale de la sécurité des systèmes d'information) is
the French Network and Information Security Agency, a part of the French
Government. It issues certificates for French Government websites, which
are used by the general public.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=693450

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#ANSSI%20(Government%20of%20France)

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=667137

Noteworthy points:

* The primary documents are the Référentiel Général de Sécurité (RGS)
and CP documents for each type of certificate issued, which are in French.

RGS Documents:
http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/

IGCA-PC: http://www.ssi.gouv.fr/IMG/pdf/IGCA_PC_v2-1.pdf
CP for SSL/TLS authentication certs:
http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Authentification_Serveur_V2-3.pdf
CP for e-sign certs for servers:
http://www.ssi.gouv.fr/IMG/pdf/RGS_PC-Type_Cachet_V2_3.pdf
CP for email certs for people working for the Foreign Affairs Ministry:
http://crl.diplomatie.gouv.fr/AC_Utilisateurs/AC_UTILISATEURS_PC_Signature_Agent_V1.5.pdf
CP for email certs for people working for another Administration working
with the Foreign Affairs Ministry:
http://crl.diplomatie.gouv.fr/AC_Utilisateurs/AC_UTILISATEURS_PC_Signature_Externe_V1.3.pdf
Variables de Temps:
http://www.ssi.gouv.fr/IMG/pdf/RGS_Variables_de_temps_V2-3.pdf
IGC/A FAQ:
http://www.ssi.gouv.fr/fr/menu/pied-de-page/aide-et-accessibilite/foire-aux-questions/faq-igc-a.html

CA Hierarchy Diagram:
https://bugzilla.mozilla.org/attachment.cgi?id=566036
(Note that another subCA has been created for Ministère de l'Intérieur.)

The IGC/A root issues subordinate CAs for government or administrative
organizations only. All subCAs are operated by French governmental IT
services and controlled by ISS services. Each of the 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.

The request is to turn on all three trust bits.

* Organizational verification is described in IGCA-PC section 3.2.
Translations:
3.2.2, Validating the identity of the administrative authority (AA)
… The AE of the IGC/A verifies that AA is an administrative authority
within the scope of application of this PC. If the information provided
was incomplete or insufficient to identify the AA, AE may request
additional information from the applicant (for example references a
decree specifying the public service mission or ministry AA, the
directory of the French administration, etc..), or contact a trusted
third party can identify the AA (eg Ministry of HFD or HFDS).
3.2.4 Validation of the identity of the applicant, agent or witness
3.2.6 Validation of Authority of Applicant
The AE of the IGC/A can contact the FSSI, the HFD or HFDS a relevant
ministry to ensure the authority of the applicant with the AA concerned
by the application.

* CP for SSL/TLS authentication certs:
** 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.
person 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."
** Page 26: In order for a certificate request to be accepted, the
request must include at least:
- A written certificate request, dated less than 3 months, signed by a
legal representative of the entity, mentioning 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
sub-delegation 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 address allowing the RA to contact the RCAS ;
- The general conditions of use signed.

** Comment: In addition, French governmental 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 ability
of a RCAS to manage SSL certificate.

* CP for email certs for people working for the Foreign Affairs Ministry:
** Section 3.1.2: email address must be of the form
surnam...@diplomatie.gouv.fr
** Section 4.1.2: Information required:
- The certificate profile;
- The full name of the bearer;
- The unique identifier (logon at OROBAS);
- The agent code (identifier at OROBAS);
- The email address of the bearer.
** Section 4.2.1: Validation of the certificate subscriber is done by
checking the database AROBAS, containing all agents’ e-mail addresses.
** Comment: According to IGCA-PC, as far as end entities are
administrative agents, the e-mail addresses are stored in Active or
e-mail servers directories. PKI refers 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 which is often the IT service.

* CP for email certs for people working for another Administration
working with the Foreign Affairs Ministry:
** Section 3.1.2: email address must be of the form
surnam...@domaine.fr
* Section 3.2.2: The identity of entities is verified. Indeed, carriers
are using their certificate(s) as part of their business within their
entity to which they depend and can legally bind that entity.
Certificates are issued only to holders belonging to entities related to
the Ministry (eg Matignon, Elysee, other department).
** Section 3.2.5: Validation of the authority of the Trustee shall be
effected by the Registration Authority.
** Section 4.1.2: Information required:
- The certificate profile;
- The full name of the bearer;
- The email address of the bearer.
- The connecting entity.
** Section 4.2.1: Validation of the certificate request is based on
prior knowledge by the EA that the representative is authorized to
forward requests of certificates.

* EV treatment is not requested.

* Root Cert URL: http://www.ssi.gouv.fr/IMG/crt/igcaRSA4096-072011.crt

* Test Website: https://test4096.igc.agriculture.gouv.fr/

* CRL
http://www.ssi.gouv.fr/fr/sigelec/igca/revocation/igca4096.crl
http://igc-crl.agriculture.gouv.fr/crl/crl-ac-serveurs-standard.crl
(NextUpdate: 6 days)
Variables de Temps document: F_PUB_LCR = Minimal frequency of
publication of the CRL = 72 hours or 24h)

* OCSP: Not provided.

* Audit: The audits are done by the French Secretariat Général de la
Défense Nationale, which acts as the French national security authority,
according to the ETSI TS 102042 criteria.
http://www.ssi.gouv.fr/site_rubrique31.html
http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/attestation-audits.html
https://bug666771.bugzilla.mozilla.org/attachment.cgi?id=661038

* Potentially Problematic Practices – None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices):

This begins the discussion of the request from ANSSI to add the “IGC/A
AC racine Etat francais” root certificate and turn on all three trust
bits. At the conclusion of this discussion I will provide a summary of
issues noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

[Kathleen Wilson]

All,

Please reply in this discussion if you any concerns or comments
regarding this request to include the renewed the French Government
IGC/A root cert?

Kathleen

[Kathleen Wilson]

May I interpret the lack of input into this discussion about this
request to included a renewed root from the French Government to mean
that there are no concerns, and that I may close this discussion and
recommend approval in the bug?

Thanks,
Kathleen

[Erwann Abalea]

Le mardi 2 octobre 2012 22:38:45 UTC+2, Kathleen Wilson a écrit :
[...]

> * Test Website: https://test4096.igc.agriculture.gouv.fr/

This certificate shows that no entropy is provided in the serial numbers. At least 20 bits of entropy is mandatory.

The certificatePolicies chaining is not coherent.
Starting from the root down to the subscriber certificate, here are the policyIds found:
1.2.250.1.223.1.1.2 IGC/A AC racine Etat francais (useless for a trust anchor)
1.2.250.1.223.1.1.1 AC RACINE MINISTERE EN CHARGE DE L'AGRICULTURE
1.2.250.1.134.1.1.10 AC SERVEURS STANDARD
1.2.250.1.134.1.1.15.1 test4096.igc.agriculture.gouv.fr

It means that the IGC/A root has constrained "AC RACINE MINISTERE EN CHARGE DE L'AGRICULTURE" to only 1 policyId (...223.1.1.1), but this CA certified the CA "AC SERVEURS STANDARD" with a constraint on possible policyIds to be ...134.1.1.10 (so not in-scope with its own constraint), and this later CA has produced a certificate with another policyId ...134.1.1.15.1.
I don't know how it is handled by libPKIX (probably right), and I don't how it will be handled regarding CABForum evolutions on DV/OV OIDs.

> * OCSP: Not provided.

Has Mozilla adopted the Baseline Requirements yet, or is it still a work in progress?
The BR say that OCSP is a MUST for subscriber certificates.

> * Audit: The audits are done by the French Secretariat Général de la
> Défense Nationale, which acts as the French national security authority,
> according to the ETSI TS 102042 criteria.

Can an audit performed by the SGDN on ANSSI be qualified as a third-party audit? SGDN and ANSSI both report to the same entity (our Prime Minister).
The supplied audit report also states that compliance to the CABForum BR has been audited, but no OCSP is present while being mandatory.

[ig...@ssi.gouv.fr]

First of all let me thank you for your interest in the integration of the French root certificate in Mozilla products.


You specify in your remarks that "At least 20 bits of entropy is mandatory". You are right. However,

it appears that the obligation of a 20 bits entropy in the serial number only concern SHA-1. Our PKI gave up this function in favour of SHA 256.


Furthermore, the certificatePolicies chaining remains consistent with certifications.

The OID arc of the French Ministry of agriculture is composed of the following items :
- a dedicated branch to regular uses whose eighth elements can go from 10 to 19 (number 15 identifies a certificate family for authentication servers) ;
- a branch for advanced uses whose eighth element of the OID arc can go from 20 to 29.

Concerning OCSP, Mozilla requirements (on the url : https://wiki.mozilla.org/CA:Communications) don't impose OCSP control for subscriber certificates. Such requirements concern EV certificates only. No EV certs are delivered.


Extract from the web site : “As per the CA / Browser Forum's Guidelines for EV Certs, CAs must Provide year OCSP capability for end-entity certificates That Are Issued Effective December 31, 2010. Mozilla is Considering technical ways to enforce this requirement OCSP Such That if Firefox cannot Obtain a valid response from the OCSP responder, then the certificate will not be Given EV treatment. Considering We are requiring the end-entity certificate To Provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122 # c23 Additionally, we urge all CAs OCSP To Provide for all certs, When They are not even EV.”

Security issues regarding national security impose that audits of the French root CA are carried out by the relevant government organization (ANSSI in that case). ANSSI splits audits and implementation activities between two independent teams.

[ig...@ssi.gouv.fr]

[Erwann Abalea]

Bonjour,

Le mardi 30 octobre 2012 16:55:01 UTC+1, ig...@ssi.gouv.fr a écrit :
> You specify in your remarks that "At least 20 bits of entropy is mandatory". You are right. However,
> it appears that the obligation of a 20 bits entropy in the serial number only concern SHA-1. Our PKI gave up this function in favour of SHA 256.

That's the rationale, adding entropy to help defeat a prefix-chosen collision for non collision resistant hash functions. I agree that using SHA256 without entropy isn't a problem in a near future. However, the Mozilla Policy doesn't say that; the entropy is mandatory for all new certificates, the used hash function isn't taken into consideration.
This isn't a blocker for this inclusion request if SHA1 is forbidden in the hierarchy.

I haven't found where in the CP/CPS is stated that SHA1 isn't an acceptable hash algorithm for certificates. Moreover, in RGS-A-14 document (http://references.modernisation.gouv.fr/sites/default/files/RGS_Profils_Certificat_LCR_OCSP_V2_3.pdf, clause V), it is said that SHA1 is acceptable for legacy applications support.

> Furthermore, the certificatePolicies chaining remains consistent with certifications.
>
> The OID arc of the French Ministry of agriculture is composed of the following items :
>
> - a dedicated branch to regular uses whose eighth elements can go from 10 to 19 (number 15 identifies a certificate family for authentication servers) ;
> - a branch for advanced uses whose eighth element of the OID arc can go from 20 to 29.

The chaining may be consistent with certifications, but you may read X.509, clause 8.2.2.6. Here's an excerpt:
-----
The presence of this extension in an end- entity certificate indicates the certificate policies for which this certificate is valid. The presence of this extension in a certificate issued by one CA to another CA indicates the certificate policies for which certification paths containing this certificate may be valid.
-----

What it means it that the certificatePolicies of a CA certificate doesn't have to contain the CP OID of this CA, but the acceptable CP OIDs of end-user certificates.

If you follow the normalized path validation algorithm (clause 10) with this chain, the result will be a valid certificate with an empty list of valid policies. The algorithm is worded differently in RFC5280 but the result is identical.

> Concerning OCSP, Mozilla requirements (on the url : https://wiki.mozilla.org/CA:Communications) don't impose OCSP control for subscriber certificates. Such requirements concern EV certificates only. No EV certs are delivered.
>
> Extract from the web site : “As per the CA / Browser Forum's Guidelines for EV Certs, CAs must Provide year OCSP capability for end-entity certificates That Are Issued Effective December 31, 2010. Mozilla is Considering technical ways to enforce this requirement OCSP Such That if Firefox cannot Obtain a valid response from the OCSP responder, then the certificate will not be Given EV treatment. Considering We are requiring the end-entity certificate To Provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122 # c23 Additionally, we urge all CAs OCSP To Provide for all certs, When They are not even EV.”

You're right in that Mozilla doesn't require OCSP to be activated for *all* subscriber certificates.
However, the audit attestation (https://bug666771.bugzilla.mozilla.org/attachment.cgi?id=661038) mentions compliance to CABForum Baseline Requirements v1.0 in a surveillance audit, and this BR states that OCSP is mandatory for subscriber certificates.

> Security issues regarding national security impose that audits of the French root CA are carried out by the relevant government organization (ANSSI in that case). ANSSI splits audits and implementation activities between two independent teams.

I'll let others show their opinion on wether ANSSI-audit team auditing ANSSI-implementation team is acceptable as a qualified third-party audit. A check of other governmental CAs applications might help.

[Kathleen Wilson]

On 11/1/12 9:26 AM, Erwann Abalea wrote:
> Bonjour,
>
> Le mardi 30 octobre 2012 16:55:01 UTC+1, ig...@ssi.gouv.fr a écrit :
>> You specify in your remarks that "At least 20 bits of entropy is mandatory". You are right. However,
>> it appears that the obligation of a 20 bits entropy in the serial number only concern SHA-1. Our PKI gave up this function in favour of SHA 256.
>
> That's the rationale, adding entropy to help defeat a prefix-chosen collision for non collision resistant hash functions. I agree that using SHA256 without entropy isn't a problem in a near future. However, the Mozilla Policy doesn't say that; the entropy is mandatory for all new certificates, the used hash function isn't taken into consideration.

That's correct.
http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
item #9, last sub-bullet: "all new end-entity certificates must contain
at least 20 bits of unpredictable random data (preferably in the serial
number)."

> This isn't a blocker for this inclusion request if SHA1 is forbidden in the hierarchy.

Agreed.

>
> I haven't found where in the CP/CPS is stated that SHA1 isn't an acceptable hash algorithm for certificates. Moreover, in RGS-A-14 document (http://references.modernisation.gouv.fr/sites/default/files/RGS_Profils_Certificat_LCR_OCSP_V2_3.pdf, clause V), it is said that SHA1 is acceptable for legacy applications support.
>

Good point. Needs to be addressed -- if SHA1 certs aren't allowed within
the hierarchy, then it should be documented in the CP/CPS.

>> Furthermore, the certificatePolicies chaining remains consistent with certifications.
>>
>> The OID arc of the French Ministry of agriculture is composed of the following items :
>>
>> - a dedicated branch to regular uses whose eighth elements can go from 10 to 19 (number 15 identifies a certificate family for authentication servers) ;
>> - a branch for advanced uses whose eighth element of the OID arc can go from 20 to 29.
>
> The chaining may be consistent with certifications, but you may read X.509, clause 8.2.2.6. Here's an excerpt:
> -----
> The presence of this extension in an end- entity certificate indicates the certificate policies for which this certificate is valid. The presence of this extension in a certificate issued by one CA to another CA indicates the certificate policies for which certification paths containing this certificate may be valid.
> -----
>
> What it means it that the certificatePolicies of a CA certificate doesn't have to contain the CP OID of this CA, but the acceptable CP OIDs of end-user certificates.
>
> If you follow the normalized path validation algorithm (clause 10) with this chain, the result will be a valid certificate with an empty list of valid policies. The algorithm is worded differently in RFC5280 but the result is identical.
>

This needs to be further explained/resolved.

>> Concerning OCSP, Mozilla requirements (on the url : https://wiki.mozilla.org/CA:Communications) don't impose OCSP control for subscriber certificates. Such requirements concern EV certificates only. No EV certs are delivered.
>>
>> Extract from the web site : “As per the CA / Browser Forum's Guidelines for EV Certs, CAs must Provide year OCSP capability for end-entity certificates That Are Issued Effective December 31, 2010. Mozilla is Considering technical ways to enforce this requirement OCSP Such That if Firefox cannot Obtain a valid response from the OCSP responder, then the certificate will not be Given EV treatment. Considering We are requiring the end-entity certificate To Provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122 # c23 Additionally, we urge all CAs OCSP To Provide for all certs, When They are not even EV.”

This quote is from the CA Communication that was sent on October 11,
2010. This wiki page is for historical purposes, so old CA
Communications listed in this page will not be updated, though their
content may become outdated.

However, this reminded me to update the Recommended Practices wiki page
regarding OCSP...
https://wiki.mozilla.org/CA:Recommended_Practices#OCSP

>
> You're right in that Mozilla doesn't require OCSP to be activated for *all* subscriber certificates.
> However, the audit attestation (https://bug666771.bugzilla.mozilla.org/attachment.cgi?id=661038) mentions compliance to CABForum Baseline Requirements v1.0 in a surveillance audit, and this BR states that OCSP is mandatory for subscriber certificates.
>

BR #13.2.2: "The CA SHALL update information provided via an Online
Certificate Status Protocol..."

BR Appendix B regarding authorityInformationAccess in Subordinate CA
Certificate and Subscriber Certificate: "With the exception of stapling
.... this extension MUST be present ... and it MUST contain the HTTP URL
of the Issuing CA’s OCSP responder"

So it is concerning that the audit statement mentions compliance to the
CA/Browser Forum Baseline Requirements without noting the exception.

>> Security issues regarding national security impose that audits of the French root CA are carried out by the relevant government organization (ANSSI in that case). ANSSI splits audits and implementation activities between two independent teams.
>
> I'll let others show their opinion on wether ANSSI-audit team auditing ANSSI-implementation team is acceptable as a qualified third-party audit. A check of other governmental CAs applications might help.
>

I recall there being discussion about this when their root was first
included in 2009 (https://bugzilla.mozilla.org/show_bug.cgi?id=368970),
but I can't find the discussion thread. My recollection is that it was
determined that the auditing organization was separate from the group
that operated the root certificate, even though they are both part of
the French Government.

Thanks,
Kathleen

[Kathleen Wilson]

On 10/2/12 1:38 PM, Kathleen Wilson wrote:

> ANSSI has applied 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 (bug #368970).
>
> ANSSI (Agence nationale de la sécurité des systèmes d'information) is
> the French Network and Information Security Agency, a part of the French
> Government. It issues certificates for French Government websites, which
> are used by the general public.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=693450
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#ANSSI%20(Government%20of%20France)
>
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=667137

I am closing 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