certification practice statement support of … · © keynectis. all rights reserved. ref:...

© KEYNECTIS. All rights reserved.

Ref: DSQ_CPS_PRIMARY CA CLASS 2_CPS_1.3.doc

- 1 -

� CERTIFICATION PRACTICE STATEMENT

SUPPORT OF KEYNECTIS

ELECTRONIC CERTIFICATION SERVICES CLASS 1-3

CERTIFICATES

Date: 11/07/2007


Ref : DSQ_CPS_PRIMARY CA CLASS 2_CPS_1.3.doc

- 2 -

CERTIFICATION PRACTICE STATEMENT FOR KEYNECTIS ELECTRONIC CERTIFICATION SERVICES

Document Version 1.3 Total No. of Pages: 82

Document Status Project Final Version

Document Author Caroline Drobinski KEYNECTIS

Distribution List: External Internal

Document History:

Date Version Author Comments Verified by

03/12/07 1.0 EA Document draft CDR

04/12/07 1.1 CDR Additional information, chapters 5 and 6 EA

09/26/07 1.2 CDR Adding OID identifying the CPS + information on test certificates

RP

11/07/07 1.3 CDR Update version RP

Publication date: 11/07/07 Effective date: 11/07/07



- 3 -

PREAMBLE Without limiting the rights reserved and except as authorized below, no part of this publication may be reproduced, recorded, or transmitted in any form or by any means (electronic, mechanical, photocopy, recording, or other), without prior written permission from the KEYNECTIS Corporation. Notwithstanding the above, permission is granted to reproduce and distribute this Certification Practice Statement (CPS) on a non exclusive; royalty-free basis provided that: � The copyright notice above and beginning paragraphs are prominently displayed at the beginning of each copy and that, � This document is accurately reproduced in full, complete with attribution to the KEYNECTIS Corporation.

Requests for any other permission to reproduce this KEYNECTIS Certification Practice Statement must be addressed to KEYNECTIS, 30 rue du Château des Rentiers 75647 Paris Cedex 13, France. Comment: The KEYNECTIS Certification Practice Statement may be granted under license by KEYNECTIS to commercial entities who wish to use it as part of their own electronic certification services. KEYNECTIS is a brand filed by the KEYNECTIS Corporation. KEYNECTIS, a company created in 2004 from the merger between the Certplus and PK7 companies, has acquired an expertise in marketing electronic certification services. All of the acquired knowledge from CERTPLUS and PK7 was then transferred to KEYNECTIS when it was founded. Since 1999, KEYNECTIS has held five (5) Root Certification Authorities under the following names: � “CERTPLUS PRIMARY CA Class 1” � “CERTPLUS PRIMARY CA Class 2” � “CERTPLUS PRIMARY CA Class 3” � “CERTPLUS PRIMARY CA Class 3P” � “CERTPLUS PRIMARY CA Class 3TS” This CPS can be completed by the following documents: � Procedures for registering and validating certificate requests



- 4 -

OVERVIEW OF CPS RIGHTS AND OBLIGATIONS The overview below is incomplete. Please refer to the CPS text for a complete version. This Certification Practice Statement governs the delivery and use of KEYNECTIS electronic certification services, which include certification request [§ 4], request validation [§ 0], certificate issuance [§ 7], acceptance [§ 8], use [§ 9] and revocation [§ 10]. Your the user, you acknowledge that KEYNECTIS has advised you to seek training and obtain adequate information to become familiar with digital signature and certificates before requesting, using and trusting a certificate [§1.5]. It is your responsibility to decide whether or not the certificate offered by KEYNECTIS meets your needs [§2.2]. Before submitting a certificate request [§ 4.2], you must generate a key pair [§ �] and protect the private key from any violation using a reputable method [§ 0]. Your software programs are responsible for providing this security. You must accept a certificate [§ 8.1] before releasing it to others or using it in any way. By accepting a certificate, you are making important representations [§ 8.2]. If you are the recipient of a digital signature of certificate, it is your responsibility to decide if you can trust the signature or certificate. Before doing so, KEYNECTIS advises you to check the KEYNECTIS reference archives to make sure that the certificate is valid and unrevoked. Then, use the certificate to verify [§ �] that the digital signature was created during the certificate’s active validity date using the private key corresponding to the public key listed on the certificate and make sure that the message related to the digital signature was not changed. You agree to notify [§ 0] the appropriate certification authority if your private key is violated. This Certification Practice Statement contains different guarantees and promises made by KEYNECTIS and certification authorities [§ 12.1] that may indemnify and hold harmless the applicant [§ 0]. Beyond that, any guarantee is refused and the responsibility of KEYNECTIS and certification authorities is limited [§ 12.4]. The Certification Practices Statement includes a series of various provisions [§ 13] and prohibits infringements [§ 13.1]. To find out more, visit the KEYNECTIS website at http://www.KEYNECTIS.com.



- 5 -

COMMENTS AND SUGGESTIONS KEYNECTIS gladly welcomes comments and suggestion for future revisions of this CPS. Please send comments to: [email protected].



- 6 -

TABLE OF CONTENTS

1 INTRODUCTION ______________________________________________________________________ 12 1.1 Overview .................................................................................................................................................... 12 1.2 Structure of the CPS ................................................................................................................................ 13 1.3 Citing the CPS........................................................................................................................................... 13 1.4 Document name and Identification......................................................................................................... 13 1.5 Underlined Text ........................................................................................................................................ 13 1.6 Customer Service Assistance, Education, and Training ..................................................................... 14 1.7 Table of Acronyms and Abbreviations .................................................................................................. 15

2 KEYNECTIS CERTIFICATION INFRASTRUCTURE __________________________________________ 16 2.1 Trust Infrastructure .................................................................................................................................. 16 2.2 General Description of Certificate Issuance and Management ........................................................... 16

2.2.1 Security Services ................................................................................................................................. 16 2.2.2 Certification services Domain Administration ...................................................................................... 17

2.3 Class 1, 2, and 3 Certificates ................................................................................................................... 17 2.3.1 Class 1 Certificates .............................................................................................................................. 18 2.3.2 Class 2 Certificates .............................................................................................................................. 18 2.3.3 Class 3 Certificates .............................................................................................................................. 18 2.3.4 Test Certificates ................................................................................................................................... 19

2.4 Certificate Class Properties .................................................................................................................... 20 2.4.1 Confirmation of subscriber identity ...................................................................................................... 21 2.4.2 CA private key protection ..................................................................................................................... 21 2.4.3 Certificate applicant private key protection .......................................................................................... 21 2.4.4 Operational controls ............................................................................................................................. 21

2.5 Extensions and Naming ........................................................................................................................... 21 2.5.1 Extension mechanisms and authentication framework ....................................................................... 21 2.5.2 Standard and specific extensions ........................................................................................................ 21 2.5.3 Identification and criticality of special extensions ................................................................................ 21 2.5.4 Certificate chains and types of CAs ..................................................................................................... 22 2.5.5 End user certificate extensions ............................................................................................................ 22 2.5.6 ISO basic constraint extensions .......................................................................................................... 22 2.5.7 ISO “Key Usage" and "Extended Key Usage” extensions ................................................................... 22 2.5.8 ISO “Certificate Policy” extension ........................................................................................................ 22

2.6 PKI Hierarchy ............................................................................................................................................ 23 2.6.1 Root Certification Authorities (RCA) .................................................................................................... 24 2.6.2 Certification Authority (CA) .................................................................................................................. 24 2.6.3 Registration authorities (RA) ................................................................................................................ 25 2.6.4 Naming authority .................................................................................................................................. 25 2.6.5 KEYNECTIS reference archives .......................................................................................................... 26

3 PREREQUISITES FOR CERTIFICATION OPERATIONS ______________________________________ 27 3.1 Prerequisites for Approval as a Non-KEYNECTIS CA within the Electronic Certification

Services ..................................................................................................................................................... 27 3.1.1 Non-KEYNECTIS CA certificate application ........................................................................................ 27 3.1.2 Submission of a non-KEYNECTIS CA application to KEYNECTIS ..................................................... 27 3.1.3 Authorization to initiate CA activities .................................................................................................... 27

3.2 KEYNECTIS’ Right to Investigate Violations ......................................................................................... 28 3.3 Compliance with this CPS ....................................................................................................................... 28 3.4 Trustworthy Systems ............................................................................................................................... 28 3.5 Financial Responsibility .......................................................................................................................... 28 3.6 Records Documenting Compliance........................................................................................................ 28 3.7 Time Stamping .......................................................................................................................................... 29 3.8 Document Retention Schedule ............................................................................................................... 29 3.9 Audit .......................................................................................................................................................... 29 3.10 Emergency Planning and Disaster Recovery ........................................................................................ 30



- 7 -

3.11 Availability of CA certificates .................................................................................................................. 30 3.12 Publication by Certification Authorities ................................................................................................. 30 3.13 Confidential Information .......................................................................................................................... 30 3.14 Personnel Management Procedures ...................................................................................................... 30

3.14.1 Trusted positions .................................................................................................................................. 31 3.14.2 Investigation and compliance .............................................................................................................. 31 3.14.3 Removal of individuals in trusted positions .......................................................................................... 31

3.15 Accreditations........................................................................................................................................... 31 3.15.1 Approval of software and hardware devices ........................................................................................ 31 3.15.2 Personnel in trusted positions .............................................................................................................. 31 3.15.3 Organizational good standing .............................................................................................................. 31

3.16 CA Key Generation ................................................................................................................................... 31 3.17 Secret Sharing .......................................................................................................................................... 32

3.17.1 Protection using cryptographic hardware ............................................................................................ 32 3.17.2 RA representation ................................................................................................................................ 32 3.17.3 Acceptance of secret shares by secret share holders ......................................................................... 32 3.17.4 Protecting the secret share .................................................................................................................. 32 3.17.5 Availability and Release of Secret Shares ........................................................................................... 33 3.17.6 Records to be kept by secret share issuers and holders ..................................................................... 33 3.17.7 Secret share holder liability .................................................................................................................. 33 3.17.8 Indemnity by secret share issuer ......................................................................................................... 34

3.18 Compliance with Operational Period Requirements ............................................................................ 34 3.19 Security Requirements ............................................................................................................................ 34

3.19.1 Communications security ..................................................................................................................... 34 3.19.2 Facilities security .................................................................................................................................. 34

3.20 Requirements for RA Administrators ..................................................................................................... 34 3.21 Termination or Cessation of CA Activities ............................................................................................ 34

3.21.1 Requirements prior to cessation .......................................................................................................... 34 3.21.2 Reissuance of certificates by a CA successor ..................................................................................... 35

4 CERTIFICATE APPLICATION PROCEDURES ______________________________________________ 36 4.1 Key Generation and Protection ............................................................................................................... 36

4.1.1 Holder exclusivity: controlling access to private keys ......................................................................... 36 4.1.2 Delegation of private key responsibilities............................................................................................. 36

4.2 Certificate Application Content and Communication ........................................................................... 37

5 CERTIFICATE APPLICATION VALIDATION _______________________________________________ 38 5.1 Validation Requirements for Certificate Applications .......................................................................... 38

5.1.1 Personal presence ............................................................................................................................... 39 5.1.2 Third-party confirmation of personal information ................................................................................. 39 5.1.3 Third-party confirmation of company information ................................................................................ 40 5.1.4 Postal address confirmation ................................................................................................................ 40 5.1.5 InterNIC domain name and serial number assignment ....................................................................... 40 5.1.6 Export controls confirmation ................................................................................................................ 40

5.2 Initial Registration .................................................................................................................................... 40 5.2.1 Name agreement ................................................................................................................................. 41 5.2.2 Need for names to be meaningful ........................................................................................................ 41 5.2.3 Rules for interpreting various name forms ........................................................................................... 41 5.2.4 Uniqueness of name ............................................................................................................................ 41 5.2.5 Name claim dispute resolution procedure ........................................................................................... 41 5.2.6 Authentication of organization and individual identity .......................................................................... 41 5.2.7 Unverified Information .......................................................................................................................... 42 5.2.8 Proof of private key possession ........................................................................................................... 42

5.3 Verifications for Key Renewals ............................................................................................................... 42 5.3.1 Routine re-key or re-key after revocation ............................................................................................ 42 5.3.2 Authentification of a revocation request ............................................................................................... 43

6 OPERATIONAL REQUIREMENTS ________________________________________________________ 43



- 8 -

6.1 Application for a Certificate .................................................................................................................... 43 6.1.1 Origin of the application ....................................................................................................................... 43 6.1.2 Registration procedure for user certificates ......................................................................................... 43 6.1.3 Registration procedure for SSL certificates ......................................................................................... 44

6.2 Verification of the Organization’s Name ................................................................................................ 46 6.2.1 Records archiving ................................................................................................................................ 48

6.3 Issuance and Distribution of a Certificate ............................................................................................. 48 6.3.1 Approval or rejection of a certificate application .................................................................................. 48 6.3.2 Client certificate issuance notification .................................................................................................. 48 6.3.3 Processing time of a certificate request ............................................................................................... 49

6.4 Certificate suspension and revocation .................................................................................................. 49 6.4.1 Possible reasons for revocation ........................................................................................................... 49 6.4.2 Origin of a certificate revocation request ............................................................................................. 49 6.4.3 Procedure and processing of a certificate revocation request............................................................. 50 6.4.4 Procedure and processing of an SSL certificate revocation request ................................................... 50 6.4.5 Grace period ........................................................................................................................................ 50 6.4.6 Time period for processing a revocation.............................................................................................. 51 6.4.7 Revocation verification requirements for third-parties ......................................................................... 51 6.4.8 CRL integrity ........................................................................................................................................ 51 6.4.9 CRL publication frequency ................................................................................................................... 51 6.4.10 Online revocation status checking ....................................................................................................... 51 6.4.11 CRL publication forms.......................................................................................................................... 51 6.4.12 Special requirements for key compromise revocation ......................................................................... 51 6.4.13 Certificate suspension.......................................................................................................................... 51

6.5 Event Logging........................................................................................................................................... 51 6.6 Archives .................................................................................................................................................... 52 6.7 End of Subscription ................................................................................................................................. 52

7 ISSUANCE OF CERTIFICATES __________________________________________________________ 52 7.1 Consent by the Subscriber for Issuance of a Certificate ..................................................................... 52 7.2 Refusal to Issue a Certificate .................................................................................................................. 53 7.3 CA’s Representations Upon Certificate Issuance ................................................................................. 53

7.3.1 CA’s representations to the Subscriber ............................................................................................... 53 7.3.2 CA representations to trusted parties .................................................................................................. 53

7.4 CA’s Representations Upon Publication ............................................................................................... 53 7.5 Limitations on CA Representations ....................................................................................................... 53 7.6 Time Period for Certificate Issuance ...................................................................................................... 54 7.7 Certificate Validity .................................................................................................................................... 55 7.8 Restrictions on Issued but not Accepted Certificates ......................................................................... 55

8 ACCEPTANCE OF CERTIFICATES BY SUBSCRIBERS ______________________________________ 56 8.1 Certificate Acceptance ............................................................................................................................. 56 8.2 Representations by Subscriber Upon Acceptance............................................................................... 56 8.3 Subscriber’s Obligation to Prevent Private Key Disclosure ................................................................ 57 8.4 Indemnity by the Subscriber ................................................................................................................... 57 8.5 Publication ................................................................................................................................................ 57

9 USE OF CERTIFICATES _______________________________________________________________ 58 9.1 Verification of Digital Signatures ............................................................................................................ 58 9.2 Effect of Validating a Subscriber’s Certificate ...................................................................................... 59 9.3 Procedures upon Failure of Digital Signature Validation .................................................................... 59 9.4 Trust in Digital Signatures ....................................................................................................................... 59 9.5 Writings ..................................................................................................................................................... 59 9.6 Signatures ................................................................................................................................................. 59 9.7 Security Measures .................................................................................................................................... 59 9.8 Issuing certificates ................................................................................................................................... 60

10 CERTIFICATE REVOCATION ___________________________________________________________ 61



- 9 -

10.1 General Reasons for Revocation ............................................................................................................ 61 10.2 Revocation of a CA certificate ................................................................................................................ 61 10.3 Revocation at a Subscriber’s Request ................................................................................................... 61 10.4 Revocation for Faulty Issuance .............................................................................................................. 61 10.5 Notification and Confirmation of Revocation ........................................................................................ 62 10.6 Effect of Revocation ................................................................................................................................. 62

10.6.1 On certificates ...................................................................................................................................... 62 10.6.2 On underlying obligations .................................................................................................................... 62

10.7 Protecting a Private Key upon Revocation ............................................................................................ 62

11 CERTIFICATE EXPIRATION ____________________________________________________________ 63 11.1 Notice Prior to Expiration ........................................................................................................................ 63 11.2 Effect of Certificate Expiration on the Underlying Obligations ........................................................... 63 11.3 New Request and Renewal ...................................................................................................................... 63

12 OBLIGATIONS OF ISSUING AUTHORITIES AND KEYNECTIS, AND LIMITATIONS OF THESE OBLIGATIONS _____________________________________________________________________________ 64

12.1 Limited Warranties and other Obligations ............................................................................................. 64 12.2 Disclaimers and Limitations of CA Obligations .................................................................................... 64 12.3 Exclusion of Certain Damage Elements ................................................................................................ 65 12.4 Damage and Loss Limitations ................................................................................................................ 65 12.5 Applicant Liability to Trusting Parties ................................................................................................... 65 12.6 No Fiduciary Relationship ....................................................................................................................... 65 12.7 Dangerous Activities ................................................................................................................................ 65

13 MISCELLANEOUS PROVISIONS ________________________________________________________ 67 13.1 Conflicting Provisions ............................................................................................................................. 67 13.2 Compliance with Export Laws and Regulations ................................................................................... 67 13.3 Applicable Law ......................................................................................................................................... 67 13.4 Dispute Resolution, Choice of Forum, and Presumptions .................................................................. 67

13.4.1 Notification among parties of a dispute................................................................................................ 67 13.4.2 Official resolution of legal disputes ...................................................................................................... 67

13.5 Succession and Assignment .................................................................................................................. 67 13.6 Merger ........................................................................................................................................................ 68 13.7 Severability ............................................................................................................................................... 68 13.8 Interpretation and Translation ................................................................................................................ 68 13.9 No Waiver .................................................................................................................................................. 68 13.10 Communications ...................................................................................................................................... 68 13.11 Headings and Appendices of this CPS .................................................................................................. 69 13.12 Change of Subscriber Information in CA files; Amendments to the CPS .......................................... 69

13.12.1 Change of subscriber information in a CA's file; amendment to the CPS ........................................... 69 13.12.2 Amendment of the CPS ....................................................................................................................... 69

13.13 Ownership of Security Material ............................................................................................................... 69 13.14 Infringement and Other Sources of Damage ......................................................................................... 70 13.15 Fees ........................................................................................................................................................... 70 13.16 Choice of Cryptographic Methods ......................................................................................................... 70 13.17 Survival ...................................................................................................................................................... 70

14 APPENDIX ___________________________________________________________________________ 71



- 10 -

FIGURES INDEX Figure 1 – The central role of the KEYNECTIS CPS ...................................................................................... 12 Figure 2 – CPS life cycle structure .................................................................................................................. 13 Figure 3 – KEYNECTIS PKI basic hierarchy ................................................................................................... 24



- 11 -

INDEX OF TABLES

Table 1 – Acronyms and abbreviations ........................................................................................................... 15 Table 2 – Certificate properties affecting trust ................................................................................................. 20 Table 3 – KEYNECTIS certificate extensions.................................................................................................. 23 Table 4 – Distribution of secret shares ............................................................................................................ 32 Table 5 – Required certificate application information .................................................................................... 37 Table 6 – Certificate application validation requirements ................................................................................ 39 Table 7 – Deadlines for certificate issuance .................................................................................................... 54 Table 8 – Certificate validity period ................................................................................................................. 55 Table 9 – Certificate acceptance methods ...................................................................................................... 56 Table 10 – Pre-requisites for revoking a certificate ......................................................................................... 61 Table 11 – Renewal and new request ............................................................................................................. 63 Table 12 – Liability caps .................................................................................................................................. 65



- 12 -

1 INTRODUCTION

This chapter presents the KEYNECTIS Certification Practice Statement (CPS) and describes its structure and underlying conventions. It concludes with a list of abbreviations and acronyms used in the CPS to make it easier to read and understand.

1.1 Overview

This KEYNECTIS Certification Practices Statement presents the practices that KEYNECTIS, its certification authorities (CA) and authorized non-KEYNECTIS certification authorities participating in the provision of KEYNECTIS electronic certification services employ in issuing and managing certificates and in maintaining a certificate-based public key infrastructure (PKI). The CPS details and controls the certification process, from establishing certification authorities, implementing operations, to registering certificate applicants. Electronic certification services provide for issuing, managing, using, revoking, and renewing of certificates. The CPS is intended to legally bind and provide notice to all parties that create, use, and validate certificates within the context of the electronic certification services. As such, the CPS plays a central role in governing the electronic certification services, as represented in Figure 1.

Figure 1 – The central role of the KEYNECTIS CPS

This CPS governs only a portion of the services offered by KEYNECTIS. Other KEYNECTIS services may neither require nor invoke a CA hierarchy. The electronic certification services will inevitably evolve to incorporate other structures in response to market demands.

KEYNECTIS CPS

Subscriber Contracts

Trusted Third Party

Contracts

Certification Authority

KEYNECTIS Security Policy

Guidelines and Standards

Naming authority

Subscriber

KEYNECTIS Reference Archives

Trusted Third Parties

Recipients

KEYNECTIS

FAQs



- 13 -

1.2 Structure of the CPS

The CPS takes a comprehensive “cradle-to-grave” approach to describing certification processes. It begins with CA installation and start-up procedures, and then covers general CA operations: application; use of certificates; certificate revocation and expiration. The advantages of this approach include a chronological presentation of events and compatibility with the anticipated structure of leading private and public sector practice statements as shown by Figure 2 below.

Figure 2 – CPS life cycle structure

1.3 Citing the CPS

This Certification Practices Statement should be cited in other documents as the “Keynectis CPS” or the “KEYNECTIS Certification Practice Statement”. It is internally cited as the “CPS” or as “CPS Section x”, and its appendices are cited as “Appendix Section 1.x”. The CPS is updated regularly. Versions of the CPS are indicated by a version number following "CPS" (e.g., "version 1.0" or "CPS 1.0").

1.4 Document name and Identification

This CPS is the KEYNECTIS property. This CPS has a global registered policy object identifier (OID) that is: 1.3.6.1.4.1.22234.2.5.2.1. This specific version of CPS has a registered policy object identifier (OID) that is: 1.3.6.1.4.1.22234.2.5.2.1.2.

1.5 Underlined Text

Underlined text represents the first instance defined terms in Appendix 14 are used in this document. The CPS is published by KEYNECTIS: � in electronic form at the following address: www.keynectic.com/PC � in paper form from 30 rue du Château des Rentiers 75647 Paris Cedex 13, France

KEYNECTIS CPS operations cycle [CPS

§3]

Certificate Application [CPS §4]

Validation of Certifcate Application [CPS §0]

Certificate Issuance [CPS §7]

Acceptance of Certifcate by Subscribers [CPS §8]

Use of Certificate [CPS §9]

Revocation of Certificate [CPS §10]

Expiration and Renewal of Certificate [CPS §11]

KEYNECTIS CPS



- 14 -

The “unprotected” mode (http:11) must be used to access the official version of all of the documents open through the Web. If a “protected” mode is required, replace http:// with https://: invoking the Secure Socket Layer (SSL) security protocol. For any additional information, please send an email to [email protected].

1.6 Customer Service Assistance, Education, and Training

This CPS assumes that the reader is familiar with digital signature, PKIs and KEYNECTIS’ electronic certification services. If not, we advise some training in the use of public key techniques before the reader applies for a certificate. Educational and training information is available from KEYNECTIS. KEYNECTIS customer service ([email protected]) can also provide additional assistance. All electronic certification services applicants and subscribers acknowledge that: � They have been advised to receive proper training in the use of public key techniques before requesting a certificate and that, � The documentation and training about digital signatures, certificates, PKI, and electronic certification services are available from KEYNECTIS.



- 15 -

1.7 Table of Acronyms and Abbreviations

CA Certification Authority

RCA Root Certification Authority

RA Registration Authority

CSR Certificate Signing Request

CPS Certification Practice Statement

DAM Draft Amendment

GMT Greenwich Meridian Time

FIPS Federal Information Processing Standard

FTP File Transfer Protocol

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol with SSL

HSM Hardware Security Module

PKI Public Key Infrastructure

UVI Unverified Information

CRL Certificate Revocation List

RDN Relative Distinguished Name

PIN Personal Identification Number (activation data)

PKCS Public Key Cryptography Standards

SCP KEYNECTIS Security Procedures

RSA A cryptographic system

CSR Certificate Signature Request.

S/MIME Secure Multipurpose Internet Mail Extensions

ECS Electronic Certification Services

SSL Secure Socket Layer

URL Uniform Resource Locator (standardized resource locator on the WWW)

EU End User

WWW or WEB World Wide Web

X.509 The ITU-T standard for certificates and the corresponding authentication framework

Table 1 – Acronyms and abbreviations



- 16 -

2 KEYNECTIS CERTIFICATION INFRASTRUCTURE

This chapter explains the architecture underlying the distribution of KEYNECTIS’ electronic certification services, as well as certificates, extensions, and time stamping.

2.1 Trust Infrastructure

KEYNECTIS electronic certification services (ECS) are designed to support secure e-commerce and other general services to meet users’ technical, business, and personal needs for electronic signatures and other network security services. To accomplish this, KEYNECTIS-authorized certification authorities act as trusted third parties, issuing, managing, and revoking certificates in compliance with published practices. KEYNECTIS CERTIFICATION SERVICES’ management and administration features are designed to handle a large, widely distributed community of users with different needs for communications and information security. To ensure that KEYNECTIS services are substantially uniform, a general statement about the management and administration practices used to protect the integrity of KEYNECTIS certification services is included in the CPS. These practices enable KEYNECTIS ESC to manage a large number of users over a wide geographical area, enhancing users’ trust in these services.

2.2 General Description of Certificate Issuance and Management

A CA acts as a trusted third party to facilitate the confirmation of the relationship between a public key and a named entity (“naming"). This confirmation is represented by a certificate; in other words, a digitally-signed message issued by a CA. High-level management of this certification process includes registration, naming, applicant authentication, issuance, revocation, and generation of audit status. Naming is performed primarily by KEYNECTIS, but can also be done by another party. Naming of certification authorities follows a registration process that is different from the process used to manage certificates, which determines when certificates are valid and operational. KEYNECTIS currently offers three distinct levels of electronic certification services. Each certificate level, or class, provides specific security functions and features. Certificate applicants must choose from these different service qualities according to their needs and indicate which certificate class they would like. Depending on the class of certificate desired, certificate applicants may send their application to a CA electronically, or they may have to apply in person by contacting a registration authority (RA). Each certificate issued by a CA corresponds to a specific electronic certification service trust level. Several CAs may issue certificates for a given trust level; these CAs may differ by additional services and practices suitable for different communities. In response to a certificate application, a certificate is then issued to the applicant, or a draft of the certificate contents is sent to the applicant. The applicant must review the certificate or draft, determine if it meets his/her needs, and if satisfied, accept the certificate through the certificate registration process. The new applicant agrees to be bound by the continuing obligations of this CPS. Certificate management also includes the deactivation of certificates and the decommission of the corresponding private keys through a certificate revocation process. Other CA services may include printing, distributing, publication, storage, and retrieval of certificates according to their particular intended use.

2.2.1 Security Services



- 17 -

The KEYNECTIS electronic certification services support a variety of security mechanisms to protect communications and information. Certificates alone do not constitute a security mechanism. KEYNECTIS’ CERTIFICATION SERVICES provide a framework in which security services may be used by other communicating parties. This framework uses digital signatures and their verification to facilitate the protection of communication and computer-based commerce over open networks; it provides a way for determining whether security services are providing the intended assurances. Certificate-based security services may be used to counter security threats in a user-defined environment. Users select security mechanisms, security technology, and security service contracts, as well as the electronic certification services that suit the users’ anticipated level of risk, in order to protect users’ communication environments from compromise. KEYNECTIS’ CERTIFICATION SERVICES currently use the RSA public key system for all certification needs. However, KEYNECTIS is committed to supporting other digital signature standards when the market demands alternative solutions.

2.2.2 Certification services Domain Administration

KEYNECTIS certification services are administered in such a way that some certification services may be performed by parties other than KEYNECTIS. However, quality of service remains uniform, even if service provision is physically and functionally distributed. The underlying principle of domain administration is a strict delegation of authority. To accomplish this, KEYNECTIS relies on an auditable, decentralized agreement with the CAs for the performance of specific published practices. Each CA is authorized by a superior CA to perform certain certification services in a prescribed manner. Each CA also acts as an RA, unless it delegates the responsibility. Some of these functions involve creating CAs, while others concern the execution of authorized procedures by a CA once a higher level CA has granted approval. To improve the uniformity of certification services, superior CAs delegate specific duties. KEYNECTIS administration rules guarantee that autonomous parties agree to comply with practices, including the issuance and management of certificates, in a way that will maintain the uniformity of electronic certification services.

2.3 Class 1, 2, and 3 Certificates

As part of the framework of its certification services, KEYNECTIS currently supports three distinct certificate classes. Each class provides a given level of trust. The following subsections explain each certificate class. Further detail is provided in Table 2 (Certificate attributes that affect trust).

The description of each certificate class reflects the applications and communication systems that have been or are in the process of being implemented by users. It does not represent an endorsement or recommendation by KEYNECTIS or any other CA for any particular application or purpose and should not be considered as such. Users must independently evaluate and determine the suitability of each certificate class based on their needs.



- 18 -

2.3.1 Class 1 Certificates

Class 1 certificates are issued only to individuals. They confirm that the name of a user or his/her alias and/or email address form a subject. Class 1 certificates are sent to subscribers electronically and added to their set of available certificates. They are generally used for Internet browsing and personal emails to moderately increase the security of these environments. They are also used to establish continuity in the sequence of exchanges (ensuring that subsequent messages are always from the same user). When a certificate applicant provides certain optional information (country, zip code, age, and gender) on the certificate application, and this information is made available to third party services through the certificate, Class 1 certificates may also facilitate the delivery of specific services by third-party service providers such as Web site hosts. Class 1 certificates do not facilitate authentication of the subscriber’s identity. They simply verify the uniqueness of the subject name within the KEYNECTIS Reference Archives, and conduct a limited verification of the email address. The subscriber’s common name listed on a Class 1 certificate is considered to be unverified information (UVI). Of all of the KEYNECTIS certificates, these certificates offer the lowest trust level. They are not intended for commercial use in situations where proof of identity is required. Consequently, it is recommended that you not rely on these certificates for such uses.


Class 2 certificates are issued to individuals and organizations. They verify that information provided by the applicant is consistent with information available in credible databases. Class 2 Certificates are used primarily by KEYNECTIS customers for external and internal email; small, low risk transactions, personal/individual email; password replacement; software validation and subscription to online services. Class 2 Certificates may also facilitate and improve the benefits of some third-party service providers, such as Web site hosts, by enabling them to access information contained in the subscriber’s certificate (when an individual submits a certificate application, they may fill out additional information fields, which is made available to third-party service providers). After submitting a Class 2 Certificate application online to a registration authority (RA), the certificate applicant’s registration information is checked against third-party databases. Based on this information, the RA will either approve or reject the request. Class 2 Certificates may significantly (but not absolutely) ensure the applicant’s identity based on a process that checks the requestor’s name, address, and other information provided in the certificate application by comparing it to information in widely referenced databases. Direct phone calls are also made to confirm the applicant’s identity, company, etc. Confirmation is based on KEYNECTIS matching criteria of third-party databases against the information in the application.

Although KEYNECTIS uses an advanced authentication method to verify and validate the certificate applicant’s identity for a Class 2 Certificate, it does not require the applicant’s personal appearance before a trust authority (such as an RA). Consequently, the decision to obtain, use or rely on a Class 2 certificate should take into account its advantages and limitations, and the certificate should be used accordingly. Additional information about the authentication process is available from KEYNECTIS.


Class 3 certificates are issued to individuals and organizations. These certificates significantly guarantee the identity of individual applicants by requiring their physical appearance before a Class 3 RA or the RA's delegate. One Class 3 individual certificate type is the "Class 3 administrator certificate (registration authority)." It is only issued to authorized, permanent, and salaried RA Administrators and approved by an



- 19 -

external RA to perform authorized RA administrator functions. This RA administrator must be authorized by the responsible RA (through authenticated records) before the administrator certificate can be approved. The private key corresponding to the public key contained in a Class 3 administrator certificate must be generated and stored in a secure manner according to the criteria in effect (for example, in a smart card). The Class 3 Certificate uses different procedures in order to prove the identity of the individual applicant in a probative manner. Face-to-face communication with the business organization and the confirmation of its related information through third-parties provides additional reasons for trust. 2.3.4 Test Certificates

This CPS sets forth certain conditions under which KEYNECTIS' Test Certification Authority issues and manages test certificates and under which the certificates for the test are used.

A test SSL certificate enables a subscriber to simulate the operation of a web site that provides certain security services when a server certificate is properly used. A test certificate enables a subscriber to use the test SSL certificate to test the functionality of server certificates in his/her application.

A subscriber using a test certificate may approve test certificate applications or test the functionality of client certificates in his/her application and makes the test CA available on its web site for authorized test purposes only in accordance with this CPS.

A person downloading and/or using the test SSL certificate can simulate the process by which a browser authenticates and establishes a secure channel to a web site that properly uses a server certificate. This CPS is intended to provide notice to subscribers and other users.

It is agreed that: � Test CA and test certificates shall be used exclusively for test purposes. Tests certificates and all components thereof shall not be used or relied upon for any other purposes, including commercial transactions, authenticating the identity of a subscriber or in connection with ensuring the confidentiality of any information. � Subscribers acknowledge that neither the identity nor authority of subscribers has been authenticated or approved by KEYNECTIS in test purposes � Upon KEYNECTIS' receipt of a complete application for a test certificate, KEYNECTIS shall issue a test certificate to a subscriber. Test SSL certificates shall be used exclusively for authorized testing purposes in simulating the process by which a browser authenticates and establishes a secure channel to a web site that properly uses a server certificate. � Subscribers acknowledge that KEYNECTIS shall not be required to suspend or revoke test certificates at the request of the subscriber.

KEYNECTIS makes no representation, warranty or guarantee to any person that any subscriber to which it has issued a test certificate is in fact the person or organization it claims to be in information supplied to KEYNECTIS or that any person or organization is in fact the person listed in a test certificates. KEYNECTIS makes no assurances of the accuracy, authenticity, integrity or reliability of information contained in test certificates or of the results of cryptographic methods implemented in connection with such certificates. KEYNECTIS shall not be liable to any other person for any consequential, indirect, special or incidental damages.

The validity period for a test certificate is set forth 2 weeks (14 days) from the date of certificate issuance

Information about test certificate in this CPS constitutes the entire understanding and agreement and supersedes all prior or contemporaneous oral and written other agreements.

Information contained in a test certificate shall be considered as UVI.



- 20 -

2.4 Certificate Class Properties

Erreur ! Source du renvoi introuvable. 2 describes certain characteristics of each certificate class. Table headings are explained below.

Overview of identity

confirmation

CA private key protection

Applicant private key protection

Applications implemented or contemplated by

users

Class 1 Automated, unambiguous name and email address search

CA: trustworthy hardware (HSM)

Encryption software (PIN protection) recommended but not required.

Web browsing and email operations.

Class 2 � Unambiguous name, technical contact, and email address search; � Confirmation of registration information; � Physical address check.


Encryption software (PIN protection)

Personal email, internal/external company email, online subscription, and password replacement.

Class 3 � Unambiguous search for names, contacts, physical addresses and email documents or business records for organizations, SIREN no, company registration certificate, etc. � Confirmation of registration information; � Physical address check.


� Encryption software (PIN protection) required; � Cryptographic hardware recommended but not required.

E-banking, company databases, home banking, online subscription services, content integrity services, e-commerce servers, RA authentication and strong cryptography for certain servers, electronic signature, etc.

Table 2 – Certificate properties affecting trust

Each certificate class is characterized by a different level of the following properties: � Identity confirmation � CA private key protection (and guarantee of appropriate use). � Applicant private key protector and operational control.



- 21 -

Even though the certificates (and KEYNECTIS' related products and services) have many other properties, those listed in Table 2 provide a framework for distinguishing the security level of each one. Each property is explained below. 2.4.1 Confirmation of subscriber identity This refers to various measures taken by the CA to validate the certificate applicants’ identity and confirm the information provided by them during the application process. The type and scope of confirmation depends on the certificate class, type of applicant, and other factors. 2.4.2 CA private key protection The private key of each CA is protected against violations by trustworthy hardware. 2.4.3 Certificate applicant private key protection The secrecy of the certificate applicant’s private key must be protected through encryption software or cryptographic hardware (for example, a smart card) as specified in this CPS.

CAs never generate nor hold the private keys of certificate applicants. CAs cannot guarantee or enforce any particular private key protection needs of any certificate applicant.

2.4.4 Operational controls

Operational controls refer to the organization, human resources, and other management controls implemented for each certificate class. These controls involve individuals authorized to receive a certificate, training requirements for CA personnel, policies establishing the breakdown of duties within the CA, documentation needs, and mandatory procedures and audits. Most of these controls are explained in this CPS.

2.5 Extensions and Naming

2.5.1 Extension mechanisms and authentication framework

Certification services facilitate the use of X.509 v3 certificates. X.509 v3 certificates expand the capabilities of v1 and v2 and allow you to add extensions to a certificate. This capability, a standard component of KEYNECTIS certification services, rounds out the standard authentication services model.

2.5.2 Standard and specific extensions

The X.509 “Amendment 1 to ISO/IEC 9594-8:1995” defines a series of extensions. These extensions provide management and administration controls that are useful for large-scale and multipurpose authentication. KEYNECTIS certification services use several of these controls for purposes identified in X.509. (Comment: user software compliant with X.509 is assumed to apply the validation rules of the CPS.

In addition, the CPS enables users to define additional “private” extensions for purposes or methods specific to their application environment. The definition for service-based extensions to and practices for processing this information during certification application, approval, and issuance, are specified in the KEYNECTIS security procedures as well as publicly available documents from the organizations sponsoring these extensions. 2.5.3 Identification and criticality of special extensions



- 22 -

The function of each extension is indicated by a standard “object identifier” value. In addition, each certificate extension is assigned a criticality value of true or false. This value is determined by the CA, possibly based on information provided by the applicant on the certificate application. This value must comply with certain constraints imposed by the organization responsible for the extension definition. The presence of a “true” criticality value in a given extension requires anyone validating the certificate to consider it invalid if they do not know the purpose and requirements for any specific extension with a criticality value of true. If this value is false, these individuals shall process the extension in compliance with the applicable definition during validation or else ignore the extension.

2.5.4 Certificate chains and types of CAs

KEYNECTIS electronic certification services use chains of certificates. Each CA of a KEYNECTIS certificate chain performs particular procedures based on its assigned role in the KEYNECTIS PKI. One CA may have two different roles. � “Root” certification authority (CA) and, � CA for another CA. When a CA is its own Root Authority, its self-signed public key conforms to the X.509 format. The CA is trustworthy (based on authentication mechanisms) without recourse to additional validations during verification of digital signatures.

2.5.5 End user certificate extensions

CAs for end users may issue certificates containing extensions defined in the document “X.509 Amendment 1 to ISO/IEC 9594-8:1995”. ISO extensions used in the KEYNECTIS certification services, whose content is assigned by the CA concerned, are currently limited to the following: � Basic constraints � Key usage � Extended key uses � Certificate policy � AKI (authority key identifier / SKI (subject key identifier)

The use of these extensions controls the process of issuing and validating certificates. Table 3 specifies the minimum number of extensions present in each certificate.

2.5.6 ISO basic constraint extensions

The basic constraints extension is used to limit the role and position of a CA or end user certificate in a chain of certificates. For example, certificates issued to CAs and subordinate CAs contain a basic constraint extension that identifies them as CA certificates. End user certificates have an extension that constrains the certificate from being a CA certificate.

2.5.7 ISO “Key Usage" and "Extended Key Usage” extensions

The “Key Usage” extension limits the technical purposes for which a public key listed in a valid certificate can be used within the KEYNECTIS electronic certification services. CA certificates may contain a key usage extension that restricts the use of the key to signing certificates, certificate revocation lists, and other information.

2.5.8 ISO “Certificate Policy” extension

The “Certificate Policy” extension limits a certificate to the practices required by (or indicated for) trusted parties. The “Certificate Policy”, such as the one implemented in the certification services, refers its users to the CPS and indicates appropriate usages.



- 23 -

Extensions and enhanced naming are either fully provided in a certificate or partially provided with the remainder in an external document included by reference in the certificate.

Information contained in the”Organizational Unit” field is also found in the certificatePolicy extension, when included in the certificate. This CPS constitutes a “certificate policy” according to the terms in the “X.509 Amendment 1 to ISO/IEC 9594-8:1995”. A CA, acting as an authority authorized to form policies, assigns to the CPS an object identifier value (OID) that is present in the certificatePolicy extension.

2.5.8.1 Pointers to the CPS

User-readable text and computer pointers (URL-based or other identifiers and mechanisms) are used so that certificate users can easily locate and access the CPS and other pertinent information.

2.5.8.2 Warnings, liability limitations, and warrant disclaimers

Each certificate may contain a brief statement explaining applicable liability limitations and warrant disclaimers, with a pointer to the full text of these warnings, disclaimers, and limitations in the CPS. This information may also be displayed through the certificate viewing function, possibly through a hypertext link to a message accessible by users or agents, instead of being included in the certificate. The method used to share information (to be presented to users) is a CA qualifier to a certificate policy registered with KEYNECTIS (using a standard v3 extension). Erreur ! Source du renvoi introuvable.describes the content of certificate extensions, as well as the qualifier items from the extension to the Keyncectis CPS certificate policy.

Name/Certificate extension fields Purpose and description English Text

General CA extension Basic constraints Key use

See CPS See CPS

Non-critical � CA=TRUE Non-critical � KEY CERTSIGN (bits 5 set) � CRLSIGN (bits 6 set)

General applicant extension Basic constraints CertificatePolicy

See CPS See CPS

Non-critical � CA=TRUE Non-critical See CPS

Table 3 – KEYNECTIS certificate extensions

This certificate refers to the KEYNECTIS CPS. Use of this certificate is governed by this CPS. The CPS disclaims and limits certain liabilities including consequential and punitive damages. The CPS also includes caps on liability related to this certificate. The CPS and this certificate are copyrighted: Copyright © KEYNECTIS. All rights reserved.

2.6 PKI Hierarchy

KEYNECTIS electronic certification services are implemented within a hierarchy of PKI entities comprised of the following CAs:



- 24 -

� Root Certification Authority (RCA) � Several certification authorities (CA) issuing CA certificates and end user (EU) certificates. � Several certification authorities (CA) issuing certificates of end user (EU) certificates.

Within the PKI-entity hierarchy, CAs are related through the “subordinate to” relationship, which indicates that one CA is acting on behalf of another. A CA shall issue CA certificates using general or enhanced identification procedures (for CA validation), based on the certificate class of the end user certificates issued by the last CA in the hierarchy. In addition, the CA may delegate certain registration functions to one or more RAs. The KEYNECTIS PKI also includes the naming authority and KEYNECTIS reference archives. Figure 3 is an overview of the KEYNECTIS PKI (to avoid overloading the diagram, not all CAs and RAs are included).

Figure 3 – KEYNECTIS PKI basic hierarchy

2.6.1 Root Certification Authorities (RCA)

RCAs are the highest-level active certification entities in the KEYNECTIS certification services. RCAs issue, suspend, and revoke the certificates of every CA in the KEYNECTIS certification services. Each RCA is owned and managed by the KEYNECTIS Corporation. The initial key size of each RCA is 2048 bits. Trustworthy hardware (FIPS 140-1 compliant minimum Level 2) is used to create, protect, and destroy the private key of each RCA. The purposes, assurances, services and obligations of each RCA, as well as the rights and responsibilities of its applicants, recipients, trustworthy parties, and CAs within the certification chain, are presented in this CPS. Cross-certification between KEYNECTIS RCAs and non-KEYNECTIS PKI type entities is permitted if: � KEYNECTIS decides that the non-KEYNECTIS entity provides a relatively comparable function and trust/assurance level. � Cross-certification may improve the value of KEYNECTIS certificates to subscribers. � Both entities have entered into an ad hoc KEYNECTIS cross-certification agreement. � KEYNECTIS and the non-KEYNECTIS entity issued mutual certificates. � Each party accepted this certificate and, � The parties agreed upon revocation and filing procedures.

2.6.2 Certification Authority (CA)

Class 1 Root CA

CA 1

Class 2 Root CA

CA 2

CA EU 1 CA EU 2

Class 2 Root CA

CA 3

CA EU 1 CA EU 2 CA EU … CA EU…



- 25 -

Each CA is subordinate to a superior CA and operates in accordance with this CPS and any other particular requirement imposed by that CA (within the limits of this CPS). Class 1-3 CAs may issue, manage, and revoke end-user certificates, as provided by this CPS. The initial key size of each CA is 2048 bits. Trusted hardware (FIPS 140-1-compliant minimum Level 2) is used to create, protect, and destroy the private keys of CAs. CAs are usually owned and operated by KEYNECTIS.

2.6.3 Registration authorities (RA)

Registration authorities are entities that evaluate, and either approve or reject certificate applications. RAs also have the authority to approve certificate revocation. RAs may use RA Administrators to perform RA functions. RAs operate (within the framework of the CPS) on behalf of and under the exclusive authority of a single CA (RCA or CA that actually issues the certificates). An RA may also have several delegated registries. Without otherwise limiting their authority, RAs may rely on the following items to confirm information about the certificate applicant: � Notorial acts that appear to be completed in good order. � Forms of identification � Databases with reputable information, etc. Requirements imposed on RA administrators are described in this CPS.

2.6.4 Naming authority

A naming authority coordinates the assignment of relative distinguished names (RDN) for all KEYNECTIS RAs. The KEYNECTIS naming authority may also formulate naming conventions for all subject names in the KEYNECTIS reference archives, which may vary by certificate class and by RA. Name agreements may also vary between issuance and re-issuance. Non-KEYNECTIS RAs must either use the KEYNECTIS naming authority, or establish or otherwise use a naming authority whose procedures do not conflict with those of the KEYNECTIS naming authority and not register RDNs by the KEYNECTIS naming authority.



- 26 -

2.6.5 KEYNECTIS reference archives

KEYNECTIS reference archives are a publicly available collection of databases used to store and retrieve certificates and certificate-related information. All CAs must use the KEYNECTIS reference archives as the primary, official archive base for all KEYNECTIS certification service needs. KEYNECTIS reference archive content includes, but is not limited to: certificates, CRLs and other revocation information, current and prior versions of the KEYNECTIS CPS, as well as other information prescribed by KEYNECTIS. KEYNECTIS reference archives will not modify any certificates or certificate revocation notices it receives in proper form from a CA, and it will accurately reflect the content of these items.



- 27 -

3 PREREQUISITES FOR CERTIFICATION OPERATIONS

This chapter explains the basic electronic certification services and controls for trustworthy operations. It includes the operating requirements for KEYNECTIS certification services, including record keeping, auditing, and personnel requirements. It also explains the obligations of a CA upon the termination or suspension of its activities.

3.1 Prerequisites for Approval as a Non-KEYNECTIS CA within the Electronic Certification Services

KEYNECTIS certification services are based on CAs operated by KEYNECTIS. At KEYNECTIS’ discretion, other trustworthy entities may participate in KEYNECTIS certification services as non-KEYNECTIS CAs. To achieve a uniform level of trust throughout all of the certification services, non-KEYNECTIS CAs agree to comply with the control requirements of this CPS.

3.1.1 Non-KEYNECTIS CA certificate application

Any non-KEYNECTIS entity that would like to act as a CA shall complete a non-KEYNECTIS CA certificate application that corresponds to the certificate class it intends to issue. The application must include: � The name, address (street, number, etc.), telephone and fax numbers, the requestor's email address(es), their administrators and authorized representatives; � The applicant’s proposed distinguished name; � The applicant’s public key(s) and procedures for generating, storing, using and destroying its corresponding private key(s). � A description of any past or present event (for example, insolvency) that could materially affect the applicant’s ability to act as a CA under the terms of the CPS. � A reference (with confirmation) of the acceptance of this CPS by the applicant and the applicant’s procedures for distributing copies of this CPS. � A statement about the purpose and scope of certificate technology, management, or operations to be outsourced. � Certified or acknowledged copies of the applicant’s business registration documents (example from the trade register, etc.). � A declaration from the applicant that to its best knowledge it can and will comply with this CPS. � Any other information required by KEYNECTIS (such as the Certification Policy and Certification Practices Statement).

Failure to provide this information required in the application will delay or preclude application processing.

3.1.2 Submission of a non-KEYNECTIS CA application to KEYNECTIS

Completed, certified Non-KEYNECTIS CA applications (with all of the requested additional information) shall be submitted to KEYNECTIS.

3.1.3 Authorization to initiate CA activities

Upon completion of its examination of a CA application and any other inquiries deemed necessary, the appropriate KEYNECTIS CA shall approve or reject the applicant’s participation as a CA. The KEYNECTIS CA shall make a reasonable effort to approve or reject applications within three to six weeks.

A KEYNECTIS CA will indicate approval of a CA application by: � Cosigning a KEYNECTIS CA - CA contract and



- 28 -

� Issuing a certificate for the applicant's use. The decision to approve or deny a CA application shall be the sole responsibility of the appropriate KEYNECTIS CA, which further reserves the right to withdraw approval for the subordinate CA at any time. Any violation or failure to observe CPS rules is a valid reason for cancellation.

3.2 KEYNECTIS’ Right to Investigate Violations

KEYNECTIS may (but is not legally obligated) to investigate any violation within the limits permitted by law. By submitting a CA application or certificate application, all applicants accept the undertaking and scope of such investigations and agree to help in determining all facts, circumstances, and other pertinent information that KEYNECTIS deems appropriate and consistent with the CPS, provided that these investigations respect all privacy and data protection laws. The investigation of a CA may include- but is not necessarily limited to - interviews, review of applicable books, documents and procedures, and inspection of the facilities concerned. An investigation of subscribers or certificate applicants may include but are not necessarily limited to interviews and requests for examination of documents.

3.3 Compliance with this CPS

CAs, RAs and the KEYNECTIS reference archive shall comply with this CPS when providing their respective services.

3.4 Trustworthy Systems

CAs, RAs, and KEYNECTIS reference archives will use only trusted systems in providing their respective services.

3.5 Financial Responsibility

CAs shall have sufficient financial resources to conduct their operations and perform their duties. They must be reasonably able to bear the risk of liability to subscribers and recipients of certificates and other individuals who may rely on the certificates and time stamps they issue. CAs shall also maintain insurance coverage for errors and omissions.

3.6 Records Documenting Compliance

CAs shall maintain records in a trustworthy manner, and when requested, provide KEYNECTIS with certain documents such as: � Documents proving compliance with CPS rules � Documentation of actions and information that is relevant to each certificate application and to the creation, issuance, use, revocation, expiration, and renewal of each issued certificate. These records shall contain all information in the CA’s possession regarding: � The identity of the subscriber named in each certificate (except for Class 1 Certificates for which only the subscriber’s unambiguous name is maintained). � The identity of the individuals requesting certificate revocation (except for Class 1 Certificates, for which only the subscriber’s unambiguous name is maintained). � Other facts represented in the certificate � Time stamps � Certain foreseeable material facts related to certificate issuance.



- 29 -

Documents may be kept in the form of computer-based messages or paper documents, provided that their indexing, storage, preservation, and reproduction are accurate and complete. CAs may ask a subscriber or its agent to provide documents that will enable the CA to comply with this chapter.

3.7 Time Stamping

Time stamping is intended to improve the integrity of KEYNECTIS’ electronic certification services and the trustworthiness of certificates. It also assists in the nonrepudiation of digitally signed messages. Time stamping creates a notation that shows (at least) the correct date and time of an action (explicitly or implicitly), as well as the identity of the person or system that created the notation. All time stamps adopt GMT time (Greenwich Meridian Time) and adopt the UTC (Universal Time Convention). For this CPS' purposes, any year written between 00 and 60 means 2000-2069, and any year between 70 - 99 means 1970-1999. The appropriate CA shall time stamp the following data either directly on the information, or on a trustworthy audit report: � Certificates � CRL and other suspension and revocation database information. � Each version of the CPS � Customer service messages � Other information, according to the provisions of this CPS.

Comment: Cryptographic time stamping will be implemented incrementally by the CA for all relevant messages.

3.8 Document Retention Schedule

CAs shall save all Class 2 records and related documents in a trustworthy manner for at least five (5) months and Class 3 documents for at least thirty (3) years after the date a certificate is revoked or expires. These documents shall be retained either electronically or on paper.

3.9 Audit

CAs shall set up and maintain trustworthy systems for keeping an audit log of all material events, such as key generation, certificate application, validation, and revocation. A licensed expert specializing in computer security or an accredited computer security professional shall inspect the operations of each CA and corresponding RAs at least once a year, at the expense of the inspected entity, in order to evaluate its compliance with this CPS and other applicable agreements, guidelines, procedures, and standards. Non-KEYNECTIS CAs shall promptly provide KEYNECTIS with the resulting audit reports. KEYNECTIS’ receipt of third-party audit reports does not constitute acceptance or approval of the content, conclusions, or recommendations of these reports on the part of KEYNECTIS. KEYNECTIS may review these reports to protect its electronic certification services. KEYNECTIS is not the author of such audit reports and is therefore not responsible for their content. KEYNECTIS does not express any opinion of these audit reports and shall not be held responsible for any damages resulting from KEYNECTIS reliance on these audit reports.



- 30 -

3.10 Emergency Planning and Disaster Recovery

CAs shall establish, document, and periodically test emergency and disaster recovery capabilities and procedures, in accordance with the CPS and KEYNECTIS security procedures.

3.11 Availability of CA certificates

CAs shall make copies of their own certificates (in other words, those in which CA is the subject) and revocation data (if needed) available to anyone who must and wishes to verify a digital signature that can be verified through such a certificate.

3.12 Publication by Certification Authorities

CAs must publish their certificates, revocation information and the CPS.

3.13 Confidential Information

The following information shall be considered received and generated confidentially by KEYNECTIS and the CAs concerned, and may not be disclosed except as provided below:

� CA application records, approved or disapproved � Subscriber agreements and certificate application documents (except for information placed in a certificate or reference archives as defined in this CPS). � Transaction records (full records and audit logs). � Certification services audit log records created or retained by KEYNECTIS or a CA � Certification services audit reports created by KEYNECTIS, a CA, the KEYNECTIS reference archive (to the extents to which these reports are maintained), or the respective auditors (internal or public). � Emergency planning and disaster recovery plans � Security measures that control the operation of CA hardware and software and the administration of certification services and designated enrollment services.

Neither CAs nor KEYNECTIS shall disclose or sell applicants’ names or other identification information, nor shall they share this information, except in accordance with this CPS. Note, however, that the KEYNECTIS reference archives shall contain certifications, revocations, and other data. Neither CAs nor KEYNECTIS shall disclose or be required to disclose any confidential information without a prior authentic and reasonably specific request from: � The individual for whom the CA or KEYNECTIS must maintain confidentiality � A person requesting confidential information (if not the same person) or if the information is required by court order. The CA or KEYNECTIS may ask the requesting person to pay a reasonable fee in order to obtain the desired information.

3.14 Personnel Management Procedures

CAs shall devise and follow personnel management procedures that provide reasonable assurance of the credibility and competence of their employees, and of the satisfactory performance of their duties. These practices shall conform to the CPS.



- 31 -

3.14.1 Trusted positions

All of a CA's employees, contractors, and consultants (collectively called "personnel") who have access to or control over cryptographic operations that may materially affect the CA’s issuance, use, or revocation of certificates, including access to restricted operations of the KEYNECTIS reference archives, shall be considered, for the purposes of this CPS, to be in a trusted position. These personnel include (but are not limited to) customer service personnel, system administration personnel, designated technical personnel, and managers who supervise the trustworthy system of the CA’s infrastructure.

3.14.2 Investigation and compliance

CAs shall conduct an initial investigation of all personnel who are candidates for trusted positions in order to determine their trustworthiness and competence as reasonably as possible. CAs shall conduct a periodic investigation of all personnel who occupy a trusted position to confirm their continued trustworthiness and competence, in accordance with KEYNECTIS’ employee practices or the equivalent.

3.14.3 Removal of individuals in trusted positions

Any individual who fails an initial or periodic investigation shall be removed from the trusted position. The removal of someone in a trusted position shall be left to the sole discretion of the CA concerned (or KEYNECTIS, in the case of KEYNECTIS personnel).

3.15 Accreditations

3.15.1 Approval of software and hardware devices

All software and hardware related to electronic certification services shall be approved by KEYNECTIS, an authorized KEYNECTIS consultant, or other recognized authorities (periodically designated by KEYNECTIS), based on need.

3.15.2 Personnel in trusted positions

Any individual in a trusted position shall be accredited by a recognized, external accreditation organization, as appropriate. This provision does not apply to members of the KEYNECTIS board of directors or CAs, unless they occupy an operational position within the electronic certification services.

3.15.3 Organizational good standing

A CA shall be in good standing with bodies and authorities whose rules and regulations materially affect CA trustworthiness in compliance with laws or contract. The CA shall be accredited, certified or licensed based on requirements.

3.16 CA Key Generation

CAs shall securely generate and protect their own private keys through a trustworthy system, and take the necessary precautions to prevent loss, disclosure, modification, or unauthorized use.



- 32 -

3.17 Secret Sharing

CAs shall use secret sharing using authorized secret share holders to improve the trustworthiness of their private key(s) and ensure their keys’ recovery, as shown in Table 4 – Distribution of secret shares – below:

Entity Secret share required to enable CA’s private key to sign end user certificates

Secret share needed to sign the CA certificate

Total secret shares distributed

Shares recovered from disaster

Needed Total

Class 1 KEYNECTIS CA (RCA)

N/A 3 5 3 5


N/A 3 5 3 5


N/A 3 5 3 5

Class 1-3 Non-KEYNECTIS CA

3 3 5 3 5

Class 1-3 End User CA

3 N/A 5 3 5

Table 4 – Distribution of secret shares

3.17.1 Protection using cryptographic hardware

CAs must use trustworthy hardware cryptographic modules for all operations requiring the use of their private key. The procedure for creating private keys may be published in the KEYNECTIS reference archives.

3.17.2 RA representation

CAs who intend to distribute the secret shares of their private key(s) declare and certify to all entities concerned that they legally possess private keys intended for sharing and that they are authorized to transfer them to authorized secret share holders in compliance with the CPS.

3.17.3 Acceptance of secret shares by secret share holders

In order for a secret share holder to accept a secret share, a majority of the designated secret share holders must have personally observed the creation, re-creation, and distribution of the share and its subsequent chain of custody. Each secret share holder must receive the secret share on a physical medium; for example, cryptomaterial approved by KEYNECTIS Once the secret share holder is convinced that the secret share delivered is complete, he or she shall acknowledge acceptance by signing and returning to the CA concerned a secret share acceptance form provided by that CA.

3.17.4 Protecting the secret share

The secret share holder shall use trustworthy systems to protect its secret share from violations. Unless stated otherwise in this CPS, the secret share holder agrees that he or she shall not:



- 33 -

� Disclose, publish, copy, share with third parties, or participate in any unauthorized use the secret share; � Reveal (explicitly or implicitly) to anyone outside of the company that he or she, or anyone else, is a secret share holder; � Store the secret share in a location where it cannot be recovered in the event that the secret share holder becomes incapacitated or unavailable (unless the secret share is being used for other purposes).

3.17.5 Availability and Release of Secret Shares

The secret share holder shall make the secret share available to authorized entities (list included in the secret share acceptance form) only after obtaining proper authorization through an authenticated record (see next paragraph). In case of an accident (declared by the secret share issuer), the secret share holder shall contact a recovery site in accordance with the instructions from the secret share issuer. Before reporting to an emergency or recovery site and releasing the secret share, the secret share holder shall authenticate the declaration of the secret share issuer according to the instructions on the secret share acceptance form (unless prohibited by law or legal process; for example, in the case of a criminal investigation). This procedure shall include the use of a Challenge Phrase (given by the secret share issuer to the secret share holder) to ensure that the secret share holder is not tricked into going to the wrong site, thus preventing the secret share issuer from recovering. On the recovery site, the secret share holder shall deliver (in person) the secret share in order to participate in the recovery process after the accident. The secret share holder may rely on any instruction, document, message, record, instrument, or signature he or she feels with reasonable certainty to be authentic, provided that he or she authenticates the secret share issuer's declaration in accordance with the preceding paragraph. The secret share issuer shall provide the secret share holder with a sample of all of the signatures used to authenticate the secret share issuer’s instructions.

3.17.6 Records to be kept by secret share issuers and holders

Secret share issuers and holders shall keep records of their secret-share related activities. The secret share holder shall provide information about secret share status to the secret share issuer or designated representative upon authenticated request.

3.17.7 Secret share holder liability

The secret share holder shall fulfill his or her obligations under this CPS and must act reasonably and carefully in all areas. The secret share holder shall notify the secret share issuer of any loss, theft, improper disclosure, or violation of the secret share immediately upon knowledge. The secret share holder is not responsible for failure to fulfill his or her obligations for causes reasonably beyond his or her control. However, he or she shall be liable for improper disclosure of secret shares or failure to notify the secret share issuer of improper disclosure or violation through his or her fault, including negligence.



- 34 -

3.17.8 Indemnity by secret share issuer

The secret share issuer agrees to indemnify and hold harmless the secret share holder from all claims, legal action, damage, judgments, arbitration fees, expenses, costs, attorney fees, and any other liability incurred by the secret share holder if these liabilities were not caused either directly or indirectly through the fault, negligence, or carelessness of the secret share holder.

3.18 Compliance with Operational Period Requirements

The CA applicant shall ensure that the validity period for the CA certificate complies with restrictions imposed on that CA.

3.19 Security Requirements

3.19.1 Communications security

All communications pursuant to this CPS between KEYNECTIS and other parties involved with electronic certification services must use an application that provides the appropriate security mechanisms with measured risk. Without limiting their scope, computer notices, the acknowledgments of receipt for these notices, and any other communication affecting the security of the certification services shall also be protected in the appropriate manner.

3.19.2 Facilities security

CAs shall use trustworthy facilities that substantially comply with KEYNECTIS security procedures or the equivalent standards.

3.20 Requirements for RA Administrators

RA Administrators occupy trusted positions. The minimum requirements for an RA Administrator depends on the class and affiliation of the issued certificate, and the applications that an Administrator is authorized to approve.

3.21 Termination or Cessation of CA Activities

The following obligations are intended to reduce the impact of a discontinued service by providing timely notice, transfer of responsibilities to succeeding entities, record maintenance and certain compensations.

3.21.1 Requirements prior to cessation

Before ceasing CA activities, CAs must: � Notify their superior CA of their intention to stop acting as a CA. This notification must be made at least ninety (90) days before discontinuance. The superior CA may ask for additional statements in order to verify compliance with this provision. � Provide the subscriber of each unrevoked or unexpired certificate issued by them with ninety (90) days notice of their intention to discontinue their RA activities. � Revoke all of the certificates that remain unrevoked or unexpired at the end of the ninety-day period (90), regardless of whether the subscriber requested revocation or not. � Notify each affected subscriber of the revocation.



- 35 -

� Do what they are reasonably able to ensure that discontinuing their certification services will cause minimum disruption for subscribers and individuals who must verify digital signatures by reference to the public key contained in outstanding certificates. � Take reasonable steps to retain their records. � Pay reasonable restitution (without exceeding the certificate’s purchase price) to subscribers for revoking their unexpired certificates.

3.21.2 Reissuance of certificates by a CA successor

In order to provide uninterrupted CA services to certificate applicants, CAs that are being discontinued must arrange with another similar authority, subject to the other CA's written agreement, the re-issuance of their outstanding subscriber certificates. By reissuing a CA certificate, the successor CA assumes the rights and restrictions of the discontinued CA, and to the extent agreed in writing between the two authorities, also assumes the obligations and responsibilities related to unexpired certificates. Unless otherwise stipulated between the discontinued CA and the applicant, and under written agreement from the successor CA, the CPS will remain in effect under the successor CA as it did under the original CA. The requirements stated here may vary from one contract to another, provided that the changes only affect the contracting parties.



- 36 -

4 CERTIFICATE APPLICATION PROCEDURES

This chapter describes the certificate application process. It explains the requirements for generating and protecting key pairs and lists the information that is required for each certificate class.

Anyone other than a CA who would like a certificate shall simultaneously complete the following general procedures for each certificate application: � Generate a key pair and prove to the CA that this pair works; � Protect the private key (of this key pair) from violations; � Propose a distinguished name; � Submit the certificate request (and the subscription agreement) with the public key from the key pair to the appropriate CA.

4.1 Key Generation and Protection

The following procedures apply to all entities generating keys within the framework of this CPS.

4.1.1 Holder exclusivity: controlling access to private keys

Unless otherwise authorized in this CPS, each certificate applicant shall securely generate their own private key using a trustworthy system, and take the necessary precautions to prevent its violation, loss, disclosure, modification, or unauthorized use. It is understood that certificate applicants will generally use non-KEYNECTIS product to protect their keys properly.

Each certificate applicant acknowledges that he/she is exclusively responsible for protecting his/her private key(s) against violation, loss, disclosure, modification, and unauthorized use.

Users and CAs agree not to monitor, interfere with, or reverse the technical implementation of the electronic certification services unless given explicit permission from the CPS or prior written agreement from KEYNECTIS.

4.1.2 Delegation of private key responsibilities

Delegation, if necessary, does not relieve the delegators of their responsibilities and obligations concerning the generation, use, retention, or destruction of their private key(s).



- 37 -

4.2 Certificate Application Content and Communication

Information that is not included in the certificate shall be kept confidential by the CA. Some information contained in the Class 2 Certificates for individuals affiliated with RAs is not required during application, but instead is available through these RAs.

Certificate Class Required certificate application information

Class 1 Individuals: � Common name (or alias) � Subject public key � Email address � Signed subscription agreement � Challenge Phrase (for later authentication of the requestor by the CA) � Other information, based on KEYNECTIS requirements Class 1 certificates are issued to individuals only.

Class 2 Individuals: � Proper name (consisting of common name) � Proposed distinguished name � Street, City, Zip Code, Country � Telephone number � Email address � Public key � Challenge Phrase (for later authentication of the requestor by the RA) � Signed subscription agreement Organizations: � Domain name � Organization � Department (if applicable) � Technical and/or administrative contact � Street, Location, Zip Code, Country � Proof of right to use name (via a third-party database check and out-of-band verification) � Proof of corporate form (articles of association, company registration certificate, SIREN no., etc.) � Other information, based on CA requirements

Class 3 Individuals: Required information: same as Class 2, plus: � Subscription agreement � Maiden name � Social security number � Birth date � Authorized agents/representatives

Organizations: � Domain name � Organization � Department (if applicable) � Technical and/or administrative contact � Street, Location, Zip Code, Country � Proof of right to use name (via a third-party database check and out-of-band verification) � Proof of corporate form (articles of association, company registration certificate, SIREN no., etc.) � Other information, based on CA requirements

Table 5 – Required certificate application information



- 38 -

5 CERTIFICATE APPLICATION VALIDATION

This chapter presents the requirements for validation of certificate applications to be performed by the appropriate CA or an authorized registration authority. It also explains the procedures for applications who fail validation. It also defines verification requirements concerning power, representation, and mandate.

5.1 Validation Requirements for Certificate Applications

Upon receipt of certificate applications, CAs shall perform all required validations before issuing certificates. The CA shall establish that: � The certificate applicant is the person identified in the application (in agreement with and within the limits of the certificate class description). � The certificate applicant has the right to hold the private key corresponding to the public key listed on the certificate (this obligation may be satisfied by an ad hoc statement from the applicant). � The information to be listed on the certificate (except for unverified applicant information) is correct; � Any organization that requests a certificate listing the public key of the certificate applicant (permitted for Class 2 and 3 certificates) are duly authorized to make this request.

Once the certificate is issued, the CA is no longer obligated to monitor or check the accuracy of certificate information, unless the CA is notified of the certificate’s violation, in accordance with the CPS. Erreur ! Source du renvoi introuvable. 6 highlights some of the differences between the validation requirements according to certificate class. KEYNECTIS reserves the right to update its validation procedures in order to improve the validation process. Updated validation procedures may be obtained from KEYNECTIS, 30 rue du Château des Rentiers 75647 Paris Cedex 13, France.



- 39 -

Validation Requirements Class 1 Class 2 Class 3

Personal presence No No Optional

Personal investigation (for individuals)

No No Yes

Third-party automatic confirmation of personal information

No Yes Yes

Third-party confirmation of companies

N/A Yes Yes

Postal address confirmation

N/A Yes Yes

InterNIC domain name confirmation

N/A Yes Yes

Export controls confirmation N/A Yes Yes

Table 6 – Certificate application validation requirements

5.1.1 Personal presence

In order to create an effective connection between applicants and their public key, and to facilitate confirmation of their identity, individuals applying for Class 3 certificates must appear personally (face-to-face) before a trusted entity (such as an RA). The criteria for personal presence varies depending on the class and type of certificate, including but not limited to required credentials.

5.1.2 Third-party confirmation of personal information

When necessary, a third party confirms personal information provided by the certificate applicant by comparing it to its (the third-party's) database. Confirmation is successful if the certificate applicant’s data is consistent with the information contained in the database. This determination is made through KEYNECTIS' correspondence algorithm or another acceptable determination procedure. An online investigation may provide some assurance of identity by comparing information about the certificate applicant’s identity with public databases. These databases may also confirm the applicant’s address. The scope of online investigations is sometimes subject to each country's data protection and privacy laws. Depending on the criteria imposed on the certificate applicant and the certificate class to be issued, special procedures may also be implemented by a CA.



- 40 -

5.1.3 Third-party confirmation of company information

Where required, the third-party confirms the company's name, address, and other contact information by comparing it with their database and consulting the appropriate official organizations. Confirmation of information about companies and banks require certain customized (and possible localized) procedures focusing on legal criteria (such as proof of business registration). The third-party also provides telephone numbers used for out of band communications with the company to confirm certain information (for example, to confirm an agent’s position in the company or that the person listed on the application is indeed the applicant). If the database does not contain all of the information required, the third-party may conduct an investigation upon request by the CA, or the certificate applicant may be asked to provide additional information and proof.

5.1.4 Postal address confirmation

Once Class 2 and 3 certificates are issued, the CA must send a confirmation letter (by mail with acknowledgement of receipt) to the postal address indicated on the certificate application and confirmed through third-party databases. This confirmation procedure provides additional proof that the applicant is who he or she claims to be and that the address listed on the certificate is correct. The confirmation letter contains a personal identification code (Personal Identification Number - PIN), which is provided to improve the authentication of the applicant. The letter instructs the recipient to request cancellation of the subscription process and revocation of the certificate if the request was made by an imposter. This cancellation procedure can only be carried out during the certificate’s provisional period, and is separate from normal revocation procedures. If a revocation request is not made during this period, the certificate shall become normal thereafter.

5.1.5 InterNIC domain name and serial number assignment

The naming authority used by the CA and KEYNECTIS is solely responsible for assigning relative distinguished names (RDN) and certificate serial numbers appearing on the certificates that it issues. The CA shall use the InterNIC to resolve any RDN conflicts.

5.1.6 Export controls confirmation

In addition to other verifications performed for Class 3 certificates, KEYNECTIS shall perform the following checks prior to issuing export control certificates for installation on a server. KEYNECTIS shall require the certificate applicant to identify the country in which the server will be installed. This information provided by the applicant shall be a guarantee that the server shall be installed in the country indicated; If the certificate applicant guarantees that the server shall be installed in France, KEYNECTIS shall confirm that the “Country” field on the certificate applications contains the “FR” value (ISO standard). KEYNECTIS shall confirm that information obtained from a third-party database indicates that the entity indicated in the "Contact Information" field is located in France. KEYNECTIS shall verify that the activity code contained on the certificate application identifies the certificate applicant as a bank, financial institution, insurance company, or medical/health organization. If this is not the case, the certificate applicant shall provide the credentials authorizing it to perform the activities of a bank, financial institution, financial company, or medical/health organization. Approval of Class 1 to 3 certificate requests.

5.2 Initial Registration



- 41 -

5.2.1 Name agreement The subscriber’s name appears in the certificate’s “Subject” field, under the CN ("Common Name") section. This mention is required. For individual certificates, it is comprised of the usual first name and last name. This name is that of the subscriber as it appears in Civil Status documents. 5.2.2 Need for names to be meaningful Names used in the certificate must have an association with the entity (person or object) for which they are used. Information in the “Subject” field of the certificate is meaningful: � Subscriber's name (CN section) � Subscriber’s email � Corporate name of the organization represented by the subscriber, as it appears on the company registration certificate. � The SIREN number of the organization represented by the subscriber, as it appears in the company registration certificate. � The name of the territorial division in which the headquarters for the organization represented by the subscriber is located, as it appears in the company registration certificate. � The country in which the headquarters of the organization represented by the subscriber is located, as it appears in the company registration certificate and created according to the international naming agreement. If the client changes any of the information contained in the "subject" field, he/she must inform the CA. The CA will then verify the new identity. Based on the changes made, the subscriber may have been asked to have his or her public key re-certified. 5.2.3 Rules for interpreting various name forms There is to be no special interpretation of the information contained in certificates' "Subject" field. 5.2.4 Uniqueness of name All of the SSL certificates issued by the CA have a unique identity. The RA ensures this uniqueness through the registration process. Any technical contact that requires an SSL certificate from the CA must demonstrate that they have the right to use the name in question for identity. In case of a dispute concerning the use of a name for a certificate, the CA is responsible for resolving the dispute in question. The uniqueness of a user certificate is established through a serial number within the Certificate Authority. The CA shall ensure that the "Subject" field also has a unique character using the subscriber’s email, with the exception of certificate renewal or the subject field is reused. 5.2.5 Name claim dispute resolution procedure The CA will ensure that the names of its subscribers are unique and will be responsible for resolving name claim disputes. 5.2.6 Authentication of organization and individual identity Organization identity Authentication is the sole responsibility of the Registration Authority.



- 42 -

The RA will confirm that the organization listed on the certificate application (domain name and SSL client) exists and that it has the exclusive right to use its name. This is done by cross-checking the information provided with the information gathered by the RA from the databases of the appropriate official organizations or authorities who can confirm the existence of the organization. The client’s technical contact will submit the certificate application form to the RA. Communications between the technical contact and the RA are protected to ensure the integrity and origin of the transmitted data. It is the RA’s responsibility to verify that the information contained in the certificate application is correct and confirm the organization and identity of the CT. The RA verifies everything needed for authentication through a procedure under the dual control of two people in trusted positions within the RA. The RA records all of the information used to confirm the client’s identity as it is listed on the certificate application, and as applicable, any special attribute, including any reference numbers contained in the documentation used for verifications, and any validity limitations. Individual identification The RA confirms during telephone interviews conducted at his/her initiative that the identity of technical contacts listed on the certificate applications is correct. During these interviews, various client information is verified. These verifications include confirmation of secret information sent by the client with the certificate application. In addition, the RA records the steps taken to issue each certificate. Validation of a legal representative A certificate application containing either an explicit or implicit affiliation with an organization is only issued after it has been confirmed that the technical contact has the authorization to act on behalf of this organization. If the certification of a technical contact requires authorization (confirmation of employment and authorization from the employer, existence and identity of the cited service, job assignment, etc.), the RA will authenticate this authorization and/or the legal representative. 5.2.7 Unverified Information Unverified information is not included in certificates. 5.2.8 Proof of private key possession At the time of the certificate application (standard PKCS#10), the Certification Authority requires applicants to provide proof of possession of the private key corresponding to the public key to be certified. Clients requesting an SSL certificate are to ensure that their key pair is generated so that the individual authorized to manage and use this key pair within their organization is the only person who has the private key corresponding to the public key to be certified.

5.3 Verifications for Key Renewals

Key pairs are periodically renewed in order to minimize cryptographic attacks. Thus, subscribers' signature key pairs are to be renewed every year. 5.3.1 Routine re-key or re-key after revocation Subscribers follow the usual process for requesting a certificate. If this occurs after a revocation, a new key pair is generated.



- 43 -

For SSL certificates, a re-key can only be requested by a client under the domain name for which the key was generated. The client is identified using the initial identity verification process. After an SSL certificate has been revoked for a reason other than a renewal or update, the client shall begin the initial registration procedure again to obtain a new certificate. If the SSL certificate was revoked due to a key compromise, the client must generate a new key pair before submitting a new certificate application. 5.3.2 Authentification of a revocation request A revocation request is authenticated by presenting a revocation code, indicated by the subscriber (or representative) at the time of the initial registration. The RA authenticates revocation requests. The verification procedure requires the same trust level as that of the initial registration in order to ensure that the certified client has really made a revocation request. Consequently, the RA shall confirm the identities of organizations and individuals requesting a revocation according to the applicable steps of the initial registration.

6 OPERATIONAL REQUIREMENTS

6.1 Application for a Certificate

6.1.1 Origin of the application A request for a user certificate must come from the head of the company or one of his/her duly mandated representatives. An SSL certificate application may only be sent to the RA through the client’s technical contact. 6.1.2 Registration procedure for user certificates The information to be provided is that which is sent in the certificate application file. A certificate application is done in three steps: � Step 1: The future subscriber sends the certificate application file; � Step 2: The documents that are received are checked, and the RA validates the applications � Step 3: The subscriber retrieves the certificate The RA shall process certificate applications only if they are in a certificate application file with all of the credentials described below: Document 1: Letter from the customer. This refers to the written (and signed) request from the head of the company or one of his/her representatives. This letter designates the individual to whom the certificate shall be issued. The letter must include the following: � Co-signature of acceptance from the recipient individual (future subscriber) � A revocation code (comprised of an alphanumeric chain) known by the company representative so that he/she can revoke the applicant’s certificate when the mandate is no longer in effect for whatever reason. � Email address of the customer if they would like to be informed of the certificate’s revocation. Document 2: Company registration certificate. The original certificate is to be provided, dated within less than three months, and must include the company's SIREN number and address.



- 44 -

Document 3: Two forms of identity for the authorized applicant. The authorized individual’s identity credentials must be certified copies in compliance with French regulations (original documents and their copies brought to City Hall or possibly to the police station, in order to establish the copies consistency with the originals). Standard certified copies of two out of the five possible forms of identity may be selected: registration certificate, standard certified photocopy of the national identity card, standard certified photocopy of a passport, or standard certified copy of a driver’s license. Document 4: Letter from the authorized applicant. The letter from the authorized individual must contain the following information: � Work phone number � Cell phone number (personal or business) � Personal code for withdrawal and revocation (hereinafter called the revocation and withdrawal code). � Email address � Declaration accepting the CA's general sales conditions and stated obligations. Document 5: Purchase order and payment method. This is from the company for the issuance of one or more certificates, and states the desired payment method (a completed and signed check is included if needed). The RA shall perform the following verifications: � Establish the identity of the future subscriber. � Confirm the right of the future subscriber to represent the company. � Confirm the relationship between the public key to be certified and the future subscriber. � Ensure that the future subscriber has been informed of the terms and conditions for certificate use. 6.1.3 Registration procedure for SSL certificates The following information must be included in the SSL certificate application: � Personal identification of the technical contact: Last name, first name, email, position, complete mailing address, telephone numbers (standard and direct line). � Organization identification: Name, first names and legal status, as well as any other information useful for registration (for example, company's SIREN no.). � PKCS#10-standard public key. � Domain name identification � Validity period for the SSL certificate � “Secret” customer information for the authentication process during identity verification (question/answer pair is provided). Before entering into a contract with a client, the CA informs the client of the contracts terms and conditions for using SSL certificates. For a better understanding of the role of customer service in the process of SSL certificate issuance, a flow diagram presents: � The different steps to be followed from registration to certificate issuance. � The players involved in each of the steps as well as their interactions. The validation process for an SSL certificate application has 2 different steps: � Authentication and � Verification In order to avoid errors and fraudulent issuance of SSL certificates, the process is based on the principle of “separate tasks”. The individual who authenticates may not verify and vice-versa. The process must work through a “buddy system” (person no. 1 / person no. 2) in which tasks shall be broken down as follows:



- 45 -

� Validation of purchase order receipt (person no.1) � Verification of the existence of the company and its contact information (person no.1). � Verification that the company owns the domain name (person no. 1). � Confirmation of the technical contact’s identity and his/her employment with the company listed on the application (person no.2) � Verification that the domain name administrator knows about the request and is in agreement (person no. 2). The authentication procedure determines the specific identity of an organization requesting an SSL certificate. Authentication is one of the two validation procedures steps; the other is verification. This “Authentication” step confirms that: � The organization indicated in the CSR exists and that it has the exclusive legal right to use its name. � The domain name on the application belongs to the organization and therefore, it may use it. � The technical contact is authorized to make a request because he/she belongs to the organization or a company authorized by the organization holding the domain name, which authorized the contact to make the request. For example: - A company with business ties (ex: Campanile, which is connected to the Accor Group, and Accor is listed on societe.com). - A Web host Reminder: Before generating its CSR (Certificate Signing Request) on its Web server, the client must fill in the Distinguished Name (DN) fields. If any of the information contained in these fields is incorrect, the client service will not be able to issue the SSL certificate for the client. The process must be started over by generating a new CSR. The Distinguished Name is comprised of the following elements:

� Organization O =

� We call “Organization” the entity for which the certificate is issued. The term

“Organization” is a generic name that covers the various statuses of entities

requesting SSL certificates (company, administration, local community,

association, etc.). The Organization’s name must be the same as the name associated with the SIREN number listed on the application.

� Common Name CN =

� The Common Name is the Fully Qualified Domain Name (FQDN). For

diagramming, it is the name of the site to be protected. The Common Name corresponds to everything following http:// - extension included.

� Example: In

http://www.certinomis.com, the Common Name is www.certinomis.com

In http://intranet.certinomis.com, the Common Name is intranet.certinomis.com

NB: For an intranet, the



- 46 -

FQDN may be comprised of one or more words (ex: intranet or intranet.masociete.com).

The Common Name may never be an IP address.

� Department OU = (for Organization Unit)

� This field is optional. It may be used for: - Differentiating divisions (or branches) within the Organization. - Differentiating machines when the same site is hosted on several devices (load sharing).

� City L= LOCALITY

� The client must fill in this field with the city where the headquarters of its organization are located.

� State/Department/Region ST = STATE

� The organization’s state, region, or department is indicated here. This information may be written in all letters or with the department’s number.

� Country C = COUNTRY

� The 2-letter country code must be entered here (ISO standard).

The SSL certificate application is validated following three consecutive verifications, which all yielded an acceptable response according to the rules. The first step involves administrative-type verifications followed by the second step of telephone verifications. 1. The name of the organization in the DN is similar (but not necessarily the exact same) to that of the domain’s owner (business relationship between 2 organizations, request made by a host on behalf of the organization). 2. The domain name’s owner did not bock the certificate application (within 24 hours) after being informed of an application submitted by the technical contact. 3. The organization specified in the certificate request (CSR) is associated with the owner of the domain name.

6.2 Verification of the Organization’s Name

For the organization’s name, the objective is to verify that: � The organization (company for which the SSL certificate is to be issued) actually exists (see its SIREN no. or DUNS for overseas companies). � The DN is associated with the organization. For French companies, the organization’s name can be verified on official sites such as www.dnb.com. If reference sites show during verification that the SIREN no. (or DUNS for companies outside of France) corresponds to the O (Organization) listed on the application, customer service may validate this step and continue verification. If the SIREN no. or DUNS does not correspond to the organization, customer service must ask the client to provide what is called the “Proof of Right Document” – an official document proving the existence of the company (ex: company registration certificate, official journal, etc.). It is imperative that this document include:



- 47 -

� The organization’s name � Its official brand (stamp, logo, etc.) � Its company number (or registration number) � The name of the department where the document was issued. � The signature of the agent from the department that issued the document. When the application is registered, notification will be automatically sent to the administrative contact of the domain name associated with the organization to inform them of the SSL certificate application. The administrative contact has 24 hours to “oppose” the issuance of the requested certificate. A copy of the notification is sent to customer service. In the case of an intranet, disregard this verification. If an application is rejected by the administrative contact of the domain name after the certificate is issued, the client service shall revoke said certificate. NB: In order to avoid arbitrarily revoking a certificate (at the request of a domain name’s administrative contact), customer service will make sure to confirm this request by calling the domain name's administrative contact who issued the refusal. If the contact confirms his/her revocation request and the reason for it, customer service will go ahead and revoke the SSL certificate that was already issued. The Common Name is the Fully Qualified Domain Name (FQDN). For diagramming, it is the name of the site to be protected. The Common Name corresponds to everything following http:// - extension included. The domain name is the name that the organization files with organizations such as AFNIC or INTERNIC. It is comprised of the name preceding the full extension of the extension itself. The domain name must always be registered in the name of the organization that makes the request. When filed, the domain name is “associated" with an owner that holds the user rights of this domain name. The domain name holder must be the same as the Organization – or be a part of its subsidiaries - for which the SSL certificate is issued.

To verify the registration of a domain name, customer service searches the WHOIS pages. If the domain name registered on reference sites corresponds to the name of the organization listed on the request (CSR), customer service validates this step and proceeds to telephone verifications. If the domain name is not registered under the name of the organization listed on the certificate request, or if the domain is registered under the name of an individual, customer service shall send additional documents to terminate the validation. There are 4 alternate procedures for a positive validation:

1. Legal relationship: Clients must prove that they have a legal relationship between their organization and the organization that appears in the domain name registration by providing an official document such as: a company registration certificate, articles of association, annual report, order published in the official bulletin, etc.).

2. Modification of the domain name registration: If the owner of the domain name does not correspond

to the organization. Clients must change domain name registration information and enter the name of their organization as the owner of the domain name.

3. Authorization for domain name use: Clients shall be authorized to submit a request in the name of

the domain name owner (ex: Internet provider and requestor organization relationship). Clients must prove this relationship by sending us a letter of Authorization of domain name use. This letter must be signed by the administrative contact listed in the domain name registration, authorizing the requesting organization to use the domain name specified in the application.



- 48 -

4. Restart the process: Clients submit a new application under the name of the organization that appears in the domain name registration.

The telephone verification procedure ensures the following points: � The contact indeed works for the company that made the request. � He/she knows about the request. � He/she confirms email addresses. � He/she is authorized to request a certificate, receive it, and install it. The telephone number may be verified on the following official sites or through telephone information. When the telephone number entered is a cell phone number: the technical contact must provide legal proof that there is an association between this individual and the company (telephone bill in the name of the Organization for example) During the telephone call, customer service asks a certain number of questions to validate the merits of the request made online: � If customer service obtains all of the answers, it validates this verification step and issues the certificate. � If some of the information is missing, customers must correct their request. 6.2.1 Records archiving Each certificate request record is archived by the CA's customer service from the date that the certificate is made available to the requestor. During this archiving period, the certificate application record is consultable upon request approved by the appropriate authorities or by the requestor.

6.3 Issuance and Distribution of a Certificate

6.3.1 Approval or rejection of a certificate application A user certificate applicant is deemed to have accepted the certificate once he/she has used it within an application. Furthermore, accepting a certificate means accepting the CP in reference (unique OID stored in the certificate). An SSL certificate request is approved by the RA after identity verification and telephone contact. If the verifications are positive and the full validation procedure is completed, the RA sends the certificate request to the CA, who confirms that all of the fields and extension fields of the certificate to be signed are filled out correctly. Information from the RA is sent to the CA by a secure line for protection. All of the certificate issuance operations are protected in a way to guarantee the integrity, confidentiality (if needed), and the origin of the data that is sent and processed. Once the client’s technical contact has downloaded the certificate, the CA deems the certificate to be accepted. 6.3.2 Client certificate issuance notification The CA notifies the client of the certificate issuance by sending an email. Notifications are also sent about the publication of an SSL certificate by the publication department. Before trusting an SSL certificate, third parties must: � Identify and verify the certification path that supports the SSL certificate. � Verify all of the electronic signatures of certificates from the certification path.



- 49 -

� Confirm the “key usage” field of the certificate and then use the certificate. � Check information about the SSL certificate's validity status. 6.3.3 Processing time of a certificate request Filing a user certificate application does not constitute an obligation for the CA to issue the requested certificate. The length of time for processing an SSL certificate application is 24 hours if all verifications are completed (in other words, if the individuals in charge of verifications were able to conduct them correctly).

6.4 Certificate suspension and revocation

A certificate is available in one of the three following conditions: valid, expired, or revoked. The Certification Authority does not allow certificates to be suspended. 6.4.1 Possible reasons for revocation User certificate A user certificate must be revoked, and the serial number placed on a list of revoked certificates (CRL) if one of the following circumstances is identified: � Information about the subscriber listed on his/her certificate changes before the certificate's "normal" expiration. � Failure to follow the certificate’s rules of use � The subscriber’s private key is suspected of being compromised, lost, or stolen. � The subscriber makes the request himself. � The CA’s certificate is revoked (which leads to the revocation of all of the certificates signed by the corresponding private key). � The organization’s activity is discontinued. SSL Certificate An SSL certificate is revoked when the association between this certificate and the public key that it certifies is no longer considered to be valid. Examples of reasons that invalidate this association: � The registered domain name or organization’s name changes, and the technical contact is no longer authorized to use the domain name. � DN information is not filled in correctly. � Loss of the private key, loss of the private key’s control, suspicion or compromise of key. � The technical contact used an inaccurate DN in the initial request. � End of CA services � Change in the size of keys imposed by the appropriate national or international institutions. � The CA is revoked. If any of these events occur, the certificate in question shall be revoked and added to the CRL. 6.4.2 Origin of a certificate revocation request A user certificate may be revoked by: � The subscriber in whose name the certificate was issued. � A representative of the subscriber. � The CA who issued the certificate � The RA who authorized issuance of the certificate Revocation of an SSL certificate may be requested in the following cases:



- 50 -

� Loss of the private key, loss of the private key’s control, suspicion or compromise of key. � Loss of SSL certificate. � Requested change in the length of the key or algorithm (signature and/or hashing) recommended by an

appropriate international or national organization. � Change in the organization's name or domain name, and the technical contact is no longer authorized to

use the domain name. � The DN included in the certificate is wrong. � The technical contact used an inaccurate DN in the initial request. � End of the relationship between the CA and client. 6.4.3 Procedure and processing of a certificate revocation request Revocation requests are made through the RA. It must contain identification information about the certificate and its owner. Each individual authorized to revoke certificates has their own revocation code given when they subscribed to the service. Online service is available to the subscriber 24/7 in order to revoke certificates as quickly as possible. Subscribers connect to the CA’s site and may revoke their certificate by entering their email and withdrawal and revocation code, which was sent to the CA when they signed up. Offline service is available to subscribers or their representatives, from 9:00 a.m. to 5:00 p.m. during the business week. Certificates are revoked with the subscriber’s withdrawal and revocation code, or the representative's revocation code. When a revocation request is received from the subscriber or the CA, the RA analyzes this request by confirming the authenticity of the subscriber and the right to revoke the certificate. This verification may be performed: � By telephone through a set of questions/answers about information contained in the certificate application

document. � By the presentation of the subscriber’s withdrawal and revocation code, or the representative's revocation

code. If the request is receivable, the CA asks the RA to revoke the certificate, by adding the certificate’s serial number to the Certificate Revocation List. The certificate’s owner is informed of the revocation through a receipt (email). The operation is registered in the CA’s event log. 6.4.4 Procedure and processing of an SSL certificate revocation request The technical contact sends a revocation request to the RA with the following information at least: � His/her personal identification. � “Secret” information that he/she sent when applying for the certificate for which he/she is requesting

revocation. The RA authenticates the authorized revocation request and sends it to the CA. The CA authenticates the RA and revokes the certificate by activating its private signature key. Information from the RA is sent to the CA by a secure line for protection. All of the certificate revocation operations are protected in a way to guarantee the integrity, confidentiality (if needed), and the origin of the data that is sent and processed. The technical contact is notified of the change in the validity status of his/her certificate. Once revoked, a certificate is not recertified. 6.4.5 Grace period There is no grace period for a revocation. The parties in question must request the revocation of a certificate as soon as the conditions for revocation are identified.



- 51 -

6.4.6 Time period for processing a revocation The revocation request is processed and the subscriber’s right to revoke the user certificate is verified synchronously, and the CRL is updated with new revocations every 24 hours. The publication of a certificate revocation shall not take more than 24 hours. 6.4.7 Revocation verification requirements for third-parties Third parties must verify the validity status of a certificate before trusting this certificate. Third-parties are responsible for how often they check the CRL. If it is temporarily impossible to obtain information about a certificate’s status, third parties must not trust this certificate, or shall accept the risks and responsibilities incurred by this certificate. 6.4.8 CRL integrity The CA signs the available CRL to ensure its integrity and maintain the trust chain. 6.4.9 CRL publication frequency CRLs are published at least every 24 hours, even if there are no changes to their content. The CA shall make sure that the old CRL is withdrawn from publication once the new CRL is published. CRLs are available 24 hours a day, seven days a week. 6.4.10 Online revocation status checking It is possible to check the status of a user certificate online, on the CA's Web site. Users are responsible for checking a certificate's validity before any use. Online status checking of SSL certificates is unavailable. 6.4.11 CRL publication forms CRLs are available on a dedicated site. 6.4.12 Special requirements for key compromise revocation

There is no special procedure in place if the cause for revocation is the compromise of the requestor's private key. The revocation request follows the process defined in sections 6.4.3 and 6.4.4.

6.4.13 Certificate suspension Suspension service is not offered as part of the CA.

6.5 Event Logging

Logging events involves all of the events related to the security of the computer systems used. It ensures auditability, traceability, and accountability, as well as to ensure that the separation of functions is effective. This system also makes it possible to collect audit evidence and detect anomalies. Event logging is protected, saved, and integrated, and is subject to strict operation rules.



- 52 -

Logging tasks are described in detail in the CA’s internal manuals and cover the following topics in particular: � Events recorded by the RA. � Events recorded by the CA. � Event logging process. � Saving event logs � Protecting event logs � Duplicating event log backups � Collecting event logs (internal or external) � Accountability � Anomalies and auditing

6.6 Archives

Archiving is performed by the CA in order to ensure service continuity, accountability and the nonrepudiation of operations. The CA implements the measures needed to make these archives available and to protect their integrity. These archives are subject to strict rules of use and protection against destruction. The following points are explained in the CA’s internal procedures: � Type of data to be archived � Archive retention period In particular: The successive CP and DPC are saved for the entire length of the CA service. Certificates, receipts, notifications and identity credentials are save for ten years after key expiration. CRLs are saved for ten years: � Archive protection � Archive duplication � Time stamping of recordings � Archive collection (internal and external) � Retrieval and verification of archives

6.7 End of Subscription

A request to end a subscription involves requesting a certificate revocation. This revocation request may or may not result in the reimbursement of the subscription.

7 ISSUANCE OF CERTIFICATES

This chapter presents the requirements for the issuance of certificates. It also explains the specific representations issuing authorities make upon issuing certificates.

Upon approving a certificate request, the CA issues a certificate. The issuance of a certificate indicates the complete and final approval of the certificate by the RA. The certificate is considered to be valid as soon as it is accepted by the applicant.

7.1 Consent by the Subscriber for Issuance of a Certificate



- 53 -

A CA shall not issue a certificate without the consent of the certificate applicant. The applicant is presumed to have consented to issue when he/she submitted an application, notwithstanding the fact that the certificate has not yet been accepted.

7.2 Refusal to Issue a Certificate

CAs may refuse to issue a certificate to any individual at their sole discretion, without incurring any liability or responsibility for any loss or expense caused by such a refusal. After refusing to issue a certificate, CAs shall promptly reimburse the applicant for any paid certificate enrollment fees unless the certificate applicant submitted fraudulent or falsified information to the CA.

7.3 CA’s Representations Upon Certificate Issuance

7.3.1 CA’s representations to the Subscriber

Unless otherwise specified in this CPS or mutually agreed upon between the CA and subscriber in an authenticated document, the CA assures the subscriber named in the certificate that: � The certificate contains no incorrect statements known to the CA or originating from the CA. � There are no data transcription errors as received by the CA from the certificate resulting from a failure by the CA to exercise reasonable care in creating the certificate. � The certificate meets all of the material requirements of this CPS. Unless otherwise specified in this CPS or mutual agreement between the CA and the applicant in an authenticated document, the CA makes a commitment to the subscriber to make reasonable efforts within the framework of this CPS to: � Promptly revoke or suspend certificates in compliance with the CPS. � Notify subscribers of any facts known to the CA that may materially affect the validity and reliability of the certificate issued to the subscriber. The obligations and representations in the CPS are for the sole benefit of the subscriber and are not intended to benefit or to be applied by another party. A CA is deemed to be making reasonable efforts if he/she substantially conducts him/herself in compliance with this CPS and the applicable laws.

7.3.2 CA representations to trusted parties

By issuing a certificate, a CA represents to all who reasonably trust a digital signature that can be verified by the public key listed on the certificate, in compliance with this CPS: � All information contained in the certificate or included by reference, except unverified applicant information (UVI), is accurate. � The CA has substantially complied with the CPS when issuing the certificate.

7.4 CA’s Representations Upon Publication

By publishing a certificate, a CA certifies to the KEYNECTIS reference archives and to all who reasonably trust the information included in the certificate, that it has issued the certificate to the subscriber and that the subscriber has accepted the certificate according to the CPS.

7.5 Limitations on CA Representations

The previous representations in the CPS are subject to disclaimers of warranty and limitations of liability in the CPS.



- 54 -

7.6 Time Period for Certificate Issuance

The CA shall make every reasonable effort possible to confirm certificate application information and issue end-user certificates once all relevant information has been received within the following time periods:

Class 1 Class 2 Class 3

Time Period “Immediately” to 2 hours 2-3 business days 2-5 business days

Table 7 – Deadlines for certificate issuance

KEYNECTIS’ and the CA’s compliance with these deadlines depends on the client's timely submission of accurate information, and their prompt response to KEYNECTIS or CA requests, including the provision of appropriate and accurate payment information and approval.



- 55 -

7.7 Certificate Validity

All certificates shall be considered valid upon issuance by the CA and acceptance by the subscriber. Except for the early termination of the validity period due to suspension or revocation, standard validity periods for certificates of the different classes are indicated below:

Certificate issued by Class 1 Class 2 Class 3

RCA to CA 5 years 5 years 5 years

CA To be determined To be determined To be determined

CA EU � Individual 1 year

� Individual 1 year � Organization: 1 or 2 year(s)

� Individual 1 year � Organization: 1 or 2 year(s)

Table 8 – Certificate validity period

All certificates begin their validity period at the date and time of issuance, unless a later date and time is indicated in the certificate (no later than sixty (60) days after the date of issuance. The validity period begins at this date and time even if the certificate has not been accepted and is therefore not yet valid.

7.8 Restrictions on Issued but not Accepted Certificates

A subscriber may not create digital signatures using a private key corresponding to the public key listed in a certificate (or otherwise use the private key) if the foreseeable effect would be to induce or permit trust in an invalid certificate (because it has not yet been accepted).



- 56 -

8 ACCEPTANCE OF CERTIFICATES BY SUBSCRIBERS

This chapter explains the requirements for certificate acceptance by subscribers, the representations made by subscribers upon acceptance, their obligations to protect their private key, and certificate publication procedures.

8.1 Certificate Acceptance

The subscriber is deemed to have accepted a certificate when, following communication of the request according to the CPS, approval is demonstrated as described in Table 10.

Class Acceptance Method

Class 1 Individuals: Online acceptance (via the Web): Applicants enter their PIN code to obtain and accept the certificate. Note: the applicant must notify the CA of any inaccuracy or defect in a certificate immediately after receipt of the certificate or publication of the certificate in the archives; or upon earlier notice of information to be included in the certificate.

Organizations: N/A

Class 2 Individuals: Same as Class 1 online.

Organizations: Same as Class 1 individuals online.

Class 3 Individuals: Same as Class 1 online.

Organizations: Same as Class 1 individuals online.

Table 9 – Certificate acceptance methods

8.2 Representations by Subscriber Upon Acceptance

By accepting a certificate issued by a CA, the subscriber assures and acknowledges to the CA and all who reasonably trust the information contained in the certificate, that at the time of acceptance and during the validity period of the certificate, unless otherwise notified by the subscriber: � Any digital signature created using the private key corresponding to the public key listed in the certificate is the subscriber’s digital signature, and the certificate has been accepted and is valid (not expired, suspended, or revoked) at the time the digital signature is created. � No unauthorized individual has had access to the subscriber’s private key; � All representations made by the subscriber to the CA about information contained in the certificate is true; � All information contained in the certificate is true to the extent that the subscriber had knowledge or notice of this information and does not promptly notify the CA of any material inaccuracies in such information in compliance with the CPS; � The certificate is being used exclusively for authorized and legal purposes, in compliance with the CPS;



- 57 -

� The subscriber is an end user subscriber and not a CA, and shall not use the private key corresponding to the public key listed in the certificate in order to sign a certificate (or any other form of certified public key) or a CRL, as a CA or otherwise, unless expressly agreed in writing between the subscriber and the CA. By accepting a certificate, the subscriber acknowledges acceptance of the terms and conditions in this CPS and the corresponding subscription contract.

8.3 Subscriber’s Obligation to Prevent Private Key Disclosure

By accepting a certificate, the subscriber assumes the responsibility of maintaining control of the applicant's private key, to use a trustworthy system, and to take reasonable precautions to prevent the loss, disclosure, modification, or unauthorized use of the private key.

8.4 Indemnity by the Subscriber

By accepting a certificate, the subscriber agrees to indemnify and hold the CA, KEYNECTIS, and their contractors harmless from any act or omissions resulting in liability, any damage or loss, legal actions, or expenses of any kind, including reasonable attorney's fees, that the CA, KEYNECTIS, and their contractors may incur due to the use or publication of a certificate following: � A false statement made the subscriber (or by a person acting upon instruction from anyone authorized by the subscriber), � Failure by the subscriber to disclose a material fact if the false statement or omission was made negligently or with the intent to deceive the CA, KEYNECTIS, or any individual receiving or trusting the certificate or, � The subscriber's failure to protect his/her private key, use a trustworthy system or otherwise take the necessary precautions to prevent the violation, loss, disclosure, modification, or unauthorized use of the subscriber's key.

8.5 Publication

Upon the subscriber’s acceptance of the certificate, the CA shall publish a copy of the certificate in the KEYNECTIS reference archives and in other directories, at the discretion of the CA and KEYNECTIS. Applicants may publish their KEYNECTIS certificates in other reference archives.



- 58 -

9 USE OF CERTIFICATES

This chapter addresses the rights and obligations of the entities whose rights and obligations are intended to be governed by this CPS, regarding the use of digital signatures and digitally signed messages corresponding to certificates issued by KEYNECTIS.

The CA and certificate users are notified here of the rules related to the reciprocal rights and obligations of parties, which are deemed to be agreed upon between the parties and effective: � Upon publication of this CPS in the case of the CA � Upon submission of a certificate request in the case of a certificate applicant and � Upon trust of a certificate or digital signature corresponding to a public key listed in the certificate in the case of a certificate recipient or a trusted party.

9.1 Verification of Digital Signatures

Verification of a digital signature confirms that: � The digital signature was created by the private key that corresponds to the public key listed in the signer's certificate and that � The signed message has not been modified since the creation of the digital signature.

Digital signatures shall be verified in compliance with the CPS, in other words, as follows:

� A certificate chain for the digital signature will be established. A digital signature shall be verified with regard to a successful confirmation of certificate chain. � The certificate chain will be checked to make sure that it is the most suitable for the digital signature: It is possible to have more than one valid certificate chain from a given certificate to an acceptable root (particularly in the case of cross-certification). If there is more than one certificate chain to an acceptable root, the person who verifies the digital signature may have several options for selecting and validating a certificate chain. � The KEYNECTIS (or other) reference archives will be checked for revocation of certificates in the chain: The recipient must determine if any of the certificates in the chain that link the signer to an acceptable root in the electronic certification services have been revoked. A revocation can prematurely terminate the validity period during which the verifiable digital signatures can be created. This can be checked in two ways. The KEYNECTIS reference archives may be searched for the most recent revocation status. Or, CRLs may have been provided in the certificate chain, which can then be used to determine the revocation status of certificates in the chain. � Delimit data to which the digital signatures are attached: In order to verify a digital signature, it is necessary to know precisely what data has been signed. In the case of public key cryptography standards (PKCS), a standard signed message format is specified to accurately display the signed information. � Indicate the time and date the digital signature was created: In order for a digital signature to support nonrepudiation, the information to which it is attached must include or reference a time stamp. The time stamp shall display the time and date at which the signature was attached to the message. � Establish the assurances desired by the signer: Various technical methods are available to determine the purpose (or meaning) of the digital signature intended by the signer. In formal protocols (EDI for example), digital signatures are classified as specific security services with defined semantics in order to convey their exact meaning. The verifier must also determine if the certificate is normal or provisional. � Confirm that all of the certificates in the chain authorize the use of a private key of a subscriber (end user): A CA may limit the purposes for which a private key corresponding to a certificate it issues may be used. These limitations are indicated or included by reference in the certificate and provide a way to notify recipients of situations in which trust in a certificate would not be considered reasonable. Individuals who



- 59 -

validate certificates must inspect the certificate to find out if they contain such warnings or limitations to make sure that no certificate in the chain prevents appropriate use of a subscriber’s certificate. � Confirmation of a certificate chain: Each CA is certified by a superior CA (except for the RCA, who has a self-signed public key) and thus inherits the trust associated with its superior. Each CA is deemed to be at least as trustworthy as the superior CA. Confirming a certificate chain is the process of validating a certificate chain and subsequently validating a subscriber’s certificate.

9.2 Effect of Validating a Subscriber’s Certificate

A digital signature binds the signer if: � It was created during the validity period of a valid certificate. � The digital signature can be properly verified by confirming the certificate chain. � The trusting party has no knowledge or notice of a violation of the rules of this CPS by the signer, and � The trusting party has complied with all of the rules of this CPS.

The use of certificates does not confer evidence of authority on the part of any user to act on behalf of another individual or to undertake any particular act. Individuals who verify electronically-signed documents are solely responsible for exercising reasonable judgment and due diligence before trusting certificates and digital signatures. A certificate does not grant any rights or privileges from an RA, except as specified in this CPS.

9.3 Procedures upon Failure of Digital Signature Validation

An individual who trusts an unverifiable digital signature assumes all risks involved and cannot presume that the digital signature is effective as the signature of the subscriber according to the CPS.

9.4 Trust in Digital Signatures

The recipient of a message digitally signed by the subscriber may consider the digital signature as binding to the subscriber if: � The digital signature was created during the validity period of a valid certificate and can be verified by referencing a validated certificate chain, and � Such trust is reasonable under all circumstances. If the circumstances show a need for additional assurances, the trusting party must obtain these assurances for such trust to be reasonable. In addition, the verifier must take into account the certificate’s class and status. The final decision whether or not to trust a verified digital signature is exclusively that of the verifier.

9.5 Writings

A message bearing a verified digital signature using a public key listed in a valid certificate is as valid, effective, and enforceable as if the message had been written and signed on paper.

9.6 Signatures

When a rule of law or applicable practice requires a signature or provides for certain consequences in the absence of a signature, that rule is satisfied by a digital signature affixed to the message by a signer with the intention of signing a message and subsequently verified by reference to the public key listed in a valid certificate.

9.7 Security Measures



- 60 -

Any individual using or trusting a certificate issued as part of the KEYNECTIS electronic certification services in conjunction with a message shall apply reasonable security measures to ensure the authentication of the message, and if needed, ensure the message's confidentiality.

9.8 Issuing certificates

Only authorized CAs may issue certificates.



- 61 -

10 CERTIFICATE REVOCATION

This chapter explains the circumstances in which a certificate may or must be revoked. It also details the procedures for revoking and restoring a certificate.

10.1 General Reasons for Revocation

A certificate shall be revoked if: � There has been a loss, theft, modification, unauthorized disclosure or other violation of the private key of the certificate’s subject. � The certificate’s subject (CA or subscriber) has violated a material obligation under this CPS; � The completion of a person’s obligations under this CPS is delayed or prevented by unpreventable damage, natural disaster, computer or communications failure, change of statute; or any other cause beyond the person’s control and as a result another person's information is materially threatened or compromised. � The subscriber (or authorized representative) specifically requested a revocation.

10.2 Revocation of a CA certificate

The CA must do what is reasonably within his/her power to revoke a "subordinate" CA's certificate, regardless of whether the subordinate CA consents, if any of the following situations exists: � The CA knows or believed with reasonable certainty that a fact listed in the certificate is false; � A prerequisite to the certificate's issuance was neither satisfied nor waived; � The subordinate CA’s private key or trustworthy system was compromised in a way that materially affects the certificate's reliability; � The certificate’s subject (here, a CA) has violated a material obligation under this CPS. The CA must immediately notify the subordinate CA of any suspension or revocation.

10.3 Revocation at a Subscriber’s Request

The CA must revoke a certificate once it has been established that the person requesting the revocation is in fact the subscriber.

10.4 Revocation for Faulty Issuance

The CA shall revoke a certificate immediately upon discovering and establishing that it was not issued in compliance with the procedures imposed by this CPS. Table 10 shows the prerequisites for revoking a certificate

Prerequisites for Revoking a CA's certificate

RCA and CA � Certificate revocation request from a CA � Request in the form of an authenticated document from the subscriber or subscriber’s agent (authenticated through a challenge phrase or statement of certain pre-submitted registration information).

Table 10 – Pre-requisites for revoking a certificate



- 62 -

10.5 Notification and Confirmation of Revocation

Upon revoking a certificate, the CA must publish notice of the revocation in the KEYNECTIS reference archives. A CA may publish one or more of the following: � A list of revoked certificates available through a secure channel. � A certificate revocation list (CRL) of the revoked certificates. A CA must publish a CRL at least once a day for Class 2 and 3 CAs, unless otherwise provided by the KEYNECTIS reference archives. The CRL shall also be published in case of an emergency as determined by the CA. CAs may also provide the following revocation notification services, upon request and payment by the subscriber. � Confirmation that a certificate has been revoked upon request by a recipient of a digitally-signed message signed by the certificate subject in question; � “Push service” by which the CA notifies the subscriber upon revocation of designated certificates.

10.6 Effect of Revocation

10.6.1 On certificates

During the revocation of a subscriber’s certificate, that certificate’s validity period shall immediately be considered terminated. Similarly, in the case of a certificate issued to a CA, the expiration of the CA's certificate withdraws the authority of that CA to issue certificates, but does not affect the validity of the certificates issued by the CA when the CA's certificate was still valid.

10.6.2 On underlying obligations

Revocation of a certificate does not affect the underlying contractual obligations created or communicated under this CPS.

10.7 Protecting a Private Key upon Revocation

Private keys corresponding to the public keys contained in a revoked certificate shall be protected by the subscriber in a trustworthy manner throughout the applicable retention period, unless it is destroyed.



- 63 -

11 CERTIFICATE EXPIRATION

This chapter explains parties’ obligations concerning certificate expiration. Expiration is different from revocation. Validity and validity periods are addressed in the CPS.

11.1 Notice Prior to Expiration

CAs shall do what is reasonably within their power to notify subscribers by email of the impending expiration of their certificates. This notification is sent to make it easier for subscribers to request or renew certificates.

11.2 Effect of Certificate Expiration on the Underlying Obligations

Certificate expiration shall not affect the validity of any contractual obligation created or communicated under this CPS.

11.3 New Request and Renewal

Subscribers' new requests or renewals shall be submitted as follows:

Class 1 Class 2 Class 3

Same procedure as initial request.

Same procedure as initial request, but the certificate applicant needs to submit only new or modified information.

Same procedure as initial request, but the certificate applicant needs to submit only new or modified information.

Table 11 – Renewal and new request

Requirements for new requests or renewal are subject to change at the discretion of KEYNECTIS.



- 64 -

12 OBLIGATIONS OF ISSUING AUTHORITIES AND KEYNECTIS, AND LIMITATIONS OF THESE OBLIGATIONS

This chapter summarizes and provides references regarding the warranties and commitments made by certification authorities and KEYNECTIS, and explains the disclaimers and limitations of these obligations.

12.1 Limited Warranties and other Obligations

Certification authorities and KEYNECTIS, to the extent specified in the referenced CPS sections, warrant and undertake to: � Establish the infrastructure and certification services, including the installation and management of the KEYNECTIS reference archives, as stated in this CPS. � Perform validation procedures for the specified certificate class, as defined in this CPS. � Issue certificates according to the CPS and honor the various representations to subscribers and trusting parties according to the CPS; � Publish accepted certificates in accordance with the CPS � Perform the obligations of a CA and support the rights of subscribers and trusted parties who use the certificates according to the CPS; � Suspend and revoke certificates in accordance with the CPS; � Ensure the expiration, re-enrollment, and renewal of certificates in accordance with the CPS; � Comply with the CPS provisions.

In addition, CAs guarantee that their own private keys have not been violated unless they provide notice to the contrary through the KEYNECTIS reference archives. CAs make no other warranties and have no further obligations under this CPS.

12.2 Disclaimers and Limitations of CA Obligations

Except as expressly stipulated above, certification authorities and KEYNECTIS disclaim all warranties and obligations of any type, including any warranty of merchantability or special use, and any warranty of the accuracy of information provided, and also disclaim any and all liability for negligence or lack of reasonable care.

Except for that which has been expressly stipulated in the CPS, CAs: � Do not guarantee the accuracy, authenticity, reliability, completeness, currentness, merchantability, or fitness of any information contained in certificates or otherwise compiled, published, or disseminated by or on behalf of certification authorities or KEYNECTIS; � Assume no responsibility for the information contained in a certificate, provided that the certificate content substantially complies with this CPS; � Do not guarantee “nonrepudiation” of a certificate or message (nonrepudiation is determined exclusively by law and the applicable dispute resolution mechanisms); � Do not warrant any software. CAs disclaim all warranties and obligations of any type, including any warranty of merchantability or special use, and any warranty of the accuracy of information provided, and also disclaim any and all liability for negligence or lack of reasonable care.



- 65 -

12.3 Exclusion of Certain Damage Elements

In no event shall a CA or KEYNECTIS be held liable for any indirect, special, incidental, consequential, or penal damage in connection with the use, delivery, effectiveness, or nonperformance of certificates, digital signatures, or any other transaction or services offered or expected by this CPS, even if the issuing authorities or KEYNECTIS, or both, have been notified of the possibility of these damages.

12.4 Damage and Loss Limitations

Under no circumstances shall the accumulated liability to all parties (including, but not limited to, an applicant, recipient or a trusting party) of a certification authority and all superior CAs in the certification chain to which the CA certificate belongs, exceed the liability cap for this certificate. The accumulated liability of all certification authorities to any and all individuals affected by a certificate, for all digital signatures and transactions related to such certificate, is limited to the cap indicated below:

Liability caps

Class 1 76.22 euros

Class 2 4,573.47 euros

Class 3 76,224.51 euros

Table 12 – Liability caps

The cap on damages applies to loss and damages of all types, including but not limited to direct, compensatory, indirect, special, consequential, exemplary, or incidental damages incurred by an individual, including but not limited to an applicant, recipient, or a trusting party, that are caused by trust in or use of a certificate that is issued, managed, used, suspended, or revoked by a CA or the expiration of such certificate. The cap on damages also applies to liability under contract, tort, or any other form of liability claim. The liability cap on each certificate shall remain the same regardless of the number of digital signatures, transactions, or claims related to such certificate. If the liability cap is exceeded, the available party shall be allocated first to the earliest claims to achieve final dispute resolution, unless otherwise ordered by a court of competent jurisdiction. Under no circumstances shall KEYNECTIS be obligated to pay more than the accumulated liability cap for each certificate, regardless of how this amount is allocated among claimants.

12.5 Applicant Liability to Trusting Parties

Without limiting other subscriber obligations under this CPS, subscribers are liable for any misrepresentations they make in certificates to third parties who, having verified one or more digital signatures with the certificate, reasonably trust the content of such certificate.

12.6 No Fiduciary Relationship

CAs and KEYNECTIS are not the fiduciary agents, nominees, or other representatives of subscribers or trusting parties.

The relationship between CAs (or KEYNECTIS) and trusting parties is not that of an agent and principal. Neither subscribers nor trusting parties have the authority to bind a CA (or KEYNECTIS) by contract or otherwise. CAs and KEYNECTIS shall make no representation to the contrary, either expressly, implicitly, by appearance, or otherwise.

12.7 Dangerous Activities



- 66 -

KEYNECTIS’ electronic certification services are not designed or authorized for resale as monitoring equipment in hazardous conditions or for uses requiring fail-safe performance (for example, nuclear facilities, aircraft navigation or communication, or air traffic control systems), where failure could lead directly to death, injury or severe environmental damage.



- 67 -

13 MISCELLANEOUS PROVISIONS

This chapter covers general terms and conditions that are not included in other parts of this CPS.

13.1 Conflicting Provisions

In the event of a conflict between this CPS and other rules, guidelines or contracts, the subscriber shall be bound by the provisions of this CPS, unless the other contract (i) predates the first publication of this CPS; or (ii) specifically takes precedence over this CPS, for which such contract shall be valid against parties of said CPS, except to the extent that the provisions of this CPS are prohibited by law.

13.2 Compliance with Export Laws and Regulations

Export of certain software used as part of the KEYNECTIS certification services may require the authorization of the appropriate government authorities. The parties shall comply with the export laws and regulations in effect.

13.3 Applicable Law

This CPS, its implementation, interpretation, and its validity are governed by French laws, notwithstanding any other choice of applicable law in the contract or otherwise, and without the requirement of a commercial establishment in France. The choice of French law aims at the uniformity of procedures and interpretation for all users, no matter where they reside or how they use their certificates.

13.4 Dispute Resolution, Choice of Forum, and Presumptions

13.4.1 Notification among parties of a dispute

Before invoking any dispute resolution mechanism (including arbitration) with respect to a dispute involving any aspect of this CPS or a certificate issued by an RA, aggrieved individuals shall notify KEYNECTIS, the CA concerned, and any other party affected by the resolution of a dispute.

13.4.2 Official resolution of legal disputes

Except where each directly involved party agrees to an alternative dispute resolution (arbitration for example), any action aimed at applying a provision of this CPS or arising in connection with the CPS or any other business relationship between the parties concerned, shall be brought before the courts of Paris. Each person hereby agrees that such courts shall have exclusive personal jurisdiction over him/her and each person hereby submits to the exclusive personal jurisdiction of these courts. The parties hereby waive any right to a jury trial regarding any action brought in connection with this CPS or KEYNECTIS certification services. If the parties choose an alternative resolution method, French law shall govern the arbitration and procedure.

13.5 Succession and Assignment

This CPS grants and binds successors, executors, heirs, representatives, administrators, and assignees of the parties, regardless of whether they are explicit, implicit or apparent. The rights and obligations explained in this CPS are assignable to the parties by operation of law (including after a merger or the transfer of a controlling interest in share ownership) or otherwise, provided that the assignment complies with the CPS on the termination or suspension of the CA’s operations, and provided further that the assignment is not a



- 68 -

novation of any other debt or obligation that the assigning party owes to other parties at the time of such assignment.

13.6 Merger

No term or provision of this CPS directly affecting the rights and obligations of KEYNECTIS or any CA may be orally amended, waived, supplemented, modified, or terminated without an authenticated message or document from the affected party; unless authorized by the CPS.

13.7 Severability

If any of this CPS, or its application, is found to be invalid or unenforceable for any reason or any extent, the remainder of this CPS (and the application of the invalid or unenforceable provision to other individuals or circumstances) shall be interpreted so as to best comply with the intention of its parties. It is expressly agreed that each and every provision of this CPS that stipulates a limit of liability, disclaimer, or limitation of warranty of another obligation, or exclusion from damages is severable and independent of any other provision and is to be enforced as such.

13.8 Interpretation and Translation

Unless otherwise stipulated, this CPS shall be interpreted in conformance with what is commercially reasonable under the circumstances. The interpretation of this CPS shall take into account its international scope and application, in view of the uniformity of its application and observance of good faith. Translated versions of this CPS are available in some languages and are found in the archives. In the event of a conflict between the French and non-French versions, the original version shall be retained.

13.9 No Waiver

Failure by an individual to comply with a CPS provision shall not be deemed a waiver of future compliance with that or any other provision.

13.10 Communications

Any party who would like to, or is required to, issue a notice, demand, or request as part of this CPS shall do this using a digitally-signed message that complies with the requirements of this CPS, or in writing. Electronic communications shall be effective upon the sender’s receipt of a digitally-signed acknowledgement of receipt from the recipient. The acknowledgement of receipt must be received within five (5) days; or else written notice must be sent. Communications in writing shall be delivered by registered mail with acknowledgement of receipt, to the following address: KEYNECTIS, 30 rue du Château des Rentiers 75647 Paris Cedex 13, France



- 69 -

13.11 Headings and Appendices of this CPS

Headings, subheadings, and other legends of this CPS are for convenience and reference only. They shall not be used for interpreting or enforcing any of the provisions in this CPS. The appendices, including definitions, are for all purposes, and are an integral and mandatory part of this CPS.

13.12 Change of Subscriber Information in CA files; Amendments to the CPS

13.12.1 Change of subscriber information in a CA's file; amendment to the CPS

Any subscriber may change personal information on file with their CA that does not appear on their certificate (normally, information provided in the subscription agreement or certificate application) by giving thirty (30) days notice in compliance with this CPS. The change shall take effect after this thirty-day (30) period. KEYNECTIS is authorized to place these amendments in the reference archives.

13.12.2 Amendment of the CPS

KEYNECTIS may amend the reference archives either in the form of an amended version of the CPS, or in the “Practice Updates and Notifications” section of the KEYNECTIS reference archives.

Amendments to this CPS that are placed in the Practice Updates and Notifications section of the reference archives will amend the CPS. Such amendments shall override ay conflicting and designated provisions of the referenced version of the CPS.

Each change shall become effective fifteen (15) days after KEYNECTIS publishes an amendment proposal in the KEYNECTIS reference archives, unless (i) KEYNECTIS has published a withdrawal notice of the amendment proposal prior to the end of the fifteen (15)-day period; or if (ii) by not making the proposed change, KEYNECTIS risks violating electronic certification services, to which case the proposed change shall enter into effect once it is published in the KEYNECTIS reference archive. The decision of a subscriber to not request revocation of his/her certificate after the publication of a proposed change constitutes acceptance of the change.

13.13 Ownership of Security Material

Unless otherwise agreed, information and data related to security are regarded as the property of the designated parties below:

� Certificates: Certificates are the personal property of their respective CA. Certificates issued by the KEYNECTIS RCA and its “subordinate” CAs contain a copyright notice "Copyright (c) KEYNECTIS. All rights reserved”. or “©”. � This CPS authorizes the reproduction and distribution of certificates on a nonexclusive, royalty-free basis, provided that they are reproduced and distributed in full, except that certificates may not be published in any public reference archives without written permission from KEYNECTIS. The purpose of this restriction is to protect the privacy of subscribers against unauthorized copying of their certificates. � CPS: This CPS is the personal property of the KEYNECTIS Corporation. � Distinguished names: distinguished names are the personal property of designated individuals (or their employer or principal). � Private keys: Private keys are the personal property of subscribers, who use them good reason or are capable of using them (or their employer or principal), regardless of the hardware device on which they are stored and protected.



- 70 -

� Public keys: Private keys are the personal property of subscribers (or their employer or principal), regardless of the hardware devices on which they are stored and protected. � Secret share of private keys: Secret shares of a CA's private key are the personal property of the appropriate CA.

13.14 Infringement and Other Sources of Damage

Certificate applicants declare and guarantee that their submission (to a CA) and use of a domain name and distinguished name (and all other certificate application information) does not infringe upon or interfere with the rights of any third party in any jurisdiction with respect to their trademark, service mark, business name, or company name, or any other intellectual property right, and that they are not seeking to use the domain name or distinguished name for unlawful purposes, including (but not limited to) malicious interference with contract or prospective business advantage, unfair competition, injuring the reputation of another, or misleading an individual or organization. Certificate applicants shall defend, indemnify, and protect their CA from any lost or damage resulting from any such infringement or interference. CAs and KEYNECTIS shall not be held responsible for unverified subscriber information (UVI) submitted to KEYNECTIS, a CA, or the KEYNECTIS reference archives, or otherwise submitted for inclusion in a certificate. In particular, subscribers shall be solely responsible for the legality of the information they submit for inclusion in the certificates issued as part of this CPS, in any jurisdiction where certificate content may be used or viewed. Laws regarding the sharing and availability of information are constantly changing and vary greatly; therefore, the responsibilities of certificate applicants and subscribers are defined not only by the laws in effect at the time a CA issues a certificate to an applicant, but also by any laws enacted after such a date. Certificate applicants should be aware that there are many laws regarding the transmission of data, particularly information that is encrypted or involves a cryptographic algorithm, and that these laws may vary considerably from one state or country to another. Furthermore, it is generally impossible to limit the distribution of content on the Internet or other networks based on the location of the user or of the individual viewing the information, which may compel certificate subscribers to comply with the laws of each jurisdiction in which the information may be used or viewed. Certificate applicants shall not submit to KEYNECTIS, a CA, or the KEYNECTIS reference archive any materials that contains statements that are (i) libelous, defamatory, obscene, pornographic, abusive, bigoted, hateful, or racist, (ii) advocate illegal activity or discuss legal activity with the intent to commit, or (iii) violate the law in any other way.

13.15 Fees

KEYNECTIS may charge subscribers for the use of its electronic certification services. These fees may change seven (7) days after being published in the KEYNECTIS reference archives.

13.16 Choice of Cryptographic Methods

All persons acknowledge that they (not KEYNECTIS or any CA) are solely responsible for selecting security software, hardware, and encryption/digital signature algorithms, including settings, procedures, and techniques, and state that they have made their choice based on independent judgment.

13.17 Survival

The obligations and restrictions of the certification authorities and KEYNECTIS stated in this CPS shall survive after the application of this CPS is terminated.



- 71 -

14 APPENDIX

This document contains acronyms and abbreviations. The glossary below provides a reference for the most commonly used terms: A / B Accept (a certificate) Certificate applicants demonstrate that they approve a certificate while knowing or having notice of the information that it contains in accordance with the CPS. Access A specific type of interaction between a request and communications or information sources that results in a flow of information, exercise of control, or the activation of a process. Accreditation / Accredited A formal declaration by an authorized KEYNECTIS representative that a given information system, professional, employee, subcontractor, or company is approved to perform certain operations and to operate in a specific security mode, using a defined set of security of measures. Affirm / Affirmation To recognize or indicate that data is correct or information is true. Alias Synonym of pseudonym Archive To store records and corresponding logs during a given period for security, backup, or auditing purposes Audits A procedure used to demonstrate that controls are in place and are suitable for their purpose. An audit records and analyzes operations to monitor intrusions or uses within an information system. Anomalies detected by an audit are reported to the appropriate department. Authentication A process that is implemented to confirm the identity of an individual or the integrity of information. A message is authenticated by determining its origin and verifying that it has not been modified or replaced in route. Authenticate See Authentication Authorization The granting of rights, particularly the ability to access specific information or resources. Availability The extent to which information or processes may be reasonable accessed or used, upon demand, by an authorized entity. Availability allows authorized access to resources and ensures the timely performance of urgent operations. Binding Confirmation by a registration authority of the relationship between a named entity and its public key.



- 72 -

C CA Certificate Certificate issued by a CA to a subordinate CA. CA Certificate Application A request sent by a non-KEYNECTIS entity to KEYNECTIS electronic certification services to become a CA and to receive a CA certificate. Certificate A message that, at least, states a name or identifies the applicant, contains the applicant’s public key, identifies the certificate’s validity period, contains a certificate serial number, and carries the CA’s digital signature. Any reference to a “class certificate” (1, 2, 3…) without another qualifier shall mean a "normal" or "provisional" certificate, unless the context requires otherwise. References to a certificate refer exclusively to certificates issued by a CA. Certificate Applicant A person or authorized agent that requests the issuance of a public key certificate by a CA. Certificate Applicant Authorized person who requests the issuance of a certificate from a CA. Certificate Application A request from a certificate applicant to a CA for the issuance of a certificate. Certificate of Authenticity A document issued by an authorized official authority of the jurisdiction in which an acknowledgement by a notary was made to authenticate the status of a notary. Certificate Chain A sequenced list of certificates containing a certificate applicant (end user) and CA certificates. Certificate Expiration The date and time specified in a certificate, marking the end of the validity period, without including a possible earlier revocation. Certificate Extension An extended field of a certificate, which may provide additional information about the certified public key, the certificate subscriber, certificate issuer, and/or the certification process. Standard extensions are defined in Amendment 1 of ISO/IEC 9594-8: 1995 (X.509). Certificate Hierarchy Within the electronic certification services, all of the CAs classified by category based on their role in the CA tree structure. A CA issues and manages certificate for end-user subscribers and/or for one or more subordinate CA(s). A CA in a trust hierarchy must observe uniform procedures, particularly naming, and the maximum number of levels, etc., to assure integrity of the domain and thereby ensure uniform accountability, auditability, and management through trustworthy operational processes. Certificate Issuance The actions performed by a CA in creating a certificate and notifying the certificate applicant (anticipated to become a subscriber) listed in the certificate. Certificate Revocation See Revoke a Certificate. Certificate Revocation List (CRL) A periodically issued list, digitally signed by a CA, of certificates that have been identified as suspended or revoked before their expiration date. The list generally includes the CRL issuer's name, date of issue, the



- 73 -

date of the next edition, the serial number of the revoked certificates, and specific times and reasons for revocation. Certificate Serial Number A value that unambiguously identifies a certificate issued by a CA. Certificate Signing Request (CSR) A machine-readable form a certificate application. Certification Authority (CA) Also called the Certificate Authority. The entity who issues digital certificates. It sets the terms and conditions related to managing a certificate life cycle (issuance, renewal, revocation, etc.). To do this, the certification authority is responsible for writing a certificate policy (CP) explaining these terms and conditions. Certification / Certify The process of issuing a certificate by a registration authority. Certification Policy (CP) Also called a Certificate Practice Statement. Defines the procedures for generating and managing certificates. It defines the trust relationship between the end user and certificate holder. Certification Practice Statement (CPS) A document, revised from time to time, that represents the statements of practices a CA uses in issuing certificates. Challenge Phrase A set of numbers and/or letters selected by a certificate applicant, sent to the registration authority with a certificate request, and used by this authority to authenticate the applicant as required by this CPS. Class 1, 2, and 3 Certificates A certificate for a specified level of trust. Commercial reasonableness In the context of e-commerce, installation, and use of technology, controls, and administrative and operational procedures that reasonably ensure system and message trustworthiness. Compromise A violation (or suspected violation) of a security measure, in which confidential information may have been disclosed or loss of control may have occurred (see data integrity). Confidentiality The status in which important information is kept secret and only disclosed to authorized parties. Confirm To declare or indicate through an action (examination, investigation) that data is true and information is accurate. Controls Measures taken to ensure the integrity and quality of a process. Correspond To belong to the same key pair. Cross-Certification A situation in which a KEYNECTIS CA and/or an RA other than KEYNECTIS (representing another certification domain) issues a certificate with the other as the subject of that certificate. Cryptographic Algorithm



- 74 -

A clearly specified calculation process for resolving a problem. A set of rules that produce a prescribed result. Cryptographic Hardware Security hardware devices that contain the user’s private key, public key certificate and, as an option, a cache of other certificates, including all of the certificates in the user's certification chain. Cryptographic Resource Material resource that stores private keys. Cryptography There are two types of cryptography: the symmetrical cryptography of a private key and the asymmetrical cryptography of a public key. Cryptomodule A trustworthy implementation of a cryptosystem, which safely encrypts and decrypts data. D Data Programs, files, and other information stored in, communicated, or processed by a computer. Database A set of related information, created, stored, or manipulated by a computerized management system. Data Integrity A condition in which data has not been modified or destroyed in an unauthorized manner. Digital Identification Name given to a certificate. Digital Signature The transformation of a message through an asymmetric encryption system such that a person with the initial message and the signer's public key can accurately determine if the transformation was created using the private key corresponding with the signer's public key and if the message has been altered since the transformation. Directory See Reference Archives Distinguished Name Distinctive name. Distinguished Name (DN) A set of data that identifies a real entity, such as a person in a computer-based environment (CN = Common Name) (C = Country) (S = State) (O = Organization) (OU = Organization Unit). E / F Electronic certificate A certificate is an electronic file that represents a digital identification document by establishing a link with the entity associated with it. Electronic mail Messages sent, received, or forwarded in digital form via a computer-based communications system (email).



- 75 -

Electronic Certification Service Services provided by a certification (electronic) services provider. For example, issuance of electronic certificates, certification directory service, CRL provision, provision of time stamp token, archiving, etc. Employee in Good Standing A non-probationary employee that has not been terminated or suspended, and is not facing pending disciplinary action by his or her employer. Encryption Process by which intelligible information is made unintelligible in order to protect confidentiality. Entity See person. File Transfer Protocol (FTP) An application protocol that offers a file transfer system in an Internet environment. Free certificate A certificate issued by a registration authority without charge. G / H Generate a Key Pair To create, in a trustworthy environment, during certificate application, private keys whose corresponding public keys are submitted to the CA in a way that demonstrates the applicant’s capacity to use the private key. Hash (Hash Function) A mathematical function such as: � A message yields the same result each time that the algorithm is applied to the same message; � It is mathematically impossible to deduct or reconstitute the message from the result produced by the algorithm; It is mathematically impossible to find two different messages that produce the same hash result with the same algorithm HSM Hardware Security Module I / J Identification The process of confirming the identity of a person. Identification is facilitated in public key cryptography by certificates. Identity A unique piece of information that marks or signifies a particular entity in a domain. This information is only unique within its domain. Identity Naming The use of an “Organization Unit” extended field (OU = ) in an X.509 v3 certificate. Integrity See data integrity



- 76 -

K / L Key Generation Trustworthy process for creating a key pair (private / public). KEYNECTIS Naming Authority A naming authority that established and enforces controls over and has decision-making power regarding the issuance of relative distinguished names for all RAs. Key Pair A private key and its corresponding public key. The public key can authenticate a digital signature created by using the corresponding private key. In addition, depending on the type of algorithm used, key pair components can also encrypt and decrypt information for confidentiality purposes, in which case, only a private key allows you to read encrypted information through its corresponding public key. M Message A digital representation of information; computer-based record. N / O Name A set of identifying attributes used to describe a certain type of entity. Naming The assignment of descriptive identifiers to objects of a particular type. This is done by an authority that follows specific issuing procedures and maintains specific records in keeping with identified registration procedures. Naming Authority An entity that executes naming procedures and policies and has control over the registration and assignment of basic names to objects of a particular class. Non-KEYNECTIS RA An RA that is not owned or operated by KEYNECTIS, and whose functions are limited to that of an RA, or machines. Nonrepudiation Provides proof of the origin or delivery of data in order to protect the issuer against a false declaration by the recipient that the information has not been received and to protect the recipient against a false declaration by the issuer that the data has not been issued. Provides proof in case of disagreement. Notice The result of notification in accordance with this CPS. Notify To share specific information with another person as required by this CPS and applicable law. Organization An entity with which a user is affiliated. The organization itself may be a user. Originator A person by whom (or on whose behalf) a data message is presumed to have been generated, store, or communicated. A person acting as an intermediary is not considered to be an originator.



- 77 -

P / Q Parties Entities whose rights and obligations must be governed by a CPS. These entities may be certificate subscribers, CAs, or trusting third parties. Password Confidential authentication information comprised of a string of characters used for access to a resource. Person A human being or organization (or a device under the control of a human or organization) capable of signing or confirming a message. Personal Presence The act of appearing (physically, rather than virtually or figuratively) before an RA or its designee and proving one's identity as a prerequisite to the issuance of a certificate under certain conditions. PKI Hierarchy All of the CAs whose functions are organized according to the principle of delegation of authority and related to each other as subordinate or superior. Private Key A mathematical key kept secret by its holder. It is used to sign information electronically and decrypt data encrypted by the corresponding public key. Promise Agreement or behavior whose purpose is to convey the general intention of a registration authority, supported by a good faith effort, to provide and maintain a specific service. A “Promise” does not necessarily involve a guarantee that the services shall be fully provided and satisfactory. Promises are separate from assurance and guarantees, unless expressly indicated. Public Key A mathematical key that can be made public used to verify the electronic signatures created by its corresponding private key. A public key may also be used to encrypt data that is decrypted by the corresponding private key. Public Key Certificate See certificate Public Key Cryptography A method of cryptography based on a pair of mathematically related keys. The public key can be made available to anyone who wishes to use it. It can encrypt information or verify a digital signature. The private key is kept secret by its holder and can decrypt information or generate a digital signature. Public Key Infrastructure (PKI) All the technical, human, document, and contract means made available to users to ensure, along with asymmetrical cryptographic systems, a secure environment for electronic communications. Publish To record and classify information in the reference archives in order to disclose and make public certain information in compliance with this CPS and applicable law. Qualifier A data syntax facilitating the representation of a set of values that restrict the meaning of the CPS. The qualifier value increases the certificate policy extension in all certificates, according to the rules defined by X509.



- 78 -

R Recipient (of a digital signature) A person who receives a digital signature and who is in a position to trust it, regardless of whether such trust occurs. Record Information that is inscribed on a tangible medium (a document) or stored in an electronic medium or other, which can be retrieved in a perceptible form. The term “record” is the cumulative term for “document” and “message” (see document, message). Reference archives Certificate database that also contains other relative information. Registration Process by which an applicant requests a certificate. Registration Authority Administrator An employee of an RA responsible for performing the functions of an RA. Registration Authority (RA) An entity responsible for identifying and authenticating electronic certificate applicants on behalf of a CA, but is not in charge of issuing electronic certificates. Registration Field Information Country, zip code, age, and type of data included within a designated certificate, based on options selected by the applicant Relative Distinguished Name (RDN) A set of attributes including an entity's distinguished name that distinguishes this entity from others of the same type. Renewal The process of obtaining a new certificate of the same class and type as the previous certificate once it has expired. Repudiation The denial or attempted denial by an entity involved in communication of having participated in all or part of the communication. Revoke a Certificate The process of permanently ending the validity of a certificate from a specific time (for example, when a private key is compromised). Root The CA that issues the first certificate in a certification chain. The root’s public key must be known in advance by the certificate user in order to validate a certification chain. Root Certification Authority (RCA) Highest level Certification Authority RSA A public key cryptographic system invented by Rivest, Shamir, and Adelman.



- 79 -

S S/MIME A specification for secure electronic mail using a cryptographic message syntax in an Internet environment. Secret Share A portion of an encrypted secret distributed among a number of physical tokens. Secret Share Holder An authorized holder of a physical token containing a secret share. Secret Share Issuer A person designated by a RA to create and distribute secret shares. Secret Sharing The practice of distributing secret shares of a private key to a certain number of secret share holders, based on the tolerance of key sharing. Secure channel A cryptographically-enhanced communications path that protects messages against perceived threats. Security The quality or state of being protected against unauthorized access or uncontrolled losses or events. Absolute security is impossible to achieve in practice and the security of any given system is relative. Security Policy A document articulating the needs and good practices in regards to the protection and security practices maintained by a trustworthy system in support of the CPS. Security Services Services provided by a set of security mechanisms. Among these services are access control, data confidentiality, and data integrity. Self-Signed Public Key A data structure that is constructed like a certificate, but signed by its own subject. Unlike a certificate, a self-signed public key may not be used to authenticate a public key to other parties. Serial Number (See certificate serial number). Server A computer system that responds to requests from client systems. Sign To create a digital signature for a message or to affix a signature to a document. Signature A method that is adopted or used by a document's originator to identify himself or herself. This method is either accepted by the recipient, or its use is routine under the circumstances. Signer A person who creates a digital signature for signing a message or document. Smart Card A hardware security device that contains a user certificate and related private key.



- 80 -

Smart key Physical cryptographic device enabling the secure manufacturing and storage of an electronic certificate. It can be used without a reader and connects to the computer’s USB port. Subject Holder of a private key corresponding to a public key. The term “subject” can refer to both the equipment and device that holds the private key and to the individual person, if any, who controls that equipment or device. A subject is assigned an unambiguous name bound to a public key contained in the subject’s certificate. Subject Name Unambiguous value contained in the subject name field bound to the public key. Subscriber A person who is the subject of, has been issued a certificate, and who is capable of using and authorized to use, the private key that corresponds to the public key listed in the certificate. Subscription agreement An agreement executed between an applicant and a CA for the provision of designated electronic certificate services in accordance with this CPS. T / U Test Certificate A certificate issued by a CA for technical testing only. Only authorized individuals may use test certificates. Threat A circumstance or event likely to cause harm to a system, including the destruction, unauthorized disclosure or modification of data, or denial of service. Time Stamping A service that indicates the correct date and time of an event in a reliable manner. Transaction Transfer of professional information by computer, which consists of special processes to facilitate communication over global networks. Trust / To Trust To accept a digital signature and act in a way that would be harmful if the digital signature should be proven ineffective. Trusted Root A trusted root is a public key that has been confirmed as bound to a CA by a user or a system administrator. Software and systems that perform authentication using public key cryptography and certificates assume that the key’s value has been correctly obtained. Trust is confirmed by always accessing the root from a trusted archives base that can only be modified by identified, trusted administrators. Trusted Third Party Independent and impartial third party that contributes to the final security and trustworthiness of computer-based information transfers. Trusting Parties Recipients who act in trust of a certificate or digital signature. Trustworthy System



- 81 -

Computer hardware, software, and procedures that are protected against intrusion and misuse; provide a reasonable level of availability; suited to perform their intended functions; and strengthen the applicable security policy Type of Certificate The defined properties of a certificate that limit its role to a class of applications associated to that exact type. Unambiguous Name See Distinguished Name Universal Resource Locator (URL) A standard device for identifying and locating certain records and other resources located on the World Wide Web. Unverified Information (UVI) Information contained in a certificate and submitted by an applicant to a CA that has not been confirmed by the CA, and for which the CA provides no assurances other than that the information was submitted by the certificate applicant. Information such as titles, professional degrees, accreditations, and registration field information are considered UVI, unless otherwise indicated. User An authorized entity that uses a certificate as applicant, recipient, or trusted party. Does not include the CA who issues the certificate. V Validation of a Certificate The process performed by a recipient or trusted party to confirm that a certificate is valid, and to confirm that it was valid at the date and time a digital signature was created. Validation of a Certificate Application The process performed by the CA, following the submission of a certification request, as a prerequisite for the approval of the application and issuance of a certificate. Validation of a Certificate Chain For each certificate in the chain, the process performed by the recipient or trusted party to: � Authenticate the public key (of each certificate), � Confirm that each certificate is valid � Was issued during its validity period, and that all of the trusted parties acted in compliance with the CPS. Validity Period The period beginning on the date and time a certificate is issued (or later if specified in the certificate) and ending with the date and time on which the certificate expires or is revoked. Verify (a digital signature) To accurately determine that: � The digital signature was created during the certificate’s validity period by the private key corresponding to the public key contained in the certificate. � The message has not been modified since the creation of the digital signature. Violation A violation (or suspected violation) of a security measure (i.e. confidential information was or possible was disclosed or control of this information was lost).



- 82 -

W / X / Y / Z World Wide Web (WWW) A hyper-text based, distributed information system in which users may create, edit, or browse hypertext documents. Graphic publication media and document viewing. Writing Information in a record that is accessible and useable for future reference X.509 The ITU-T (International Telecommunications Union-T) standard for certificates. Designates certificates containing or capable of containing extensions.