545614 - Add Certinomis root CA cert

Status: RESOLVED FIXED

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

Description

[Franck Leroy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/531.2 (KHTML, like Gecko) Chrome/3.0.191.0 Safari/531.2
Build Identifier: 

Certinomis is the Certificat Service Provider of "La Poste" the French Postal Service.
Certinomis is a commercial CA that delivers certificate to any public.
	
Primary geographical area(s)
	The primary area is France.
		
Types of certificates
	SSL/TLS web server.
	
Number and type of subordinate CAs
	3 sub CAs:
		"1 étoile" software or token, no face-to-face.
		"2 étoiles" only crypto token with face-to-face
		"Corporate" for BtoB purpose.
	
Website
	http://www.certinomis.com
		
Audit Type
	ETSI 101 456

Auditor
	LSTI http://www.lsti-certification.fr

Audit Documents
	http://www.certinomis.com/publi/rgs/8035_OC_TS_101_456_ex1F.pdf

Certificate Name (exactly as listed in NSS)
	CN = Certinomis - Autorité Racine
 
 Certificate Data URL
	http://www.certinomis.com/publi/rgs/ac-racine-g2.cer
	http://www.certinomis.com/publi/rgs/ac-racine-g2.pem
Version
	X509 v3
SHA1 Fingerprint
	2e 14 da ec 28 f0 fa 1e 8e 38 9a 4e ab eb 26 c0 0a d3 83 c3
Modulus Length (a.k.a. "key length")
	4096
Valid From
    september,17 2008
Valid To
    september,17 2028
CRL URL
    http://crl.certinomis.com/AC_Racine/crl/crl-1.crl
Certificate Policy URL
	http://www.certinomis.com/publi/rgs/DT-FL-0905-001-PC-RACINE-1.2.pdf
	http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-1E-SSL-1.2.pdf
CPS URL
    http://www.certinomis.com/publi/rgs/PR_AE_OpC_100125.pdf

Reproducible: Always

Comment 1

[Franck Leroy]

Additional CP document :
    http://www.certinomis.com/publi/rgs/DT-FL-1001-001-PC-PROFILS-1.0.pdf

Comment 2

[Kathleen Wilson]

Accepting this bug, and starting the Information Gathering and Verification
phase:
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

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

Comment 4

[Franck Leroy]

Thanks for this fast reply.
I'll work on it on Monday and give additional informations as soon as possible.

Regards
Franck Leroy

Comment 5

[Franck Leroy]

Attachment: Initial Information : Policy Information

Comment 6

[Franck Leroy]

I hope that my english is not too bad.
Let me no if you do not anderstand some answers.

Regards

Comment 7

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 8

[Kathleen Wilson]

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

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

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

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

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

Comment 9

[Kathleen Wilson]

This request is near the top of the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

As such, I am re-reviewing the information to ensure it is current.

1) CA Hierarchy. Please confirm that the following is still accurate, or please provide updated information:

*  This root has internally-operated subordinate CAs according to the Class of certificates, where the Class specifies the steps taken to verify the identity of the subscriber. SSL certs may only be issued from Class 2 and Class 3 sub-CAs. 

* The current subCAs are:
** "1 étoile" software or token, no face-to-face. (Class 1: Certificate issued upon verification of the e-mail)
** "2 étoiles" only crypto token with face-to-face (Class 2: Certificate issued upon verification of documents)
** "Corporate" for BtoB purpose. (Class 3: Certificate issued on vouchers, with identity checks face to face)
** Autorité de Test 


2) Are these the current documents? If not, please provide updated urls.

CPS: http://www.certinomis.com/publi/rgs/PR_AE_OpC_100125.pdf

Root CP: http://www.certinomis.com/publi/rgs/DT-FL-0905-001-PC-RACINE-1.2.pdf

Class 2 CP: http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-1E-SSL-1.2.pdf

Class 3 CP: http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-2E-SSL-1.2.pdf


3) Please provide urls to:
a) A website whose ssl cert chains up to the Class 2 intermediate CA that is signed by this root.
b) A website whose ssl cert chains up to the Class 3 intermediate CA that is signed by this root.

Comment 10

[Franck Leroy]

Hello Kathleen, this is good news to read you.

1) CA Hierarchy. Please confirm that the following is still accurate, or please
provide updated information:

>*  This root has internally-operated subordinate CAs according to the Class of
>certificates, where the Class specifies the steps taken to verify the identity
>of the subscriber. SSL certs may only be issued from Class 2 and Class 3
>sub-CAs. 

This is correct.

>* The current subCAs are:
>** "1 étoile" software or token, no face-to-face. (Class 1: Certificate issued
>upon verification of the e-mail)

This is correct.

>** "2 étoiles" only crypto token with face-to-face (Class 2: Certificate issued
>upon verification of documents)

This is correct.

>** "Corporate" for BtoB purpose. (Class 3: Certificate issued on vouchers, with
>identity checks face to face)

The CA is now out of scope, we are about to change the CA chaining to a new root CA.

>** Autorité de Test 

This is a TEST CA, no certificate are issued to public, for test purpose only.

>2) Are these the current documents? If not, please provide updated urls.

>CPS: http://www.certinomis.com/publi/rgs/PR_AE_OpC_100125.pdf

OK

>Root CP: http://www.certinomis.com/publi/rgs/DT-FL-0905-001-PC-RACINE-1.2.pdf

OK

>Class 2 CP:
>http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-1E-SSL-1.2.pdf

OK

>Class 3 CP:
>http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-2E-SSL-1.2.pdf

Typo error, the correct URL is ;
http://www.certinomis.com/publi/rgs/DT-FL-0808-016-PC-SERV-2E-SSL-1.2.pdf

>3) Please provide urls to:
>a) A website whose ssl cert chains up to the Class 2 intermediate CA that is
>signed by this root.
>b) A website whose ssl cert chains up to the Class 3 intermediate CA that is
>signed by this root.

I'll do it ASAP.


There is another change: Certinomis is now member of the Windows Root Certificate Program:
http://social.technet.microsoft.com/wiki/contents/articles/windows-root-certificate-program-members/revision/5.aspx

Regards
Franck Leroy
Certinomis CTO.

Comment 11

[Franck Leroy]

Hi,

>3) Please provide urls to:
>a) A website whose ssl cert chains up to the Class 2 intermediate CA that is
>signed by this root.

https://class2.test-certinomis.com/

>b) A website whose ssl cert chains up to the Class 3 intermediate CA that is
>signed by this root.

https://class3.test-certinomis.com/

Regards
Franck Leroy
Certinomis CTO

Comment 12

[Kathleen Wilson]

Thank you for your prompt response.

I am confused about the correspondence between “étoile” and “class”. My notes indicate that "1 étoile" corresponds to “class 1” verification, and "2 étoiles" corresponds to “class 2” verification. My notes also say that SSL certs may only be issued from Class 2 and Class 3 sub-CAs. However, I see that the CN of the class 2 subCA is "Certinomis AC 1 étoile", and the title of the class 2 CP is "POLITIQUE DE CERTIFICATION CERTIFICAT D’ORGANISATION Authentification Serveur SSL 1 étoile". Similarly the CN of the class 3 subCA is "Certinomis AC 2 étoiles", and the title of the class 3 CP is "POLITIQUE DE CERTIFICATION CERTIFICAT D’ORGANISATION Authentification Serveur SSL 2 étoiles".

Would you please explain the correspondence between “étoile” and verification “class”?

Would you please provide a list of the CN of each of the subCAs that are signed by this root, and explain their usage and verification class?

Comment 13

[Franck Leroy]

Hi,

There is a cut&paste mistake in this document :https://bug545614.bugzilla.mozilla.org/attachment.cgi?id=428971

The original text in https://bug545614.bugzilla.mozilla.org/attachment.cgi?id=426986 is :

	CA Hierarchy 	This root has 3 sub-CAs. 
	"Corporate" for BtoB purpose: Class 1: Certificate issued upon verification of the e-mail  (out of scope)
	"1 étoile" software or token, no face-to-face.  ; Class 2: Certificate issued upon verification of documents
	"2 étoiles" only crypto token with face-to-face ; Class 3: Certificate issued on vouchers, with identity checks face to face


	
Here is the list of CA certificates

C=FR,O=Certinomis,OU=0002 433998903,CN=Certinomis - Autorité Racine
	->Selfsigned Root CA

C=FR,O=Certinomis,OU=0002 433998903,CN=Certinomis Corporate
	->Class 1 verification, now out of scope because we stop this CA on January 2011
	
C=FR,O=Certinomis,OU=0002 433998903,CN=Certinomis AC 1 étoile
	->Class 2 verification
		
C=FR,O=Certinomis,OU=0002 433998903,CN=Certinomis AC 2 étoiles
	->Class 3 verification

C=FR,O=Certinomis,OU=0002 433998903,CN=Certinomis - Autorité de Test
	-> Internal use only for test purpose
	
	
Class 1 verification no more exists in french "RGS" so now the start level is "1 étoile".

1 étoile (1 star) is equiv to class 2 (DV+OV for SSL) : Certificate issued upon verification of documents.

2 étoiles (2 stars) is equiv to class 3 (EV like for SSL), and it will be a good candidate for a furture EV extension request.


Best regards
Franck Leroy
Certinomis CTO

Comment 14

[Kathleen Wilson]

Thank you for the clarification. Now I understand.  I have one more area that I need help with...

Based on translations of CPS section 2.1.2.1, FC_AE_OPC_JUSTIFS, and section 3.2 of the CP for Serveur SSL 1 étoile, I see clearly the information that the certificate subscriber is required to provide.  What I am not finding is what third-party information the RA uses to confirm the authenticity of the information being provided by the certificate subscriber. Perhaps I am simply loosing this in the translations. Please provide the translations that will clarify what third-party sources of information are used to verify the information that is provided by the certificates subscriber in regards to organization identity/authority.

In the CPS section 2.1.3.1 it says "the operator must verify... ownership of the domain name...". Who is "the operator"?

Comment 15

[Franck Leroy]

>Based on translations of CPS section 2.1.2.1, FC_AE_OPC_JUSTIFS, and section
>3.2 of the CP for Serveur SSL 1 étoile, I see clearly the information that the
>certificate subscriber is required to provide. 

>What I am not finding is what
>third-party information the RA uses to confirm the authenticity of the
>information being provided by the certificate subscriber. Perhaps I am simply
>loosing this in the translations. 


 1. A company registered at the French Trade Register
	An original K-Bis certificate of incorporation date less than 3 months, delivered by the registry   
or
	One valid copy of your company’s articles of association, bearing the signature of its representative

[...]



>Please provide the translations that will
>clarify what third-party sources of information are used to verify the
>information that is provided by the certificates subscriber in regards to
>organization identity/authority.


The organization validation is based on theses official documents delivered by the french governemment (French Trade Register)
The documents must be originals and date less than 3 months.

The domain validation is based on registrar internet web sites. 
The RA verifies that the owner of the FQDN is the validated organization.

There is also a pre-check of the identity of the organization when the subscriber create its account on certinomis web site.
We use the INSEE database to check the activity of the organization : http://avis-situation-sirene.insee.fr/avisitu/jsp/avis.jsp
I have a process document, I will translate it ASAP.
This process is not describe in CP/CPS as it is not mandatory in french RGS.


>In the CPS section 2.1.3.1 it says "the operator must verify... ownership of
>the domain name...". Who is "the operator"?

The operator is the RA employee who validate the certificate request.

Best regards
Franck Leroy
Certinomis CTO

Comment 16

[Franck Leroy]

Attachment: 3rd party OV validation (french)

Comment 17

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

I hope to start the discussion for this request next week.
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 18

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Certinomis to add the “Certinomis - Autorité Racine” root certificate and enable the websites 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.

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

The discussion thread is called “Certinomis Root Inclusion Request”

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

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

Comment 19

[Kathleen Wilson]

Attachment: Translations Regarding Subscriber Verification Procedures

This document contains translations into English of sections from the following three documents:

CP: http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-1E-SSL-1.2

CPS: http://www.certinomis.com/publi/rgs/PR_AE_OpC_100125.pdf

PROC: http://www.certinomis.com/publi/rgs/PR-SC-CDR-0036-06.pdf
(Processing Request of Certificate)

Comment 20

[Kathleen Wilson]

This request has been evaluated as per the Mozilla CA Certificate 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 from Certinomis to add the “Certinomis - Autorité Racine” root certificate and enable the websites trust bit.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Certinomis, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. Certinomis appears to provide a service relevant to Mozilla users: It is a commercial CA that delivers certificates to the general public in France, and is the Certificate Service Provider of "La Poste" the French Postal Service.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CP and CPS documents and the Processing Request of Certificate (PROC), which are in French. Translations into English of sections of these documents have been provided in attachment 498137 [details] and attachment 513645 [details].

CPS: http://www.certinomis.com/publi/rgs/PR_AE_OpC_100125.pdf

Root CP: http://www.certinomis.com/publi/rgs/DT-FL-0905-001-PC-RACINE-1.2.pdf

CP Serveur SSL 1 étoile: 
http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-1E-SSL-1.2.pdf

CP Serveur SSL 2 étoiles: 
http://www.certinomis.com/publi/rgs/DT-FL-0808-016-PC-SERV-2E-SSL-1.2.pdf 

PROC: https://www.certinomis.com/publi/rgs/FC_AE_OPC_JUSTIFS_091216.pdf

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

* Email: Not applicable; not requesting the email trust bit.

* SSL: Translations of the corresponding sections of the CP, CPS, and PROC documents are provided in attachment 513645 [details].

** For domain verification, WHOIS is used to check the link between FQDN and Organisation Name. Then the domain contact is notified (a phone call to the organization main phone number and asking to talk to the domain contact) for checking the domain name recording. The domain contact is asked about the FQDN value in order to avoid mistake on sub-domain value. During the phone call to the domain owner, the RA ask if he agrees the certificate creation. 

** After Certinomis confirms that the organization exists, then Certinomis verifies that the applicant is authorized to represent the organization in question. This is done by requiring national ID cards and an authorization document signed by both the organization representative and the certificate agent. The authorization document contains the FQDN of the certificate and names the certificate manager (the person who will receive the certificate). The certificate manager must also provide a copy of the national ID card and another signed document. 

** Certinomis confirms that the representative is who he claims to be as follows. 
*** When the subscriber creates an account on the Certinomis web site. Certinomis uses the INSEE database to check the name and the activity of the organization: http://avis-situation-sirene.insee.fr/avisitu/jsp/avis.jsp 
*** For "1 étoile" level, the identity of the certificate subscriber is verified by using the ID card and the extrait K-bis from the Trade Registry. 
*** For "2 étoiles" level, the identity of the certificate subscriber is verified by a face-to-face in a post office.
 
* Code: Not applicable; not requesting the code signing trust bit.

* EV Policy OID: Not applicable; not requesting EV treatment.

Section 13 [Certificate Hierarchy]
* This root has internally-operated subordinate CAs: 
** “Certinomis AC 1 étoile”  (OV verification for SSL)
** “Certinomis AC 2 étoiles” (EV like verification for SSL)
** “Certinomis - Autorité de Test” (for internal testing only) 
** “Certinomis Corporate” (discontinued)

Other: 

* ARL: http://crl.certinomis.com/AC_Racine/crl/crl-1.crl
* CRL 1 star: http://crl.certinomis.com/AC_1_ETOILE/crl/crl-2.crl (NextUpdate: 7 days)
* CRL 2 stars: http://crl.certinomis.com/AC_2_ETOILES/crl/crl-2.crl (NextUpdate: 7 days)

* OCSP:  Currently none.

Section 8-10 [Audit]. 
* LSTI performs the audits according to the ETSI 101 456 criteria. The current  ETSI certificate is valid until 2012.11.03, and is posted on the LSTI website at 
http://www.lsti-certification.fr/index.php?option=com_content&view=article&id=58&Itemid=53&lang=en

Based on this assessment I intend to approve this request from Certinomis to add the “Certinomis - Autorité Racine” root certificate and enable the websites trust bit.

Comment 21

[JP Donnio]

Hi, I am a French native speaker. I went through the PROC document 
http://www.certinomis.com/publi/rgs/PR-SC-CDR-0036-06.pdf

which claims to be the "SSL certificate request processing" procedure and I found that it contains items which do not match your findings. I'll comment inline below:


> Section 7 [Validation]. Certinomis appears to meet the minimum requirements for
> subscriber verification, as follows:
> 
> * Email: Not applicable; not requesting the email trust bit.
> 
> * SSL: Translations of the corresponding sections of the CP, CPS, and PROC
> documents are provided in attachment 513645 [details].
> 
> ** For domain verification, WHOIS is used to check the link between FQDN and
> Organisation Name. Then the domain contact is notified (a phone call to the
> organization main phone number and asking to talk to the domain contact) for
> checking the domain name recording. The domain contact is asked about the FQDN
> value in order to avoid mistake on sub-domain value. During the phone call to
> the domain owner, the RA ask if he agrees the certificate creation.


The 1.1.4 section of the PROC document states that an email is sent to the whois' admin contact. If he does not react within 24 hours, then the user of the domain is approved. 

A phone call is made (bullet point 4) only if they receive an answer rejecting the request to ensure they are not revoking the cert by error.

I'd like to point out that this process is even weaker than a standard domain validation system, in which someone has to actively agree... Here passive silence is considered acceptance!
May I also point out that many whois use anonymized email addresses or end up in junk mailbox. Expecting someone to pick-up the request within 24h is hazardous.
I hope this process is used in conjunction with a match on the registrant's name!



On page 6 of the PROC document, in the intranet section, the check is extremely weak. It states that the requester has to send a letter to confirm that "it is for an intranet use and it is not connected to the internet".
In other words, there are no security checks guarding against someone requesting a CN "company.int". A check against IANA root database should be required.



> ** After Certinomis confirms that the organization exists, then Certinomis
> verifies that the applicant is authorized to represent the organization in
> question. This is done by requiring national ID cards and an authorization
> document signed by both the organization representative and the certificate
> agent. The authorization document contains the FQDN of the certificate and
> names the certificate manager (the person who will receive the certificate).
> The certificate manager must also provide a copy of the national ID card and
> another signed document.


The PROC document mentions no ID cards at all. It says that once the organisation has been checked, a phone call is made (section 1.2 page 8) to check with the contact named (on the order form I guess) is really aware of the order for said CN.



> ** Certinomis confirms that the representative is who he claims to be as
> follows.
> *** When the subscriber creates an account on the Certinomis web site.
> Certinomis uses the INSEE database to check the name and the activity of the
> organization: http://avis-situation-sirene.insee.fr/avisitu/jsp/avis.jsp
> *** For "1 étoile" level, the identity of the certificate subscriber is
> verified by using the ID card and the extrait K-bis from the Trade Registry.
> *** For "2 étoiles" level, the identity of the certificate subscriber is
> verified by a face-to-face in a post office.

That does not show up in the PROC document.

> * OCSP:  Currently none.

Off topic but: shouldn't that be compulsory by now?



> Based on this assessment I intend to approve this request from Certinomis to
> add the “Certinomis - Autorité Racine” root certificate and enable the websites
> trust bit.
> 


I think that the PROC document is at least mis-leading; it is incompatible with the CP and CPS documents discussed here.

I note that the PROC document is dated in 2006 while the other documents are dated from 2010. I think that PROC document is related to an old verification process, not to the one compatible with RGS discussed here.

I would recommend to reject that PROC document and request clarification.

Comment 22

[Franck Leroy]

--- Comment #21 from JP Donnio <[e-mail]> 2011-02-19 02:13:59 PST ---
Hi, I am a French native speaker. I went through the PROC document
http://www.certinomis.com/publi/rgs/PR-SC-CDR-0036-06.pdf

which claims to be the "SSL certificate request processing" procedure and I
found that it contains items which do not match your findings. I'll comment
inline below:


This is not the RGS SSL procedure. This is an internal process for another SSL CA (from 2006).

The RGS process is this document :  http://www.certinomis.com/publi/rgs/PR_AE_OpC_100125.pdf 

The other document was given in order to answer to the question of phone call process.
Then I explain that it was done the same way as described in chapter :   1.2 VERIFICATIONS TELEPHONIQUES 

To make it clear I can update the RGS document : http://www.certinomis.com/publi/rgs/PR_AE_OpC_100125.pdf  
to add the phone call chapter, and then forget the 2006 document.


>On page 6 of the PROC document, in the intranet section, the check is extremely

Only FQDN is authorised in RGS SSL certificate, intranet name CAN NOT be inserted even in a  SAN.

Regards
Franck Leroy
Certinomis CTO

Comment 23

[JP Donnio]

> To make it clear I can update the RGS document :
> http://www.certinomis.com/publi/rgs/PR_AE_OpC_100125.pdf
> to add the phone call chapter, and then forget the 2006 document.

In my opinion, that's needed to clarify it all.

Comment 24

[Franck Leroy]

Hello

the updated document is available at :

http://www.certinomis.com/publi/rgs/PR_AE_OpC_110075.pdf

See new chapters: 2.1.3.3 and 3.4.4

Best regards
Franck Leroy
Certinomis CTO

Comment 25

[Kathleen Wilson]

>> Hi, I am a French native speaker. I went through the PROC document
>> http://www.certinomis.com/publi/rgs/PR-SC-CDR-0036-06.pdf
>> which claims to be the "SSL certificate request processing" procedure 
>> and I found that it contains items which do not match your findings. 
>> I'll comment inline below:
>
> This is not the RGS SSL procedure. This is an internal process 
> for another SSL CA (from 2006).

I interpret this as saying that the PROC document is in regards to a different SSL CA, and is NOT related to this root. If this is correct, then it means that the answers that were provided by this PROC document are not relevant. The appropriate documentation must be added to the CP/CPS for this root. In my opinion this means that we need to go back to public discussion to make sure all of the questions get answered in the appropriate documents.

Franck, Please post to the discussion in mozilla.dev.security.policy to provide the URL to the updated CPS and to provide the relevant translations from only the CP and CPS that answer the questions that were asked.


>> * OCSP:  Currently none.
> Off topic but: shouldn't that be compulsory by now?

OCSP is required for EV treatment. Unfortunately it's not currently required for non-EV.

Comment 26

[Franck Leroy]

Hello

>Franck, Please post to the discussion in mozilla.dev.security.policy to provide
>the URL to the updated CPS and to provide the relevant translations from only
>the CP and CPS that answer the questions that were asked.

This is done.

Regards
Franck Leroy

Comment 27

[Kathleen Wilson]

I have re-opened the public discussion for this request from
Certinomis to add the “Certinomis - Autorité Racine” root certificate and
enable the websites trust bit. 

The discussion thread is called “Certinomis Root Inclusion Request”, and is in the mozilla.dev.security.policy forum.

Comment 28

[Franck Leroy]

Attachment: CP chapter 3.2 EN translation

CP chapter 3.2 EN translation

Comment 29

[Franck Leroy]

Attachment: CPS parts EN translation

CPS parts EN translation

Comment 30

[Franck Leroy]

Attachment: PROC parts EN translation

Id validation process document.

Comment 31

[Kathleen Wilson]

Thanks for providing the direct translations.

Please see Comment #25 and clarify that this new PROC document 
(http://www.certinomis.com/publi/rgs/FC_AE_OPC_JUSTIFS_110207.pdf) 
is indeed related to this root.

Comment 32

[Franck Leroy]

Hello,

This document 

http://www.certinomis.com/publi/rgs/FC_AE_OPC_JUSTIFS_110207.pdf 

is pointed in the CPS chapter 2.1.1 :

http://www.certinomis.com/publi/rgs/PR_AE_OpC_110075.pdf 

Original:
2.1.1 Vérification de l’identité des personnes 
[PERSONNE] [ORGANISATION] [SERVEUR] 
Chaque personne physique mentionnée dans un dossier de demande, qu’elle fasse la demande en 
son nom ou au nom de son entreprise, doit fournir la preuve de son existence. Cette preuve prend la 
forme d’une pièce officielle d’identité en cours de validité.  
Une liste des pièces justificatives acceptées fait l’objet de la fiche complémentaire :  
[FC_AE_OPC_JUSTIFS]] 


Translated:
2.1.2.1 Existence of the organization
In principle, the organization must provide proof of his existence and his identification number (unique registration number and identified with a commercial register or any other official list and update.)
This evidence takes the form of a supporting document. In the most common case, this is a K-Bis issued by the registries of commercial courts of the company's headquarters, in the case of a company. 

A list of documents accepted subject to the additional sheet:
[FC_AE_OPC_JUSTIFS]
^^^^^^^^^^^^^^^^^^^^^ This is it !

About naming:
PR_AE_OpC_110075.pdf

PR means process / AE means RA / OPC means verifications part / followed by a version number.

FC_AE_OPC_JUSTIFS_110207.pdf 

FC means additionnal document / AE means RA / OPC means verifications part / Justifs means evidences / followed by a version number

Regards
Franck Leroy

Comment 33

[Kathleen Wilson]

The CPS has been updated, and the url of a the RA Procedures document that is referenced in the CPS has been provided. English translations of sections of the CPS, CP (1 star), and the RA Procedures documents have been attached to this bug.

CPS (French): http://www.certinomis.com/publi/rgs/PR_AE_OpC_110075.pdf
English Translations of Sections 2.1 and 3.4: https://bugzilla.mozilla.org/attachment.cgi?id=517740

CP Serveur SSL 1 étoile (French): http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-1E-SSL-1.2.pdf
English Translation of Section 3.2: https://bugzilla.mozilla.org/attachment.cgi?id=517725

RA Procedures Document – PROC (French): 
http://www.certinomis.com/publi/rgs/FC_AE_OPC_JUSTIFS_110207.pdf
English Translations of Sections 1.2, 1.3, and 2:
https://bugzilla.mozilla.org/attachment.cgi?id=518021


In my original recommendation for approval in Comment #20 I had made the following assertions to demonstrate that appropriate public-facing and audited documentation is provided to meet the requirements of sections 7 and 14 of the Mozilla CA Certificate Policy.
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

I will indicate in {} where this information may be found in the documents listed above.

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

** For domain verification, WHOIS is used to check the link between FQDN and Organisation Name. 
{CPS 2.1.3.1}
Then the domain contact is notified (a phone call to the organization main phone number and asking to talk to the domain contact) for checking the domain name recording. 
{CPS 2.1.3.3}
The domain contact is asked about the FQDN value in order to avoid mistake on sub-domain value. During the phone call to the domain owner, the RA ask if he agrees the certificate creation. 
{CPS 3.4.4}

** After Certinomis confirms that the organization exists, then Certinomis verifies that the applicant is authorized to represent the organization in question. This is done by requiring national ID cards and an authorization document signed by both the organization representative and the certificate agent. The authorization document contains the FQDN of the certificate and names the certificate manager (the person who will receive the certificate). The certificate manager must also provide a copy of the national ID card and another signed document. 
{CP 3.2.3.1. CP 3.2.3.2, and CP 3.2.3.3}

** Certinomis confirms that the representative is who he claims to be as
follows. 
*** When the subscriber creates an account on the Certinomis web site. Certinomis uses the INSEE database to check the name and the activity of the organization: http://avis-situation-sirene.insee.fr/avisitu/jsp/avis.jsp 
{RA Procedures 1.2.2 -- In this chapter there is a tab, in the first columns in front of the URL it is written: "MOYEN DE VERIFICATION ET PIECE  JUSTIFICATIVE" that means "verify means and justifying documents" which means the RA must verify with this. The document called “3rd party OV validation” which is attachment #498112 [details] in this bug, describes how the INSEE website is used to verify the SIREN.} 

*** For "1 étoile" level, the identity of the certificate subscriber is verified by using the ID card 
{CP 3.2.3.2}
and the extract K-bis from the Trade Registry. 
{CP 3.2.2; note that K-bis are printed on a specific paper (with watermark) that cannot be photocopied.}
*** For "2 étoiles" level, the identity of the certificate subscriber is verified by a face-to-face
{RA Procedures section 2}

Comment 34

[Franck Leroy]

Hello,

About 2 stars policy.

The main difference is in CP chapter 3.2.3.3

There is this additionnal requirement :
La distribution par l’AE peut se faire directement au RCAS ou au mandataire de certification.
•	S’il s’agit du RCAS, avant la distribution, l’AE vérifie en face-à-face, c'est-à-dire en présence du RCAS, un original d’une pièce d’identité officielle du RCAS en cours de validité comportant sa photo et sa signature.
•	S’il s’agit du mandataire de certification, avant la distribution, l’AE vérifie en face-à-face, c'est-à-dire en présence du mandataire de certification, un original d’une pièce d’identité officielle du mandataire de certification en cours de validité comportant sa photo et sa signature.
	Le mandataire a par la suite la charge de distribuer en face-à-face les éléments qui lui ont été remis au RCAS.

English translation :

The delivery by the RA can be directly made to the certificate manager or to the certificate agent.
•	If it is the certificate manager, before delivery, RA checks in face-to-face, that is in presense of the certificate manager, an original of an official ID card of the certificate manager in course of validity containing his photo and its signature.
•	If it is the certificat agent, before delivery, RA checks in face-to-face, that is in presense of the certificate agent, an original of an official ID card of the certificate agent in course of validity containing his photo and its signature.
	The certificate agent has afterward the load to distribute the certificate in face-to-face with the certificate manager.


Regards
Franck Leroy
Certinomis CTO

Comment 35

[Kathleen Wilson]

This request has been evaluated as per the Mozilla CA Certificate 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 from Certinomis to add the “Certinomis - Autorité Racine” root certificate and enable the websites trust bit.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Certinomis, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. Certinomis appears to provide a service relevant to Mozilla users: It is a commercial CA that delivers certificates to the general public in France, and is the Certificate Service Provider of "La Poste" the French Postal Service.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CP and CPS documents and the RA Procedures document, which are in French. English translations of certain sections of these documents have been attached to this bug.

CPS (French): http://www.certinomis.com/publi/rgs/PR_AE_OpC_110075.pdf
English Translations of Sections 2.1 and 3.4:
https://bugzilla.mozilla.org/attachment.cgi?id=517740

CP Serveur SSL 1 étoile (French):
http://www.certinomis.com/publi/rgs/DT-FL-0808-006-PC-SERV-1E-SSL-1.2.pdf
English Translation of Section 3.2:
https://bugzilla.mozilla.org/attachment.cgi?id=517725

CP Serveur SSL 2 étoiles: 
http://www.certinomis.com/publi/rgs/DT-FL-0808-016-PC-SERV-2E-SSL-1.2.pdf 

RA Procedures Document – PROC (French): 
http://www.certinomis.com/publi/rgs/FC_AE_OPC_JUSTIFS_110207.pdf
English Translations of Sections 1.2, 1.3, and 2:
https://bugzilla.mozilla.org/attachment.cgi?id=518021

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

* Email: Not applicable; not requesting the email trust bit.

* Code: Not applicable; not requesting the code signing trust bit.

** According to CPS sections 2.1.3 and 3.4.4, domain verification begins with using WHOIS to check the link between FQDN and Organisation Name. Then the domain contact is notified (a phone call to the organization main phone number and asking to talk to the domain contact) for checking the domain name recording. The domain contact is asked about the FQDN value in order to avoid mistake on sub-domain value. During the phone call to the domain owner, the RA ask if he agrees the certificate creation. 

** According to CP (1-star) section 3.2.3, after Certinomis confirms that the organization exists, then Certinomis verifies that the applicant is authorized to represent the organization in question. This is done by requiring national ID cards and an authorization document signed by both the organization representative and the certificate agent. The authorization document contains the FQDN of the certificate and names the certificate manager (the person who will receive the certificate). The certificate manager must also provide a copy of the national ID card and another signed document. 

** According to sections 1.2.2 and 2 of the RA Procedures and section 3.2 of the CP (1-star), Certinomis confirms that the representative is who he claims to be as follows. 
*** When the subscriber creates an account on the Certinomis web site. Certinomis uses the INSEE database to check the name and the activity of the organization: 
http://avis-situation-sirene.insee.fr/avisitu/jsp/avis.jsp 
*** For "1 étoile" level, the identity of the certificate subscriber is verified by using the ID card and the extrait K-bis from the Trade Registry. Note that K-bis are printed on a specific paper (with watermark) that cannot be photocopied.
*** For "2 étoiles" level, the identity of the certificate subscriber is verified by a face-to-face meeting as described in section 3.2.3.3 of the 2-star CP.
 
* EV Policy OID: Not applicable; not requesting EV treatment.

Section 15 [Certificate Hierarchy]
* This root has internally-operated subordinate CAs: 
** “Certinomis AC 1 étoile”  (OV verification for SSL), 
** “Certinomis AC 2 étoiles” (EV like verification for SSL)
** “Certinomis - Autorité de Test” (for internal testing only), 
** “Certinomis Corporate” (discontinued). 

Other: 

* ARL: http://crl.certinomis.com/AC_Racine/crl/crl-1.crl
* CRL 1 star: http://crl.certinomis.com/AC_1_ETOILE/crl/crl-2.crl (NextUpdate: 7 days)
* CRL 2 stars: http://crl.certinomis.com/AC_2_ETOILES/crl/crl-2.crl (NextUpdate: 7 days)

* OCSP:  Currently none.

Section 9-11 [Audit]. 
* LSTI performs the audits according to the ETSI 101 456 criteria. The current  ETSI certificate is valid until 2012.11.03, and is posted on the LSTI website at 
http://www.lsti-certification.fr/index.php?option=com_content&view=article&id=58&Itemid=53&lang=en

Based on this assessment I intend to approve this request from Certinomis to add the “Certinomis - Autorité Racine” root certificate and enable the websites trust bit.

Comment 36

[Kathleen Wilson]

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

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

As per the summary in Comment #35, and on behalf of the Mozilla project I
approve this request from Certinomis to include the following root certificates in Mozilla:

** Certinomis - Autorité Racine (websites)

I will file the NSS bug to effect the approved changes.

Comment 37

[Kathleen Wilson]

I have filed bug #645880 against NSS for the actual changes.

Comment 38

[Kathleen Wilson]

Note that even though the ETSI certificate is valid for 3 years, Certinomis is audited annually by LSTI. I have received relevant portions of the audit report from January of this year. I have also received similar information for the previous audit.

Comment 39

[Kathleen Wilson]

Attachment: Audit Statement 2013