711366 - Add Atos Trustcenter CA cert to trusted root CA cert list

Status: RESOLVED FIXED

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

Description

[Martin Kramer]

Attachment: Atos_ca_Information_v1.0.pdf

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




Expected results:

Hello,

we want you to add the Atos Trustcenter Root CA to Mozilla's trusted root CA cert list.

I collected all needed information from the "Ca Information Checklist" to the attached document "Atos_ca_Information_v1.0.pdf".

If you need more information please contact me.
In second case you can contact the Atos Trustcenter leader Matthias Mönter ([e-mail]).

Additional hint:
At the moment our company executes a corporate conversion. Our previous company name was Atos Origin (Atos Origin GmbH), now we are Atos (Atos Information Technology GmbH).
So, our website is available at https://aopki.atosorigin.de (the old URL) and https://pki.atos.net (the new one).
At the moment the SSL-certificate is exposed for aopki.atosorigin.com and will be changed to the new one in the next few days.

Comment 1

[Martin Kramer]

Attachment: Atos CPS

Comment 2

[Martin Kramer]

Attachment: Atos Subscriber Agreement

Comment 3

[Martin Kramer]

Attachment: Client-Certificate (Martin Kramer)

Comment 4

[Martin Kramer]

Attachment: CodeSigning-Certificate (Martin Kramer)

Comment 5

[Martin Kramer]

The website ist now available with the correct SSL-certificate at 

https://pki.atos.net/TrustedRoot/

Comment 6

[Kathleen Wilson]

I plan to start the Information Verification soon (still catching up from holidays).
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 7

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

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

Comment 8

[Martin Kramer]

Hello, here are the further information for the highlighted items.

1:
I see that there may be external RAs. Are they allowed to directly issue certificates? If yes, how are they constrained? Does Atos run any checks before issuing the certs?

->
No RA is issuing certificates on behalf of Atos Trusted Root and it is not intended to do this in the future. RAs are only be used to register subscribers but not to issue certificates. For this Atos Trusted Root will perform the following steps:
1) The RA will have a signed contract with Atos. Part of this contract is the CPS in the then-current version, corresponding Work-instructions and Security Requirements.
2) The RA has to agree to act according to the paragraphs of this documents.
3) Periodic audits by Atos Trusted Root will be done to verify that.
4) Those audits will be scheduled in the list Periodical Checks (in German: "Regelmäßige Prüfungen"), which is an attachment to the IT security concept of Atos Trusted Root.

2:
Mozilla’s policy requires annual audits. I did not find a statement about annual audits in the CPS.

->
Annual audits are requirements which derive directly from the ETSI-certification. 
Therefore they are not explicitly mentioned in the CPS. Annual audits (internal and external) are scheduled in the list 
Periodical Checks (in German: "Regelmäßige Prüfungen"), which is an attachment to the IT security concept of Atos Trusted Root.

3:
I see that the organization and subscriber identity are checked. Where does it say how it is verified that the certificate subscriber is authorized by the organization to request the code signing certificate?

-> 
This is part of the work instruction document for our trustcenter employees that handles the identification procedure. It is the same procedure like SSL certificate request check, described in our "information checklist" (section 1.4.2 table 1 & 2 / especially table 1 step 2).

4:
Handling of IDNs

->
We are on implmenting a new IDN check in our pki portal. At a new SSL certification request the system will generate the punycode (RFC 3492) of the requested domain name.
While the trustcenter employee checks the reuqest, he has to type the domain name into an input textfield (copy&paste is not allowed/available).
The punycode of this input will be generated too and compared with the first code. On mismatch the trustcenter employee gets a hint and has to check the domain name manually in detail, because there could be an issue of homographic spoofing.

Comment 9

[Martin Kramer]

Hello,
what is the status of this Bug? There are no comments since 2012-02-02.
Do you need further informations or what is the next step ?

regards 
Martin Kramer

Comment 10

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 11

[Kathleen Wilson]

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

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

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

Comment 12

[Martin Kramer]

I attached the Declaration of Conformity, the result of the annual audit as part of our ETSI certification.
(File: AZ 334220 - Declaration of conformity-english.pdf)

Comment 13

[Martin Kramer]

Attachment: AZ 334220 - Declaration of conformity-english.pdf

Comment 14

[Martin Kramer]

Attachment: Atos_ca_Information_v1.1.pdf

Comment 15

[Martin Kramer]

We changed the port of our OCSP service from 2560 to 80.
With this change the users will have fewer firewall conflicts.

I added the information in "Atos_ca_Information_v1.1.pdf"

Comment 16

[Sylvain Rossi]

Hello,

We see you are in the queue for public discussion process. We read your CPS and we understand that your "Client CA" generates end-users' certificates to encrypt email messages.

You have made a key escrow and recovery service to permit to your clients to retrieve their decrypting keys. Can you describe more this service and the security level that you assure on this. Moreover, can you describe the identification process that allow a subscriber to obtain his keys.

Regards,
Sylvain Rossi

Comment 17

[Martin Kramer]

Hello Sylvain,

Only encryption keys (not authentication keys) are stored in an encrypted database in the CA-System of the Atos Trustcenter.
In the case that the user has lost his private key, he is able to restore it and is again able to decrypt his encrypted data.
We see this requirement quite often in business environments.

The security level is the same as when creating the keys, because the keys are stored in an encrypted database in the CA-System.
To recover the keys we follow the 4-eyes-principle: It needs the owner of the keys together with a Trustcenter-employee to process the key-recovery: The user sends the request to the Trustcenter. In the Trustcenter the request is approved. The User is then able to download the keypair (encrypted container).

Regards,

Comment 18

[Sylvain Rossi]

Hello Martin,

Thanks for your answers. We understand that the security level is really high to protect encryption keys and that the process to recover key is done by dual control.

If you are interested , you can see our bugtrack (https://bugzilla.mozilla.org/show_bug.cgi?id=662259) for our SG Trust Root CA.

You can ask us any information on the organizational process or technical requirement we have done.

Regards,
Sylvain

Comment 19

[Kathleen Wilson]

Please add a comment to this bug to provide your response to the action items listed in the CA Communication that was sent today, and is available here:
https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

Comment 20

[Martin Kramer]

Our response to the action items listed in the CA Communication of January 10, 2013:

1.
The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.

Details:
Item #6, third bullet: We already use multi-factor authentication for our trustcenter employees who are capable of directly causing certificate issuance. (Described in 1.4.6 of Atos_ca_Information_v1.1.pdf)
Item #6, fourth bullet: We already have a CA hierachy (Described in 1.3.1 of Atos_ca_Information_v1.1.pdf) so that the included Root-CA does not directly issue end-entity certificates to customers.
There are Sub-CAs (for SSL, Code-Signing and User certuficates) which issuing the end-entity certificates.
Items #9, 10, and 11: All subordinate CA certificates will comply with version 2.1 of the Inclusion Policy. All pre-existing subordinate CA certificates will be updated to comply with version 2.1 of the Inclusion Policy. 
We will not create other certificates that are capable of being used to issue new certificates.
Item #13: All SSL-certificates will also conform to the current version of the CA/Browser Forum Baseline Requirements. (See Point 2)

2.
a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.

3.
We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. 
We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.

4.
We stopped issuing SSL certificates containing Reserved IP Addresses or Internal Server Names since 01-01-2013.

5.
Available at https://pki.atos.net:7081/

Comment 21

[Martin Kramer]

Kathleen, do you already know a start date for the public discussion of our root inclusion request ?

Comment 22

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

I apologize for the delay in my response. My work on root inclusion requests was postponed for a while.

Please check the attached document to confirm that the information is still current.

Comment 23

[Martin Kramer]

We would do two little changes in the document.

1. 
Page 1 - Technical information about each root certificate - Certificate Summary
-> This root has three internally‐operated intermediate types of CAs for issuing SSL server, client, and code signing certificates.
(Change: added word "types")

2.
Page 2 - CA Hierarchy information for each root certificate - CA Hierarchy
The internally-operated types of subCAs are:
• Atos TrustedRoot Client‐CA (Atos TrustedRoot Client‐CA 2011 & Atos TrustedRoot Client‐CA 2012
• Atos TrustedRoot Server‐CA (Atos TrustedRoot Server‐CA 2011)
• Atos TrustedRoot CodeSigning‐CA (Atos TrustedRoot CodeSigning‐CA 2011)
(Change: we created sub-ca "Atos TrustedRoot Client‐CA 2012")


All other information is still current.

Comment 24

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 25

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Atos to include the “Atos TrustedRoot 2011” root certificate and turn on all three trust bits.

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 “Atos Root Inclusion Request”

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

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

Comment 26

[Kathleen Wilson]

The first round of discussion for this request has been closed. The result of the discussion is the following action item, which will be tracked in this bug. After I have confirmed completion of the action item, I will open a second round of discussion for this request. 

ACTION Atos: Complete a Baseline Requirements Audit according to BR #17, and attach the BR audit statement to this bug.

Comment 27

[Martin Kramer]

Hello, 

we now have finished the actions we had to do after the first public discussion.

Our actions we had to do after first public diskussion: 
- We completed a Baseline Requirements Audit. ETSI TS 102042 V2.4.1 
  - Available at: https://pki.atos.net/Download/ETSI_2013-07-10_English.pdf
 
Attachements:
ETSI certificate  (ETSI_2013-07-10_English.pdf)
DQS Statement to Impacts of the public diskussion (DQSStatementImpactsAtos.pdf)
CPS v1.6 (AtosTrustedCACPSv1.6.pdf)
  
Also we updated the OCSP to not answering with "good" for non issued serialnumbers.

Additionally here are our answers for the CA Communication from July 30, 2013:

1) Update your CA operations and policies to include the CA/Browser Forum’s Baseline Requirement #11.1.4 regarding new gTLD domains, and subscribe to ICANN’s new gTLD Registry Agreement notification mailing list at: https://mm.icann.org/mailman/listinfo/gtldnotification

No action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that we want to include in Mozilla’s program.

2) 2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. Mozilla’s CA Certificate Enforcement Policy has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates.

We have reviewed Mozilla’s updated CA Certificate Enforcement Policy and understand that knowing or intentional mis-issuance of a certificate is expressly against Mozilla’s CA Certificate Policy and could result in removal of all of our certificates from Mozilla’s products.

3) 3) Ensure that your CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current, including links to the CP/CPS documents, audit statements, and test websites. Mozilla will be adding a column to this spreadsheet to indicate the date of the most recent audit statement for each root certificate.

Here is the current information for our certificates that we want to include in Mozilla’s program:
Owner
 - Atos
Organization (O from Issuer Field)
 - Atos
Organizational Unit (OU from Issuer Field)
 - -/-
Common Name or Certificate Name
 - Atos TrustedRoot 2011
From
 - ‎‎2011 ‎Jul 7
To
 - ‎2031 ‎Jan 1
Modulus
 - 2048
Signature Algorithm
 - SHA-256
Web Trust Bit
 - Yes
Email Trust Bit	
 - Yes
Code Trust Bit	
 - Yes
EV Enabled?	
 - No
Approval Bug
 - https://bugzilla.mozilla.org/show_bug.cgi?id=711366
Release When First Included
 - -/-
URL to Test Website
 - https://pki.atos.net:7081
Company Website	
 - http://atos.net
Certificate Policy (CP)	/ Certification Practice Statement (CPS)	
 - https://pki.atos.net/Download/AtosTrustedCACPSv1.6.pdf
Audit / Baseline Requirements Audit	
 - https://pki.atos.net/Download/ETSI_2013-07-10_English.pdf
 - https://pki.atos.net/Download/ETSI_2013-07-10_Deutsch.pdf
EV Audit	
 - -/-
Auditor	
 - DQS
Audit Criteria	
 - ETSI TS 102 042

Comment 28

[Martin Kramer]

Attachment: ETSI_2013-07-10_English.pdf

Comment 29

[Martin Kramer]

Attachment: DQSStatementImpactsAtos.pdf

Comment 30

[Martin Kramer]

Attachment: AtosTrustedCACPSv16.pdf

Comment 31

[Kathleen Wilson]

Is the ETSI_2013-07-10 ETSI Certifiate available on the DQS website? 
If yes, would you please tell me how to get to it?
If no, I will have to contact the auditor to confirm the authenticity of the document. 
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification step 4: "Do an independent verification of the audit when the report is provided by or posted by the submitter"

Is the new version of the CPS also available on the Atos website? If yes, please tell me how to get to it.
I get v1.5 when I browse to https://pki.atos.net/TrustedRoot/  -> Downloads -> Other downloads

Comment 32

[Martin Kramer]

After contacting DQS the ETSI certificate is available on the DQS website.
https://www.mydqs.com/en/customers.html
Search in customer database with company = Atos Information Technology GmbH
At the moment only the german version is available on the website. DQS is working on provide the english one. (I will notify you if its is available too)

We added version 1.6 of the CPS to the Atos website (https://pki.atos.net/TrustedRoot/), so both versions are available, 1.5 and 1.6.

Comment 33

[Martin Kramer]

Now also the english version of the ETSI certificate is available on the DQS website.

Comment 34

[Kathleen Wilson]

I am now opening the second public discussion period for this request from Atos to include the “Atos TrustedRoot 2011” root certificate and turn on all three trust bits.

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 “Atos Root Inclusion Request”

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

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

Comment 35

[Kathleen Wilson]

> The discussion thread is called “Atos Root Inclusion Request”

The new discussion thread is called "Second discussion of Atos Root Inclusion Request"

Comment 36

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s 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 to include the “Atos TrustedRoot 2011” root certificate and turn on all three trust bits.

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

Section 6 [Relevance and Policy]. Atos appears to provide a service relevant to Mozilla users. It is a large IT-company in Europe that manages servers for many different customers. Atos Trustcenter acts in Europe, but also has international customers. The PKI-Services are offered to the Public, with no restrictions to user groups. 

Policies are documented in the CPS published on their website and listed in the entry on the pending applications list.

Document Repository: https://pki.atos.net/TrustedRoot/
CPS (English): https://pki.atos.net/Download/AtosTrustedCACPSv1.7.pdf

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

* SSL: According to section 4.2 of the CPS, Atos verifies the legal entity is the Domain Name Registrant or has control over the Internet Domain Names given in the certificate (can be found for Germany with www.denic.de or internation-al with www.iana.org); the legal entity full name or a verified tradename matches the subject’s organization name in the certificate; and the existence of the legal entity is evident from an excerpt from the commercial register (certificate of registration, in Germany: Handelsregisterauszug).

* Email: According to section 4.2 of the CPS, a challenge-response mechanism is used to confirm that the certificate subscriber owns/controls the email address to be included in the certificate.

* Code: According to section 4.2 of the CPS, Atos verifies the identity of the certificate subscriber, the organization, and the authority of the certificate subscriber to request the certificate on behalf of the organization.

Section 18 [Certificate Hierarchy]
This root signs three types of internally-operated intermediate certificates for issuing SSL server, client, and code signing certificates. 

* EV Policy OID: Not applicable. Not requesting EV treatment for this root.

* CRL 
https://pki.atos.net/crl/Atos_TrustedRoot_CA_2011.crl
http://pki.atos.net/crl/Atos_TrustedRoot_Server_CA_2011.crl (NextUpdate: 24 hours)
CPS section 3.3: CRLs are published at least every 24 hours.

* OCSP
http://pki-ocsp.atos.net

Sections 11-14 [Audit]. 
Annual audits are performed by DQS GmbH according to the ETSI TS 102 042 criteria. The most recent audit also included verification of compliance with the CA/Browser Forum Baseline Requirements.
The ETSI certificate may be found on the auditor’s website, https://www.mydqs.com/en/customers.html
Search in customer database with Company = Atos Information Technology GmbH

Based on this assessment I intend to approve this request to include the “Atos TrustedRoot 2011” root certificate and enable all three trust bits.

Comment 37

[Kathleen Wilson]

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

** "“Atos TrustedRoot 2011" (websites, email, code signing)

I will file the NSS bug for the approved changes.

Comment 38

[Kathleen Wilson]

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

Comment 39

[Kathleen Wilson]

Attachment: Bericht ETSI 334220.pdf

2016 Audit Statement