OTU Certification Authority

Reference document: OTU.PC.0002

Revision of the document: 1.3

Document Date: 01/02/2015

Classification Public

www.worldline.com

OTU Certification Authority

Certification Policy Statement

This document is a translation of the

Certificate policy in French language.

The French version of this document is the reference version and

prevails over any other document.

Table of Contents

DOCUMENT REVISION HISTORY ... 7

1. INTRODUCTION ... 8

1.1 PURPOSE OF THE DOCUMENT ... 8

1.2 IDENTIFICATION ... 9

1.2.1 Document Identification ... 9

1.2.2 Identification of Certification Authority ... 9

1.3 PKI COMPONENTS ... 9

1.3.1 PKI Functional diagram ... 9

1.3.2 CA hierarchy ... 10

1.3.3 OTU CAs... 10

1.3.4 Registration Authority (RA) ... 11

1.3.5 Certificate holder ... 11

1.3.6 Subscriber and Subject ... 12

1.3.7 Certificate user ... 12 1.3.8 Organization... 12 1.3.9 Other participants ... 12 1.4 CLASSES OF CERTIFICATES... 13 1.4.1 One-time-use certificates ... 13 1.4.2 Organization certificate ... 13 1.5 USE OF CERTIFICATES ... 13 1.5.1 Areas of use ... 13 1.5.2 Prohibited uses ... 14 1.6 CP MANAGEMENT ... 15

1.6.1 Entity that manages the CP ... 15

1.6.1 Contact ... 15

1.6.2 Entity that determines whether a CPS complies with this CP ... 15

1.6.3 CPS compliance approval procedure ... 15

1.7 DEFINITIONS AND ABBREVIATIONS ... 15

1.7.1 Main Definitions ... 15

1.7.2 Abbreviations ... 18

1.8 COMPLIANCE STATEMENT ... 18

2 RESPONSIBILITIES WITH REGARD TO THE INFORMATION THAT HAS TO BE PUBLISHED ... 19

2.1 ENTITIES IN CHARGE OF MAKING THE INFORMATION AVAILABLE ... 19

2.2 INFORMATION THAT HAS TO BE PUBLISHED ... 19

2.3 PUBLICATION TIME AND FREQUENCY ... 19

2.4 ACCESS RESTRICTIONS APPLICABLE TO THE PUBLISHED INFORMATION ... 19

2.1.1 2.4.1 Access to the other documents ... 19

3 IDENTIFICATION AND AUTHENTICATION ... 21

3.1 NAMING ... 21

3.1.1 Types of names... 21

3.1.2 Necessity of using explicit names ... 21

3.1.3 Anonymization or pseudonymization of Holders ... 21

3.1.4 Rules for interpreting the various name forms ... 21

3.1.5 Names uniqueness ... 21

3.1.6 Identification, authentication and role of registred trademarks ... 21

3.2 INITIAL IDENTITY VALIDATION ... 21

3.2.1 Method for proving the possession of the private key ... 21

3.2.2 Validation of organizations’ entities ... 22

3.2.3 Validation of an individual’s identity ... 23

3.2.4 Unverified information ... 25

3.2.6 RA validation ... 25

3.2.7 Interoperability criteria ... 25

3.3 IDENTIFICATION AND VALIDATION OF A KEY RENEWAL REQUEST ... 26

3.3.1 One-time-use Certificate ... 26

3.3.2 Organization Certificate ... 26

3.4 IDENTIFICATION AND VALIDATION OF A REVOCATION REQUEST ... 26

3.4.1 One-time-use certificate ... 26

3.4.2 Organization certificate ... 27

4 OPERATIONAL REQUIREMENTS ON THE LIFECYCLE OF CERTIFICATES ... 28

4.1 CERTIFICATE REQUEST ... 28

4.1.1 Origin of a certificate request ... 28

4.1.2 Drawing up of a certificate request: process and responsibilities ... 28

4.2 CERTIFICATE REQUEST PROCESSING ... 29

4.2.1 Execution of the processes for identifying and validating the request ... 29

4.2.2 Acceptance or rejection of the request ... 30

4.2.3 Time needed to draw up the certificate ... 30

4.3 CERTIFICATE DELIVERY ... 31

4.3.1 Actions of the CA with regard to certificate delivery ... 31

4.3.2 Notification by the CA of the delivery of the certificate to the Holder ... 31

4.4 CERTIFICATE ACCEPTANCE ... 31

4.4.1 Certificate acceptance process ... 31

4.4.2 Certificate publication ... 31

4.4.3 Notification sent by the CA to inform other entities of the delivery of the certificate ... 31

4.5 KEY PAIR AND CERTIFICATE USES ... 32

4.5.1 Use of the private key and certificate by the Holder ... 32

4.5.2 Use of the private key and certificate by stakeholders ... 32

4.6 CERTIFICATE RENEWAL ... 33

4.6.1 Possible causes of certificate renewal ... 33

4.6.2 Origin of a renewal request ... 33

4.6.3 Renewal request processing ... 33

4.6.4 Notification of the creation of a renewed certificate ... 33

4.6.5 Process of acceptance of the new certificate ... 33

4.6.6 Publication of the new certificate ... 33

4.6.7 Notification sent by the CA to inform other entities of the delivery of the new certificate ... 33

Not applicable ... 33

4.7 DELIVERY OF A NEW CERTIFICATE AFTER THE KEY PAIR IS CHANGED ... 34

4.7.1 Possible causes of certificate renewal ... 34

4.7.2 Origin of a request for a new certificate ... 34

4.7.3 Processing of a request for a new certificate ... 34

4.7.4 Notification of the creation of the new certificate ... 34

4.7.5 Process of acceptance of the new certificate ... 34

4.7.6 Publication of the new certificate ... 34

4.7.7 Notification sent by the CA to inform other entities of the delivery of the new certificate ... 34

4.8 CERTIFICATE MODIFICATION ... 35

4.8.1 Possible causes of certificate renewal ... 35

4.8.2 Origin of a request for a new certificate ... 35

4.8.3 Processing of a request for a new certificate ... 35

4.8.4 Notification of the creation of the new certificate ... 35

4.8.5 Process of acceptance of the new certificate ... 35

4.8.6 Publication of the new certificate ... 35

4.8.7 Notification sent by the CA to inform other entities of the delivery of the new certificate ... 35

4.9 REVOCATION AND SUSPENSION OF CERTIFICATES ... 36

4.9.1 Possible causes of suspension ... 36

4.9.2 Origin of a revocation request... 38

4.9.3 Revocation request processing ... 38

4.9.4 Time given to the Holder to request the revocation... 39

4.9.5 Time needed by the CA to process a revocation request ... 39

4.9.7 CRL publication frequency ... 39

4.9.8 CRL publication deadline ... 39

4.9.9 Other ways of getting information about revocations ... 39

4.9.10 Requirements with regard to the online verification of the revocation of certificates by certificate users ... 39

4.9.11 Other ways of getting information about revocations ... 40

4.9.12 Specific requirements if the private key is compromised ... 40

4.9.13 Possible causes of suspension ... 40

4.9.14 Origin of a suspension request ... 40

4.9.15 Processing of a suspension request ... 40

4.9.16 Minimum and maximum durations of the suspension period of the certificate ... 40

4.10 CERTIFICATE STATUS INFORMATION FUNCTION ... 40

4.10.1 Operational characteristics ... 40

4.10.2 Availability of the function ... 40

4.10.3 Optional mechanisms ... 41

4.11 END OF THE RELATIONSHIP BETWEEN THE SUBSCRIBER AND THE CA ... 41

4.12 KEY ESCROW AND RECOVERY ... 41

4.12.1 Policy and practices with regard to the recovery of the keys held in escrow ... 41

4.12.2 Policy and practices with regard to the recovery of session keys through encapsulation ... 41

5 NON-TECHNICAL SECURITY MEASURES ... 42

5.1 PHYSICAL SECURITY MEASURES ... 42

5.2 PROCEDURAL SECURITY MEASURES ... 42

5.2.1 Trusted roles ... 42

5.2.2 Number of people required per task ... 42

5.2.3 Identification and authentication for each role ... 42

5.2.4 Roles that require assignment separation ... 43

5.3 SECURITY MEASURES WITH REGARD TO THE STAFF ... 43

5.3.1 Required qualifications, skills and authorisations ... 43

5.3.2 Judicial record verification procedure ... 43

5.3.3 Basic training requirements ... 43

5.3.4 Continuous training requirements ... 43

5.3.5 Frequency and process for the rotation of the various assignments ... 43

5.3.6 Sanctions in the case of unauthorised actions ... 43

5.3.7 Requirements with regard to external providers' staff ... 43

5.3.8 Documents given to the staff ... 44

5.4 PROCEDURES FOR CONSTITUTING AUDIT DATA ... 44

5.4.1 Types of events logged ... 44

5.4.2 Event log processing frequency ... 45

5.4.3 Event log retention period ... 45

5.4.4 Event log protection ... 45

5.4.5 Event log backup procedure ... 45

5.4.6 Event log collection system ... 45

5.4.7 Notification of the logging of an event to the person in charge of it ... 45

5.4.8 Evaluation of vulnerabilities ... 45

5.5 DATA ARCHIVING ... 46

5.5.1 Type of data to archive ... 46

5.5.2 Archive retention period ... 46

5.5.3 Archive protection ... 46

5.5.4 Archive backup procedure ... 46

5.5.5 Data timestamping requirements ... 47

5.5.6 Archive collection system ... 47

5.5.7 Archive retrieval ... 47

5.6 CHANGE OF THE CA’S KEY ... 47

5.7 RECOVERY FOLLOWING COMPROMISE AND DISASTER ... 47

5.7.1 Procedures for reporting and processing incidents and compromises ... 47

5.7.2 Recovery procedures should IT resources (hardware, software and/or data) be corrupted ... 47

5.7.3 Recovery procedures should the private key of a component be compromised. ... 48

5.7.4 Ability to pursue the activity following a disaster ... 48

5.8.1 Transfer of activity or ceasing of activity affecting a PKI component other than the CA ... 48

5.8.2 Ceasing of activity affecting the CA ... 48

6 TECHNICAL SECURITY MEASURES ... 49

6.1 KEY PAIR GENERATION AND INSTALLATION ... 49

6.1.1 Key pair generation ... 49

6.1.2 Transmission of the private key to its owner ... 49

6.1.3 Transmission of the public key to the CA ... 50

6.1.4 Transmission of the CA's public key to the various actors ... 50

6.1.5 Key size ... 50

6.1.6 Verification of the generation of key pair settings and their quality ... 50

6.1.7 Target uses of the key ... 50

6.2 SECURITY MEASURES FOR THE PROTECTION OF PRIVATE KEYS AND FOR CRYPTOGRAPHIC MODULES ... 50

6.2.1 Security standards and measures for cryptographic modules ... 50

6.2.2 Control of the private key ... 51

6.2.3 Escrow of the private key ... 51

6.2.4 Private key emergency backup ... 51

6.2.5 Archiving of the private key ... 51

6.2.6 Transfer of the private key to/from the cryptographic module ... 51

6.2.7 Storage of a private key into a cryptographic module ... 51

6.2.8 Private key activation method ... 51

6.2.9 Private key deactivation method ... 52

6.2.10 Private key destruction method ... 52

6.2.11 Evaluation of the cryptographic module ... 52

6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT ... 52

6.3.1 Archiving of public keys ... 52

6.3.2 Key pair and certificate life times ... 53

6.3.3 Key inventory ... 53

6.4 ACTIVATION DATA ... 53

6.4.1 Generation and installation of the activation data ... 53

6.4.2 Activation data protection ... 53

6.4.3 Other aspects pertaining to activation data ... 53

6.5 IT SYSTEMS SECURITY MECHANISMS ... 54

6.5.1 Technical security requirements that are specific to IT systems ... 54

6.5.2 Evaluation of IT systems ... 54

6.6 MEASURING THE SECURITY OF SYSTEMS THROUGHOUT THEIR LIFE CYCLES ... 54

6.6.1 Security measures related to system development ... 54

6.6.2 Security management measures ... 54

6.6.3 Evaluation of the security of systems' life cycles ... 54

6.7 NETWORK SECURITY MEASURES ... 55

6.8 TIMESTAMPING SYSTEM ... 55

7 PROFILES CERTIFICATES, OCSP AND CRL ... 56

7.1 CERTIFICATE PROFILES ... 56 7.1.1 Version number ... 56 7.1.2 Certificate extensions. ... 56 7.1.3 Algorithm OIDs ... 61 7.1.4 Naming schemes ... 61 7.1.5 Naming constraints ... 61 7.1.6 CP OID ... 61

7.1.7 Use of the "policy constraints" extension ... 61

7.2 CRL PROFILE ... 61

7.2.1 CRLs and extensions ... 61

7.3 OCSP PROFILE ... 62

8 COMPLIANCE AUDIT AND OTHER EVALUATIONS ... 63

8.1 FREQUENCY AND/OR CIRCUMSTANCES OF AUDITS ... 63

8.2 AUDITORS’ IDENTIFIES/QUALIFICATIONS ... 63

8.4 SUBJECTS COVERED BY AUDITS ... 63

8.5 ACTIONS CARRIED OUT FOLLOWING AUDIT CONCLUSIONS ... 63

8.5.1 Passed ... 63

8.5.2 To be confirmed ... 63

8.5.3 Failed ... 63

8.6 PUBLICATION OF RESULTS ... 64

9 OTHER BUSINESS AND LEGAL ISSUES ... 65

9.1 PRICES ... 65

9.2 INSURANCE ... 65

9.2.1 Insurance coverage ... 65

9.2.2 Other Resources ... 65

9.2.3 Coverage and guarantee applicable to user entities ... 65

9.3 CONFIDENTIALITY OF PROFESSIONAL DATA ... 65

9.3.1 Scope of secret information ... 65

9.3.2 Scope of confidential information ... 65

9.3.3 Information that falls out of the scope of confidential information ... 65

9.3.4 Responsibilities with regard to the protection of confidential information ... 66

9.4 PROTECTION OF PERSONAL DATA ... 66

9.4.1 Policy for the protection of personal data ... 66

9.4.2 Personal Information... 66

9.4.3 Non-personal information ... 66

9.4.4 Responsibilities with regard to the protection of personal data ... 66

9.4.5 Use of personal data: notification and consent ... 66

9.4.6 Conditions for disclosing personal information to legal or administrative authorities ... 67

9.4.7 Other circumstances under which personal information is disclosed ... 67

9.5 INTELLECTUAL AND INDUSTRIAL PROPERTY RIGHTS ... 68

9.6 OBLIGATIONS AND GUARANTEES ... 68

9.6.1 Certification Authority ... 68 9.6.2 Registration Authority ... 68 9.6.3 Holders’ obligations ... 68 9.6.4 Subscribers ... 68 9.6.5 Subject ... 69 9.6.6 Certificate users... 69 9.6.7 Other participants ... 69 9.7 LIMITED GUARANTEE ... 69 9.8 LIMITATED LIABILITY ... 70 9.9 COMPENSATION ... 71

9.10 VALIDITY PERIOD AND EARLY EXPIRY OF THE CP ... 71

9.10.1 Validity period ... 71

9.10.2 Early expiry ... 71

9.10.3 Effects of expiry; clauses that remain applicable ... 71

9.11 INDIVIDUAL NOTIFICATIONS AND COMMUNICATIONS BETWEEN PARTICIPANTS ... 71

9.12 AMENDMENT PROCEDURES ... 71

9.12.1 Amendment process and information period... 71

9.12.2 Circumstances under which OID must be changed ... 72

9.13 DISPUTE RESOLUTION CLAUSE ... 72

9.14 JURIDICTION ... 72

9.15 COMPLIANCE WITH LAWS AND REGULATIONS ... 72

9.16 MISCELLANEOUS CLAUSES ... 72

9.16.1 Global Agreement ... 72

9.16.2 Activity transfers ... 72

9.16.3 Consequences of an invalid clause ... 72

9.16.4 Application and renonciation ... 73

9.16.5 Force majeure ... 73

9.17 OTHER CLAUSES ... 73

APPENDIX ... 74

10.2 CONTRACTUAL DOCUMENT ... 75

10.3 REQUIREMENTS WITH REGARD TO SECURITY OBJECTIVES ... 75

10.4 QUALIFICATION REQUIREMENTS ... 75

END OF DOCUMENT ... 76

Document Revision History

Version

Date

Author

Pattern

1.0 24/12/2012 C.BRUNET Initial public release

1.1 08/04/2013 C.BRUNET Evolution following remarks during the initial ETSI

102 042 audit:

 4.9.2.1: reformulation of the origins of the revocation

 5.8.2: More detail on CRL extended in case of cessation of activity

1.2 22/11/2013 C.BRUNET Evolution after adjustment contract

 3.2.3.1: Further explanation of conservation outside use data in the certificate

 5.5.2: Changing the retention periods of registration dossiers.

 9.6.4: The term "immediately" is replaced by "promptly"

 9.9, 9.13, 9.14, 9.16.5: Change in reference to Client contracts / AWL

1.3 01/02/15 C.BRUNET Evolution after the newname of the company, and

change of certificate template :

All the document : Worldline is replaced by Worldline (notice : it the same company using the same registration number : SIRET)

7.1.2.3 : modification of the content of DN field, Subject Alt Name and Key usage

1.

Introduction

1.1

Purpose of the document

This document describes the certification policy (CP) of the OTU CA that has been created to issue signature certificates as part of the OTU online subscription service.

This CP describes:

- The requirements which the OTU CA complies with during the registration and verification of certificate requests. - The management of certificates through their life cycles.

- The security measures applicable to the infrastructure. - the uses for which these certificates are issued

This CP is applicable to the certificates intended for certificate Holders.

A second document called Certification Practice Statement [CPS] is drawn up in addition to this CP. The CPS sets out the certificate management that a CA implements. This document describes how the OTU CA is implemented:

- IT and network resources;

- external software packages, proprietary services; - physical security implemented on hosting sites; - logical security of IT resources;

- certificate management procedures; - Operation and staff training procedures.

1.2

Identification

1.2.1 Document Identification

Elements Value

Title Certification Policy of the OTU Certification Authority

Document reference OTU.PC.0002

Version 1.2

Author Worldline

Product reference OTU Certification Authority

Keywords Certification Authority, Certification Policy, CP,

Electronic certification, Electronic signature

1.2.2 Identification of Certification Authority

The Certification Authority is called "OTU ".

AFNOR (the French national organization for standardization) has assigned n°1.2.250.1.111 to "Worldline". The OIDs are based on Worldline’s OID and built as follows: 1.2.250.1.111.x.y.z.w where:

 x is the year on which the PC was created: 2012 => 12

 y is a number that indicates that the document was the “y”-th document created during the year (in the CP number specified below, y=7, which means that the CP was the seventh document created in 2012.).

 z is the version of the CP.

 w is the type of certificate within the CA.

The OID of OTU CA’s CP is 1.2.250.1.111.12.7.1





1.3

PKI components

1.3.1 PKI Functional diagram

1.3.2 CA hierarchy

The OTU CA is attached to an Atos Worldline Root CA.

DN: C = FR O = Atos worldline OU = 0002 378901946 CN = AC Racine - Root CA - 2012 OID: 1.2.250.1.111.12.4.1 1.3.3 OTU CAs

It is imperative that the OTU CA implement this OTU CP.

The OTU CA signs the certificates that it issues with its private key and is responsible for them. For this purpose, the OTU CA relies on a technical infrastructure called Public Key Infrastructure (PKI).

The services that the PKI provides are the product of various services that correspond to the various stages of the life cycles of key pairs and certificates.

In terms of functions, the OTU PKI can be broken down as follows:

 Registration Service;

 Certificate Registration Service;

 Certificate Delivery Service;

 Certificate Revocation Service;

1.3.3.1 Certifying Authority

Here, this term refers the technical part of the Certification Authority or certification service. It is the entity that produces certificates at the request of the Registration service. It is also in charge of the complete life cycle of the certificate (manufacturing, publication...).

This service generates (electronic signature with the private keyof the OTU CA) the certificates from the information given by the Registration Authority, and the Certificate Holder's public key produced by the function that generates Holders' secret elements.

The Certification Authority is also represented by an Authority manager appointed within Worldline.

1.3.3.2 Certificate delivery service

This function delivers the certificate signed by the Certification Authority to the Registration Authority. This certificate is then sent to the certificate Holder so it can be used within the scope described in section 1.4.

1.3.3.3 Service Certificate Revocation

This service processes certificate revocation requests. The processing results are given through the certificate status information service.

1.3.3.4 Information on the status of certificates Service

This function provides certificate users with information about the statuses of certificates (revoked....). This function is implemented through the use of a Certificate Revocation List (CRL).

1.3.4 Registration Authority (RA)

The RA is the contact of customer units (Subscribers) that send certificate requests to it. This is where the following operations are carried out:

- authentication of the Subscriber that makes the request; - verification of the content of certificate requests;

- registration of certificate requests; - certificate delivery;

- archiving of certificate requests; - registration of revocation requests;

- acceptance or refusal of revocation requests; - archiving of revocation requests.

To provide these services, the RA relies on technical means, notably a Registration service for managing the life cycles of certificates for the CA. This Registration Service thus constitutes a unique point for accessing the CA (servers for conveying requests and delivering certificates).

1.3.5 Certificate holder

In the context of this CP, the Certificate Holder is different from the Certificate Subject.

Indeed, the term "Certificate Holder" refers to a software and hardware entity that is hosted by Worldline and stores the Subject’s or an organisation's certificate and private key.

The Certificate Subject is in charge of the following tasks:

 generation of the key pair;

 secure storage of the key pair;

 generation of the Certificate Signing Request (CSR) that contains the user information given by the Subscriber;

 use of the private key and certificate for electronic signature purposes on behalf of the Certificate Subject's organisation;

The Certificate Holder stores the secret elements securely and has exclusive control over them on behalf of the Subject or organisation.

1.3.6 Subscriber and Subject

In certain cases, certificates can be issued directly, at their request, to physical people who act on their own behalf and for their own use. These people are called Subjects and have a direct link with the Subscriber, which they request certificates from.

It must be noted that in the context of OTU CA, the Subscriber requests certificates from the OTU Certification Service for its Customer.

As soon as the Customer wants to sign electronically the document that the Subscriber has sent to them as part of the electronic contract signing process, the Subscriber, who has subscribed to the services of the OTU CA, requests the certificate

 for its customer, who will be the subject of the issued certificate. Prior to the certificate request for its Customer, the Subscriber, notably according to its business needs, will have identified its Customer so the Certificate issued with the Customer's name is based on a reliable, reasonably verified identity. In this case, the Certification Authority will produce a one-time-use certificate (see. 1.4.1). The Subscriber's customer can be an individual or a company's representative.

 for one or more Organisations that depend on the Subscriber. The Certification Authority then produces Organisation certificates (see section. 1.4.2).

1.3.7 Certificate user

The user is the natural or legal person that uses the information of a certificate that they receive (here through an electronic signature). This signature is associated with a digital document (PDF document).

It should be noted that the signature of a PDF document is mostly used by the products supplied by ADOBE™, such as Acrobat Reader©. These products have functions for viewing the signature of the document.

Not all other PDF viewers have functions for viewing signatures.

1.3.8 Organization

An Organisation is attached to a Subscriber that will request a signature certificate containing the Organisation's name. This certificate is only used as part of the PDF signature service operated by Worldline.

The Organisation uses a Certificate Holder operated by Worldline to store and sign documents in its stead as part of a delegation between Worldline and the Subscriber.

Although the Subscriber and the Organisation are the same entity in most cases, it is possible to make a difference between the two.

For instance, a Subscriber may want to use a brand name rather than the company's name. If a group has multiple subsidiaries, the Subscriber and the Organisation may have different names.

In any case, the Subscriber will have to prove the right that it holds (ownership of the name, extract from the French Trade Register, mandate) to specify an Organisation name that differs from its own.

An Organisation certificate refers to a person who represents the Subscriber and is duly authorised. This person's name appears in the certificate provided by the OTU CA.

In relation to the ETSI specifications document, an organisation has to be considered as a subject. However, this CP refers to the Organisation by name.

1.3.9 Other participants

Human resources complete the system:

- IT systems operators (who maintain the operational condition of the system); - teams in charge of maintaining the compliance of the system.

1.4

Classes of certificates

The OTU CA produces two types of certificates. The main difference between these two types is the OID (see 7.1).

1.4.1 One-time-use certificates

A one-time-use certificate is produced by the Certification Authority for a human subject for whom a certificate is produced at the Subscriber's request.

This certificate has a very short life time and makes it possible to produce a PDF document signature on behalf of the Subject at the Subscriber's request.

The Subscriber sends the one-time-use certificate request to the OTU Registration Authority through a message that it signs electronically. This message contains:

 the data that identify the subject.

 an electronic signature that makes it possible to guarantee the integrity of the identification data as well as the Subscriber's identity.

The CPS describes how the message is validated during the signing request.

The Subscriber is responsible for the identification data that are sent in the request and which make it possible to create a certificate that contains the subject's verified data.

A subject's private key is generated in a dedicated, secure piece of equipment (Hardware Secure Module) that has been granted certification FIPS 140-2 level 2 or above.

Once the one-time-use certificate has been used at the Subscriber's request, the corresponding private key is destroyed in the HSM.

1.4.2 Organization certificate

The Organisation certificate is delivered as part of the PDF signing service that Worldline operates on its own premises on behalf of the Organisation.

The Organisation certificate enables this Organisation to request from Worldline the signing of PDF documents by an Organisation (Certification).

The Subscriber sends to the signing request to the Subject through a message that it signs electronically.

The certificate request is a procedure that takes place between a representative authorized by the Subscriber and an Worldline Registration Operator. The information that has to be supplied for the request is specified in detail in section 4.1.1.

This PC does not impose any physical presence requirements but reserves the rights to have additional checks performed, such as verification phone calls.

An organisation's private key is generated in a dedicated, secure piece of equipment (Hardware Security Module) that has been granted certification level FIPS 140-2 level 2 or higher.

1.5

Use of certificates

1.5.1 Areas of use

1.5.1.1 Holders’key pair and certificates

This CP deals with the key pairs and certificates that are intended for the categories of Holders identified in chapter

Erreur ! Source du renvoi introuvable. above so said Holders can sign PDF documents electronically as part of a dematerialised subscription or transmission procedures.

1.5.1.2 Key pair and CA certificates and components

The OTU CA has a single key pair that is used only to sign Subject or Organisation certificates, and CRLs. Its certificate is signed by the upper-level CA; see section 1.3.2.

The structure of the OTU PKI is the following :

- certificate of the root CA: self-signed AWL-RACINE electronic certificate;

- certificate of the child CA: electronic certificate delivered by the Root CA to a CA;

- holder Certificate: electronic certificate delivered by the child OTU CA to a Holder.

1.5.2 Prohibited uses

Any use of a certificate issued by the OTU CA that contravenes the uses described in sections 1.5.1.1 & 4.5 of this CP is prohibited.

The OTU CA cannot be held liable if a certificate that it issues is used for any other use than those specified in sections 1.5.1.1 & 4.5 of this CP.

1.6

CP management

1.6.1 Entity that manages the CP

Worldline is responsible for drawing up this CP, maintaining it, and revising it as soon as necessary. For this purpose, the security committee will make regular decisions as to the necessity of making changes to this CP.

1.6.1 Contact

The authorized contact for any comment, request for additional information, claim or submission of a dispute file concerning this CP is:

Comité "MediaCert OTU" Worldline 19, rue de la Vallée Maillard

B.P. 1311

41013 Blois Cedex France [email protected]

1.6.2 Entity that determines whether a CPS complies with this CP

Worldline has the compliance of the CA verified by external auditors.

1.6.3 CPS compliance approval procedure

Worldline appoints the people who determine whether the CPS complies with this PC. These people are Worldline employees.

1.7

Definitions and Abbreviations

1.7.1 Main Definitions

The definitions of the main technical terms used in this CP are provided below.

Certificate: standardised X509 data that makes it possible to associate a public key with its possessor. A certificate contains data such as:

- the possessor's identity; - the possessor’s public key;

- the identity of the organisation that issued the certificate (CA); - the validity period;

- a serial number; - a thumbprint; - usage criteria.

All these elements are signed by the CA.

The Certificate is delivered by a Certification Authority that signs the certificate which contains the Subscriber's Customer's identity and its capacity as declared by the Subscriber, whether said Customer is a physical person who acts for their own needs, or a duly authorized physical person who acts on behalf of their Organization.

The certificate makes it possible to validate the link between the electronic signature and its declared signatory, who is the certificate subject.

As part of this CP, the certificate is not a qualified one. The certificate is valid for a period that is specified in it.

Certificate holder: software component that obtains one or more certificates from the CA. These certificates are used for electronic signature purposes according to the applications and types of certificates.

The "Certificate Holder" entity is represented by servers that are operated along with the CA, and guarantees the exclusive control of key pairs by this entity only.

Certificate management service - See section 1.3.3.3

Certificate request: request sent the Subscriber to the Registration Authority with a view to obtaining a certificate for the Subscriber's Customer . It includes information that has to be supplied to the Registration service along with the certificate request.

Certificate status information service - See section 1.3.3.4

Certificate template: computer data resulting from the Registration of a Subscriber that request a certificate from the Registration service; it is then sent to the Certification Authority so it can be signed.

Certification Authority (CA): see section 1.3.3. Authority in charge of implementing this CP. It also refers to the technical entity that produces the certificates at the request of the Registration service, and is more generally in charge of managing them (manufacturing, delivery, revocation, publishing, logging, archiving) in accordance with the CP.

Certification Policy (CP): published document that describes all the rules defining the requirements which the CA abides by when setting up and providing services, and which specifies whether a certificate is applicable to a particular community and/or application category with common security requirements. If need be, a CP can also identify the obligations and requirements applicable to the various actors as well as all the components involved in managing the life cycles of certificates. The certification policy is identified by an OID.

Certification Practice Statement (CPS): identifies the practices (Organisation, operational procedures, technical and human resources) that the CA implements when providing users with its electronic certification services in accordance with the certification policy/policies which it undertakes to abide by.

Common Name (CN): element of the "subject" field of the certificate which contains the identity of its possessor

Distinguished Name (DN): distinguished X500 name for which the certificate is issued. The DN is made up of data, including the CN, which make it possible to know its identity precisely and unequivocally.

Electronic registration file: electronic data container designed to contain all the data sent by a Subscriber during a certification request (certificate information, subject identification data, etc.). These data are archived in an archiving system with evidentiary value that the CA can search at any time.

Electronic signature: "Data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication."

In this CP, the term "electronic signature" abides by the definition of the electronic signature given by the European Directive of the European Parliament and Council dated 13 December 1999, but it does not meet the requirements of signatures based on qualified certificates.

Hash: refers to the result of a calculation performed on digital content so any change made to this content, even a tiny one, also alters the hash. The hash is used to identify data and verify their integrity over time.

Key pair: a key pair consists of a private key (which has to be kept secret) and a public key. This combination is needed to implement a cryptography service based on asymmetrical algorithms (e.g. RSA).

Lightweight Certificate Policy (LCP): certification policy that provides a service quality that is less costly than that achieved with the certification policies for qualified certificates as defined by the [ETSI].

Organization: entity that represents a company or is authorised to use a brand name for which a signature certificate will be delivered at a Subscriber’s request.

OTU Certificate: one-time-use certificate that is produced dynamically during the online contract signing process. This certificate is used by the platform during a single signing session (signing by the platform of the various documents of a contract for the subject); the signing key is then destroyed.

PKI components: hardware platforms (computers, HSMs, chip readers) and software products that play specific roles within the PKI.

Registration Authority (RA): see section 1.3.4. Authority in charge of receiving certificate requests from the Subscriber, verifying them, archiving them and sending them to the Certification Authority. This term also refers to the technical entity in charge of implementing the Registration service

Registration Service: see Registration Authority

Relying party: in the context of this CP, the relying party is the entity that uses the certificate that it receives (here through an electronic signature) This signature is associated with a digital document e.g. a PDF file.

Signing session: operation that takes place between the signing request and the return of the signed document(s) by the natural or legal person that is referred to in the request. During a signing session, several successive signing operations can be performed with the same certificate.

Subscriber: entity that has registered with the OTU certificate delivery service for the delivery

 of Organisation certificates bearing the names of duly authorised people within the Subscriber.

 of One-time-use certificates bearing the names of the Subjects referred to by name in this CP and who will have been identified in advance.

Subject: natural person identified in the certificate as its possessor. The "Certificate holder" entity is in charge of the generation and exclusive use of the private key that is associated with the public key specified in the certificate

Trust chain: set of certificates necessary to validate the origin of a certificate delivered to an entity. For this CP, the trust chain consists of the certificateof the OTU CA.

User: see “Relying Party”

1.7.2 Abbreviations

The acronyms used in this CP are:

 CA: Certification Authority

 CARL: Certificate Authority Revocation List

 CC: Common Criteria

 CN: Common Name

 CO: Certification Operator

 CP: Certification Policy

 CPS: Certification Practice Statement

 CRL; Certificate Revocation List

 CSR: Certificate Signing Request

 DN: Distinguished Name

 ETSI: European Telecommunications Standards Institute

 FQDN: Fully Qualified Domain Name

 HSM: Hardware Security Module

 ISO: Information Security Officer

 ISS: Information System Security

 KC: Key Ceremony

 OID: Object Identifier



 PKI: Public Key Infrastructure

 PP: Protection Profile

 PS: Publishing Service

 PSCE : Electronic Certification Service Provider

 RA: Registration Authority

 RCA: Root Certification Authority

 RFC: Request For Comment

 RO : Registration Operator

 RSA: Rivest Shamir Adelman

 SHA: Secure Hash Algorithm

 SS: Secure Sockets Layer

 TA: Timestamping authority

 TLS: Transport Layer Security

 URL: Uniform Resource Locator

 UTC: Universal Time Coordinated

1.8

Compliance statement

2

Responsibilities with regard to the information

that has to be published

2.1

Entities in charge of making the information available

To provide the information that has to be published for certificate users, the CA implements a publishing function and a certificate status information function.

This CP and the CRL are both available publicly.

2.2

Information that has to be published

The OTU CA publishes the Certificate Revocation List (CRL) using the HTTP protocol.

The OTU CA publishes this certification policy.

The URLs for accessing the CP and the CRL are available in extensions of the certificates delivered by the OTU CA (see Profile in section 7.1) respectively:





The OTU CA publishes the certification documents that are available and provided by an approved organisation on its website http://www.mediacert.com

2.3

Publication time and frequency

The time and frequency at which the certificate status information is published, as well as the availability requirements concerning said information, are specified in sections 4.8.1 & 4.10.

The CP that is publicly available is the most recent one in force.

2.4

Access restrictions applicable to the published information

The CRL and CP are read-only documents.

2.1.1 2.4.1 Access to the other documents

Write access to the systems used to publish information about the statuses of certificates (i.e. adding, deleting or modifying the published information) is strictly limited to the authorized internal functions of the OTU PKI through authentication on dedicated access control servers.

Write access to the other information is strictly limited to the authorized internal administration functions of the OTU. The access control is performed by dedicated servers.

3

Identification and Authentication

3.1

Naming

3.1.1 Types of names

The names used comply with the specifications of the X.500 standard.

In each X509v3 certificate, the "issuer" and "subject" fields are identified using X.501 "Distinguished Names" (DN) in the form of printable strings

3.1.2 Necessity of using explicit names

In the case of a one-time-use certificate, the certificates issued according to this CP contain the explicit name and first name of the subject.

In the case of organisation certificates, the issued certificates contain the explicit name and first name of the individual who has been authorized by the Subscriber, and the organisation's name.

3.1.3 Anonymization or pseudonymization of Holders

The notions of anonymization or pseudonymization are not used

3.1.4 Rules for interpreting the various name forms

The interpretation of the information of the DN field is explained in the Certificate Profiles chapter of the OTU CA's CP (see section 7).

3.1.5 Names uniqueness

The "Distinguished Name" (DN) field is unique for each Holder. Any request that does not comply with this rule is refused. Therefore, throughout the life of the CA, a DN that has been assigned to a Holder cannot be assigned to another. Section 7.1.2.2 specifies the rules that are applied to achieve such name uniqueness.

 For one-time-use certificates, name uniqueness is guaranteed throughout the life cycle of the CA. Therefore, if a Subject requests two distinct certificates through the Subscriber, 2 different DNs will be issued.

For Organisation certificates, the uniqueness of the DN is guaranteed by the Registration Operator during the Registration. For the same organisation, the DN will not change when certificates are renewed.

3.1.6 Identification, authentication and role of registred trademarks

See 3.2.2.2

3.2

Initial identity validation

3.2.1 Method for proving the possession of the private key 3.2.1.1 One-time-use certificate

For certificates designed to be used over a short period of time, the possession of the key is verified through a low-level cryptographic check of a first signature produced using the private key.

If the verification fails, the PDF document is not signed, the private key is destroyed, and the Subscriber who has made the request receives an error message saying that said request has failed.

The subject of this certificate is not subjected to this proof of possession.

3.2.1.2 Organization Certificate

The proof of possession of the private key supplied by the Holder is guaranteed when the latter generates the request, thanks to the signing of the message with the private key that corresponds to the public key contained in the PKCS#10 message sent to the RA.

These request formats include signing with the corresponding private key, which maintains their integrity and the proof of possession of the private key.

The authorized individual specified in the certificate is not subjected this proof of possession.

3.2.2 Validation of organizations’ entities

3.2.2.1 Initial validation of the Subscriber

The initial validation of a Subscriber is associated with the prior establishment of a contractual relationship between the Subscriber and Worldline. This is the Contract by which the Subscriber subscribes to the OTU electronic signing service.

A representative of the Subscriber has to be identified; they will later be the CA's contact for Organisation certificate requests. The Subscriber can formally appoint people who are authorized to represent it. It has to inform the CA in order to do so.

During the implementation of the subscription contract, the representative appointed by the Subscriber will have to supply a copy of a valid official identity document that includes a valid identity photograph (French national ID, passport or residence card). The RA will keep a copy of it.

They will also have to supply an e-mail address that will be used to contact them, notably to send information to them during organisation certificate requests.

When the representative of the Subscriber requests an organisation certificate, said representative is authenticated by the Registration Operator.

When they request one-time-use certificates from the RA, the representative of the Subscriber will have to authenticate themselves and sign these requests electronically.

When requesting signing from the Holder, the Subscriber will have to authenticate itself and sign these requests electronically.

It is imperative that the Subscriber use the authentication and signing modes required by the RA and Holder.

The certificates used by the Subscriber to authenticate itself, and sign the certificate and signing requests have to be issued by a certification authority approved by the OTU CA.

The CPS describes the method for authenticating the Subscriber, which is based on the use and verification of the electronic certificates with the RA and Holder. It also describes the checks that are performed.

The RA keeps all the documents sent during this subscription operation.

3.2.2.2 Validation of an Organization

As explained in section 1.3.8, the Organization is represented by an authorized individual. The Subscriber has to supply the following information:

 a request less than three months old signed by an identified representative of the Subscriber; this request has to specify:

o the Organisation's name;

o the future individual who will be authorized and identified in the certificate. The Authorized individual has to sign this request for acceptance.

 any document that is valid at the time of the certificate request and which:

o can prove the Subscriber's right to use the Organisation's name in the certificate [if the Certificate is intended for the Subscriber itself (identical name), this document is not required.].

o proves the existence of the Organisation.

o contains the SIREN number or its equivalent or, if none, another document that will identify in a unique way the Organisation that will be specified in the certificate.

 any document that is valid at the time of the certificate request and which makes it possible to prove that the authorized individual belongs to the organisation.

 a copy of a valid official identity document of the authorized individual (French national ID, passport or residence card) . The RA will keep a copy of this document.

 the postal address, e-mail address and phone number that the CA can use to contact the authorized individual. The RA keeps all the documents sent during this request.

This PC does not impose any physical presence requirements. However, the RA may carry out additional checks by phone.

3.2.3 Validation of an individual’s identity

3.2.3.1 Validation of the identity of a one-time-use certificate subject

The Subscriber requests the certificate for the Subject from a RA. The Subscriber's request is made electronically.

The Subscriber creates the request and signs it with an electronic signature. At the very least, the Subscriber's request has to contain the following identification data about the Subject:

 the Subject's name and first name;

 the Subject's title.

The Subscriber can also specify (but not only) the following elements:

 the Subject's postal address;

 the Subject's phone number;

 the Subject's date and place of birth.

Although this information is not contained in the produced certificate, it will be kept in the electronic registration file associated with the issuance of the certificate.

Keeping these data is necessary, because they are needed to create the registration file that will be associated with each certificate issuance. This registration file contains these data, which describe the processes and data for identifying the final customer.

The certificate template as described in section 7.1.2.2 defines how the uniqueness of the name is guaranteed in the certificate.

The Subscriber has to specify to the CA:

The reliable user identification process that will be used alone or along with other processes, and which makes it possible to verify the civil identity declared by the future subject, notably:

o the addition of a digitized evidentiary document (subject to the verification of the digitized image); o additional information that is known beforehand, is specific to the future subject and makes it possible to

identify the latter in a predefined database.

o a verified digital identity (as opposed to a declared digital identity);

o any other process that makes it possible or has made it possible to verify the declared identity of a subject.

This list is not exhaustive, but the Subject’s electronic signature of the electronic document submitted to them by the Subscriber has to guarantee the link between said signature and the related document.

This identification process will have been described beforehand by the Subscriber during its subscription request. The process can be implemented by a technical Operator working on behalf of the Subscriber.

Since the process is described by the Subscriber, the latter is in charge of:

 implementing it (or have it implemented by its technical service provider).

 sending, in an electronic registration file, the identification data captured during the implementation of the selected process.

The CPS describes the implementation of the electronic registration file that will be created on this occasion.

The CA reserves the right to assess the reliability of the identification process and not to deliver certificates if the reliability of the process is deemed insufficient.

The Subscriber has to provide:

 the technical information showing how the subject explicitly agreed to perform an electronic signing

operation through the one-time-use certificate. Examples of such processes are (this list is not exhaustive.): o electronic capture of a handwritten signature;

o provision of a code received via SMS on a mobile phone; o a recording of the subject's voice.

This identification process will have been described by the Subscriber beforehand. The process can be implemented by a Technical Operator working on behalf of the Subscriber.

The CA makes sure that this process is actually implemented by the Subscriber. All the data are archived electronically and kept in accordance with section 5.4.

3.2.3.2 Registration by a Registration Operator

The RA can be used by RA agents to process Organisation certificate requests. The CPS describes how RA agents are appointed.

3.2.4 Unverified information

All the information of the "Subject" field of the certificate is verified during the certificate request

3.2.5 Validation by the Authority of the Subscriber that makes a request

The Subscriber authenticates itself with the RA before any request. The CPS describes how to do so according to the type of certificate that is requested:

 one-time-use certificate: certificate-based authentication;

 authentication certificate: authentication by the Registration Operator.

3.2.6 RA validation

The RA authenticates itself with the CA before any request. The CPS describes the authentication mode, in which the RA authenticates itself with the CA using authentication certificates.

3.2.7 Interoperability criteria

3.3

Identification and validation of a key renewal request

3.3.1 One-time-use Certificate

This CP does not contain any key renewal function for this certificate category

3.3.1.1 Identification and validation for a common renewal

Not applicable

3.3.1.2 Identification and validation for renewal following a revocation

Not applicable

3.3.2 Organization Certificate

A renewal request is processed like a creation request. Therefore, no new Holder certificate can be supplied unless the corresponding key pair is renewed as well (see 4.6).

3.3.2.1 Identification and validation for a common renewal

Identification and validation for the common renewal of a Holder certificate are carried out in accordance with section 3.2.

3.3.2.2 Identification and validation for renewal following a revocation

Identification and validation for a renewal following a revocation are carried out in accordance with section 3.2.

This CP allows the renewal and revocation not to be carried out in a synchronous way; however, a reasonable maximum period has to be observed.

The Subscriber has to inform the CA of the fact that the renewal follows a revocation.

The following revocation cases (see 4.9.1.2) make the renewal of an Organisation certificate impossible:

 end of the Organisation's or Subscriber's activity;

 end of the contractual relationship between the Subscriber and the CA.

3.4

Identification and validation of a revocation request

3.4.1 One-time-use certificate

When a using a certificate with a life time of 15 minutes, revocation can only take place when said certificate is used during a signing session. This is why a Subject's certificate can only be revoked at the Certificate Holder's request as described in section 4.9 . The request is sent to the RA.

The request is sent from the RA to the CA, which performs the revocation in real time.

This CP does not impose any requirements regarding the identification of a Holder that requests a revocation.

3.4.2 Organization certificate

An Organisation certificate can be revoked by the following roles:

 the Authorized individual specified in the certificate or a person whom they may have appointed;

 the CA that issued the certificate. The operation is then carried out by a Registration Operator of the CA under the supervision of a CA manager.

4

Operational requirements on the lifecycle of

certificates

4.1

Certificate request

4.1.1 Origin of a certificate request 4.1.1.1 One-time-use certificates

The creation of a one-time-use certificate can only be requested by a Subscriber that has been identified by the CA. The Subscriber must have obtained the subject's prior consent specifically for this purpose. The Subscriber must have met this obligation before making any request to the CA.

4.1.1.2 Organisation certificate

Only a Subscriber can request the creation of a Holder certificate.

If they are different from the legal representative, the authorised individual specified in the Organisation certificate must have given their prior signed consent.

4.1.1.3 Subscriber registration

During the process of subscription to the service, the OTU CA identifies the Subscriber and informs it beforehand of its obligation to identify its subjects. A specific contract is formed between the Subscriber and the OTU CA.

The Subscriber signs a contract that will be saved and kept by the OTU CA.

The OTU CA authenticates Subscribers' requests and checks whether said Subscribers are allowed to request certificates. The CPS specifies the technical arrangements that the OTU CA implements through certificates for Subscriber verification purposes.

4.1.2 Drawing up of a certificate request: process and responsibilities 4.1.2.1 One-time-use certificates

Section 3.2.2.1 specifies the information that has to be included in the request at the very least.

The Subscriber draws up the request on the basis of information that it will obtain from the Subject in a reliable way. Through a signed agreement with the AC, the Subscriber undertakes to:

 implement one or more processes for verified subject identification.

 ask the CA for its opinion about the identification processes that are implemented.

 tell the subject about the various steps that they will have to follow to obtain certificates bearing their name so they can sign electronically the document that the Subscriber will submit to them.

 implement one or more processes for obtaining the subject's explicit agreement so the Subscriber can request a certificate from the RA on their behalf.

 provide all the information required for the certificate to be issued. The request is sent directly to the RA, which sends it to the CA.

The CA may not he held liable if the Subscriber does not honour its commitments to the CA.

The CA reserves the right to refuse to issue the certificate if the Subscriber fails to honour its obligations.

4.1.2.2 Organisation Certificate

Section 3.2.2.2 specifies the information that has to be included in the request at the very least.

The request file is drawn up by the legal representative of the Organisation. The document is sent to the RA directly. Besides, the RA makes sure that it has the contact information of the future certificate Holder.

The CA may not he held liable if the Subscriber does not honour the commitments specified in the agreement that it signed with the CA.

The CA reserves the right to refuse to issue the certificate if the Subscriber fails to honour its obligations.

4.2

Certificate request processing

4.2.1 Execution of the processes for identifying and validating the request 4.2.1.1 One-time-use certificates

The Subscriber’s and the subject’s identities are verified in accordance with the requirements set out in section 0. The RA:

 validates the subject identification data (i.e. ensures the correct data are present).

 verifies the Subscriber's identity and makes sure the RA knows it.

 makes sure the Subscriber has signed its request electronically with its name.

After performing these operations, the RA issues the certificate generation request. The RA then keeps a trace of the request as an electronic archive.

The CA will produce a certificate containing the subject’s identification data.

4.2.1.2 Organisation Certificate

The identities of the Organisation and the authorised individual are verified in accordance with the requirements set out in section 0.

The RA:

 validates the identity data of the Organisation and the authorised individual within the Organisation (completeness, accuracy).

 verifies the completeness of the request file.

After performing these operations, the RA issues the certificate generation request. The RA then keeps a trace of the request as an electronic archive.

4.2.2 Acceptance or rejection of the request

If the request is rejected, the RA informs the Subscriber and justifies the rejection.

4.2.3 Time needed to draw up the certificate

Certificate requests are processed "in real time".

For Organisation certificates, a specific document that summarises the generation of the certificate and the technical people involved is created and kept as execution log.

4.3

Certificate delivery

4.3.1 Actions of the CA with regard to certificate delivery

After authenticating the origin of the request and verifying the integrity of the request coming from the RA, the CA triggers the certificate generation processes. The conditions of the generation of keys and certificates, and the security measures to comply with are set out in sections 4.1 & 5.1. The CA then sends the generated certificate to the certificate Holder.

4.3.2 Notification by the CA of the delivery of the certificate to the Holder

The CA sends the certificate to the Holder through the RA in response to the processing of the certificate request. This transmission, which is logged in the RA's logs, is considered as a notification.

In the case of an Organisation certificate, the latter is also sent to the Subscriber for explicit validation before use.

4.4

Certificate acceptance

4.4.1 Certificate acceptance process 4.4.1.1 One-time-use certificates

This CP does not impose any requirements in this domain. A certificate produced by the CA and used by the Holder is considered as compliant with the certificate request sent by the Subscriber.

In addition, checks carried out by the Holder make it possible to detect non-conformities and revoke the certificate that has been produced if it does not match the Subscriber's request.

4.4.1.2 Organisation Certificate

The Organisation certificate produced by the CA is sent to the Subscriber for validation before use.

This CP imposes explicit acceptance either from the legal representative of the Subscriber that makes the request, or from the authorised individual identified in the certificate.

E-mail acceptance is considered as sufficient. The e-mail address is specified during the subscription request. The sender's e-mail address is used to authenticate the origin of the acceptance of the certificate.

The Holder cannot use an Organisation certificate in any way whatsoever without this acceptance phase.

4.4.2 Certificate publication

There is no service for publishing the certificates issued by the OTU CA. Only the OTU CA's certificate is published.

4.4.3 Notification sent by the CA to inform other entities of the delivery of the certificate

4.5

Key pair and certificate uses

4.5.1 Use of the private key and certificate by the Holder

The Holder's use of the private key and the associated certificate is strictly limited to the signing service described in section 1.5. Otherwise, the Holder may be held liable.

Besides, the authorised use of the Holder's key pair and the associated certificate is specified in the certificate through the key use extensions.

4.5.2 Use of the private key and certificate by stakeholders

Users and Subscribers have to take into account the use specified in the certificates produced by the OTU CA (see previous section) and refuse any other use. Otherwise, they may be held liable.

4.6

Certificate renewal

This CP prohibits certificate renewal (new certificate without changing the key).

4.6.1 Possible causes of certificate renewal

Not applicable

4.6.2 Origin of a renewal request

Not applicable

4.6.3 Renewal request processing

Not applicable

4.6.4 Notification of the creation of a renewed certificate

Not applicable

4.6.5 Process of acceptance of the new certificate

Not applicable

4.6.6 Publication of the new certificate

Not applicable

4.6.7 Notification sent by the CA to inform other entities of the delivery of the new certificate

Not applicable .

4.7

Delivery of a new certificate after the key pair is changed

In the context of the delivery of one-time-use certificates, the delivery of a new certificate is not applicable. For Organisation certificates, the delivery of a new certificate is handled like a creation request. A new key pair is generated systematically.

The use of an existing key pair associated with a former CSR is prohibited.

4.7.1 Possible causes of certificate renewal

In the context of Organisation certificates, Organisations' key pairs and associated certificates are renewed every 3 years. A key pair and a certificate can be renewed in advance following the revocation of the Holder's certificate (see section 4.9, and notably 4.9.1 for the various possible causes of revocation).

It should be noted that the following causes of revocation (see section 4.9.1.2) result in the prohibition to deliver a new certificate:

 ceasing of the Organisation's activity;

 end of the contractual relationship between the Organisation and the CA.

4.7.2 Origin of a request for a new certificate

See section 4.1.1.2

4.7.3 Processing of a request for a new certificate

See section 4.2.1.2

4.7.4 Notification of the creation of the new certificate

See section 4.3.2

4.7.5 Process of acceptance of the new certificate

See section 4.4.1.2

4.7.6 Publication of the new certificate

See section Erreur ! Source du renvoi introuvable.

4.7.7 Notification sent by the CA to inform other entities of the delivery of the new certificate