Atos Trustcenter Trust Service Provider for TrustedRoot Certificates
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Atos Trustcenter
Trust Service Provider
for TrustedRoot Certificates
Certification Practice Statements
of Atos TrustedRoot Issuing CAs
Version 2.4.0
Release 07.04.2021
Document Atos_TrustedRoot_CPS_Issuing_CAs
Owner TrustedRoot CA Service Manager
Status Released
Classification PublicPage 2 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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
Classification: PublicPage 3 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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 .......................................................................................................58
11.3 Table of tables ........................................................................................................58
11.4 References .............................................................................................................59
Classification: PublicPage 4 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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
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.
Classification: PublicPage 5 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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]).
Classification: PublicPage 6 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
1.2 Document name and identification
Document Name Certification Practice Statements of Atos TrustedRoot Issuing CAs
Document Version 2.4.0
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 atos-trustedroot-cps-rootca-id = 1.3.6.1.4.1.6189.5.1.1.1.4
Root CA Policy atos-trustedroot-id policy-identifiers(1) cps(1) root-ca(4)
Atos TrustedRoot atos-trustedroot-cps-clientca-id = 1.3.6.1.4.1.6189.5.1.1.1.1
Client CA SC Policy atos-trustedroot-id policy-identifiers(1) cps(1) client-ca(1)
Atos TrustedRoot atos-trustedroot-cps-clientca-softpse-id = 1.3.6.1.4.1.6189.5.1.1.1.1.1
Client CA P12 Policy atos-trustedroot-id policy-identifiers(1) cps(1) client-ca(1) softpse(1)
Atos TrustedRoot atos-trustedroot-cps-codesignca-id = 1.3.6.1.4.1.6189.5.1.1.1.2
CodeSign CA Policy atos-trustedroot-id policy-identifiers(1) cps(1) codesign-ca(2)
Atos TrustedRoot atos-trustedroot-cps-serverca-id = 1.3.6.1.4.1.6189.5.1.1.1.3
Server CA Policy atos-trustedroot-id policy-identifiers(1) cps(1) server-ca(3)
Atos TrustedRoot atos-trustedroot-cps-timestampca-id = 1.3.6.1.4.1.6189.5.1.1.1.5
TimeStamp CA Policy 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.
Classification: PublicPage 7 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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.
Classification: PublicPage 8 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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.
Classification: PublicPage 9 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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 gmde-trustcenter@atos.net
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.
Classification: PublicPage 10 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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.
Classification: PublicPage 11 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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.
Classification: PublicPage 12 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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
Classification: PublicPage 13 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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 Target of publication
publication
Atos TrustedRoot EE On request by the After download and • LDAP directory
Certificates subscriber confirmation by the
subscriber
Atos TrustedRoot Root At least every 12 After generation of the • HTTP directory
CA CRL months CRL
• LDAP directory
Atos TrustedRoot At least every 24 hours After generation of the • HTTP directory
Issuing CA CRL CRL
• LDAP directory
General Terms and Update if required After document • Atos TC web site
Conditions for Services approval by Atos
of Atos SE
Privacy Declaration of Update if required After document • Atos TC web site
Atos SE approval by Atos
Atos Subscriber Update if required After document • Atos TC web site
Agreement approval by
TrustedRoot CA
Service Manager
Document CPS Update if required or After document • Atos TC web site
at least every 12 approval by
months TrustedRoot CA
Service Manager
Classification: PublicPage 14 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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 Create Web-Admin User Authentication
CA Change
Delete
Read Unrestricted Anonymous
HTTP Directory Service Create Certificate User Authentication
Change Management System
Delete
Read Unrestricted Anonymous
LDAP Directory Service Create Certificate User Authentication
Change Management System
Delete
Read Unrestricted Anonymous
OCSP Responder Service Create Certificate User Authentication
Change Management System
Delete
OCSP request Unrestricted Anonymous
Classification: PublicPage 15 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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
[Server-CA] Optional
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
Client Encryption (Smart Card) UID subject identifier
Client Authentication & Encryption E subscriber e-mail address
(SoftPSE) G subscriber given name
SN subscriber surname
OU organizational unit
O organization according CATS
L locality according CATS
C country according CATS
Classification: PublicPage 16 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
Table 5: [CodeSign-CA] Names for EE certificates
Purpose Subject Name Components
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
Purpose Subject Name Components
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
Purpose Subject Name Components
Time Stamping CN Timestamp-SHA256-
O Atos
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.
Classification: PublicPage 17 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
[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.
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.
[Client-CA], [CodeSign-CA], [Server-CA]
Classification: PublicPage 18 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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 395 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.
(3) Confirming the applicants control over the domain using the ACME HTTP
Challenge method defined in section 8.3 of RFC 8555 and CABF Section
3.2.2.4.19.
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.
Classification: PublicPage 19 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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
[Client-CA], [CodeSign-CA], [Server-CA]
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.
Classification: PublicPage 20 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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.
Classification: PublicPage 21 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
4.1 Certificate application
4.1.1 Who can submit a certificate application?
[Client-CA], [CodeSign-CA], [Server-CA]
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.
[CodeSign-CA], [Server-CA]
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.
Classification: PublicPage 22 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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.
[CodeSign-CA], [Server-CA]
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.
[CodeSign-CA], [Server-CA]
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.
Classification: PublicPage 23 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
[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
[Client-CA], [CodeSign-CA], [Server-CA]
The applicant will be informed about certificate issuance via e-mail.
[TimeStamp-CA]
Not relevant.
Classification: PublicPage 24 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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.
Classification: PublicPage 25 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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
[Client-CA], [CodeSign-CA], [TimeStamp-CA]
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
[Client-CA], [CodeSign-CA], [TimeStamp-CA]
Not relevant.
[Server-CA]
The provisions made in section 4.1 shall apply.
Classification: PublicPage 26 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
4.6.3 Processing certificate renewal requests
[Client-CA], [CodeSign-CA], [TimeStamp-CA]
Not relevant.
[Server-CA]
The provisions made in section 4.2 shall apply.
4.6.4 Notification of new certificate issuance to subscriber
[Client-CA], [CodeSign-CA], [TimeStamp-CA]
Not relevant.
[Server-CA]
The provisions made in section 4.3 shall apply.
4.6.5 Conduct constituting acceptance of a renewal certificate
[Client-CA], [CodeSign-CA], [TimeStamp-CA]
Not relevant.
[Server-CA]
The provisions made in section 4.4 shall apply.
4.6.6 Publication of the renewal certificate by the CA
The provisions made in section 4.4.2 shall apply.
4.6.7 Notification of certificate issuance by the CA to other entities
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?
The provisions made in section 4.1 shall apply.
4.7.3 Processing certificate re-keying requests
The provisions made in section 4.2 shall apply.
4.7.4 Notification of new certificate issuance to subscriber
The provisions made in section 4.3 shall apply.
4.7.5 Conduct constituting acceptance of a re-keyed certificate
The provisions made in section 4.4 shall apply.
4.7.6 Publication of the re-keyed certificate by the CA
The provisions made in section 4.4 shall apply.
Classification: PublicPage 27 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
4.7.7 Notification of certificate issuance by the CA to other entities
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.
4.8.4 Notification of new certificate issuance to subscriber
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.
Classification: PublicPage 28 of 59
Atos TrustedRoot CA
ATC TR Version: 2.4.0
Issuing CA - CPS
Release: 07.04.2021
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.
Classification: PublicYou can also read
