937589 - Add Certinomis G3 (SHA256) Root Certificates

Status: RESOLVED FIXED

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

Description

[Franck Leroy]

Attachment: Certinomis_CAInformationTemplate-s.pdf

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Comment 1

[Franck Leroy]

Created attachment 816688 [details]
QuoVadis_CAInformationTemplate.pdf

Certinomis would like to request inclusion of the following root certificates to the NSS store.  This "G3" (SHA26) certificates should be added to the existing set of Certinomis roots which are already trusted in NSS.

The root is used for issuing intermediate certificates which are then used to issue end-entity SSL and end user. 

Certificate Name:  Certinomis - Root CA
Certificate Signature Algorithm:  sha256RSA
SHA1 Fingerprint: 9d 70 bb 01 a5 a4 a0 18 11 2e f7 1c 01 b9 32 c5 34 e7 88 a8
Valid From:  2013-10-21
Valid To:  2033-10-21
http://www.certinomis.fr/publi/cer/AC_Racine_G3.cer 

Test certificates may be found at https://w3-test.certinomis.fr/

Best regards
Franck Leroy
Certinomis CTO

Comment 2

[Franck Leroy]

Certinomis would like to request inclusion of the following root certificates to the NSS store.  This "G3" (SHA26) certificates should be added to the existing set of Certinomis roots which are already trusted in NSS.

The root is used for issuing intermediate certificates which are then used to issue end-entity SSL and end user. 

Certificate Name:  Certinomis - Root CA
Certificate Signature Algorithm:  sha256RSA
SHA1 Fingerprint: 9d 70 bb 01 a5 a4 a0 18 11 2e f7 1c 01 b9 32 c5 34 e7 88 a8
Valid From:  2013-10-21
Valid To:  2033-10-21
http://www.certinomis.fr/publi/cer/AC_Racine_G3.cer 

Test certificates may be found at https://w3-test.certinomis.fr/

Best regards
Franck Leroy
Certinomis CTO

Comment 3

[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, and provide the necessary information in this bug.

Comment 4

[Franck Leroy]

Test	Website	URL	(SSL)  
Example	Certificate	(non-SSL)	
https://w3-test.certinomis.fr/

fixed ! What a shame I forgot chain certificate in apache conf...

I'll try to answer to other questions ASAP.

Franck Leroy

Comment 5

[Franck Leroy]

Hello

A new CAInformation has been uploaded, but here are answers to your questions in plain text :

Hello

+ https://w3-test.certinomis.fr/

      OCSP has an open issue about "no nonce" response and will be corrected ASAP.

+ Please confirm that non-sequential serial numbers are used. 

     SHA-1 is not used even for end-entity certificates, the only signature algo is sha256WithRSAEncryption :
     Additional CP document: http://www.certinomis.com/publi/rgs/DT-FL-1310-002-PC-PROFILS-1.0.pdf
     2.2	PROFIL DES CERTIFICATS PORTEURS
     Signature	sha256WithRSAEncryption

     Nevertheless some entropy is also added (160 bits) is the end-entity serial-number generation.
     Dates are also unpredictable as all certificates issuance is done manually by operators.

+ Does the G2 root have external subCAs that will be transitioned to this new root?

     None for this root and all Certinomis Roots (including the G2).

+ Does the CP/CPS allow for external subCAs? 

     CP/CPS does not forbid external subCAs.

+ Technical Constraints or Audits of Third-Party Issuers

     There is no external third party issuer.
     All applications are processed by Certinomis operators. When a certificate request is validated by Certinomis, the subscriber has the possibility to re-issue another certificate with the same validated informations (organization and domain names). For this feature, the subscriber need a strong authentication (based on smartcard) delivered by Certinomis and with security roles granted by Certinomis security officer.

+ When the websites (SSL/TLS) trust bit is enabled the audit criteria must be equivalent to ...

     LSTI performs the audits according to the ETSI TS 101 456 criteria for QCP/QCP+ and ETSI TS 102 042 for LCP/NCP/NCP+.

     The current ETSI certificate is valid until 2015.04.29, and is posted on the LSTI website at
     http://www.lsti-certification.fr/
     ETSI list : http://www.lsti-certification.fr/images/liste_entreprise/ETSI.pdf

     For each entry (certificate profile from Root G2) ETSI level (LCP/NCP/QCP) is indicated.
     See attached document (auditor letter for Root G2) ; 2143CertinomisS.pdf
     Root G3 audit is done, auditor report is about to be published.

+ SSL Verification Procedures / Please translate section 2.1 of the CPS and section 3.2 of the CP Server into English 

     See attached translated documents; CertinomisTranslations CP EN.pdf & CertinomisTranslations CPS EN .pdf

+ Multi-factor Authentication /  Please tell me where in the CP/CPS documentation I may find this. 

     Added in CPs chapter 9.6;
     Enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.
	 
+ Delegation of Domain / Email validation to third parties  / Please tell me where I can find this in the CP/CPS documentation. 

     Added in CPs chapter 1.3.2 :
     Only Certinomis RA is capable of internet domain name (FQDN) validation in order to issue publicly trusted ssl/tls certificates such as internet browser software vendors CA root program (in particular those member of CABForum http://www.cabforum.org/forum.html). This capacity of validation can be delegated on no account to a third party.

+ Distributing generated private keys in PKCS#12 files / Is this relevant to SSL certificates? 

     Yes we issue certificates based on PKCS10 but we can also generate keys and distribute PKCS12 files for SSL/TLS usage.


I'll do a bug update when Auditor publication is availaible for new Root G3 (SHA-2).

Franck Leroy

Comment 6

[Franck Leroy]

Attachment: Certinomis_CAInformationTemplate-2.pdf

Comment 7

[Franck Leroy]

Attachment: CABForum equilavalence letter from auditor

Comment 8

[Franck Leroy]

Attachment: CertinomisTranslations CP EN.pdf

Comment 9

[Franck Leroy]

Attachment: CertinomisTranslations CPS EN .pdf

Comment 10

[Kathleen Wilson]

Thank you for the translations and clarifications. The information looks good to me.

Please comment in this bug when the updated CP/CPS documents are available on the website, and when the OCSP nonce issue has been resolved.

Comment 11

[Franck Leroy]

Hello Kathleen

I'am pleased to announce that our OCSP software has been upgraded and now compatible with firefox.

https://w3-test.certinomis.fr/

All documents are available on our web site, I'm working on a minor update to take into account the last audit review in March from LSTI.

Best regards
Franck.

Comment 12

[Kathleen Wilson]

https://w3-test.certinomis.fr/ is the test website for the “Certinomis - Autorité Racine” G2 root certificate.
Need a new test website whose SSL cert chains up to the new root (the subject of this root inclusion request).

I see the documents are listed here: http://www.certinomis.com/documents-et-liens/nos-politiques
Which of those is the CPS?

What is the status of the current audit statement? BR audit statement?

Comment 13

[Franck Leroy]

Hello

I can confirm that https://w3-test.certinomis.fr/ is the test website for the "Certinomis - Root CA" aka G3 root.

Checked with digicert certificate checker:

SSL Certificate has not been revoked

OCSP Staple:	Not Enabled
OCSP Origin:	Good
CRL Status:	Good

SSL Certificate expiration:  The certificate expires November 27, 2016 (943 days from today)

Certificate Name matches w3-test.certinomis.fr

Subject	w3-test.certinomis.fr
Valid from 27/Nov/2013 to 27/Nov/2016
Issuer	Certinomis - Standard CA
	
Subject	Certinomis - Standard CA
Valid from 21/Oct/2013 to 21/Oct/2023
Issuer	Certinomis - Root CA

SSL Certificate is not trusted


>Which of those is the CPS?

CPS is not publicly available. I have attached some translation of CPS in this bug. We share the same CPS on G2 & G3 certificate chains, only CP are different.

I am about to publish new versions of CP that take into account some issues stated by the audit.
Then this new version will be translated to English and made available on our web site.


>What is the status of the current audit statement?

LSTI has updated the audit statement on their web site on december 20th:

http://www.lsti-certification.fr/images/liste_entreprise/ETSI.pdf

All Certinomis certificate policies are ETSI qualified.

>BR audit statement?

Some of these policies concerning SSL certificates have the OVCP statement in the list :

Certinomis Easy CA 1.2.250.1.86.2.3.1.20.1 TS 102 042 OVCP Qualifié

Best regards
Franck Leroy

Comment 14

[Franck Leroy]

Hello

New Certificate Policies (only in french for now) :

SSL for private sector : http://www.certinomis.com/publi/rgs/DT-FL-1310-020-PC-SERV-1.2.pdf

SSL for administration sector : http://www.certinomis.com/publi/rgs/DT-FL-1310-040-PC-AA-1.2.pdf



New PKI disclosure statement (only in french for now) :

SSL for private sector : http://www.certinomis.com/publi/cgu/CGU_Serveur_v2.0.FR.pdf

SSL for administration sector : http://www.certinomis.com/publi/cgu/CGU_AA_v2.0.FR.pdf



Franck

Comment 15

[David E. Ross]

(In reply to Franck Leroy from comment #13)
> CPS is not publicly available. I have attached some translation of CPS in
> this bug. We share the same CPS on G2 & G3 certificate chains, only CP are
> different.

I believe it is a long-standing requirement of the WebTrust program that the CPS be published.  "Published" means available to the public.  WebTrust also cites (note the word "discloses"): 
"The CA discloses its business practices including but not limited to the topics listed in RFC 3647, RFC 2527, or WebTrust for Certification Authorities v1 CA Business Practices Disclosure Criteria (see Appendix A) in its Certification Practice Statement."  
and 
"The CA makes available its Certification Practice Statement (CPS) to all appropriate parties."

Comment 16

[Franck Leroy]

(In reply to Kathleen Wilson from comment #12)
> https://w3-test.certinomis.fr/ is the test website for the “Certinomis -
> Autorité Racine” G2 root certificate.
> Need a new test website whose SSL cert chains up to the new root (the
> subject of this root inclusion request).
> 

Hello
Here is a new test website chaining to G3 root : https://g3-test.certinomis.com
Old test website is now back to G2 root chain.

>I see the documents are listed here: http://www.certinomis.com/documents-et-liens/nos-politiques
>Which of those is the CPS?

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

Let me know if you need more informations.

Best regards
Franck Leroy

Comment 17

[Kathleen Wilson]

(In reply to Franck Leroy from comment #16)
> Hello
> Here is a new test website chaining to G3 root :
> https://g3-test.certinomis.com

I just tried it again, and the SSL cert for https://g3-test.certinomis.com looks like it is chaining up to the old root.

Comment 18

[Franck Leroy]

Hello

SSLlabs reports Certinomis G3 ROOT :

https://www.ssllabs.com/ssltest/analyze.html?d=g3-test.certinomis.com

Issuer	: Certinomis - Root CA
Signature algorithm :	SHA256withRSA

Franck

Comment 19

[Kathleen Wilson]

When I use a new Firefox profile I see the expected chain up to the new root.

Comment 20

[Franck Leroy]

Hello

New Certificate Policy (only in french for now) :
(upgraded previous SHA1 version to our new G3 root)

Web SSL (without french RGS requirements) : http://www.certinomis.com/publi/pc/DT-FL-1310-060-PC-WEB-SSL-1.2.pdf

Franck.

Comment 21

[Kathleen Wilson]

Attachment: Updated CA Information Document

Please see the items highlighted in yellow where further clarification is still needed.

Comment 22

[Franck Leroy]

Attachment: Audit Statement Revision 4

Latest audit statement with PTC-BR indication.

Comment 23

[Franck Leroy]

Hello


+ Question 1 : Audits	 & Baseline	Requirements	(SSL)	 

I have attached the latest audit statement from LSTI (revision 4) with PTC-BR indicated in front of each SSL OIDs.


+ Question 2 : Multi-factor	Authentication	 

Here is an extract of the CP

5.2.3	Identification and authentication for each role 
[...]
Remote operators intervening within the CA system must be identified by means of strong cryptographic mechanisms.


+ Question 3 : Distributing	generated	private	keys	in	PKCS#12	files	

Here is an extract of the CP

4.3.1	Actions of the CA regarding the delivery of the certificate 
[...]
For software certificates, when the CA generates the keys:
•	The CD-R is inserted into the customisation tool.
•	The PKI generates keys and certificates.
•	The PKI generates an activation code for the certificates.
•	The customisation tool burns the keys and certificates onto a CD-R.

4.3.2	Notification by the CA of the certificate’s delivery to the beneficiary
This certificate is delivered by mail, when the certificate is stored on a CD-R. Otherwise, the certificate is sent to the beneficiary by e-mail.
[...]
When the CA generate activation codes, the certificate cannot be used without having this code (PIN or password depending on the type of cryptographic device). It is sent directly to the beneficiary’s address, by secure mail.

6.2.8.2	Private keys of the servers
[...]
In the case of software, if the CA generates the activation code, the key pairs are activated via a PKCS12 password with at least 12 characters.
[...]

Let me know if you need more informations.

Best regards
Franck Leroy

Comment 24

[Franck Leroy]

Hello

"Information incomplete"

Do you need more information to go on, or only some delay ?

Best regards
Franck Leroy

Comment 25

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 26

[Kathleen Wilson]

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

Comment 27

[Kathleen Wilson]

I began to write the summary of this request for the purpose of starting the public discussion, and found that I have some more questions...

The root has signed 4 internally-operated subordinates CAs for issuing end-entity certificates: 
AA et Agents 
Easy CA
Prime CA
Standard CA

For each subCA (AA, Easy, Prime, Standard), please
1) Identify who can do domain control validation (i.e. if only Certinomis, or if external RAs or other)
2) Identify who can issue SSL certs (i.e. if only Certinomis, or if external RAs or other) and to whom SSL certs may be issued.
3) State which CP document applies, and which section numbers specify procedures for verifying domain control, subscriber identity and authority.
4) Provide translation into English of the section(s) of the CP document that specifies how the domain control validation is done (i.e. which of the options in Baseline Requirements section 11.1.1 may be used).

Please see: https://wiki.mozilla.org/CA:BaselineRequirements 

Regarding the Root CP, are there sections that describe who can apply for a subordinate CA? i.e. can someone outside of Certinomis operate a subordinate CA? If yes, what are the rules/restrictions for such subordinate CAs, and which sections of the Root CP clarify how Baseline Requirements sections 9.7 and 17 will be met. What are the SSL verification requirements that must be enforced across all subordinate CAs? And how is that controlled.

Comment 28

[Franck Leroy]

Hi Kathleen, sorry for the delay but I'm very busy theses days...

I'm working on an update of Certinomis CP, and I'll update the root CP to clarify how Baseline Requirements sections 9.7 and 17 will be met.

Franck.

Comment 29

[Franck Leroy]

Hello

An updated Root policy has been published today.

So here are the answers to your request :


AA et Agents 
------------
1) Identify who can do domain control validation : only Certinomis
2) Identify who can issue SSL certs : only Certinomis
3) State which CP document applies
AA et Agents 
------------ (requirements for French Regulation and ETSI/TS 101 042 including BR-PTC)
	http://www.certinomis.com/publi/rgs/DT-FL-1310-040-PC-AA-1.3.pdf
	3.2.3.3 Enregistrement d'un dispositif ou d’une application
	See "CertinomisTranslations CP EN.pdf"
	
Easy CA / Prime CA / Standard CA
------------ (requirements for French Regulation and ETSI/TS 101 042 including BR-PTC)
	http://www.certinomis.com/publi/rgs/DT-FL-1310-020-PC-SERV-1.3.pdf
	3.2.3.3 Enregistrement d'un dispositif ou d’une application
	See "CertinomisTranslations CP EN.pdf"

	-or-
	
	(requirements for ETSI/TS 101 042 including BR-PTC only)
	http://www.certinomis.com/publi/pc/DT-FL-1310-060-PC-WEB-SSL-1.2.pdf
	3.2.3.3 Enregistrement d'un dispositif ou d’une application
	See "CertinomisTranslations CP EN.pdf"
	
4) Document that specifies how the domain control validation is done (CPs) :
    http://www.certinomis.com/publi/rgs/PR_AE_OpC_110075.pdf
	2.1.3.1	Dans le cas de l’utilisation d’un FQDN
	2.1.3.3	Certificat SSL
	See "CertinomisTranslations CPS EN .pdf"
	Options in Baseline Requirements section 11.1.1 may be used : 3 and 5 ; Domain Authorization Document is always needed and some checking are done on WHOIS records. If CA has previously issued certificate for this FQDN for this applicant and that WHOIS records has not been modified, then no communication with the Domain Name Registrant is needed.

NB: There are differents policies according to enforcement of french regulation or not, but domain name validation follow the same process in any cases.


+ Regarding the Root CP, are there sections that describe who can apply for a subordinate CA? 
	http://www.certinomis.com/publi/rgs/DT-FL-1310-001-PC-RACINE-1.2.pdf
	3.2.2	Validation de l'identité d'un organisme 
	Any company can contract with Certinomis in order to be a subordinate CA.

+ i.e. can someone outside of Certinomis operate a subordinate CA? 
	It may be possible, but at this time, only Certinomis operates subordinate CAs of the Certinomis Root CA.

+ If yes, what are the rules/restrictions for such subordinate CAs, and which sections of the Root CP clarify how Baseline Requirements sections 9.7 and 17 will be met.
	http://www.certinomis.com/publi/rgs/DT-FL-1310-001-PC-RACINE-1.2.pdf
	[BR9.7] 4.5	USAGES DE LA BI-CLE ET DU CERTIFICAT 
and
	[BR17]	8.7	AUDIT DE CONFORMITE ET EVALUATIONS DES ACD 
	
+ What are the SSL verification requirements that must be enforced across all subordinate CAs? And how is that controlled.
	As there is no external CA, sub CAs are only operated by Certinomis, then all verification are described by Certinomis' CP/CPS.
	If an external sub CA have to be set-up, its CP/CPS shall met the same level of requirements than the current Certinomis' CP/CPS.



Best regards
Franck Leroy

Comment 30

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 31

[Kathleen Wilson]

Attachment: 937589-CAInformation-SF.pdf

Comment 32

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Certinomis to include the “Certinomis - Root CA” root certificate, and enable the Websites trust bit. This SHA-256 root will eventually replace the “Certinomis - Autorité Racine” G2 root certificate that was included in NSS via Bugzilla Bug #545614.

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 “Certinomis Request to Include Renewed Root”.

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 33

[Franck Leroy]

Hello

2 CPs are available in English :

Easy CA / Prime CA for Individuals
------------ (requirements for French Regulation and ETSI/TS 101 456 including BR-PTC)
http://www.certinomis.fr/publi/rgs/DT-FL-1310-010-PC-ORGA-1.4-EN.pdf

Easy CA / Prime CA for Servers
------------ (requirements for French Regulation and ETSI/TS 102 042 including BR-PTC)
http://www.certinomis.fr/publi/rgs/DT-FL-1310-020-PC-SERV-1.4-EN.pdf

Franck

Comment 34

[Franck Leroy]

Hello

2 CPs others are available in English :

AA & AGENTS CA for AA Servers
------------ (requirements for French Regulation and ETSI/TS 102 042 including BR-PTC)
http://www.certinomis.fr/publi/rgs/DT-FL-1310-040-PC-AA-1.4-EN.pdf

Easy CA for WebSSL
------------ (requirements ETSI/TS 102 042 including BR-PTC)
http://www.certinomis.fr/publi/rgs/DT-FL-1310-060-PC-WEBSSL-1.4-EN.pdf


Franck

Comment 35

[Kathleen Wilson]

Franck, I can no longer access the website, https://g3-test.certinomis.com/

I was just getting ready to close the discussion and recommend approval, but wanted to try out the revocation tester on the test site first:
http://certificate.revocationcheck.com/g3-test.certinomis.com

Comment 36

[Franck Leroy]

Hello

this test web site is down... May be you can try with a real one like : https://igc-g3.certinomis.com/

http://certificate.revocationcheck.com/igc-g3.certinomis.com

Franck.

Comment 37

[Kathleen Wilson]

(In reply to Franck Leroy from comment #36)
> Hello
> 
> this test web site is down... May be you can try with a real one like :
> https://igc-g3.certinomis.com/

OK. I'll change the test URL to this one.

> 
> http://certificate.revocationcheck.com/igc-g3.certinomis.com

Please resolve the OCSP errors, and comment in this bug when there are no more errors

Comment 38

[Franck Leroy]

Hello,

Error 1:
--------
"OCSP signing certificate does not contain the OCSP No Check extension"

OCSP certificates have been renewed with the no-check extension. No more error.

Error 2: 
--------
"http://igc-g3.certinomis.com/INSTANCE_SHA2/ocsp/OCSP_STANDARD (GET)
Error parsing OCSP response"

The response is an html error message, so it cannot be parsed.
Actually the OCSP responder does not support GET requests as no response are cached.
The OCSP - RFC 2560 (and newer) states:
      To enable HTTP caching, small requests (that
      after encoding are less than 255 bytes), MAY be submitted using GET.
      If HTTP caching is not important, or the request is greater than 255
      bytes, the request SHOULD be submitted using POST.

My understanding is that it is recommended (SHOULD) to use POST method but it the request is small enough then it is permitted (MAY), but not mandatory, to use GET.

GET method is mandatory for the Lightweight OCSP - RFC 5019.
BR states that: OCSP responses MUST conform to RFC2560 and/or RFC5019.
So IHMO it is not mandatory for a CA to implement the RFC 5019.

GET is only interesting for HTTP caching (for High-Volume Environments), but such requests are catchable (could generates some privacy issues).

Error 3: 
--------
"bad signature on embedded certificate
OCSP response expired"

The expired error is very strange because we do not set 'next update' is the ocsp response, so there is no expiration.
May be the script doesn't support this and says that the response is expired. Checking with openssl is OK with no expired issue:
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 6C46463BA1C0DB3931AFA07E23B21AFD44CF4BB8
          Issuer Key Hash: 2CC5E3202FAB0A11D6F73AD75178F46C8FB10059
          Serial Number: 791F4C411539E25A333BD5E7E91B2A6F325F808C
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C31AD9395D3A00EE337F9A0BA43B3293938B7C04
    Produced At: May 21 15:09:53 2015 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 6C46463BA1C0DB3931AFA07E23B21AFD44CF4BB8
      Issuer Key Hash: 2CC5E3202FAB0A11D6F73AD75178F46C8FB10059
      Serial Number: 791F4C411539E25A333BD5E7E91B2A6F325F808C
    Cert Status: good
    This Update: May 21 15:09:53.883 2015 GMT

    Signature Algorithm: sha256WithRSAEncryption
         66:dd:21:e0:11:b7:e8:15:0b:39:22:95:f9:76:a6:c0:7a:88:
         bd:d0:2a:fe:19:41:41:92:24:2e:c1:0a:e8:7f:2d:7a:51:f6:
         b6:fe:42:e6:72:e1:a7:41:00:e9:3e:19:19:f1:ad:e2:88:d5:
         9c:28:39:08:9e:63:2d:a3:d8:0a:36:2d:0a:7f:60:8f:02:c1:
         d7:be:ea:39:2c:8e:24:6d:c3:0f:8d:70:d0:c0:df:90:36:80:
         0e:03:e7:7c:90:cb:53:94:14:9f:f8:a2:99:56:bd:d4:8c:7c:
         c7:02:2e:7f:18:7b:77:61:d8:ed:10:8d:f8:d3:be:ac:af:9f:
         28:34:3c:27:de:04:f5:54:12:3d:30:c9:57:29:ed:6a:03:97:
         86:e1:8b:92:ab:0e:7c:a3:f8:42:93:1b:3e:a0:75:0a:3c:72:
         77:68:a1:a2:2c:30:7e:eb:d1:54:4f:b5:b4:66:b6:31:71:85:
         d3:4a:40:e1:b4:e5:02:1c:45:08:f7:93:4a:e4:80:31:6a:74:
         a3:1c:7a:60:c1:96:7f:57:a2:e0:8d:51:ce:a1:e7:57:34:63:
         d4:27:e1:46:22:c2:23:7e:88:79:fb:53:44:98:5b:84:e9:a2:
         fe:90:52:02:31:66:33:29:ce:25:96:71:20:63:10:72:5d:ed:
         87:04:0d:a8
[…]
-----END CERTIFICATE-----
cert-easy.pem: good
        This Update: May 21 15:09:53.883 2015 GMT

Comment 39

[Kathleen Wilson]

(In reply to Franck Leroy from comment #38)
> 
> Error 2: 
> --------
> "http://igc-g3.certinomis.com/INSTANCE_SHA2/ocsp/OCSP_STANDARD (GET)
> Error parsing OCSP response"
> 
> The response is an html error message, so it cannot be parsed.
> Actually the OCSP responder does not support GET requests as no response are
> cached.
> The OCSP - RFC 2560 (and newer) states:
>       To enable HTTP caching, small requests (that
>       after encoding are less than 255 bytes), MAY be submitted using GET.
>       If HTTP caching is not important, or the request is greater than 255
>       bytes, the request SHOULD be submitted using POST.
> 
> My understanding is that it is recommended (SHOULD) to use POST method but
> it the request is small enough then it is permitted (MAY), but not
> mandatory, to use GET.
> 
> GET method is mandatory for the Lightweight OCSP - RFC 5019.
> BR states that: OCSP responses MUST conform to RFC2560 and/or RFC5019.
> So IHMO it is not mandatory for a CA to implement the RFC 5019.
> 
> GET is only interesting for HTTP caching (for High-Volume Environments), but
> such requests are catchable (could generates some privacy issues).


I asked Paul, who is providing the http://certificate.revocationcheck.com/ site...
[Paul] The check for GET is implemented for RFC5019 and referring to the baseline requirements. I don’t see the difference from a privacy point of view between GET and POST requests as both expose the same data, only on a different place. To get OCSP scalable you want to be compliant with RFC5019 (The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments). Privacy concerns should be solved by stapling the OCSP response.

I don't believe this is a show-stopper for now, but I recommend that you consider OCSP GET and/or stapling.

> 
> Error 3: 
> --------
> "bad signature on embedded certificate
> OCSP response expired"
> 
> The expired error is very strange because we do not set 'next update' is the
> ocsp response, so there is no expiration.
> May be the script doesn't support this and says that the response is
> expired.

You are correct that the script doesn't support responses that don’t contain a Next Update value. For high volume environments (and according to RFC5019) it is necessary to set 'next update' in the OCSP response. However, this is not a show-stopper for root inclusion. Paul said that he will change the error message so it doesn't say the response is expired.

So, based on this, I will close the discussion and recommend approval in this bug.

Comment 40

[Franck Leroy]

Hello

good news!

I have open a ticket to our editor to know how to activate the GET method in the OCSP responder.

Regards
Franck Leroy

Comment 41

[Kathleen Wilson]

The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at
https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

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

Inclusion Policy Section 4 [Technical]. 
I am not aware of instances where Certinomis has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
Certinomis appears to provide a service relevant to Mozilla users. Certinomis delivers certificates to the general public in France, and is the Certificate Service Provider of "La Poste" the French Postal Service. Certinomis is a commercial CA serving a global client base, active in both the markets for SSL and End User Certificates with a focus on digital signatures. The company is a Qualified Certification Services Provider in France, and an issuer of eID for both enterprises and individuals.

	 
This request is to include the “Certinomis - Root CA” root certificate, and enable the Websites trust bit. This SHA-256 root will eventually replace the “Certinomis - Autorité Racine” G2 root certificate that was included in NSS via Bug #545614. 

Root Certificate Name: Certinomis - Root CA
O From Issuer Field: Certinomis
Trust Bits: Websites
EV Policy OID(s): Not EV

Root Certificate Download URL: http://www.certinomis.fr/publi/cer/AC_Racine_G3.cer

CA Document Repository: http://www.certinomis.com/documents-et-liens/nos-politiques
CP: http://www.certinomis.fr/publi/rgs/DT-FL-1310-060-PC-WEBSSL-1.4-EN.pdf
CPS: http://www.certinomis.com/documents-et-liens/nos-politiques
AA & AGENTS CA for AA Servers
- (requirements for French Regulation and ETSI/TS 102 042 including BR-PTC)
http://www.certinomis.fr/publi/rgs/DT-FL-1310-040-PC-AA-1.4-EN.pdf 
Easy CA / Prime CA for Individuals
-(requirements for French Regulation and ETSI/TS 101 456 including BR-PTC)
http://www.certinomis.fr/publi/rgs/DT-FL-1310-010-PC-ORGA-1.4-EN.pdf
Easy CA / Prime CA for Servers
- (requirements for French Regulation and ETSI/TS 102 042 including BR-PTC)
http://www.certinomis.fr/publi/rgs/DT-FL-1310-020-PC-SERV-1.4-EN.pdf

Certificate Revocation
CRL URL(s): http://crl.igc-g3.certinomis.com/INSTANCE_SHA2/crl/AC_AGENTS-crl-1.crl
http://crl.igc-g3.certinomis.com/INSTANCE_SHA2/crl/AC_EASY-crl-1.crl
http://crl.igc-g3.certinomis.com/INSTANCE_SHA2/crl/AC_PRIME-crl-1.crl
http://crl.igc-g3.certinomis.com/INSTANCE_SHA2/crl/AC_STANDARD-crl-1.crl
NextUpdate: 7 days max, but a fresh CRL every 24h and after each revocation
OCSP URL(s): http://igc-g3.certinomis.com/INSTANCE_SHA2/ocsp/OCSP_AC_AGENTS
http://igc-g3.certinomis.com/INSTANCE_SHA2/ocsp/OCSP_AC_EASY
http://igc-g3.certinomis.com/INSTANCE_SHA2/ocsp/OCSP_AC_PRIME
http://igc-g3.certinomis.com/INSTANCE_SHA2/ocsp/OCSP_AC_STANDARD

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

SSL Verification Procedures: As per section 3.2.3 of the CP and the explanation provided by the CA, the operator (RA) must verify:
- The link between the organization and the domain name to certify.
- If necessary, ask complements
The ownership of the domain name, on these internet web sites:
- http://www.networksolutions.com/whois/index.jhtml. (domains .com, ..org, .net)
- http://www.afnic.fr/outils/whois (domains .fr)
- http://www.eurid.eu (domains .eu)
- http://www.norid.no/domenenavnbaser/domreg.html (other countries)
If the identified organization is not the owner of the domain, the recorded owner of the domain must provide an authorization of usage of domain name to the identified organization.
The domain’s contact information must be up-to-date. If not the domain owner must update them. When done, he must notify the operator for checking the domain name recording and then the operator can validate the certificate request.
In addition, if the request is done under the form of a request accompanied with a CSR, this one is checked by the back office tool in order to verify the proof of possession of the private key. 

Email Verification Procedures: Not requesting the Email trust bit.

Code Signing Subscriber Verification Procedure: Not requesting the Code Signing trust bit.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by LSTI, according to the ETSI TS 102 042 criteria.
Standard Audit: 	http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8451590

Inclusion Policy Section 18 [Certificate Hierarchy]
The root has signed 4 internally-operated subordinates CAs for issuing end-entity certificates.
http://www.certinomis.com/documents-et-liens/nos-certificats-racines
http://www.certinomis.fr/publi/cer/AC_AGENTS.cer
http://www.certinomis.fr/publi/cer/AC_EASY.cer
http://www.certinomis.fr/publi/cer/AC_PRIME.cer
http://www.certinomis.fr/publi/cer/AC_STANDARD.cer
Externally Operated SubCAs: At this time, only Certinomis operates subordinate CAs of the Certinomis Root CA, but the CP does not forbid external subCAs. The RGS policy documentation indicates that any future external subCAs would have to meet the same level of requirements as the current Certinimos CP/CPS and be audited.
Cross Signing: This new root cross-certifies with the “Certinomis - Autorité Racine” root. As in France it is now forbidden to produce sha1 and as mozilla/Microsoft/google... process is long then we decided finally to cross certify.

Based on this assessment I intend to approve this request from Certinomis to include the “Certinomis - Root CA” root certificate, and enable the Websites trust bit. 

ACTION Items for Certinomis: (to be done in parallel of inclusion process)
1) In next update to CP/CPS, consider the feedback provided by Ryan Sleevi in the discussion: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/B44zk_YO9zE/lyfaXpVXP4MJ
2) Activate the GET method in the OCSP responder per Comment #39 and 40.

Comment 42

[Kathleen Wilson]

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

** "Certinomis - Root CA" (websites)

I will file the NSS bug for the approved changes.

Comment 43

[Kathleen Wilson]

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

Comment 44

[Franck Leroy]

Hello

Get method will be activated by the end of June, and nextUpdate will be added in response by the end of the year.

Franck.

Comment 45

[Franck Leroy]

Hello

The 'Get' method has been activated for OCSP requests.

Best regards
Franck.

Comment 46

[Kathleen Wilson]

Attachment: 2015AuditStatement.pdf

Comment 47

[Kathleen Wilson]

Attachment: 2016AuditAttestation.PDF

Comment 48

[Franck Leroy]

Attachment: CAB assessment report 2017

Comment 49

[Wayne Thayer]

Attachment: 2018 Attestation letter.PDF

Comment 50

[Wayne Thayer]

Attachment: 2018 Attestation letter.PDF

Comment 51

[Marc MAITRE]

Attachment: CERTINOMIS CPS-1.9.pdf