844163 - Add CSOEC root certificate

Status: RESOLVED WONTFIX

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

Description

[Samuel Lacas]

Attachment: CA's Information checklist (filled)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130215130331

Steps to reproduce:

CA Company/Organization Name: Conseil Supérieur de l'Ordre des Experts-Comptables (CSOEC)

Website: https://www.signexpert.fr

Summary of CA Company/Organization:

The « Ordre des Experts-Comptables », OEC, (French Institute of Certified Public Accountants), is a public body supervised administratively by the Minister of Finance which represents the French certified public accountants (« expert-comptable » in french) in public practice.
The OEC consists of a national body, the « Conseil Supérieur de l’Ordre des Experts-Comptables » (CSOEC, Certified Public Accountants National Council), and regional bodies – the Regional Councils – covering metropolitan France and the overseas departments and territories.
These councils are headed by representatives elected by members of the profession.

Each of the national body and the 25 regional bodies is considered as a separate CA issuing end-entity certificates : the regional bodies issue certificates for the certified public accountants within their region, and the national body issues certificates for the order's elected representatives.

Audit Type (WebTrust, ETSI etc.): ETSI/TS101456 V1.4.3,"Policy Requirements for certification authorities issuing qualified certificates” with QCP public+SSCD profile

Auditor: LSTI
Auditor Website: http://www.lsti-certification.fr/
Audit Document URL(s): http://lsti-certification.fr/index.php/les-normes-etsi/les-listes.html


Actual results:

Primary Market / Customer Base
The Signexpert certificates are exclusively issued to the active members of the OEC.
Only members of the OEC may keep, centralize, open, close, monitor, adjust and consolidate the accounts of entities to which they are not linked by an employment contract and carry out contractual audits.
Beyond these regulated engagements, Certified Public Accountants provide advisory services to their clients, e.g., payroll, and to some extent tax advice and legal services.
There are currently more than 18,900 individual French Certified Public Accountants and 15,600 accounting firms in France.

Are there particular vertical market segments in which it operates?
By definition, the  French Certified Public Accountants addresses the accounting services' market.

Does the CA focus its activities on a particular country or other geographic region?
The OEC's CA's exclusively cover  metropolitan France and the overseas departments and territories.

Technical information about the root certificate

Certificate Name: C=FR, O=Ordre des Experts-Comptables, OU=0002 775670003, CN=Ordre des Experts-Comptables

Certificate Issuer Field: The issuer's Organization Name and CN contain the order's official name. That is completed by the Organization Unit's field which, as required by the RGS certification scheme (see below), requires the OU to conform to the ISO/IEC 6523. It thus contain the issuer's International Code Designator (ICD) number and an entity number, both forming a word-wide unique registration number. 
The entity number is, herein, the « sirene » number of the Order, an official number given to enterprises and legal bodies by the French institute of statistics (INSEE). See http://www.cyber-identity.com/download/ICD-list.pdf for a presentation of the scheme.

Certificate Summary: That certificate is the root certificate for the OEC's PKI.
Root Cert URL : https://www.signexpert.fr/cms/index.php/content/download/770/3228/version/1/file/AC-R.cer

SHA1 Fingerprint : 82719a769d88182c70b9c0c924736bd7a711cfc7

Valid From : 2011-05-09
Valid To : 2031-05-09
Certificate Version : 3
Certificate Signature Algorithm : sha256WithRSAEncryption
Signing key parameters : RSA  4096 bits

CRL URL
The CRL's end-entity certs' URL are : 
http://seec.experts-comptables.fr/CRL/CRL_ALSACE.crl
http://seec.experts-comptables.fr/CRL/CRL_AQUIT.crl
http://seec.experts-comptables.fr/CRL/CRL_AUVERGN.crl
http://seec.experts-comptables.fr/CRL/CRL_B-FC.crl
http://seec.experts-comptables.fr/CRL/CRL_BRETAGNE.crl
http://seec.experts-comptables.fr/CRL/CRL_CHAMPAG.crl
http://seec.experts-comptables.fr/CRL/CRL_CORSE.crl
http://seec.experts-comptables.fr/CRL/CRL_GPE.crl
http://seec.experts-comptables.fr/CRL/CRL_GUYANE.crl
http://seec.experts-comptables.fr/CRL/CRL_REUNION.crl
http://seec.experts-comptables.fr/CRL/CRL_LN-PCAL.crl
http://seec.experts-comptables.fr/CRL/CRL_LIMOGES.crl
http://seec.experts-comptables.fr/CRL/CRL_LORRAIN.crl
http://seec.experts-comptables.fr/CRL/CRL_MARSEIL.crl
http://seec.experts-comptables.fr/CRL/CRL_PACA.crl
http://seec.experts-comptables.fr/CRL/CRL_MARTINI.crl
http://seec.experts-comptables.fr/CRL/CRL_MONTPEL.crl
http://seec.experts-comptables.fr/CRL/CRL_ORLEANS.crl
http://seec.experts-comptables.fr/CRL/CRL_PAR-IDF.crl
http://seec.experts-comptables.fr/CRL/CRL_P-LOIRE.crl
http://seec.experts-comptables.fr/CRL/CRL_PIC-ARD.crl
http://seec.experts-comptables.fr/CRL/CRL_POITOU.crl
http://seec.experts-comptables.fr/CRL/CRL_RHO-ALP.crl
http://seec.experts-comptables.fr/CRL/CRL_R-NORMA.crl
http://seec.experts-comptables.fr/CRL/CRL_MIDI-PY.crl
http://seec.experts-comptables.fr/CRL/CRL_CSOEC.crl

OCSP URL (Required now)
OCSP URI in the AIA of end‐entity certs: http://ocsp.experts-comptables.fr/OEC
NextUpdate for CRLs of end‐entity certs is 3 days after the issuance date. In the CP, the announced value is 1 day (24 hours).

Maximum expiration time of OCSP responses: 3 months
Requested Trust Bits: Email (Public accountants sign documents on a daily basis, including e-mails)



Expected results:

More detailed information can be found in the attached file (e.g. the CA's hierarchy), which follows the https://wiki.mozilla.org/CA:Information_checklist.

Comment 1

[David E. Ross]

Are you requesting the addition of 26 root certificates -- 25 regional and one national -- to the NSS database?

Comment 2

[Samuel Lacas]

(In reply to David E. Ross from comment #1)
> Are you requesting the addition of 26 root certificates -- 25 regional and
> one national -- to the NSS database?

No : there is only one root certificate (that of the Order). The 25 regional and the national CA's are subCA of the root ; that would have been both impracticable to manage that number of root certificate and contrary to security practices (to have root CA's to issue end-user certificates).

Comment 3

[Kathleen Wilson]

I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 4

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 5

[Samuel Lacas]

Inclusion in other major CA trust lists Does this CA have root certificates included in any other major trust lists (e.g.  Microsoft, Apple, etc)?  If yes, which?  If no, why not?

We have no root certificate yet included in any other major trust lists, but we have asked for inclusion in Adobe's AATL and Microsoft Root Certificate Program at the same time we started the current process with the Mozilla Foundation. The reviewing process is on its way.

Example Certificate (non-SSL) Please attach the sample cert with chain to the bug.

Indeed, the certificate I provided did not contained the chain. The attached PKCS#12 file (no key, no password) contains the chain up to the root.

Distributing generated private keys in PKCS#12 files ?

That is an oversight of mine. That is not applicable to us : we provide qualified certificates. As such, the private keys are generated and stored into EAL4+ CC-evaluated hardware tokens, and we do not distribute software keys/certificate in any case (doing so would be a major violation of the ETSI/TS101456 and would immediately nullify our conformance assessment).

Comment 6

[Samuel Lacas]

Attachment: Example Certificate (non-SSL) with chain (PKCS#12 format)

As requested by Comment #4 (Kathleen Wilson 2013-06-25 14:15:04 PDT)

Comment 7

[Kathleen Wilson]

Please make sure the example certificate (test cert) and password can be publicly disclosed and added to this bug, so that whomever evaluates this request during the public discussion phase can examine the cert and chain.

I was just reviewing your initial information again (Attachment #717173 [details]), and am a little confused about something...
Under the Multi-factor Authentication section it says: "but certificate issuance
is indeed strictly limited by the Certification Policy to a pre-approved domain of subscribers: as explained above,..."
What is the "as explained above" referring to?

The email address verification procedures describe an online subscription form and an email challenge-response mechanism to prove that the certificate subscriber owns/controls the email address to be included in the certificate. 
Is that online subscription form the same for all of the issuing CAs? Is it controlled by CSOEC? Or can each issuing CA have their own online subscription form?
Similar questions about the email challenge-response mechanism -- is it required of all of the issuing CAs? Managed by CSOEC? Or managed by each issuing CA independently?

Comment 8

[Samuel Lacas]

(In reply to Kathleen Wilson from comment #7)
> Please make sure the example certificate (test cert) and password can be
> publicly disclosed and added to this bug, so that whomever evaluates this
> request during the public discussion phase can examine the cert and chain.

Jean Saphores is a public figure of the CSOEC and has used his certificate to sign, for instance, some of the Certification Policies of the CSOEC. I can thus assure you that this certificate is already publicly disclosed and can be examined by anyone.

> I was just reviewing your initial information again (Attachment #717173 [details]
> [details]), and am a little confused about something...
> Under the Multi-factor Authentication section it says: "but certificate
> issuance
> is indeed strictly limited by the Certification Policy to a pre-approved
> domain of subscribers: as explained above,..."
> What is the "as explained above" referring to?

You are right, this is a little too vague. This refers to the "Primary Market/Customer Base", which states that "The Signexpert certificates are exclusively issued to the active members of the OEC."
 
> The email address verification procedures describe an online subscription
> form and an email challenge-response mechanism to prove that the certificate
> subscriber owns/controls the email address to be included in the
> certificate. 
> Is that online subscription form the same for all of the issuing CAs? Is it
> controlled by CSOEC? Or can each issuing CA have their own online
> subscription form?
> Similar questions about the email challenge-response mechanism -- is it
> required of all of the issuing CAs? Managed by CSOEC? Or managed by each
> issuing CA independently?

The online subscription form is the same for all the issuing CAs. That web portal (www.signexpert.fr) is managed by the CSOEC, and the enrolment/renewal/revocation process are the same for all the CAs. The OEC had to technically create one CA for each of the OEC's regional bodies because of legal questions (the OEC's structure comes from a French regulation dating back to 1945) but, for what pertains to processes, management and certificates' life-cycle, everything is actually defined, managed and controlled by the CSOEC and, of course, unified : there is no reason to have distinct processes between regions/CAs, and there is none, indeed.
All the regional registration authorities use the very same web portal to manage their own "flock" of certificate owners.
I hope this is clearer for you.
Do not hesitate to ask for details (please note, however, that I will be unable to log in between the 27th of July and the 10th of August).

Comment 9

[Kathleen Wilson]

Two things I'm having trouble with:

1) Importing a sample cert so I can view it and the hierarchy in the cert manager. (The one attached to this bug requires a password to import it, so probably not the right thing.) When I tried to import the other cert that was provided, it said the issuer wasn't trusted, so I must need an intermediate cert too. 

2) Finding the audit statement on the LSTI website. Maybe they changed their website?
I found a list (http://www.lsti-certification.fr/images/liste_entreprise/liste%20RGS_ETSI.pdf) with rows under "Conseil Supérieur de l’Ordre des Experts Comptables" that correspond with this CA Hierarchy.
What does: "Arrêté du 26 juillet 2004" mean?
Is an annual audit required to maintain a status of "Valide"? If yes, where on the LSTI website is that stated?
Is there an ETSI certificate? Or is this list the only statement of audit status?

Comment 10

[Samuel Lacas]

(In reply to Kathleen Wilson from comment #9)
> Two things I'm having trouble with:
> 
> 1) Importing a sample cert so I can view it and the hierarchy in the cert
> manager. (The one attached to this bug requires a password to import it, so
> probably not the right thing.) When I tried to import the other cert that
> was provided, it said the issuer wasn't trusted, so I must need an
> intermediate cert too. 
The password for the PKCS#12 should be empty (that is, no password ; there is no private key in that file).

> 2) Finding the audit statement on the LSTI website. Maybe they changed their
> website?
> I found a list
> (http://www.lsti-certification.fr/images/liste_entreprise/liste%20RGS_ETSI.
> pdf) with rows under "Conseil Supérieur de l’Ordre des Experts Comptables"
> that correspond with this CA Hierarchy.
Yes, that is the only document they provide on the Web : they maintain the list of the CA's they have certified (audited).

> What does: "Arrêté du 26 juillet 2004" mean?
This column mentions whether the CA is also certified with respect to the French signature law.

> Is an annual audit required to maintain a status of "Valide"? 
Exactly.

> If yes, where on the LSTI website is that stated?
The ETSI certification process is described here : http://lsti-certification.fr/index.php/les-normes-etsi/etsi-ts-101-456.html (they also mention there that the "Arrêté" has a little more requirements than the ETSI 101 456).
The last part of the process is indeed "Le suivi annuel" (the annual maintainance) : "La qualification est valide trois ans, sous réserve d'une surveillance annuelle" (The certification is valid for three years, assuming that an annual audit is performed). 

> Is there an ETSI certificate? Or is this list the only statement of audit
> status?
That list is indeed the only statement of audit from LSTI. I will ask the CSOEC if they have an ETSI certificate (I think I saw one once).

Comment 11

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 12

[Kathleen Wilson]

I'll try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 13

[Samuel Lacas]

Attachment: ETSI_Diplome_0392_001.pdf

Here is a scan of the ETSI-compliance certificate that LSTI provided to the CSOEC (it is in both French and English and you have the issuance date and validity period in the upper right corner).

Comment 14

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 15

[Kathleen Wilson]

I am now opening the first public discussion period for this request from CSOEC to include the “Ordre des Experts-Comptables” root certificate, and enable the email trust bit.

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.

The discussion thread is called “CSOEC Root Inclusion Request”.

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

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

Comment 16

[Kathleen Wilson]

Samuel, Are you the official representative for the CA services offered by CSOEC?

Comment 17

[Samuel Lacas]

Kathleen,

No, I do not belong to the CSOEC. As you suggested in your e-mail, I have asked the CSOEC's CA to create an account at bugzilla so he may confirm herein ASAP that I work under their supervision.

Comment 18

[Samuel Lacas]

Attachment: CSOEC's delegation to Sealweb regarding root inclusion request

Here is a delegation letter from Jean Saphores, the root CA's official representative of the CSOEC. It is digitally signed with his electronic certificate (he is an elected member of the CSOEC ("Elus de l'Ordre des Experts-Comptables")).
Jean is the one who signs the certification policies before they are published on Signexpert's web site (see, for instance, https://www.signexpert.fr/PC/PC_Experts-Comptables.pdf).

Comment 19

[Kathleen Wilson]

Who will be the ongoing primary point of contact from CSOEC? This person will be responsible for providing updated audit statements annually, and responding to CA Communications (https://wiki.mozilla.org/CA:Communications). See http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html items #4, #5, #6, and #7.

Comment 20

[Samuel Lacas]

I think that the most appropriate person is the Signexpert project manager : 

Mathieu Jorry
[e-mail]

Comment 21

[Samuel Lacas]

(In reply to Samuel Lacas from comment #20)
> I think that the most appropriate person is the Signexpert project manager : 
> 
> Mathieu Jorry
> [e-mail]

After thought, the generic e-mail "[e-mail]" may be more appropriate for CA Communications.

Comment 22

[David E. Ross]

(In reply to Samuel Lacas from comment #21)
> After thought, the generic e-mail "[e-mail]" may
> be more appropriate for CA Communications.  

I strongly object to placing any trust into a generic E-mail address.  The processing of a request to add a root certificate to the NSS database requires trust.  That means someone in authority at the CA -- someone who (1) can speak on behalf of the CA, (2) can make commitments binding on the CA, and (3) can direct action be taken by the CA in response to the Mozilla review -- needs to be the point of contact.  This means a live, corporeal (not corporate) individual.

Comment 23

[Samuel Lacas]

(In reply to David E. Ross from comment #22)
> (In reply to Samuel Lacas from comment #21)
> > After thought, the generic e-mail "[e-mail]" may
> > be more appropriate for CA Communications.  
> 
> I strongly object to placing any trust into a generic E-mail address.  The
> processing of a request to add a root certificate to the NSS database
> requires trust.  That means someone in authority at the CA -- someone who
> (1) can speak on behalf of the CA, (2) can make commitments binding on the
> CA, and (3) can direct action be taken by the CA in response to the Mozilla
> review -- needs to be the point of contact.  This means a live, corporeal
> (not corporate) individual.

Simply do not confuse the individual and the emailbox : today, Mathieu is the guy who is in charge of these tasks. Tomorrow, that may change, or Mathieu may be ill, on vacation, attending some CSOEC regional meeting where he cannot check his mailbox or whatever. And because, indeed, these tasks do mean responsibility, Mathieu will refer to other people at the CSOEC before making any commitment on behalf of the CA, people that have access to the generic e-mail.
The generic e-mail address is only a way to ensure that someone, should Mathieu be unable to answer, will at least get the message. The generic e-mail address is definitely not a redirection to /dev/null nor a way to "hide" whoever is in charge of the CA.

To sum up : the point of contact is Mathieu. He is a live individual, and you can reach him through both e-mail addresses. If you cannot or do not want to have two e-mail addresses, take the one you prefer, that's all.

Comment 24

[David E. Ross]

In some manner, each authorized representative of a CA should be vetted.  In the absence of an authorized representative of a CA, a specific individual must be identified and vetted as the substitute authorized representative.  

CAs should not be signing subscriber certificates presented by generic entities but only those presented by identified and authorized personnel.  Mozilla should take the same care in dealing with CAs that we expect CAs to take when dealing with subscribers.

Comment 25

[Kathleen Wilson]

Samuel,

Please explain why CSOEC CA needs to have their root certificate directly included in Mozilla’s products, rather than being signed by another CA’s root certificate that is already included in NSS (http://www.mozilla.org/projects/security/certs/included/). 
How do you foresee end-users benefiting by having the CSOEC CA certificate directly included in NSS?

Also, please have your contacts at CSOEC review and follow 
https://wiki.mozilla.org/CA:Information_checklist#CA_Primary_Point_of_Contact_.28POC.29

Comment 26

[Samuel Lacas]

Kathleen,
I'm working with the CSOEC on the answer to your questions and I come back ASAP.
I also have told Mathieu (the CA POC) to review that page, but I do not understand if you are currently expecting something from him (such as an e-mail confirming that he has read it) or not.

Comment 27

[Kathleen Wilson]

(In reply to Samuel Lacas from comment #26)
> I also have told Mathieu (the CA POC) to review that page, but I do not
> understand if you are currently expecting something from him (such as an
> e-mail confirming that he has read it) or not.

https://wiki.mozilla.org/CA:Information_checklist#CA_Primary_Point_of_Contact_.28POC.29
"If the CA uses a contractor as an additional POC, then someone at the CA must be CC’d on the root inclusion Bugzilla bug...
An individual within the CA must also get a Bugzilla account and comment in the bug to say that they will be a POC for the CA, and that the contractor has indeed been hired by the CA to act as one of the POCs."

Comment 28

[JORRY Mathieu]

I, Mathieu Jorry, confirm herein that I am the official POC for the CSOEC's CA and that Samuel Lacas is indeed currently hired by us to work as a secondary POC for the CA.

Best regards

Mathieu JORRY
Project manager
[e-mail]

Comment 29

[Samuel Lacas]

(In reply to Kathleen Wilson from comment #25)
> Samuel,
> 
> Please explain why CSOEC CA needs to have their root certificate directly
> included in Mozilla’s products, rather than being signed by another CA’s
> root certificate that is already included in NSS
> (http://www.mozilla.org/projects/security/certs/included/). 
> How do you foresee end-users benefiting by having the CSOEC CA certificate
> directly included in NSS?

Hello Kathleen, 

The CSOEC is a is a public body representing the French certified public accountants in public practice. Our main reason for not being signed by a third-party CA is the CSOEC's public image. On the one hand, as a french public body, the CSOEC root CA cannot be signed by a foreign CA ; on the other hand, the CSOEC wants to maintain its independence from french private CA's (commercial firms) ; finally, it cannot be signed by the IGC/A (the french government's root CA) because it is not a state administration. This does not leave much options… :)
The CSOEC built up its PKI to provide certified public accountants with clear, readable and secure digital identities and, also, european-qualified digital signatures means. Technically, this means that the CSOEC's issuing CA went through a certification process similar to, but actually more stringent than the ETSI 101 456. Having the root CA of this hierarchy be attached to a third-party hierarchy of a lower grade (no offense) would simply negate the effort that was put in all the audits we went through since the beginning of the project.
In the same vein, we feel that tying ourselves to a third-party root CA may endanger our certificates : the CSOEC can have no control on the quality of other CA that would be attached to the same third-party root CA (no third-party root CA would agree on such terms, it can only enforce a "common baseline" for all its sub-CA). Tomorrow, should a non-CSOEC sub-CA, signed by the same 3rd-party root CA, start to issue end-users certificates matching those of the CSOEC (that is, with exactly the same profile), how could the certificates users separate the wheat from the chaff ? The only way they could do it would be through a careful examination of the certification chain (thus noticing that this chain does not goes up through the genuine CSOEC's sub-CA), but this is exactly what one wants to avoid with the trusted root CA's scheme !
Technically, too, if you examine the french trusted root CA, most of them have RSA2048/SHA-1 self-signed certificate. Having such certificate sign a RSA4096/SHA-256 certificate is nonsense, isn't it ?
Moreover, although it is true that the CSOEC did not actually contacted them, we are rather sure that, among the french trusted root CA, most, if not all of them, would anyway not agree on signing the CSOEC's CA's (or any third-party CA). Like the CSOEC, these PKI were built with specific purposes, and not conceived to sign third-party CA's. The same holds of the CSOEC root CA : its the CSOEC's CA, for the CSOEC, by the CSOEC, and it is not "open" to 3rd-party sub-CA, should they knock on our door.
For the certificate holders (the public accountants) and users (their clients or partners), the NSS integration will allow the public accountants' digital signatures to be natively trusted. The CSOEC is currently pursuing the same process with other mainstream vendors (such as Adobe and Microsoft), for the same reason. We all know why it's vital. Whatever the quality of our certificate management processes, whatever the audit we go through, if the documents and e-mails the public accountants sign with our certificate raise security pop-ups, alarms, confirmation dialogs, you name it… all the CSOEC efforts to promote digital practices are just voided. The situation were the mainstream software products do not natively recognise the CSOEC certificates is more an hindrance than an asset ; the CSOEC simply aims at being at the same level as other trusted root CA.

Comment 30

[Kathleen Wilson]

(In reply to Samuel Lacas from comment #29)

Thank you for this thorough explanation.

Now I need to complete step #2, as described here:
https://wiki.mozilla.org/CA:Information_checklist#CA_Primary_Point_of_Contact_.28POC.29
"To ensure that the POC(s) has the authority to perform the tasks listed above, a representative of Mozilla will do the following.
1. Use the CA’s website, to confirm that the domain in the email address of at least one of the POCs is owned by the CA (e.g. @CAname.com).
2. Use the CA’s website to contact a person at the CA to confirm that at least one of the POCs that have been provided does indeed have the authority to perform the responsibilities listed above on behalf of the CA.
3. If a contractor is also used as a POC, then contact the POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor."


There is a fairly large organizational structure shown here: http://www.experts-comptables.fr/csoec/Qui-sommes-nous/Le-Conseil-Superieur-de-l-Ordre
Please recommend someone listed on the website whom I may contact to complete step #2.

Comment 31

[Samuel Lacas]

Hi, Jean Saphores seems the most appropriate person to contact for this step (on the center-left, second line of the structure).

Comment 32

[Erwann Abalea]

(In reply to Samuel Lacas from comment #29)
> (In reply to Kathleen Wilson from comment #25)
> > Samuel,
> > 
> > Please explain why CSOEC CA needs to have their root certificate directly
> > included in Mozilla’s products, rather than being signed by another CA’s
> > root certificate that is already included in NSS
> > (http://www.mozilla.org/projects/security/certs/included/). 
> > How do you foresee end-users benefiting by having the CSOEC CA certificate
> > directly included in NSS?
> 
> Hello Kathleen, 
> 
> The CSOEC is a is a public body representing the French certified public
> accountants in public practice. Our main reason for not being signed by a
> third-party CA is the CSOEC's public image. On the one hand, as a french
> public body, the CSOEC root CA cannot be signed by a foreign CA ;

Why not?

> on the
> other hand, the CSOEC wants to maintain its independence from french private
> CA's (commercial firms) ;

Why? Does the CSOEC also want to maintain its independence from french private computer hardware resellers and software editors? From french private banks? Because they are all commercial firms?

> finally, it cannot be signed by the IGC/A (the
> french government's root CA) because it is not a state administration. This
> does not leave much options… :)

The CSOEC is under administrative supervision (tutelle administrative) by the Ministère des Finances, as is stated in the first comment (and as is written on the CSOEC web site). That is, the CSOEC is under the control of this Ministry, with the same relationship as between a minor person and its tutor. Therefore, having the CSOEC CA being signed by the Ministry of Finance, which is itself signed by the IGC/A is not impossible.

> The CSOEC built up its PKI to provide certified public accountants with
> clear, readable and secure digital identities and, also, european-qualified
> digital signatures means. Technically, this means that the CSOEC's issuing
> CA went through a certification process similar to, but actually more
> stringent than the ETSI 101 456. Having the root CA of this hierarchy be
> attached to a third-party hierarchy of a lower grade (no offense) would
> simply negate the effort that was put in all the audits we went through
> since the beginning of the project.

The CSOEC has been audited according to ETSI TS102042 (Webtrust equivalent), ETSI TS101456 (qualified certificates), and RGS (french law). The RGS qualification is mandatory for exchanges between users and administrative authorities and between administrative authorities. A lot of european commercial CAs have also passed the 102042/101456 audits, some french CAs are also RGS-validated.

> In the same vein, we feel that tying ourselves to a third-party root CA may
> endanger our certificates : the CSOEC can have no control on the quality of
> other CA that would be attached to the same third-party root CA (no
> third-party root CA would agree on such terms, it can only enforce a "common
> baseline" for all its sub-CA). Tomorrow, should a non-CSOEC sub-CA, signed
> by the same 3rd-party root CA, start to issue end-users certificates
> matching those of the CSOEC (that is, with exactly the same profile), how
> could the certificates users separate the wheat from the chaff ? The only
> way they could do it would be through a careful examination of the
> certification chain (thus noticing that this chain does not goes up through
> the genuine CSOEC's sub-CA), but this is exactly what one wants to avoid
> with the trusted root CA's scheme !

Weird arguments. You're asking to be part of a public program, among other root CAs, so that your root CA can deliver certificates trusted by the whole Mozilla community. What kind of control do you have over the other root CAs also members of that program?
If I understand correctly, the trust level you're aiming for passes by your root CA alone, and concerned third parties would then have to negate the trust of all root CAs but yours. That's a pure private deployment, and it's the exact opposite of your inclusion request. If this is really your goal, and you're asking your users to configure their browsers that way, then you're both 1/ negating this program, and 2/ in a position to deploy your private CA. It also means that the Mozilla community isn't concerned by this CA.

> Technically, too, if you examine the french trusted root CA, most of them
> have RSA2048/SHA-1 self-signed certificate. Having such certificate sign a
> RSA4096/SHA-256 certificate is nonsense, isn't it ?

Leave the SHA1/SHA2 apart (the hash and signature on a TA isn't important, it's not checked).
IGC/A new root CA is a 4096 bits one, Certinomis is a 4096bits one.

> Moreover, although it is true that the CSOEC did not actually contacted
> them, we are rather sure that, among the french trusted root CA, most, if
> not all of them, would anyway not agree on signing the CSOEC's CA's (or any
> third-party CA).

I think you should ask a CSOEC representative on that specific part and come back later.
Anyway, those are suppositions, not facts.

Comment 33

[Kathleen Wilson]

(In reply to Samuel Lacas from comment #31)
> Hi, Jean Saphores seems the most appropriate person to contact for this step
> (on the center-left, second line of the structure).

Thanks. I sent email to Jean Saphores. I will post an update in this bug when that step is completed.

In the meantime, please reply to Comment #32. I appreciate your patience, as we are earnestly trying to understand the need to include this root certificate directly in NSS.

Comment 34

[Samuel Lacas]

(In reply to Kathleen Wilson from comment #33)
> In the meantime, please reply to Comment #32. I appreciate your patience, as
> we are earnestly trying to understand the need to include this root
> certificate directly in NSS.

I am indeed actually working on it with the CSOEC. This may take a few days because Signexpert's team is really overloaded with work these days, and I prefer to have them review my answers before posting here.

Comment 35

[Samuel Lacas]

> (In reply to Samuel Lacas from comment #29)
> > (In reply to Kathleen Wilson from comment #25)
> > > Please explain why CSOEC CA needs to have their root certificate directly
> > > included in Mozilla’s products, rather than being signed by another CA’s
> > > root certificate that is already included in NSS
> > > (http://www.mozilla.org/projects/security/certs/included/). 
> > > How do you foresee end-users benefiting by having the CSOEC CA certificate
> > > directly included in NSS?
> > 
> > The CSOEC is a is a public body representing the French certified public
> > accountants in public practice. Our main reason for not being signed by a
> > third-party CA is the CSOEC's public image. On the one hand, as a french
> > public body, the CSOEC root CA cannot be signed by a foreign CA ;
> 
> Why not?

Because it is a French public body. The CSOEC has built up its own PKI hierarchy
for its own needs and that of its users, to promote the image of the public
accountants. Having the root CA signed by a foreign CA raises the same issue
as having it signed by a private one (which country do you suggest that would
be appropriate ? Should the CSOEC attach itself to an asian-based CA to send
a message about economic growth ? Or a CA based in the Caiman islands  some
other well-known tax-evading place, for another kind of message ? I'm joking,
of course :) ).

> > on the
> > other hand, the CSOEC wants to maintain its independence from french private
> > CA's (commercial firms) ;
> 
> Why? Does the CSOEC also want to maintain its independence from french private computer hardware resellers and software editors? From french private banks? Because they are all commercial firms?

Yes, exactly. Again, this is the idea behind : (1) having your own root CA
rather than buying your certificates from another CA (even if that externally
owned/operated CA provides you with your own sub-CA), (2) assert your
independence from private interests as a public body.
 
> > finally, it cannot be signed by the IGC/A (the
> > french government's root CA) because it is not a state administration. This
> > does not leave much options… :)
> 
> The CSOEC is under administrative supervision (tutelle administrative) by the Ministère des Finances, as is stated in the first comment (and as is written on the CSOEC web site). That is, the CSOEC is under the control of this Ministry, with the same relationship as between a minor person and its tutor. Therefore, having the CSOEC CA being signed by the Ministry of Finance, which is itself signed by the IGC/A is not impossible.

That would have indeed been an option, but : 

* the Ministry of Finance's IGC/A certificate is to expire in 2016 ; they cannot sign our root CA certificate
* That certificate has a RSA2048 bit key
* You and I know too well the Ministry of Finance's position on digital
  certificates (in short, they are trying to get rid of their PKI ; they have
  not, until now, asked for a new IGC/A certificate, attached to the new,
  4096/SHA-2, IGC/A root CA) 

> > The CSOEC built up its PKI to provide certified public accountants with
> > clear, readable and secure digital identities and, also, european-qualified
> > digital signatures means. Technically, this means that the CSOEC's issuing
> > CA went through a certification process similar to, but actually more
> > stringent than the ETSI 101 456. Having the root CA of this hierarchy be
> > attached to a third-party hierarchy of a lower grade (no offense) would
> > simply negate the effort that was put in all the audits we went through
> > since the beginning of the project.
> 
> The CSOEC has been audited according to ETSI TS102042 (Webtrust equivalent), ETSI TS101456 (qualified certificates), and RGS (french law). The RGS qualification is mandatory for exchanges between users and administrative authorities and between administrative authorities. A lot of european commercial CAs have also passed the 102042/101456 audits, some french CAs are also RGS-validated.

For the european commercial CAs, they are out for the reason explained before.
For the french CAs, in Mozilla's list : Certinomis (french mail), Keynectis
Class 2 Primary CA (but 2048/SHA-1), Certigna (the same). This leaves
Certinomis only if you take into account RSA key size matters.

> > In the same vein, we feel that tying ourselves to a third-party root CA may
> > endanger our certificates : the CSOEC can have no control on the quality of
> > other CA that would be attached to the same third-party root CA (no
> > third-party root CA would agree on such terms, it can only enforce a "common
> > baseline" for all its sub-CA). Tomorrow, should a non-CSOEC sub-CA, signed
> > by the same 3rd-party root CA, start to issue end-users certificates
> > matching those of the CSOEC (that is, with exactly the same profile), how
> > could the certificates users separate the wheat from the chaff ? The only
> > way they could do it would be through a careful examination of the
> > certification chain (thus noticing that this chain does not goes up through
> > the genuine CSOEC's sub-CA), but this is exactly what one wants to avoid
> > with the trusted root CA's scheme !
> 
> Weird arguments. You're asking to be part of a public program, among other root CAs, so that your root CA can deliver certificates trusted by the whole Mozilla community. What kind of control do you have over the other root CAs also members of that program?

Sorry if was not clear, and maybe my argument was a little too artificial,
but my point is that inclusion in Mozilla community is completely
different from being cross-certified by another Mozilla-approved root CA. If we get our root CA
signed by a Mozilla-approved one, we are actually asking our users to trust that
root CA. If we get the CSOEC root CA to be Mozilla-approved, we ask our users
to trust our root CA. We prefer the later, that does not sound weird at all to me.

> If I understand correctly, the trust level you're aiming for passes by your root CA alone, and concerned third parties would then have to negate the trust of all root CAs but yours. That's a pure private deployment, and it's the exact opposite of your inclusion request. If this is really your goal, and you're asking your users to configure their browsers that way, then you're both 1/ negating this program, and 2/ in a position to deploy your private CA. It also means that the Mozilla community isn't concerned by this CA.

I am afraid you totally misunderstand my point, because we exactly aim at the
opposite : I cannot see how asking to be part of the Mozilla-approved list
could be interpreted as trying to negate the trust of all root CAs but ours ;
moreover, that inclusion request is indeed motivated by the fact that we do NOT
want to have our users to configure their browsers for them to trust ours
certificates (and, of course, NOT to negate Mozilla's CA program in any way).

Once again, the official/contractually-binding documents and e-mails that are
produced by the public accountants for their clients can be given, in turn, by
the clients to other third-parties as trustworthy documents. The public
accountant's digital signature that they bear is the legal and actual means of
ensuring that it is genuine one. Therefore, its digital signature must be
verified and trusted without any configuration or tweaking on the recipient's
software configuration. This is quite the opposite of a "pure private 
deployment" ; the signed documents are for public use.

> > Technically, too, if you examine the french trusted root CA, most of them
> > have RSA2048/SHA-1 self-signed certificate. Having such certificate sign a
> > RSA4096/SHA-256 certificate is nonsense, isn't it ?
> 
> Leave the SHA1/SHA2 apart (the hash and signature on a TA isn't important, it's not checked).
> IGC/A new root CA is a 4096 bits one, Certinomis is a 4096bits one.

We agree, then. That would leave Certinomis as the only reasonable candidate.

> > Moreover, although it is true that the CSOEC did not actually contacted
> > them, we are rather sure that, among the french trusted root CA, most, if
> > not all of them, would anyway not agree on signing the CSOEC's CA's (or any
> > third-party CA).
> 
> I think you should ask a CSOEC representative on that specific part and come back later.
> Anyway, those are suppositions, not facts.

Fine, I will ask and come back here.

Thank you for your comments.

Comment 36

[JORRY Mathieu]

For political (image, communication) reasons, the CSOEC  does not want its root CA to be attached to any third-party CA. This position should not be understood as a judgement call on Certinomis or any Mozilla-approved root CA. I confirm the intent of the CSOEC to have its root CA be approved by Mozilla's program.  
Best regards

Comment 37

[Samuel Lacas]

Hello,

It's been still for almost a year now… Is there anything yet to be done, or something blocking the inclusion process ? 

Sincerely yours

Comment 38

[Kathleen Wilson]

I'm having difficulty with the following, so I put this request on hold.
1) Relevance to Mozilla products
2) SealWeb's involvement in root inclusion requests. (SealWeb was also the main representative for another root inclusion request, which is why this caught my attention this time.)

I understand that the push for qualified signatures in the EU means that more CAs will specialize in secure email certificates. So, the question of relevance to Mozilla products may resolve itself over time, and may be answered by this root being accepted into other root stores.

So please update this bug to let us know when Microsoft accepts the CSOEC root into their root program.

Comment 39

[Kathleen Wilson]

Closing this bug due to inactivity.

If Microsoft accepts the CSOEC root cert, and you are are able to respond to Comment #38, then please create a new root inclusion request.
https://wiki.mozilla.org/CA:How_to_apply