certification practice statements of atos trustedroot issuing cas · 2020. 6. 4. · atos...

Atos Trustcenter

Trust Service Provider for TrustedRoot Certificates

Certification Practice Statements of Atos TrustedRoot Issuing CAs

Version 02.02.00

Release 04.06.20

Document Atos_TrustedRoot_CPS_Issuing_CAs

Owner TrustedRoot CA Service Manager

Status Released

Classification Public

ATC TR Atos TrustedRoot CA

Issuing CA - CPS

of 58 Version: 02.02.00 Release: 04.06.20

Classification: Public

Table of Contents

1 INTRODUCTION ...................................................................................................... 4 1.1 Overview ................................................................................................................. 4 1.2 Document name and identification ........................................................................... 6 1.3 PKI participants ....................................................................................................... 7 1.4 Certificate usage ...................................................................................................... 8 1.5 Policy administration ................................................................................................ 9 1.6 Definitions and acronyms ........................................................................................10

2 PUBLICATION AND REPOSITORY RESPONSIBILITIES ...................................... 11 2.1 Repositories............................................................................................................11 2.2 Publication of certification information .....................................................................12 2.3 Time or frequency of publication .............................................................................13 2.4 Access controls on repositories ..............................................................................14

3 IDENTICATION AND AUTHENTICATION .............................................................. 15 3.1 Naming ...................................................................................................................15 3.2 Initial identity validation ...........................................................................................17 3.3 Identification and authentication for re-key requests ...............................................20 3.4 Identification and authentication for revocation request ..........................................20

4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ........................... 21 4.1 Certificate application .............................................................................................21 4.2 Certificate application processing ...........................................................................22 4.3 Certificate issuance ................................................................................................23 4.4 Certificate acceptance ............................................................................................24 4.5 Key pair and certificate usage .................................................................................25 4.6 Certificate renewal ..................................................................................................25 4.7 Certificate re-key ....................................................................................................26 4.8 Certificate modification ...........................................................................................27 4.9 Certificate revocation and suspension ....................................................................28 4.10 Certificate status services .......................................................................................31 4.11 End of subscription .................................................................................................31 4.12 Key escrow and recovery ........................................................................................31

5 FACILITY, MANGEMENT, AND OPERATIONAL CONTROLS ............................... 32 5.1 Physical controls .....................................................................................................32 5.2 Procedural controls .................................................................................................32 5.3 Personnel controls ..................................................................................................33 5.4 Audit logging procedure ..........................................................................................34 5.5 Records archival .....................................................................................................34 5.6 Key changeover ......................................................................................................35 5.7 Compromise and disaster recovery ........................................................................35 5.8 CA or RA termination ..............................................................................................35

6 TECHNICAL SECURITY CONTROLS .................................................................... 36 6.1 Key pair generation and installation ........................................................................36 6.2 Private key protection and cryptographic module engineering controls ...................38 6.3 Other aspects of key pair management ..................................................................40 6.4 Activation data ........................................................................................................40 6.5 Computer security controls .....................................................................................40 6.6 Life cycle technical controls ....................................................................................41 6.7 Network security controls ........................................................................................41 6.8 Timestamping .........................................................................................................41

7 CERTIFICATE, CRL, AND OCSP PROFILES ........................................................ 42


Issuing CA - CPS



7.1 Certificate profile .....................................................................................................42 7.2 CRL profile .............................................................................................................45 7.3 OCSP profile ...........................................................................................................45

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS ........................................... 46 8.1 Frequency and circumstances of assessment ........................................................46 8.2 Identity/qualifications of assessor ...........................................................................46 8.3 Assessor's relationship to assessed entity ..............................................................46 8.4 Topics covered by assessment ...............................................................................46 8.5 Actions taken as a result of deficiency ....................................................................46 8.6 Communications of results ......................................................................................46

9 OTHER BUSINESS AND LEGAL MATTERS ......................................................... 47 9.1 Fees .......................................................................................................................47 9.2 Financial responsibility ............................................................................................47 9.3 Confidentiality of business information ....................................................................47 9.4 Privacy of personal information ...............................................................................48 9.5 Intellectual property rights .......................................................................................48 9.6 Representations and warranties .............................................................................49 9.7 Disclaimers of warranties ........................................................................................50 9.8 Limitations of liability ...............................................................................................50 9.9 Indemnities .............................................................................................................50 9.10 Term and termination ..............................................................................................50 9.11 Individual notices and communications with participants ........................................50 9.12 Amendments ..........................................................................................................50 9.13 Dispute resolution provisions ..................................................................................51 9.14 Governing law .........................................................................................................51 9.15 Compliance with applicable law ..............................................................................51 9.16 Miscellaneous provisions ........................................................................................51 9.17 Other provisions .....................................................................................................52

10 Abbreviations and terms ......................................................................................... 53 10.1 Abbreviations ..........................................................................................................53 10.2 Terms .....................................................................................................................55

11 Information to the document ................................................................................... 56 11.1 Document history ....................................................................................................56 11.2 Table of figures .......................................................................................................57 11.3 Table of tables ........................................................................................................57 11.4 References .............................................................................................................58


Issuing CA - CPS



1 INTRODUCTION

Preamble: The term Certificate Authority = CA is used for two different meanings:

• The organisation, which is responsible for operating trustworthiness services;

• The technical entity for issuing and revocation of electronic certificates.

The following definitions are made to differentiate both meanings:

• If the organisation is meant, then the term "Atos TrustedRoot CA" is used;

• If the technical entity is meant then the full entity name "Atos TrustedRoot <Entity> CA" is used, e.g. "Atos TrustedRoot Server CA".

The Atos Trustcenter operates the Atos TrustedRoot CA and further trust services. This CPS document refers only to Atos TrustedRoot Issuing CA services.

1.1 Overview

The Atos TrustedRoot CA operates certification services for issuing and managing publicly trusted certificates. In detail the Atos TrustedRoot CA operates the following certificate services:

• Atos TrustedRoot Root CA service issuing - sub-ca certificates and - OCSP certificates;

• Atos TrustedRoot Client CA services issuing - client certificates for authentication, encryption and/or secure e-mail and - OCSP certificates;

• Atos TrustedRoot Server CA services issuing - server certificates for TLS and - OCSP certificates;

• Atos TrustedRoot CodeSign CA services issuing - end entity certificates for code signing and - OCSP certificates;

• Atos TrustedRoot TimeStamp CA services issuing - end entity certificates for time stamping and - OCSP certificates.


Issuing CA - CPS



Figure 1 End Entity Certificate Services

The certificate of Atos TrustedRoot Root CA service is the trust anchor for the complete TrustedRoot certificate hierarchy in the Atos TrustedRoot CA.

This policy document comprises the certificate policy and the certification practice statements for issuing of TrustedRoot end entity certificates issued by Atos TrustedRoot Issuing CAs.

The following ETSI policies are considered:

• The Atos TrustedRoot Client CA end entity certificates are issued following the policies NCP and OVCP (see [6]).

• The Atos TrustedRoot Server CA end entity certificates are issued following the policies NCP, DVCP, OVCP and IVCP (see [6]).

• The Atos TrustedRoot CodeSign CA end entity certificates are issued following the policies NCP and OVCP (see [6]).

• The Atos TrustedRoot TimeStamp CA end entity certificates are issued following the policies NCP and OVCP (see [6]).

This policy document is structured according to RFC 3647 (see [1]).


Issuing CA - CPS



1.2 Document name and identification

Document Name Certification Practice Statements of Atos TrustedRoot Issuing CAs

Document Version 02.02.00

The following Policy OIDs are administrated by Atos TrustedRoot CA:

Atos TrustedRoot ID atos-trustedroot-id = 1.3.6.1.4.1.6189.5.1

iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) atos(6189) trustcenter(5) trusted-root(1)

Atos TrustedRoot Root CA Policy

atos-trustedroot-cps-rootca-id = 1.3.6.1.4.1.6189.5.1.1.1.4 atos-trustedroot-id policy-identifiers(1) cps(1) root-ca(4)

Atos TrustedRoot Client CA SC Policy

atos-trustedroot-cps-clientca-id = 1.3.6.1.4.1.6189.5.1.1.1.1 atos-trustedroot-id policy-identifiers(1) cps(1) client-ca(1)

Atos TrustedRoot Client CA P12 Policy

atos-trustedroot-cps-clientca-softpse-id = 1.3.6.1.4.1.6189.5.1.1.1.1.1 atos-trustedroot-id policy-identifiers(1) cps(1) client-ca(1) softpse(1)

Atos TrustedRoot CodeSign CA Policy

atos-trustedroot-cps-codesignca-id = 1.3.6.1.4.1.6189.5.1.1.1.2 atos-trustedroot-id policy-identifiers(1) cps(1) codesign-ca(2)

Atos TrustedRoot Server CA Policy

atos-trustedroot-cps-serverca-id = 1.3.6.1.4.1.6189.5.1.1.1.3 atos-trustedroot-id policy-identifiers(1) cps(1) server-ca(3)

Atos TrustedRoot TimeStamp CA Policy

atos-trustedroot-cps-timestampca-id = 1.3.6.1.4.1.6189.5.1.1.1.5 atos-trustedroot-id policy-identifiers(1) cps(1) timestamp-ca(5)

The document history can be found in section 11.1.

This document considers the relevant ETSI and CABF requirements:

• ETSI EN 319 401: Electronic Signatures and Infrastructures (ESI); General Policy Requirements for Trust Service Providers [5];

• ETSI EN 319 411-1: Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements [6];

• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates [7].

The standard ETSI EN 319 401 defines general requirements for a trust service provider (TSP). A TSP for certification services has to consider the requirements in standard ETSI EN 319 411-1. A TSP issuing publicly trusted certificates for webserver has in addition to consider the requirements in CABF baseline requirements.


Issuing CA - CPS



1.3 PKI participants

1.3.1 Certification authorities

The Atos TrustedRoot CA operates all certification services of the Atos TrustedRoot hierarchy. This includes:

• Atos TrustedRoot Root CAs;

• Atos TrustedRoot Client CAs;

• Atos TrustedRoot Server CAs;

• Atos TrustedRoot CodeSign CAs;

• Atos TrustedRoot TimeStamp CAs

of sequent generations.

The purpose of the Atos TrustedRoot Root CA is to issue CA certificates for itself and for all subordinated issuing CAs.

The purpose of the Atos TrustedRoot Client CA is to issue end entity certificates for client authentication, encryption and secure e-mail. If in any subsequent section this document refers only to this CA, the corresponding section is marked with: [Client-CA].

The purpose of the Atos TrustedRoot Server CA is to issue end entity certificates for TLS server applications. If in any subsequent section this document refers only to this CA, the corresponding section is marked with: [Server-CA].

The purpose of the Atos TrustedRoot CodeSign CA is to issue end entity certificates for code signing. If in any subsequent section this document refers only to this CA, the corresponding section is marked with: [CodeSign-CA].

The purpose of the Atos TrustedRoot TimeStamp CA is to issue end entity certificates for time stamping. If in any subsequent section this document refers only to this CA, the corresponding section is marked with: [TimeStamp-CA].

In addition, each CA issues the OCSP certificates for signing of OCSP responses which belongs to certificates which this CA has issued.

1.3.2 Registration authorities

The registration authorities (RA) perform the identification and authentication of end entity certificate applicants. Subordinate organizations within or a dedicated group of authorized employees of an external organization can act as a RA.

[Client-CA], [CodeSign-CA], [Server-CA]

In the case of issuing end entity certificates the Atos TrustedRoot CA handover the registration to customer specific registration authorities. The obligations and authorizations of the registration authority are defined in customer contracts (see section 9.6). The RA portals validates the entered data automatically against whitelists (see section 3.2). Acceptable values are defined in the customer agreement.

[TimeStamp-CA]

RA services are not performed by third parties.


Issuing CA - CPS



1.3.3 Subscriber

The Atos TrustedRoot CA issues end entity certificates to natural person as certificate holder (subscriber). The subscriber is:

[Client-CA], [CodeSign-CA]

the certificate user,

[Server-CA], [TimeStamp-CA]

the person who controls the systems which uses the issued certificate.

In any way the subscriber must belong to a customer which has a contract with Atos TrustedRoot CA for issuing of publicly trusted end entity certificates.

1.3.4 Relying parties

The relying parties comprise all persons and systems, who or which rely on the trustworthiness of issued certificates and therefore have to check the status of the issued certificates. Relying parties include amongst others:

• Certificate holder,

• Business partner who are using the issued certificates in business processes.

1.3.5 Other participants

No stipulation.

1.4 Certificate usage

1.4.1 Appropriate certificate uses

The end entity certificates issued by Atos TrustedRoot Issuing CA services may be used according to the purpose they are issued for:

[Client-CA]

Authentication certificates on smart card for client authentication in applications,

Encryption certificates on smart card for data and/or key encryption/decryption,

SoftPSE certificates for authentication/verify and encrypt/decrypt of data and e-mails,

[CodeSign-CA]

Codesign certificates for signature/verify application (e.g. VB scripts, Java code, etc.),

[Server-CA]

TLS client/server certificates for TLS client and server authentication and transport channel encryption,

[TimeStamp-CA]

Timestamp certificates for signature/verify of timestamps.

1.4.2 Prohibited certificate uses

The usage of end entity certificates is limited to the statements in section 1.4.1. It is not allowed to use these certificates for other purposes.


Issuing CA - CPS



1.5 Policy administration

1.5.1 Organization administering the document

The Atos TrustedRoot CA is responsible to maintain this policy document.

1.5.2 Contact person

Please use the following contact, if there are questions and/or comments to this policy document:

Postal Address: Atos Information Technology GmbH Atos Trustcenter Lohberg 10 49716 Meppen Germany

Web URL: https://pki.atos.net/trustcenter/en

E-Mail address [email protected]

To report problems, service outages, private key compromise, potential certificate misuse, or other types of fraud or inappropriate conduct, or any other matter related to certificates the Trustcenter can be contacted 24x7 via contact formula on the Atos Trustcenter web page (https://pki.atos.net/trustcenter/en/contact/trustcenter). Choose “Report problem” under the field “Topic”. In the field “Message” a detailed description of the problem should be provided. At least the common name, certificate serial number and issuer of a certificate should be given.

This document will be published according to section 2.2 after formal approval.

1.5.3 Person determining CPS suitability for the policy

The policy requirements and the guidelines for practice statements are reviewed and approved by the Atos TrustedRoot CA. The TrustedRoot CA Service Manager is responsible for the review and the approval of this document.

1.5.4 CPS approval procedures

As outlined in section 1.1 the Atos TrustedRoot CA services covered by this document follow the appropriate ETSI standards. The document on hand is the certification policy statement (CPS) describing the practices and procedures.

The conformance of the present policy with the ETSI requirements is documented in every section of this document.

The obligations of all external organizations supporting the Atos TrustedRoot CA services including the applicable policies and practices are identified in section 9.6.

This CPS is made available to subscribers and relying parties together with other relevant documentation according to section 2.2.

Other relevant documents are

(1) General Terms and Conditions for Services of Atos SE,

(2) Privacy Declaration of Atos SE and

(3) Atos (TrustedRoot) Subscriber Agreement.

mailto:[email protected]


Issuing CA - CPS



Intended changes of the CPS are announced and the revised document is published after the appropriate approval is made. The Atos TrustedRoot CA has a high-level management body with final authority and responsibility for approving the certification practice statement. The approval process is repeated with every further change of the CPS.

The TrustedRoot CA Service Manager is responsible for ensuring that the certification practices established to meet the applicable requirements specified in the present document are properly implemented.

The Atos TrustedRoot CA defines a review process for certification practices including responsibilities for maintaining the certification practice statement.

1.6 Definitions and acronyms

Terms, abbreviations and references are defined in section 10.


Issuing CA - CPS



2 PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

The Atos TrustedRoot CA publishes issued end entity certificates and the appropriate CRLs in repositories. The repository maintains a LDAP/HTTP directory service and an OCSP Responder service.

2.1.1 Directory service

The Atos TrustedRoot CA publishes end entity certificates and CRLs to the directory:

• [Client-CA]

Client certificates during its validity period if the subscriber has explicitly confirmed his agreement for certificate publication,

• [CodeSign-CA]

Codesign certificates if the subscriber has explicitly confirmed his agreement for certificate publication,

• [Server-CA]

Server certificates during its validity period if the subscriber has explicitly confirmed his agreement for certificate publication,

• [TimeStamp-CA]

Timestamp certificates during its validity period if the subscriber has explicitly confirmed his agreement for certificate publication,

• CRLs issued by Atos TrustedRoot CA services (Root CA and Issuing CA).

End entity certificates are published (if confirmed by the subscriber) to the LDAP directory service. Certificates are available for retrieval only in those cases for which the subject's consent has been obtained.

CRLs are published to the HTTP and to the LDAP directory services. The published CRLs can be downloaded from the repository via HTTP or LDAP from the internet. The URLs for downloading of the CRL are included in the extension "CRL Distribution Point (CDP)" of the issued certificates.

The directory services are publicly available 24 hours per day, 7 days per week. Upon system failure, service or other factors which are not under the control of Atos TrustedRoot CA, the Atos TrustedRoot CA applies best endeavours to ensure that this service is not unavailable for longer than 1 working day.

2.1.2 OCSP responder service

The status of issued end entity certificates can be requested from the Atos TrustedRoot OCSP responder service. There is one common OCSP responder service for all Atos TrustedRoot CA services. Each Atos TrustedRoot CA service issues its own OCSP certificate for signing of OCSP responses. If the certificate status is requested of a certificate issued by a certain issuer, then the OCSP response will be signed with a private key which belongs to an OCSP certificate signed by the same issuer (Authorized OCSP according to RFC 6960 [3]).

The OCSP response can include the following certificate status: "Good", "Revoked" or "Unknown". The appropriate URL of the OCSP responder service is included in the extension "Authority Information Access (AIA)" of the issued certificates.


Issuing CA - CPS



In case of errors, the OCSP responder returns an error message. The response "unauthorized" is returned in cases where the server is not capable of responding authoritatively (certificate issuer is unknown).

The OCSP responder service is publicly available 24 hours per day, 7 days per week. Upon system failure or other factors, which are not under the control of Atos TrustedRoot CA, the Atos TrustedRoot CA applies best endeavors to ensure that this service is available as soon as possible.

2.2 Publication of certification information

The Atos TrustedRoot CA publishes the relevant documentation on its publicly available web site. The documentation includes:

(1) General Terms and Conditions for Services of Atos SE,

(2) Privacy Declaration of Atos SE,

(3) Atos Subscriber Agreement and

(4) This CPS document.

The CPS document includes the relevant clauses for the certificate policy (CP). There is no extra document available including the CP requirements. The web site of Atos TrustedRoot CA is publicly available 24 hours per day, 7 days per week.

2.2.1 Test sites

[Server-CA]

Special web sites are operated by Atos TrustedRoot CA for testing purposes. Developers can test already prepared web sites with valid, revoked and expired TLS server certificates.

For this purpose, the following test web sites are available:

• https://pki-expired.atos.net

• https://pki-revoked.atos.net

• https://pki-valid.atos.net

https://pki-expired.atos.net/

https://pki-revoked.atos.net/

https://pki-valid.atos.net/


Issuing CA - CPS



2.3 Time or frequency of publication

The time and frequency of the publication depends on the type of information. The next table gives an overview about the relevant information:

Table 1: Published Information

Information Frequency of issuance Time of publication

Target of publication

Atos TrustedRoot EE Certificates

On request by the subscriber

After download and confirmation by the subscriber

• LDAP directory

Atos TrustedRoot Root CA CRL

At least every 12 months

After generation of the CRL

• HTTP directory

• LDAP directory

Atos TrustedRoot Issuing CA CRL

At least every 24 hours After generation of the CRL

• HTTP directory

• LDAP directory

General Terms and Conditions for Services of Atos SE

Update if required After document approval by Atos

• Atos TC web site

Privacy Declaration of Atos SE

Update if required After document approval by Atos


Atos Subscriber Agreement

Update if required After document approval by TrustedRoot CA Service Manager


Document CPS Update if required or at least every 12 months

After document approval by TrustedRoot CA Service Manager



Issuing CA - CPS



2.4 Access controls on repositories

The access to the repositories is limited by appropriate access controls. The next table gives an overview about the access controls in place:

Table 2: Access Controls for the Repositories

Publication system Access for Access by Access control

Web site of Atos TrustedRoot CA

Create Change Delete

Web-Admin User Authentication

Read Unrestricted Anonymous

HTTP Directory Service Create Change Delete

Certificate Management System

User Authentication


LDAP Directory Service Create Change Delete


User Authentication


OCSP Responder Service Create Change Delete


User Authentication

OCSP request Unrestricted Anonymous


Issuing CA - CPS



3 IDENTICATION AND AUTHENTICATION

This chapter describes identification and authentication of the subscriber.

3.1 Naming

3.1.1 Type of names

The end entity certificates issued by Atos TrustedRoot CAs include the following attributes in subject name and/or subject alternative name.

Table 3: Name attributes for EE certificates

Abbreviation Mandatory/Optional Subject Name Components

CN Mandatory Common Name

SerialNumber Optional Unique number identifying the subscriber

UID Optional Unique identifier identifying the subscriber

E Optional E-mail address of the subscriber

SN Optional Surname of the subscriber

G Optional Given name of the subscriber

OU Optional Organizational unit

O Optional Organization

L Optional Locality

C Optional Country

DNS Optional Fully qualified domain name of a server

Rfc822Name Optional E-mail address of the subscriber

UPN Optional User principal name of the subscriber

The next tables give an overview about the used names for Atos TrustedRoot end entity certificates.

Table 4: [Client-CA] Names for EE certificates

Purpose Subject Name Components

Client Authentication (Smart Card) CN Name of subscriber or functional mailbox SerialNumber subject identifier UID subject identifier E subscriber e-mail address G subscriber given name SN subscriber surname OU organizational unit O organization according CATS L locality according CATS C country according CATS

Client Encryption (Smart Card)

Client Authentication & Encryption (SoftPSE)


Issuing CA - CPS



Table 5: [CodeSign-CA] Names for EE certificates


Code Signing CN Code signing entity OU organizational unit O organization according CATS L locality according CATS C country according CATS

Table 6: [Server-CA] Names for EE certificates


TLS Client/Server CN Server name OU organizational unit O organization according CATS L locality according CATS ST state according CATS C country according CATS DNS FQDN of the server (1 or more records)

Table 7: [TimeStamp-CA] Names for EE certificates


Time Stamping CN FQDN of the time stamp server OU Trustcenter O Atos L Meppen C DE

3.1.2 Need for names to be meaningful

The attribute "Common Name" gives each end entity certificate a meaningful and user-friendly name.

3.1.3 Anonymity or pseudonymity of subscribers

[Client-CA]

The Atos TrustedRoot client certificates on smart card are issued to natural persons. The certificates do not include pseudonyms or other attributes for anonymization.

The Atos TrustedRoot client certificates on SoftPSE are issued to legal persons. The certificates do not include pseudonyms or other attributes for anonymization.

[CodeSign-CA]

The Atos TrustedRoot codesign certificates are issued to natural persons. The certificates do not include pseudonyms or other attributes for anonymization.

[Server-CA]

The Atos TrustedRoot server certificates are issued to legal persons. The certificates do not include pseudonyms or other attributes for anonymization.


Issuing CA - CPS



[TimeStamp-CA]

The Atos TrustedRoot timestamp certificates are issued to legal persons. The certificates do not include pseudonyms or other attributes for anonymization.

3.1.4 Rules for interpreting various name forms

Not relevant.

3.1.5 Uniqueness of names

The SubjectDN names are unique. The SubjectDN is clearly assigned to a specific entity.

3.1.6 Recognition, authentication, and the role of trademarks

No stipulation.

3.2 Initial identity validation

3.2.1 Method to prove possession of private key

[Client-CA]

The private keys for client authentication certificates are generated by the subscriber. The proof of possession of the private keys is explicitly checked by the certificate management system (CMS). The CMS gets the certificate signing requests in form of PKCS#10 request files, which are signed with the appropriate private key. The CMS checks the signature of the PKCS#10 request.

The private keys for client encryption or SoftPSE certificates are generated by the certificate management system (CMS). The proof of possession of the private keys is implicitly checked by the CMS.

[CodeSign-CA]

The private keys for code signing certificates are generated by the subscriber. The proof of possession of the private keys is explicitly checked by the certificate management system (CMS). The CMS gets the certificate signing requests in form of PKCS#10 request files, which are signed with the appropriate private key. The CMS checks the signature of the PKCS#10 request.

[Server-CA]

The private keys for server certificates are generated by the subscriber. The proof of possession of the private keys is explicitly checked by the certificate management system (CMS). The CMS gets the certificate signing requests in form of PKCS#10 request files, which are signed with the appropriate private key. The CMS checks the signature of the PKCS#10 request.

[TimeStamp-CA]

The private keys for time stamping are generated by the certificate management system (CMS). The proof of possession of the private keys is implicitly checked by the CMS.


Issuing CA - CPS



3.2.2 Authentication of organization identity

Atos TrustedRoot CA records all information necessary to verify the organization’s identity and, if applicable, any specific attributes including any reference number on the documentation used for verification and any limitations on its validity.


The organization(s) for end entity certificates are defined in the CATS between Atos TrustedRoot CA and the customer. Atos TrustedRoot CA checks the existence of the organization of the contracting party against an excerpt from the commercial register (certificate of registration, in Germany: Handelsregisterauszug).

The registered organizations will be implemented in a customer specific whitelist. The RA portal will not accept any organization names in certificate requests of the customer, which are not included in the customer specific whitelist.

[Client-CA], [Server-CA]

The customer DNS or e-mail domain for client certificates are defined in the CATS between Atos TrustedRoot CA and the customer. Atos TrustedRoot CA checks the registration of this domain against publicly WHOIS-services as part of each certificate issuance process.

If the domain was not validated within the last 825 days (after 01.09.2020: last 398 days) or if the last WHOIS-request got changed registration data compared with the WHOIS-request before, then the domain will be validated with one of the following methods according to CABF baseline requirements [7]:

(1) Confirming the applicants control over the domain is checked by confirming the presence of a random value (unique and valid for authorization for 30 days) in the DNS TXT record of the DNS domain; or

(2) Confirm the applicants control over the domain by sending an e-mail to one e-mail address created by using 'admin', 'administrator', 'webmaster', 'hostmaster' or 'postmaster' as the local part, followed by the @-sign, followed by the domain. The e-mail includes a random value and a link for response.

The registered domain(s) will be implemented in a customer specific whitelist. The RA portal will not accept any domain in certificate requests of the customer, which is not included in the customer specific whitelist.

[Server-CA]

Atos TrustedRoot CA will check the Certificate Authority Authorization (CAA) records for certificate application. The check will be done for each FQDN and wildcard domain names specified in the request, according to the procedure in RFC 8659 [4]. Atos TrustedRoot CA will use the CAA record “atos.net“ as permission for issuing certificates.

[TimeStamp-CA]

The organization of Atos TrustedRoot time stamping certificates is always "Atos", the organization Atos TrustedRoot CA belongs to. It is not allowed to issue Atos TrustedRoot time stamping certificates to another organization.


Issuing CA - CPS



3.2.3 Authentication of individual identity

Atos TrustedRoot CA records all information necessary to verify the individual’s identity and, if applicable, any specific attributes including any reference number on the documentation used for verification and any limitations on its validity.

[Client-CA]

The data of persons (individuals) are delivered by customer specific databases (e.g. Active Directory). The data source for personnel data is defined in the CATS between Atos TrustedRoot CA and the customer. The customer has the obligation to deliver validated personnel data.

In addition, the e-mail address of the applicant (if provided) will be checked:

The subscriber has to logon to the RA portal as part of the certificate acceptance procedure. Before starting the issuance process, an e-mail will be sent to the subscriber’s e-mail address, which will be included in the certificate. This e-mail contains a second factor which must be entered into the RA portal by the subscriber. This process ensures that the subscriber has the control over the provided e-mail address.

[CodeSign-CA], [Server-CA], [TimeStamp-CA]

Not relevant.

3.2.4 Non-verified subscriber information

Not relevant.

3.2.5 Validation of authority


The CATS between Atos TrustedRoot CA and the customer defines amongst others:

(1) The names of customer representatives(s) for administrative purposes (customer administrator) and

(2) How employees of the customer shall be authorized to RA portal (e.g. group membership).

Afterwards, the employees of the customer have the following ways to get authorized access to the RA portal:

(a) Logon to the RA portal via the pre-defined administrator account(s). The customer has the obligation that only the named administrators can logon with these accounts.

(b) Logon to the RA portal by customer employees, who get the authorization for RA portal by the membership in the pre-defined group (e.g. in Active Directory).

[TimeStamp-CA]

The subscriber for time stamping certificates gets the authorization through the role description of the Atos TrustedRoot CA. The subscriber is personally known to Atos TrustedRoot CA staff.

3.2.6 Criteria for interoperation

No stipulation.


Issuing CA - CPS



3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

The identity validation for renewal of end entity certificates will be processed in the same way like for initial certificate issuance. (see section 4.7)

3.3.2 Identification and authentication for re-key after revocation

The identity validation for renewal of end entity certificates will be processed in the same way like for initial certificate issuance. (see section 4.7)

3.4 Identification and authentication for revocation request

The Atos TrustedRoot CA performs the following checks for identification and authentication of certificate revocation requests:

• Revocation request is digitally signed;

• Revocation request is authorized with the revocation passphrase, which was agreed in CATS;

• Requester appears in person and can be identified as the subject belonging to the certificate which shall be revoked. The identification follows the requirements as described for the initial identity validation for natural persons;

• Requester is a member of the Atos TrustedRoot CA and is informed about the circumstances which are specified in section 4.9.1

• The customer administrators according to CATS have the authorization to revoke the end entity certificates of the organization they are working for.

• In addition, if defined in CATS the customer delivers daily a list of closed user accounts. The RA portal uses these lists for certificate revocation of the closed user accounts.


Issuing CA - CPS



4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certificate application

4.1.1 Who can submit a certificate application?


The authorized persons for certificate application are defined in the Customer Agreement for Trustcenter Services (CATS).

[Client-CA]

The authorized person logon to the RA portal with customer domain accounts. They get their right for certificate application through membership in the appropriate Trustcenter group.

[CodeSign-CA], [Server-CA]

The authorized person can logon to the RA portal on two ways. In CATS is defined, which way is applicable for a designated customer:

(1) Logon with customer domain accounts. The persons get their right for certificate application through membership in the appropriate Trustcenter group.

(2) Logon with RA portal user accounts. The accounts are defined in CATS.

[TimeStamp-CA]

Certificates for time stamping are requested by Atos Trustcenter administrators. These persons have personal accounts on the Trustcenter certificate management system.

4.1.2 Enrollment process and responsibilities

Before entering into a contractual relationship with a subscriber, the Atos TrustedRoot CA informs the subscriber about the policy for certificate issuance, usage and management. The related documents “Subscriber Agreement” and this CPS can be downloaded in the certificate application process from Atos RA portal. The subscriber has to agree that he has read and understood the policy before he can request a certificate.

The subscriber's obligations are defined in section 9.6 of this CPS document.

The provisions for data privacy are defined in section 9.4.

[Client-CA]

Each employee of the customer is responsible to request his own certificates.


In CATS is defined, who can request certificates from Atos RA portal.

[TimeStamp-CA]

Atos Trustcenter administrators are responsible for certificate requests of time stamping services.


Issuing CA - CPS



4.1.2.1 Key generation

[Client-CA]

The keys for authentication purposes are generated by the applicant (customer). The provisions in section 6.1 shall be considered.

The keys for encryption purposes are generated by the Atos Trustcenter in a controlled and secured environment.


The keys for code signing and server certificates are generated by the applicant (customer). The provisions in section 6.1 shall be considered.

[TimeStamp-CA]

The keys for time stamping services are generated by the Atos Trustcenter in a controlled and secured environment.

4.1.2.2 Certificate application

[Client-CA]

The application process is controlled by the RA portal. Authentication certificates are requested via PKCS#10 request.

Encryption certificates are requested via PKCS#12 requests.

The requests are generated by the RA portal.


The applicant generates the key and the certificate signing request (CSR) in advance of the certificate request process.

The resulting CSR will be inserted into the RA portal forms via copy & paste.

[TimeStamp-CA]

Time stamping certificates are requested via PKCS#10 requests.

The request is generated by the Trustcenter management system.

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

[Client-CA], [Server-CA], [CodeSign-CA]

The applicant will be identified and authenticated in the Atos RA portal.

[TimeStamp-CA]

The applicant will be identified and authenticated in the Atos TrustedRoot CA certificate management system.

4.2.2 Approval or rejection of certificate applications

[Client-CA], [CodeSign-CA]

The attribute organisation will be checked via whitelist. The acceptable value(s) are defined in CATS.

The attribute e-mail address will be checked via whitelist. The acceptable mail domains are defined in CATS.


Issuing CA - CPS



[Server-CA]

The attribute(s) FQDN will be checked via whitelist. The acceptable DNS domains are defined in CATS. In addition, there is a DNS domain validation to check, if the customer can manage the appropriate DNS domain (see section 3.2.2).

The attribute organization will be checked via whitelist. The acceptable value(s) are defined in CATS.

[TimeStamp-CA]

The attributes organisation and country are fix and cannot be changed by the applicant.

If the automatic checks are not fulfilled, then the applicant has two possibilities:

(1) The Atos TA portal offers values for substitution according to CATS. The applicant can agree for substitution and afterwards continue the process.

(2) The applicant can break the certificate request process.

4.2.3 Time to process certificate applications

[Client-CA], [CodeSign-CA], [TimeStamp-CA]

Certificates are issued automatically. There is no waiting time between certificate application and certificate issuance.

[Server-CA]

Certificates have to be DNS domain validated. The methods for domain validation lead to a waiting time up to a maximum of 2 weeks. If the domain validation could not be completed within 2 weeks the certificate request will be rejected.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

The certificates are issued automatically if the prerequisites are fulfilled. The Atos TrustedRoot CA will not issue certificates whose lifetime exceeds the lifetime of the signing CA certificate.

4.3.2 Notification to subscriber by the CA of issuance of certificate


The applicant will be informed about certificate issuance via e-mail.

[TimeStamp-CA]

Not relevant.


Issuing CA - CPS



4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

[Client-CA]

If the applicant has requested an encryption certificate with central key generation then the PKCS#12 token will be automatically downloaded and written on the applicant's smart card. In addition, the PKCS#12 token can be downloaded from the Atos RA Portal. In this case the token password is sent to the applicant via encrypted e-mail.

If the applicant has requested an authentication certificate with de-central key generation then the certificate will be automatically downloaded and written on the applicant's smart card.

If the applicant has request a SoftPSE with central key generation then the issued PKCS#12 token can be downloaded from the Atos RA Portal. The token password is sent to the applicant via e-mail. Transport channels for delivery of PKCS#12 token and the password are separated.

[Server-CA], [CodeSign-CA]

Certificates can be downloaded by the applicant from the Atos RA Portal.

[TimeStamp-CA]

Certificates can be downloaded directly after issuance in the certificate management system.

4.4.2 Publication of the certificate by the CA

[Client-CA]

Client certificates are published to customer directory if publication is defined in CATS.

[Server-CA]

Pre-certificates are published for transparency purposes to appropriate CT log server. The pre-certificates can be reviewed and downloaded via web site https://crt.sh/ .

[TimeStamp-CA], [CodeSign-CA]

Certificates are not published.

4.4.3 Notification of certificate issuance by the CA to other entities

No stipulation.

https://crt.sh/


Issuing CA - CPS



4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

The end entity keys and certificates issued by Atos TrustedRoot Issuing CA services may be used according to the purpose they are issued for (see also section 1.4):

[Client-CA]

Authentication keys/certificates on smart card for client authentication in applications,

Encryption keys/certificates on smart card for data and/or key encryption/decryption,

SoftPSE keys/certificates for authentication/verify and encrypt/decrypt of data and e-mails,

[CodeSign-CA]

Codesign keys/certificates for signature/verify application (e.g. VB scripts, Java code, etc.),

[Server-CA]

TLS client/server keys/certificates for TLS client and server authentication and transport channel encryption,

[TimeStamp-CA]

Timestamp keys/certificates for signature/verify of timestamps.

4.5.2 Relying party public key and certificate usage

Relying parties can use the public keys and the certificates for checking of certificate reliability. Relying parties shall verify that the used end-entity certificate has a CA certificate chain which ends at a trusted Root CA certificate and that every certificate in the chain is neither expired nor revoked.

4.6 Certificate renewal

4.6.1 Circumstance for certificate renewal


Certificate renewal with a key, which is already in use, is not supported.

[Server-CA]

Certificate renewal with a key, which is already in use, is supported if the cryptographic security of subject's previously certified public key is still sufficient for the new certificate's validity period and no indications exist that the subject's private key has been compromised nor that the certificate has been revoked due to any other reason.

4.6.2 Who may request renewal


Not relevant.

[Server-CA]

The provisions made in section 4.1 shall apply.


Issuing CA - CPS



4.6.3 Processing certificate renewal requests


Not relevant.

[Server-CA]


4.6.4 Notification of new certificate issuance to subscriber


Not relevant.

[Server-CA]


4.6.5 Conduct constituting acceptance of a renewal certificate


Not relevant.

[Server-CA]


4.6.6 Publication of the renewal certificate by the CA

The provisions made in section 4.4.2 shall apply.


No stipulation.

4.7 Certificate re-key

4.7.1 Circumstance for certificate re-key

Certificate renewal with a new key is allowed for any end entity certificate issued by Atos TrustedRoot CA.

4.7.2 Who may request certification of a new public key?


4.7.3 Processing certificate re-keying requests




4.7.5 Conduct constituting acceptance of a re-keyed certificate


4.7.6 Publication of the re-keyed certificate by the CA



Issuing CA - CPS




No stipulation.

4.8 Certificate modification

Certificate modification without re-keying is not supported. If any information given in the certificate is no longer valid then a new certificate with re-keying shall be issued. The provisions in section 4.1 shall apply.

4.8.1 Circumstance for certificate modification

No stipulation.

4.8.2 Who may request certificate modification?

No stipulation.

4.8.3 Processing certificate modification requests

No stipulation.


No stipulation.

4.8.5 Conduct constituting acceptance of modified certificate

No stipulation.

4.8.6 Publication of the modified certificate by the CA

No stipulation.

4.8.7 Notification of certificate issuance by the CA to other

No stipulation.


Issuing CA - CPS



4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation

Reasons for revocation of end entity certificates are:

a) The subscriber requests revocation in written form;

b) The subscriber notifies the Atos TrustedRoot CA that the original certificate request was not authorized;

c) The Atos TrustedRoot CA obtains evidence that the private key was compromised;

d) The Atos TrustedRoot CA obtains evidence that the validation of domain authorization or control for any FQDN or IP address in the certificate cannot be relied;

e) The issued certificate no longer complies with the requirements of section 6.1;

f) The Atos TrustedRoot CA obtains evidence that the certificate was misused;

g) The Atos TrustedRoot CA is made aware that a subscriber has violated one or more of its material obligations under the subscriber agreement or terms of use;

h) The Atos TrustedRoot CA is made aware of any circumstance indicating that use of a FQDN or IP address in the certificate is no longer legally permitted;

i) The Atos TrustedRoot CA is made aware that a wildcard certificate has been used to authenticate a fraudulently misleading subordinate FQDN;

j) The Atos TrustedRoot CA is made aware of a material change in the information contained in the certificate;

k) The Atos TrustedRoot CA is made aware that the certificate was not issued in accordance with the CA's CP/CPS;

l) The Atos TrustedRoot CA determines or is made aware that any of the information appearing in the certificate is inaccurate;

m) The Atos TrustedRoot CA's right to issue certificates under this CP/CPS expires or is revoked or terminated, unless the CA has planned to continue maintaining the CRL/OCSP repository;

n) Revocation is required by the CA's CP/CPS;

o) The Atos TrustedRoot CA is made aware of a demonstrated or proven method that exposes the subscriber's private key to compromise, methods have been developed that can easily calculate it based on the public key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the private key was flawed.

4.9.2 Who can request revocation

The following person are authorized to request a certificate revocation of Atos TrustedRoot end entity certificates:

• The subscriber can request the revocation of the certificates he is responsible for.

• In CATS is one or more responsible person for certificate revocation of the contracting party defined. These persons (customer administrator) can request the revocation of all certificates issued to this contracting party.

• TrustedRoot CA Service Manager as the subscriber of Atos TrustedRoot CA system certificates can request the revocation of one or more if a reason according section 4.9.1 is existent.


Issuing CA - CPS



4.9.3 Procedure for revocation request

There are three procedures for certificate revocation dependent who requests:

a) The subscriber uses the Atos RA Portal for certificate revocation requests. If the subscriber is authenticated and has requested the certificate revocation, then this process will be performed automatically by the Atos TrustedRoot CA.

b) The customer administrators send certificate revocation requests via digitally signed e-mail to the Atos TrustedRoot CA. The Trustcenter administrators check the origin and the authorization of the received revocation request. The Request shall at least contain:

• Which certificates shall be revoked?

• Why is the certificate revocation necessary?

c) The TrustedRoot CA Service Manager has the authorization to request the revocation of Atos TrustedRoot CA end entity certificates. The formal revocation request shall be handed over in written form. The Request shall at least contain:

• Which certificates shall be revoked?

• Why is the certificate revocation necessary?

The case of b) and c) the certificate revocation process will be performed by person of the Atos TrustedRoot CA:

• TrustedRoot CA Service Manager informs the customer administrator about the planned certificate revocation;

• Atos TrustedRoot System administrators revoke the certificates.

Afterwards, the subscriber will be informed if his/her certificate is revoked.

A revoked certificate will never be reinstated.

4.9.4 Revocation request grace period

No stipulation.

4.9.5 Time within which CA must process the revocation request

Atos TrustedRoot CA shall revoke an end entity certificates within 24 hours if one of the reasons in section 4.9.1 a) to d) is true.

If one of the remaining reasons in section 4.9.1 e) to o) is true, then the Atos TrustedRoot CA shall review the facts and circumstances. Atos TrustedRoot CA shall work together with the subscriber and the entity, who has reported the problem report.

Atos TrustedRoot CA has to decide if and when the impacted end entity certificates have to revoked. The certificate subscribers have to be informed in a proper way about the decision.

If the decision for certificate revocation was made, then Atos TrustedRoot CA should revoke an end entity certificates within 24 hours and shall revoke an end entity certificate within 5 days. This time period starts with the planned day for certificate revocation.

The certificate revocation information shall be promptly published after processing.

4.9.6 Revocation checking requirement for relying parties

Relying parties, who rely on Atos TrustedRoot CA certificates, have the obligation to validate the certificate status. The validation can be done using the OCSP responder service or via CRL examination.


Issuing CA - CPS



4.9.7 CRL issuance frequency (if applicable)

Provisions are defined in section 2.3.

4.9.8 Maximum latency for CRLs (if applicable)

The CRL of Atos TrustedRoot Issuing CAs shall be rebuild and published on a regular base every day. The maximum delay between certificate revocation and publication in the CRL is 24 hours.

4.9.9 On-line revocation/status checking availability

The OCSP responder service is publicly available 24 hours per day, 7 days per week and the OCSP responses are conform to RFC6960 [3] and/or RFC5019. OCSP responses are either:

1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or

2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked.

In the latter case, the OCSP signing Certificate contains an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960.

4.9.10 On-line revocation checking requirements

OCSP status requests shall be compliant with RFC 6960 [3]. OCSP status responses are digitally signed by the OCSP responder service. The URL of the OCSP responder service is included in the issued end entity certificates (see section 7.1).

If the OCSP responder receives a request for the status of a certificate serial number that is "unused", then the responder will not respond with a "good" status. (see section 2.1.2)

4.9.11 Other forms of revocation advertisements available

Certificate revocation information of Atos TrustedRoot Issuing CAs is published on Atos Trustcenter web site. The web site is publicly available and the issued CRL can be downloaded by relying parties.

4.9.12 Special requirements re key compromise

If a private key is compromised, then this key shall not be used any more. The issuance of a new certificate with re-keying shall be started as soon as possible according to section 4.7. Atos Trustcenter shall inform the concerned certificate holder.

4.9.13 Circumstances for suspension

Suspension of Atos TrustedRoot end entity certificates is not allowed.

4.9.14 Who can request suspension

Not relevant.

4.9.15 Procedure for suspension request

Not relevant.

4.9.16 Limits on suspension period

Not relevant.


Issuing CA - CPS



4.10 Certificate status services

4.10.1 Operational characteristics

The Atos Trustcenter provides certificate revocation information in form of CRLs and OCSP responses. The HTTP directory and the OCSP responder services mentioned in section 2.1 are used for this purpose.

The integrity and authenticity of the certificate status information is protected: CRLs and OCSP-responses are electronically signed.

Revocation status information includes information on the status of certificates at least until the certificate expires.

4.10.2 Service availability

The HTTP directory and the OCSP responder services are publicly available 24 hours per day, 7 days per week.Upon system failure or other factors, which are not under the control of Atos TrustedRoot CA, the Atos TrustedRoot CA applies best endeavors to ensure that this service is available as soon as possible.

4.10.3 Optional features

No stipulation.

4.11 End of subscription

The basement for certificate issuance for a dedicated customer is a Customer Agreement for Trustcenter Services (CATS). The subscription ends when the contract is withdrawn either by the contracting party or by the Atos TrustedRoot CA.

4.12 Key escrow and recovery

The private keys of Atos TrustedRoot end entity encryption certificates are generated by the Atos TrustedRoot CA. Backups of these keys are used for key recovery processes requested by the subscriber or by the contracting party. If defined in CATS, then the keys for encryption certificates will be handed over to the contracting party.

4.12.1 Key escrow and recovery policy and practices

No stipulation.

4.12.2 Session key encapsulation and recovery policy and practices

No stipulation.


Issuing CA - CPS



5 FACILITY, MANGEMENT, AND OPERATIONAL CONTROLS

5.1 Physical controls

The provisions are defined in the document Certification Practice Statements of Atos TrustedRoot Root CA in section 5.1 [16].

5.1.1 Site location and construction

The provisions are defined in the document Certification Practice Statements of Atos TrustedRoot Root CA in section 5.1.1 [16].

5.1.2 Physical access


5.1.3 Power and air conditioning


5.1.4 Water exposures


5.1.5 Fire prevention and protection


5.1.6 Media storage


5.1.7 Waste disposal


5.1.8 Off-site backup


5.2 Procedural controls


5.2.1 Trusted roles



Issuing CA - CPS



5.2.2 Number of persons required per task


5.2.3 Identification and authentication for each role


5.2.4 Roles requiring separation of duties


5.3 Personnel controls


5.3.1 Qualifications, experience, and clearance requirements


5.3.2 Background check procedures


5.3.3 Training requirements


5.3.4 Retraining frequency and requirements


5.3.5 Job rotation frequency and sequence


5.3.6 Sanctions for unauthorized actions


5.3.7 Independent contractor requirements


5.3.8 Documentation supplied to personnel



Issuing CA - CPS



5.4 Audit logging procedure


5.4.1 Types of events recorded


5.4.2 Frequency of processing log


5.4.3 Retention period for audit log


5.4.4 Protection of audit log


5.4.5 Audit log backup procedures


5.4.6 Audit collection system (internal vs. external)


5.4.7 Notification to event-causing subject


5.4.8 Vulnerability assessments


5.5 Records archival


5.5.1 Types of records archived


5.5.2 Retention period for archive



Issuing CA - CPS



5.5.3 Protection of archive


5.5.4 Archive backup procedures


5.5.5 Requirements for timestamping of records


5.5.6 Archive collection system (internal or external)


5.5.7 Procedures to obtain and verify archive information


5.6 Key changeover


5.7 Compromise and disaster recovery


5.7.1 Incident and compromise handling procedures


5.7.2 Computing resources, software, and/or data are corrupted


5.7.3 Entity private key compromise procedures


5.7.4 Business continuity capabilities after a disaster


5.8 CA or RA termination



Issuing CA - CPS



6 TECHNICAL SECURITY CONTROLS

6.1 Key pair generation and installation

6.1.1 Key pair generation

The key generation process for end entity certificates depends from the kind of the certificate.

[Client-CA]

Keys for authentication certificates on smart card are generated by the subscriber on card.

Keys for encryption certificates on smart card are generated by Atos TrustedRoot CA.

Keys for certificates on SoftPSE are generated by Atos TrustedRoot CA.

[CodeSign-CA]

Keys for codesign certificates are generated by the subscriber.

[Server-CA]

Keys for server certificates are generated by the subscriber.

[TimeStamp-CA]

Keys for timestamp certificates are generated by the Atos Trustcenter in a controlled and secured environment..

If Atos TrustedRoot CA generates the keys, then the key generation procedure is logged and can be reviewed afterwards.

The Atos TrustedRoot CA will reject a certificate request if the requested Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or if it has a known weak Private Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys).

6.1.2 Private key delivery to subscriber

The delivery of private keys is only relevant for keys generated by Atos TrustedRoot CA.

[Client-CA]

Not relevant for private keys of authentication certificates on smart card.

Private keys of encryption certificates on smart card and private keys of SoftPSE can be downloaded by the subscriber from the RA portal. The delivery channel is encrypted with TLS.


Not relevant.

[TimeStamp-CA]

Not relevant. Private keys are generated in a secured environment.

6.1.3 Public key delivery to certificate issuer

The delivery of public keys is only relevant for keys generated by the subscriber.

[Client-CA]

Public keys for authentication certificates are delivered in form of PKCS#10 requests.


Issuing CA - CPS



Not relevant for public keys of encryption certificates on smart card and public keys of SoftPSE.

[CodeSign-CA]

Public keys for codesign certificates are delivered in form of PKCS#10 requests.

[Server-CA]

Public keys for server certificates are delivered in form of PKCS#10 requests.

[TimeStamp-CA]

Not relevant for public keys of timestamp certificates.

6.1.4 CA public key delivery to relying parties

The CA public keys are made available to relying parties as part of the appropriate CA certificates. The fingerprint of the certificates can be verified on the Atos TrustedRoot CA web site.

6.1.5 Key sizes

The key length is defined according to ETSI TS 119312 [13]. The key length for end entity certificates shall have the same key algorithm (RSA, ECC) like the key of the issuing CA and shall not be stronger than the key of the issuing CA.

Table 8: End entity Key Length

Key algorithm Key Length Usage until

RSA 1 2048 Bit

End of 2022

3072 ... 4096 Bit

2022 and longer

ECC 256 Bit (NIST P-256)

2022 and longer

6.1.6 Public key parameters generation and quality checking

End entity certificates are issued based on keys that comply with [13] in its latest applicable version. The applicable signature schemas are defined in section 7.1.

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

The keys of end entity certificates may be used according to the purpose they are issued for. Key usages are defined in section 7.1.2

[Client-CA]

Keys of authentication certificates on smart card for client signature/verify,

Keys of encryption certificates on smart card for encryption/decryption,

Keys of SoftPSE certificates for signature/verify and encrypt/decrypt,

[CodeSign-CA]

Keys of codesign certificates for signature/verify of code,

1 RSA key pairs are generated with public key OID rsaEncryption.


Issuing CA - CPS



[Server-CA]

Keys for server certificates for signature/verify and encryption/decryption of transport channel,

[TimeStamp-CA]

Keys of timestamp certificates for signature/verify of timestamps.

6.2 Private key protection and cryptographic module engineering controls

6.2.1 Cryptographic module standards and controls

[Client-CA]

Private keys of authentication certificates on smart card are generated, stored and used within the smart card.

Private keys of encryption certificates on smart card are stored and used within the smart card.

Atos TrustedRoot CA supports the CardOS smart card, which comply with cryptographic requirements [13] in its latest applicable version. The use of the smart card is contractually agreed in CATS.

Not applicable for private keys of SoftPSE.


Not applicable.

6.2.2 Private key (n out of m) multi-person control

Not applicable for end entity keys.

6.2.3 Private key escrow

[Client-CA]

Not supported for private keys of authentication certificates.

Private keys of encryption certificates will be handed over to customer representatives if this procedure is contractually agreed in CATS.


Not supported.

6.2.4 Private key backup

[Client-CA]


Private keys of encryption certificates will be backed up for recovery purposes. The backup will be encrypted using a strong symmetric key algorithm. The same level of protection is ensured as provided by the certificate management system.


Not supported.


Issuing CA - CPS



6.2.5 Private key archival

[Client-CA]


Private keys of encryption certificates will be archived for recovery purposes. The archive will be encrypted using a strong symmetric key algorithm. The same level of protection is ensured as provided by the certificate management system.

The private keys shall be archived for a period of 7 years after the end of the year of the expiration of the assigned certificate.


Not supported.

6.2.6 Private key transfer into or from a cryptographic module

[Client-CA]


Private keys of encryption certificates on smart card will be transferred from RA portal in a secure TLS channel directly to the smart card. This process is used for certificate application and for certificate recovery.

Not supported for private keys of encryption certificates on SoftPSE.


Not supported.

6.2.7 Private key storage on cryptographic module

[Client-CA]

Supported for private keys of authentication certificates on smart card.

Supported for private keys of encryption certificates on smart card.

Not supported for private keys of certificates on SoftPSE.


Not supported.

6.2.8 Method of activating private key

The activation of the private key is defined in CATS.

[Client-CA]

Th private keys of authentication and encryption certificates on smart card shall be protected by a PIN.

The private keys of certificates on SoftPSE shall be protected by a password.


The keys generated by the subscriber shall be protected with a password.

[TimeStamp-CA]

The private keys of certificates are stored permanently in the appropriate application systems


Issuing CA - CPS



6.2.9 Method of deactivating private key

The usage period of private keys is linked to the usage period of the assigned certificate. If a key shall be deactivated, then the assigned certificate must be revoked.

6.2.10 Method of destroying private key

Not applicable.

6.2.11 Cryptographic Module Rating

No stipulation.

6.3 Other aspects of key pair management

6.3.1 Public key archival

The generated public keys are stored and archived as part of the certificate (see section 6.2.5).

6.3.2 Certificate operational periods and key pair usage periods

The validity of the certificates depends on the certificate type and is shown in the certificate. The validity of the assign key pair shall have the same value as the validity of the certificate.

Table 9: EE key and certificate validity period

EE Certificate Certificate Validity Period

Client certificate Up to 3 years

Codesign certificate Up to 3 years

Server certificate Certificates issued until 30.08.2020: 1 or 2 years (max. 825 days)

Certificates issued starting 01.09.2020: 1 year (max. 398 days)

Timestamp certificate Up to 3 years

6.4 Activation data

The provisions made in section 6.2.8 shall apply.

6.4.1 Activation data generation and installation

No stipulation.

6.4.2 Activation data protection

No stipulation.

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

The provisions as defined in the document Certification Practice Statements of Atos TrustedRoot Root CA [16] I n section 6.5.1 shall apply for RA portal.


Issuing CA - CPS



6.5.2 Computer security rating

The provisions as defined in the document Certification Practice Statements of Atos TrustedRoot Root CA [16] in section 6.5.2 shall apply for RA portal.

6.5.3 Other aspects of computer security


6.6 Life cycle technical controls

6.6.1 System development controls


6.6.2 Security management controls


6.6.3 Life cycle security controls

No stipulation.

6.7 Network security controls

The provisions as defined in the document Certification Practice Statements of Atos TrustedRoot Root CA [16] in section 6.7 shall apply for RA portal.

6.8 Timestamping

The provisions as defined in the document Certification Practice Statements of Atos TrustedRoot Root CA [16] in section 6.8 shall apply for RA portal.


Issuing CA - CPS



7 CERTIFICATE, CRL, AND OCSP PROFILES

7.1 Certificate profile

Atos TrustedRoot CA issues certificates according to RFC 5280 [2].

7.1.1 Version number(s)

Atos TrustedRoot CA issues X.509 certificates version 3 according to RFC 5280 [2].

7.1.2 Certificate extensions

Atos TrustedRoot CA issues publicly trusted end entity certificates with extensions according to RFC 5280 [2]. The standard version 1 attributes are not mentioned here. The following version 3 extensions shall be used:

Table 10: Certificate extensions for end entity certificates

Extension Client Encr Certificate

Client Auth Certificate

Client SoftPSE Certificate

Server Certificate

Code Sign Certificate

Time Stamp Certificate

Authority Key Identifier

M M M M M M

Subject Key Identifier

O O O O O O

Certificate Policies

M M M M M M

Authority Info Access

M M M M M M

CRL Distribution Point

M M M M M M

Issuer Alternative Name

O O O O O O

Key Usage; critical

keyEncr

digitalSign keyEncr digitalSign

keyEncr digitalSign

digitalSign digitalSign

Extended Key Usage

secureEmail EFS

EFSrecovery

clientAuth secureEmail secureIKE

smartCardLogon

clientAuth secureEmail secureIKE

ClientAuth ServerAuth

CodeSign TimeStamp

Basic Constraints; critical

O Value, if set:

CA=false

O Value, if set:

CA=false

O Value, if set:

CA=false

O Value, if set:

CA=false

O Value, if

set: CA=false

O Value, if set:

CA=false

Remarks to notation:

M Mandatory extension O Optional extension -- Extension shall not be used


Issuing CA - CPS



7.1.3 Algorithm object identifier (OID)

Atos TrustedRoot CA issues end entity certificates with signature algorithm based on RSA or ECDSA. This depends from the type of the public key which shall be certified.

Table 11: Signature algorithm for end entity certificates

Key algorithm

Signature algorithm

Parameters and Remarks OID

RSA 2048 bit rsa-sha256 SHA-256 hash, PKCS#1 v1.5 Padding, RSA encryption

1.2.840.113549.1.1.11

RSA 4096 bit rsa-sha384 SHA-384 hash, PKCS#1 v1.5 Padding, RSA encryption

1.2.840.113549.1.1.12

ECC 256 bit ecdsa-with-SHA256 SHA-256 hash, ECDSA signature 1.2.840.10045.4.3.2

ECC 384 bit ecdsa-with-SHA384 SHA-384 hash, ECDSA signature 1.2.840.10045.4.3.3

7.1.4 Name forms

The allowed subject names components are defined in section 3.1. The extensions SubjectDN and SubjectAlternativeName (SAN) are built as follows:

Table 12: Certificate extensions for system certificates

Extension Client Encr Certificate

Client Auth Certificate

Client SoftPSE Certificate

Server Certificate

Code Sign Certificate

Time Stamp Certificate

SubjectDN CN serialNumber

UID E G

SN OU O L C

CN OU O ST L C

CN OU O L C

CN OU O L C

SAN Rfc822Name Rfc822Name UPN

Rfc822Name UPN

DNSName n.r. n.r.

Mandatory attributes are underlined.

The Atos TrustedRoot CA ensures that over the lifetime of a CA a subject distinguished name, which has been used in a certificate, is not re-assigned to another entity.

7.1.5 Name constraints

The allowed name attributes are defined in section 3.1.


Issuing CA - CPS



7.1.6 Certificate policy object identifier

Certificates issued under this policy include in the extension certificate policy. The extension certificate policies contain the appropriate Atos policy identifier which reflects the practices and procedures undertaken for management of the appropriate certificate.

Table 13: Certificate Policies for end entity certificates

EE Certificate CA Policy

Client Authentication & Encryption Certificates on Smart Card

Each certificate Atos TrustedRoot Client CA SC Policy

Client SoftPSE Certificates Atos TrustedRoot Client CA P12 Policy

CodeSign Certificates Atos TrustedRoot CodeSign CA Policy

Server Certificates Each certificate Atos TrustedRoot Server CA Policy

Additionally: If domain validated

joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)

Additionally: If organization and domain validated

joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) organization-validated(2)

Additionally: If subject:DN includes givenName and/or surname attribute(s)

joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) individual-validated(3)

TimeStamp Certificates Atos TrustedRoot TimeStamp CA Policy

7.1.7 Usage of policy constraints extension

The certificate extensions "Policy Mappings", "Policy Constraints" and "Inhibit Any Policy" shall not be used.

7.1.8 Policy qualifiers syntax and semantics

Atos TrustedRoot Ca issues system certificates with the following policy qualifier.

Table 14: Policy Qualifier for Atos TrustedRoot CA certificates

Attribute Explanation Value

Policy URL URL of Atos TrustedRoot CA https://pki.atos.net/Download


Issuing CA - CPS



7.1.9 Processing semantics for critical certificate policies extension

The certificate extension "Certificate Policies" shall net be set critical.

7.2 CRL profile

Atos TrustedRoot ensures that certificates are revoked in a timely manner based on authorized and validated certificate revocation requests. Requirements concerning the identification and authentication for revocation requests are described in section 3.4. Certificate Revocation Lists (CRLs) are published according to the provisions made in section 2.2.


Atos TrustedRoot CA generates certificate revocation lists version 2 according to RFC 5280 [2] for all operated CA services.

7.2.2 CRL and CRL entry extensions

Atos TrustedRoot CA generates certificate revocation lists (CRL) for all operated CA services. The CRLs shall include information about all revoked certificates if not expired.

The following extensions shall be used according to RFC 5280:

Table 15: CRL extensions

Extension Explanation

Authority Key Identifier Hash value of the public issuer key

CRL Number Number of the (final) certificate revocation list

7.3 OCSP profile


The OCSP responder service of Atos TrustedRoot CA issues OCSP responses version 1 according to RFC 6960 [3] for all issued certificates.

7.3.2 OCSP extensions

The OCSP responder services of Atos TrustedRoot CA is operated as "Authorized Responder" according to RFC 6960 [3].

7.3.3 Other provisions

OCSP responses are signed with a signature schema which uses SHA1.


Issuing CA - CPS



8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS

8.1 Frequency and circumstances of assessment


8.2 Identity/qualifications of assessor


8.3 Assessor's relationship to assessed entity


8.4 Topics covered by assessment


8.5 Actions taken as a result of deficiency


8.6 Communications of results



Issuing CA - CPS



9 OTHER BUSINESS AND LEGAL MATTERS

9.1 Fees


9.1.1 Certificate issuance or renewal fees


9.1.2 Certificate access fees


9.1.3 Revocation or status information access fees


9.1.4 Fees for other services


9.1.5 Refund policy


9.2 Financial responsibility


9.2.1 Insurance coverage


9.2.2 Other assets


9.2.3 Insurance or warranty coverage for end-entities


9.3 Confidentiality of business information



Issuing CA - CPS



9.3.1 Scope of confidential information


9.3.2 Information not within the scope of confidential information


9.3.3 Responsibility to protect confidential information


9.4 Privacy of personal information


9.4.1 Privacy plan


9.4.2 Information treated as private


9.4.3 Information not deemed private


9.4.4 Responsibility to protect private information


9.4.5 Notice and consent to use private information


9.4.6 Disclosure pursuant to judicial or administrative process


9.4.7 Other information disclosure circumstances


9.5 Intellectual property rights



Issuing CA - CPS



9.6 Representations and warranties

9.6.1 CA representations and warranties

The obligations of Atos TrustedRoot CA shall comply with the provision in the relevant ETSI and CABF norms [5], [6] and [7]. Atos TrustedRoot CA has the obligation to provide revocation information about issued certificates. The revocation information will be provided at least until the certificate is expired.

Atos TrustedRoot CA informs the CABF body and the Atos information security office about every security incident and every loss of integrity within 24 hours. If the incident can have an impact on the certificate holder, then these persons will be informed in suitable manner.

9.6.2 RA representations and warranties


The registration tasks are performed by customer staff. The obligations are defined in the Customer Agreement for Trustcenter Services (CATS).

[TimeStamp-CA]

The registration tasks for timestamp certificates are performed by Atos TrustedRoot CA staff. There is no additional organization for registration purposes.

9.6.3 Subscriber representations and warranties

The rights and obligations of subscriber shall comply with the provisions in the relevant ETSI and CABF norms [5], [6] and [7] as well as with the provisions in the administrative agreements between Atos TrustedRoot CA and them.

• The subscribers are obligated to make true declarations regarding their own person and the certificate content in the registration process.

• The subscriber notifies the Atos TrustedRoot CA (see section 1.5.2) without any reasonable delay, if any of the following incidents occur up to the end of the validity period of their certificate:

o the subscriber's private key has been lost, stolen, or potentially compromised;

o control over the subscriber's private key has been lost due to compromise of the activation data (e.g. PIN code) or other reasons;

o inaccuracy or changes of the certificate content.

• If the subscriber private key is potentially compromised, then the subscriber's private key must not be used any more.

9.6.4 Relying party representations and warranties

Relying parties, who rely on Atos TrustedRoot CA certificates, have the obligation to validate the certificates status. The validation of the certificate status can be done

• either via online certificate status validation using the appropriate OCSP responder service or

• via download of the CRL and offline status validation.

Invalid certificates shall not be used.

Relying parties shall consider the restrictions for the usage of the cryptographic keys. The restrictions are included in the certificate in the extensions "Key Usage" and if existing "Extended Key Usage" (see section 7.1).


Issuing CA - CPS



Relying parties shall consider the restrictions for the usage of the certificates. The restrictions are defined in section 1.4.

Relying parties shall inform Atos TrustedRoot CA in case of suspicion of or really detected misuse of issued certificates. The contact addresses defined in section 1.5.2 shall be used.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of warranties

See the General Terms and Conditions for Services of Atos Information Technology GmbH (see section 2.2).

9.8 Limitations of liability


9.9 Indemnities


9.10 Term and termination


9.10.1 Term


9.10.2 Termination


9.10.3 Effect of termination and survival


9.11 Individual notices and communications with participants

The Atos TrustedRoot CA accepts communication in written form or digitally signed e-mails. The Atos TrustedRoot CA will send a signed e-mail acknowledgement of receipt within 10 working days.

Written communication should be sent to the postal address given in section 1.5.2.

E-mails should be sent to the e-mail address given in section 1.5.2.

9.12 Amendments

9.12.1 Procedure for amendment

The CPS document can be changed by the Atos TrustedRoot CA. After the change, the new CPS document is identified by a new version number and release date.


Issuing CA - CPS



9.12.2 Notification mechanism and period

If there are relevant changes in the CPS document, then Atos TrustedRoot CA will inform the subscriber via the appropriate subscriber agreement. Only subscribers of newly issued certificates are concerned.

If there are changes which lead to revocation of Issuer certificates, then the concerned subscriber will be informed in a proper way. This case might happen if there is an evidence that a used cryptographic algorithm was broken.

The new CPS document in written form replaces all preceding CPS documents. Verbally announcements are not foreseen.

9.12.3 Circumstances under which OID must be changed

The document OID will be changed, if the scope of the CPS document regarding the trust services will be changed.

9.13 Dispute resolution provisions


9.14 Governing law


9.15 Compliance with applicable law


9.16 Miscellaneous provisions

Policies and procedures under which the Atos TrustedRoot CA operates are non-discriminatory.

The Atos TrustedRoot CA makes its services accessible to all applicants whose activities fall within its declared field of operation.

The Atos TrustedRoot CA has a properly documented agreement and contractual relationship in place where the provisioning of services involves subcontracting, outsourcing or other third parties’ arrangements.

The parts of the Atos TrustedRoot CA concerned with certificate generation and revocation management have a structure that safeguards impartiality of operations as documented in this CPS.

9.16.1 Entire agreement

No stipulation.

9.16.2 Assignment

No stipulation.

9.16.3 Severability

If any part of this agreement is declared unenforceable or invalid, the remainder will continue to be valid and enforceable.


Issuing CA - CPS



9.16.4 Enforcement (attorneys' fees and waiver of rights)

The place of jurisdiction is regulated in the law.

9.16.5 Force majeure

No stipulation.

9.17 Other provisions

No stipulation.


Issuing CA - CPS



10 Abbreviations and terms

10.1 Abbreviations

BDSG Privacy Law of Federal Republic of Germany (Bundesdatenschutzgesetz)

C Country

CA Certificate Authority

CAB Conformity Assessment Body

CABF CA/Browser Forum

CAR Conformity Assessment Report

CATS Customer Agreement for Trustcenter Services

CC Common Criteria (ISO/IEC 15408)

CCADB Common CA Database

CERTSN Certificate Serial Number

CMS Certificate Management System

CN Common Name

CP Certificate Policy

CPS Certification Practice Statements

CRL Certificate Revocation List

CSP Certification Service Provider

DN Distinguished Name

DNS Domain Name Service

DSGVO Datenschutzgrundverordnung (GDPR)

DVCP Domain Validation Certificate Policy

EAL Evaluation Assurance Level

EE End Entity

EN European Norm

ETSI European Telecommunications Standard Institute

EU European Union

FQDN Fully Qualified Domain Name

GDPR General Data Protection Regulation

HSM Hardware Security Module

HTTP Hyper Text Transfer Protocol

HW Hardware

ID Identification

IDN Internationalized Domain Name

IETF Internet Engineering Task Force

IT Information Technology


Issuing CA - CPS



ITSEC Information Technology Security Evaluation Criteria

LAN Local Area Network

LCP Lightweight Certificate Policy

LDAP Lightweight Directory Access Protocol

NCP Normalized Certificate Policy

NCP+ Extended Normalized Certificate Policy

Nonce Number used once

NTP Network Time Protocol

O Organization

OCSP Online Certificate Status Protocol

OID Object Identifier

OU Organizational Unit

OVCP Organizational Validation Certificate Policy

PC Personal Computer

PDS PKI Disclosure Statement

PEN Private Enterprise Number

PIN Personal Identification Number

PKCS Public Key Cryptography Standards

PKI Public Key Infrastructure

PN Pseudonym

PSE Personal Security Environment

PTB Physical Technical Federal Agency Braunschweig (Physikalisch-technische Bundesanstalt Braunschweig)

PUK Personal Unblocking Key

RA Registration Authority

RFC Request for Comments - Internet Standards der IETF

RSA Asymmetric cryptographic algorithm developed by Rivest, Shamir and Adleman

SHA Secure Hash Algorithm

SW Software

TC Trustcenter

TSP Trust Service Provider

URL Unified Resource Locator

UTC Universal Time Coordinated

WAN Wide Area Network

X.509 ITU-Standard for certificates and CRL's


Issuing CA - CPS



10.2 Terms

Attribute Information bound to an entity that specifies a characteristic of an entity, such as a group membership or a role, or other information associated with that entity.

Certificate Electronic data structure for binding a public key together with certificate holder information based on cryptographic algorithms like electronic hash and electronic signature.

Certificate Policy The term „Certificate Policy“ comprises rules and guidelines for the usability of the managed certificates the term Certificate Policy is defined in RFC 3647. Amongst other information a Certificate Policy shall define,

• Requirements for creation of keys and certificates in application, issuing and publication processes,

• Requirements for usage of certificates, keys and if appropriate signature creation devices,

• Meaning of certificates. Certification Practice Statements

Certification Practice Statements (CPS) - statements of the practices that a Certificate Authority employs in application, issuing, managing, revoking, and renewing certificates. The term Certificate Practice Statements is defined in RFC 3647. The CPS document defines guidelines for the operation of a Certificate Authority.

EE Certificate End Entity Certificate

Electronic Signature Electronic data attached to or logically associated with application electronic data for attestation of integrity by a trusted body.

Extended Normalized Certificate Policy

Normalized certificate policy according [6] requiring use of a secure cryptographic device for storage and usage of private keys

Lightweight Certificate Policy

Certificate policy, which offers a quality of service less onerous than the normalized certificate policy as defined in [6]

Lightweight Directory Access Protocol

Application protocol for querying and modifying directory services running over TCP/IP.

Normalized Certificate Policy

Normalized certificate policy according [6]

Online Certificate Status Protocol

Internet protocol used for obtaining the revocation status of an X.509 digital certificate.

Relying Party Recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate.

Subject Entity identified in a certificate as the holder of the private key associated with the public key given in the certificate.

Subscriber Entity subscribing with a Certification Authority on behalf of one or more subjects. The subject and the subscriber may be the same entity.

Trust Service Provider

Trust Service Provider means a natural or a legal person who provides one or more trust services either as a qualified or as a non-qualified trust service provider.


Issuing CA - CPS



11 Information to the document

11.1 Document history

Version Date Section/Page Reason

1.2 01.10.2010 All Creation

1.2.1 24.11.2010 Small changes

1.3 16.03.2011 All Finalizing

1.3.1 04.04.2011 Small changes

1.3.2 04.05.2011 2.3, 5.9 Corrections after audit

1.4 16.12.2011 All Changed company name to Atos

1.4.1 02.02.2012 4.2 Added IDN check

1.5 01.03.2012 2.1 Changed Policy Identifier

1.6 17.06.2013 All Added DVCP and OVCP, Added CAB Req,

Changed CA names to Atos

1.7 29.10.2013 4.2 Update clause 77

1.7.1 05.11.2013 4.2 Update clause 75/76

1.8 05.04.2016 All Changes regarding mailbox certificates

1.8.1 30.06.2017 6.3 Changes in Personnel controls

1.8.2 19.08.2017 4.2 Update clause 7,57,60,77 and 256

1.8.3 30.01.2018 4.4, 7.1, 9.5 Update clause 87,194 and 266

1.9.0 31.05.2018 5.12 Change to ESTI EN 319 411-1; Update clause 1, 7, 9, 79,

107, 108, 160, 134, 171, 194, 235, 239, 259

1.9.1 31.10.2018 4.2, 5.1, 5.6, 10.4

Change to DSGVO; Update clause 77, 92, 114, 281, 283,

284

1.9.2 25.10.2019 2.1

3.2

Identifier added for mailbox certificates; Test websites

provision to developers

2.0.0 12.03.2020 All Update CPS for Issuing Cas

2.1.0 01.04.2020 7.1.2 Small changes in table for certificate extensions

2.2.0 07.04.2020 3.2.2 Added details about storing private keys of

timestamping certificates

Added information about re-use of domain validiation


Issuing CA - CPS



11.2 Table of figures

Figure 1 End Entity Certificate Services ................................................................................. 5

11.3 Table of tables

Table 1: Published Information ............................................................................................. 13

Table 2: Access Controls for the Repositories ...................................................................... 14

Table 3: Name attributes for EE certificates .......................................................................... 15

Table 4: [Client-CA] Names for EE certificates ..................................................................... 15

Table 5: [CodeSign-CA] Names for EE certificates ............................................................... 16

Table 6: [Server-CA] Names for EE certificates .................................................................... 16

Table 7: [TimeStamp-CA] Names for EE certificates ............................................................ 16

Table 8: End entity Key Length ............................................................................................. 37

Table 9: EE key and certificate validity period ...................................................................... 40

Table 10: Certificate extensions for end entity certificates .................................................... 42

Table 11: Signature algorithm for end entity certificates ....................................................... 43

Table 12: Certificate extensions for system certificates ........................................................ 43

Table 13: Certificate Policies for end entity certificates ......................................................... 44

Table 14: Policy Qualifier for Atos TrustedRoot CA certificates ............................................ 44

Table 15: CRL extensions .................................................................................................... 45


Issuing CA - CPS



11.4 References

[1] RFC 3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework; Release November 2003; https://tools.ietf.org/html/rfc3647.html

[2] RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Release Mai 2008; https://tools.ietf.org/html/rfc5280.html

[3] RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, Release June 2013; https://tools.ietf.org/html/rfc6960.html

[4] RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record, Release November 2019; https://tools.ietf.org/html/rfc8659

[5] ETSI EN 319 401 V2.2.1 (2018-04); Electronic Signatures and Infrastructures (ESI); General Policy Requirements for Trust Service Providers

[6] ETSI EN 319 411-1 V1.2.2 (2018-04); Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements

[7] CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates, Version 1.6.8, released Mar 3rd 2020 https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.8.pdf

[8] Mozilla Root Store Policy, Version 2.7, released Jan 1st 2020 https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

[9] ETSI EN 319 412-1 V1.1.1 (2016-02); Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures

[10] ETSI EN 319 412-2 V2.1.1 (2016-02); Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 2: Certificate profile for certificates issued to natural persons

[11] ETSI EN 319 412-3 V1.1.1 (2016-02); Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons

[12] ETSI EN 319 412-4 V1.1.1 (2016-02); Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 4: Certificate profile for web site certificates

[13] ETSI TS 119312 V1.3.1 (2019-02); Electronic Signatures and Infrastructures (ESI); Cryptographic Suites

[14] Atos Subscriber Agreement, https://pki.atos.net/trustcenter/de/download/trusted-root-ca

[15] Atos Security Concept for Operating of Atos TrustedRoot CA, Version 1.5, released Oct 8th 2018

[16] Certification Practice Statements of Atos TrustedRoot Root CA, Version 2.1 https://pki.atos.net/Download/Atos_TrustedRoot_CPS_RootCA_v2.1.0.pdf

https://tools.ietf.org/html/rfc3647.html



https://tools.ietf.org/html/rfc8659

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.8.pdf

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

https://pki.atos.net/trustcenter/de/download/trusted-root-ca

https://pki.atos.net/Download/Atos_TrustedRoot_CPS_RootCA_v2.1.0.pdf

certification practice statements of atos trustedroot issuing cas · 2020. 6. 4. · atos...

Documents