Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Certinomis Request to Include Renewed Root

415 views
Skip to first unread message

Kathleen Wilson

unread,
Dec 18, 2014, 7:19:33 PM12/18/14
to mozilla-dev-s...@lists.mozilla.org
Certinomis has applied 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.

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. Certinomis delivers certificates to the general public in
France, and is the Certificate Service Provider of "La Poste" the French
Postal Service.

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

And in the pending certificates list:
http://www.mozilla.org/projects/security/certs/pending/

Summary of Information Gathered and Verified:
Old format: https://bugzilla.mozilla.org/attachment.cgi?id=8520786
New SalesForce format:
https://bugzilla.mozilla.org/attachment.cgi?id=8538844

Noteworthy points:

* The primary documents are in French. Some sections have been
translated into English and attached to the bug.

Document Repository:
http://www.certinomis.com/documents-et-liens/nos-politiques
Root CP (French):
http://www.certinomis.com/publi/rgs/DT-FL-1310-001-PC-RACINE-1.2.pdf
Web SSL CP (French):
http://www.certinomis.com/publi/pc/DT-FL-1310-060-PC-WEB-SSL-1.2.pdf
SSL for private sector:
http://www.certinomis.com/publi/rgs/DT-FL-1310-020-PC-SERV-1.3.pdf
SSL for administration sector:
http://www.certinomis.com/publi/rgs/DT-FL-1310-040-PC-AA-1.3.pdf

CP sections translated into English:
https://bugzilla.mozilla.org/attachment.cgi?id=8340982
CPS sections translated into English:
https://bugzilla.mozilla.org/attachment.cgi?id=8340984

* CA Hierarchy: The root has signed 4 internally-operated subordinates
CAs for issuing end-entity certificates: AA et Agents – issues 1 and 2
star SSL certificates, Easy CA, Prime CA, and Standard CA. 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.

* This request is to turn on only the Websites trust bit.

** Translation of Web SSL CP section 3.2.3.3: The identification of the
future device (or application) representing a organization needs, on one
hand, the identification of this entity and, on the other hand, the
identification of the physical person in charge of the device and at
last the identity of the device.
The identification of the entity and person in charge of the device is
realized following the disposals of the item 3.2.3.1 and if the entity
designates a certificate agent, following disposals of the item 3.2.3.2.
RA verifies that the requester is authorized by his organization to
receive certificates for the device or the application. The person or
the organization that presents a request must establish the proof of his
right of usage on the device or the application that will have the
requested certificate. In particular in the case of a web server, the
person will have to establish the proof that the domain name belongs to him.
RA verifies that the request contains the following documents:
- A written request of certificate, dated back to less than 3 months,
signed by a legal representative of the entity or by the certificate
agent, containing the server FQDN.
- A signed mandate, and dated back to less than 3 months, by a legal
representative of the organization or by the certificate agent
designating the future holder to which the certificate must be
delivered. This mandate must be signed for acceptance by the future
certificate holder.
- A proof of possession by the entity of the domain name corresponding
to the FQDN of the server.
The RA preserves the documents received for the recording of the holder,
examines the given pieces and documents with a reasonable care and
verifies if they appear to be conformant and valid.

Explanation:
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.

* EV Policy OID: Not requesting EV treatment at this time.

* Root Cert URLs
http://www.certinomis.fr/publi/cer/AC_Racine_G3.cer

* Test Websites
https://g3-test.certinomis.com/

* CRL
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
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


* Audit: Certinomis is audited by LSTI according to the ETSI TS 102 042
v2.4.1 criteria for LCP/NCP/NCP+/PTC-BR.
http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf
Auditor’s Statement (G2):
https://bugzilla.mozilla.org/attachment.cgi?id=8451590

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

This begins the discussion of the request from Certinomis to include the
“Certinomis - Root CA” root certificate, and enable the Websites trust
bit. At the conclusion of this discussion I will provide a summary of
issues noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

Matt Palmer

unread,
Dec 18, 2014, 8:35:13 PM12/18/14
to dev-secur...@lists.mozilla.org
On Thu, Dec 18, 2014 at 04:18:27PM -0800, Kathleen Wilson wrote:
> Certinomis is a commercial CA serving a global client base, active

[...]

> * The primary documents are in French. Some sections have been
> translated into English and attached to the bug.

While the sections translated into English are reasonably detailed (compared
to other CPS I've read), I'm a bit... wary, I guess I'd call it -- about a
CA that purports to serve a global audience yet distributes its core
documentation in French. For better or worse, English is the common
language of the Internet.

If I'm a lone voice on this, that's OK -- I just bring it up as a point for
discussion.

Of the sections of the CPS that have been translated, the only thing that
stood out for was the description of what an FQDN is -- it isn't
particularly accurate. It reads like a request to register a certificate
for `example.com` would be rejected because it doesn't match the description
of an FQDN (also, hopefully, because it would be tricky to prove control
over the name...)

- Matt

Franck Leroy

unread,
Dec 19, 2014, 5:43:20 PM12/19/14
to mozilla-dev-s...@lists.mozilla.org
Hello mat,

Previous CP (sha1) have been translated into English, and this one (sha2) is quite the same and will be translated after our next audit on January.
If needed I can give you the link to the previous English one, CA names changed but not practices.

Franck
Certinomis CTO

Kathleen Wilson

unread,
Jan 15, 2015, 12:08:12 PM1/15/15
to mozilla-dev-s...@lists.mozilla.org
On 12/18/14 4:18 PM, Kathleen Wilson wrote:
> Certinomis has applied 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.
>

All,

The status of this discussion is that we are waiting for the current CP
to be translated into English. Franck is trying to get this done by
early February, and will update this discussion when the document is
available.

In the meantime, please add to this discussion if you have further
questions or comments about this root inclusion request.

Thanks,
Kathleen



Kathleen Wilson

unread,
Apr 6, 2015, 1:02:33 PM4/6/15
to mozilla-dev-s...@lists.mozilla.org
Certinomis has translated the following into 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



Please continue with this review and discussion of the request from
Certinomis to include the “Certinomis - Root CA” root certificate, and
enable the Websites trust bit.

Thanks,
Kathleen

Kathleen Wilson

unread,
Apr 6, 2015, 3:20:41 PM4/6/15
to mozilla-dev-s...@lists.mozilla.org
> Certinomis has translated the following into 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
>

These have also been translated into 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


kwi...@mozilla.com

unread,
Apr 24, 2015, 7:45:37 PM4/24/15
to mozilla-dev-s...@lists.mozilla.org
On Thursday, December 18, 2014 at 4:19:33 PM UTC-8, Kathleen Wilson wrote:
> Certinomis has applied 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.
>
> 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. Certinomis delivers certificates to the general public in
> France, and is the Certificate Service Provider of "La Poste" the French
> Postal Service.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=937589
>
> And in the pending certificates list:
> http://www.mozilla.org/projects/security/certs/pending/
>
> Summary of Information Gathered and Verified:
> Old format: https://bugzilla.mozilla.org/attachment.cgi?id=8520786
> New SalesForce format:
> https://bugzilla.mozilla.org/attachment.cgi?id=8538844
>


Does anyone have questions or comments about this root renewal request from Certinomis?

If not, I will close this discussion and recommend approval in the bug.

Thanks,
Kathleen

Ryan Sleevi

unread,
May 4, 2015, 7:02:45 PM5/4/15
to kwi...@mozilla.com, mozilla-dev-s...@lists.mozilla.org
On Fri, April 24, 2015 4:45 pm, kwi...@mozilla.com wrote:

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

> Does anyone have questions or comments about this root renewal request
> from Certinomis?
>
> If not, I will close this discussion and recommend approval in the bug.

Hi Kathleen,

I've completed review of the AA Server [1] and TLS server [2] CPSes.

Overall, I found these much more detailed then the average CPS I've
reviewed, and so I'm appreciative of Certinomis taking the time to provide
this information.

In the course of reviewing, I found several areas for clarification. I
defer to your judgement on whether or not these represent blocking issues.

In examining both documents, it seems these issues are shared. As such,
I'll only refer to citations from the AA document [1] for ease of
discussion.

===== Copyright =====
Page 8 establishes that the CPS is protected by copyright and may not be
redistributed, in part or in full, by third parties without prior express
written agreement. This does seem potentially problematic, in as much as
Mozilla is therefore not authorized to archive or provide a copy of the
CPS for future review or discussions.

The current Mozilla policy requires only that certificates be unencumbered
- namely, part 10 of [3] - which states "All disclosure MUST be made
freely available and without additional requirements, including, but not
limited to, registration, legal agreements, or restrictions on
redistribution of the certificates in whole or in part."

I highlight this as a potential issue, but one that may not require
remediation pursuant to Mozilla's policies.

===== Usage Restrictions =====
Page 15, Section 1.4.2 establishes a set of restrictions on the use of the
certificates it issues. In doing so, it also includes a disclaimer that
"Under none of the above hypotheses can the CA be held liable in any way."

It is important for Certinomis to be aware that if they issue a
certificate that is technically capable of causing further issuance, they
will be held liable under the Mozilla policy. This was most recently
evidenced in the actions taken against CNNIC.

While Certinomis establishes a certificate profile that prohibits the
certificates from being technically capable, should those controls fail
(e.g. as with TurkTrust), they will be held accountable and liable for
that.

===== Trademark Usage =====
Page 22, Section 3.1.6, disclaims liability for the use of trademarked
names. Namely, "The CA cannot be held liable in case of the unlawful usage
by its customers and beneficiaries of
registered trademarks, well-known marks and distinctive signs, or of
domain names."

However, as with Mozilla policy, if the CA misissues a certificate
containing a trademarked domain name to a party not authorized to receive
such a certificate, then they will be held liable.

That is, it's perfectly reasonable for the CA to disclaim any liability
that might occur with issuing a certificate to "fordsucks.com" (as perhaps
the most notable example of such a dispute), but they would be liable if
they issued a certificate for "facebook.com" to an entity not authorized.

===== Revocation Issues =====
On both Page 28, Section 3.3.2, and Page 36, Section 4.9.2.1, the list of
parties authorized to request revocation exclude the public. This creates
an issue where the public (or relying party) may detect a certificate that
is non-compliant with the CA's policies and practices. This is an issue
that I've raised in the past.

The revised BRs 1.3.0 failed to account for this in 4.9.2, but 4.9.1.2
establishes the obligation of the CA to revoke when made aware of issues.
Under the BRs 1.2.5 (which BRs 1.3.0 is meant to be identical in
obligations to), this was made explicit in Section 13.1.2 - which is
carried onto 4.9.3 in the BRs 1.3.0.

===== Publication of Certificates =====
While not a blocker, as it is not required by current Mozilla policy, Page
31, Section 4.4.2 seems to prohibit Certinomis from participating in
Certificate Transparency unless/until it updates these documents.

That may be desired or intentional, but it's just worth noting.


[1] http://www.certinomis.fr/publi/rgs/DT-FL-1310-040-PC-AA-1.4-EN.pdf
[2] http://www.certinomis.fr/publi/rgs/DT-FL-1310-060-PC-WEBSSL-1.4-EN.pdf
[3]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/


Kathleen Wilson

unread,
May 5, 2015, 5:37:58 PM5/5/15
to mozilla-dev-s...@lists.mozilla.org
Ryan,

Thank you for your thorough review of this CA's policy documentation.

While all of these items are indeed worth noting and I encourage
Certinomis to consider this feedback in the next iteration of their CPS,
I don't believe any of these items are show-stoppers for this request.

If anyone disagrees, please speak up now.
Otherwise, I will close this discussion and recommend approval in the bug.

Thanks,
Kathleen

Kathleen Wilson

unread,
May 21, 2015, 4:40:04 PM5/21/15
to mozilla-dev-s...@lists.mozilla.org
On 5/5/15 2:37 PM, Kathleen Wilson wrote:
> On 5/4/15 4:02 PM, Ryan Sleevi wrote:
>> On Fri, April 24, 2015 4:45 pm, kwi...@mozilla.com wrote:
>>
>>>> The request is documented in the following bug:
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=937589
>>
>>> Does anyone have questions or comments about this root renewal request
>>> from Certinomis?
>>>
>>> If not, I will close this discussion and recommend approval in the
>>> bug.
>>

Thanks again to all of you who reviewed and commented on this request
from Certinomis to include the “Certinomis - Root CA” root certificate,
and enable the Websites trust bit.

I am not aware of remaining issues that would prevent us from moving
forward with this request. Therefore, I am closing this discussion and
will recommend approval in the bug.

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

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen

0 new messages