THALES CA CERTIFICATION POLICY ROOT CAcrl.thalesgroup.com/certification_policy/A4284000-DOC... ·...

Thales S.A 45, rue de Villiers 92526 Neuilly-sur-Seine Cedex FRANCE

THALES CA

CERTIFICATION POLICY

ROOT CA

THALES ROOT CA

PUBLICATION DATE : 15/04/2005

Thales PKI –Certification prractice Thales Root CA

A4284000-DOC-075-PCACR_EN-V2.0.doc 15/04/2005 Page 3 © Thales S.A 2005 – Tous droits réservés

DOCUMENT

PROJECT:

TITLE: Thales PKI - Ccertification practice Thales Root CA

REFERENCE: A4284000-DOC-075-CPRCA

ACTION NAME DATE SIGNATURE

Author Christel Réman Validators Claude-Luce Imbaud / Paul Dias / Patricia

Violette / Sandrine Paulic / Candice Zimmermann / Julien Dufay / Christel Réman / Patrick Anglard

HISTORY

RELEASE DATE MODIFICATIONS NAME V1.0 14/04/05 Creation Christel Réman

V2.0 31/07/09 New PKI Laurent Broussy



Documents of reference ............................. .................................................................... 8

1 Domain of application .............................. ....................................................... 12 General Presentation......................................................................................... 12

1.1.1 General purpose................................................................................. 12 1.1.2 Policy views........................................................................................ 12

General Definitions ............................................................................................ 13 1.1.3 Definitions........................................................................................... 13 1.1.4 Definitions of the Policy on the Security............................................. 14

List of the Acronyms .......................................................................................... 15 Identification ( OID)............................................................................................ 17 Applications and concerned users groups ......................................................... 17

1.1.5 Concerned Applications ..................................................................... 17 1.1.6 Concerned users groups .................................................................... 17 1.1.7 Applicability of the Policy.................................................................... 19

2 General disposition ............................... ......................................................... 20 2.1 Obligations.......................................................................................... 20

2.1.1 Obligations common to several constituents .................................... 20 2.1.2 Obligations of the RCA...................................................................... 20 2.1.3 Obligations of the RA ........................................................................ 21 2.1.4 Obligations of the delegated CA ....................................................... 22

2.2 Responsibility...................................................................................... 23 2.2.1 Requirements .................................................................................... 23 2.2.2 Limits of the responsibility ................................................................. 23 2.2.3 Other modalities ................................................................................ 23

2.3 Interpretation and application .............................................................. 23 2.3.1 Applicable right.................................................................................. 24 2.3.2 Regulation of the disputes................................................................. 24

2.4 price.................................................................................................... 24 2.5 Publication and associated services.................................................... 24

2.5.1 Published Information........................................................................ 24 2.5.2 Frequency of publication ................................................................... 25 2.5.3 Control of the access......................................................................... 25 2.5.4 Service of publication ........................................................................ 25

2.6 Control of Compliance......................................................................... 25 2.6.1 Frequency of audit of compliance ..................................................... 26 2.6.2 Identity / quality of the auditor ........................................................... 26 2.6.3 Link between the auditor and the verified function............................ 26 2.6.4 Goal of the audit ................................................................................ 26 2.6.5 Measures to be taken following the audit.......................................... 26 2.6.6 Communication of the results............................................................ 27

2.7 Policy of confidentiality........................................................................ 27 2.7.1 Types of information considered as confidential ............................... 27 2.7.2 Types of information considered as confidential ............................... 28 2.7.3 Communication of the causes of revocation of certificate................. 28 2.7.4 Delivery to the legal authorities ........................................................ 28 2.7.5 Delivery at the request of the owner ................................................. 28 2.7.6 Other circumstances of possible Delivery ......................................... 28



2.8 Rights relative to the intellectual property............................................ 28

3 Identification and authentication................. .................................................. 29 3.1 Initial registry....................................................................................... 29

3.1.1 Agreements of names ....................................................................... 29 3.1.2 Required to use explicit names ........................................................... 29 3.1.4 Uniqueness of names ......................................................................... 29

3.1.7 Proof of ownership of a private key................................................... 30 3.1.8 Check of the identity of Organistation ............................................... 30 3.1.9 Check of the identity of an RCA or a constituent .............................. 30 3.1.10 Check of the identity of the delegated CA......................................... 30

3.2 Renewal of certificate at the end of validity ......................................... 31 3.3 Renewal of keys after revocation ........................................................ 31 3.4 request of revocation........................................................................... 31

4 operational Requirements.......................... .................................................... 32 4.1 Request of certificate .......................................................................... 32 4.2 Issue of certificate ................................................................................ 32 4.3 Acceptance of certificate ..................................................................... 33 4.4 Suspension, revocation and recovery of certificate.............................. 33

4.4.1 Possible Causes of revocation.......................................................... 33 4.4.2 people who can ask for a revocation................................................. 33 4.4.3 Procedure of request of revocation ................................................... 34 4.4.4 Time of treatment of a request of revocation .................................... 34 4.4.5 Possible Causes of suspension ........................................................ 34 4.4.6 people who can ask for a suspension ............................................... 34 4.4.7 Procedure of request of suspension ................................................. 35 4.4.8 Limits of the period of suspension..................................................... 35 4.4.9 Frequency of publication of the CRL................................................. 35 4.4.10 Requirements of check of the CRL ................................................... 35 4.4.11 Publication of the causes of revocation............................................. 35 4.4.12 On-line Check of the revocation........................................................ 35 4.4.13 Other forms of publication of the notices of revocation..................... 35 4.4.16 Possible Causes of recovery............................................................. 36 4.17 Persons who can ask for a recovery ................................................. 36 4.4.18 Procedure of demand of recovery..................................................... 36 4.4.19 Time of treatment of a request of recovery ....................................... 36

4.5 Log of the events ................................................................................ 36 4.5.1 Types of registered events ................................................................ 36 4.5.2 Frequency of the logs........................................................................ 37 4.5.3 life of the logs of events..................................................................... 37 4.5.4 Protection of logs of events............................................................... 38 4.5.5 Backup of the logs of events ............................................................. 38 4.5.6 System of logss (internal or external)................................................ 38 4.5.7 Imputability of the events................................................................... 38 4.5.8 Analysis of the vulnaribilities ............................................................. 38

4.6 Files archive......................................................................................... 38 4.6.1 Types of data to be archived............................................................. 38 4.6.2 Period of keeping back of archives ................................................... 39 4.6.3 Protection of archives........................................................................ 39 4.6.4 Procedures of backup of archives..................................................... 39



4.6.5 Needs of timestamp of the logs......................................................... 39 4.6.6 System of backup of archives (internal or external) .......................... 39 4.6.7 Procedures of recovery of archives................................................... 39

4.7 Change of key of a constituent ............................................................ 40 4.8 Recovery in case of disaster or of dishonest compromise................... 40

4.8.2 Revocation of the public key of a constituent.................................... 41 4.8.3 Dishonest compromise of the keys of the constituent....................... 41 4.8.4 Security measure in case of disaster ................................................ 41

4.9 Discontinuance of business of a constituent........................................ 41 5.1 Physical Controls ................................................................................ 42

5.1.1 Geographical Situation and construction of sites .............................. 42 5.1.2 Physical Access ................................................................................ 42 5.1.3 Energy and air-conditioning............................................................... 43 5.1.4 Exposure to liquids ............................................................................. 43 5.1.5 Prevention and fire protection ........................................................... 43 5.1.6 Preservation of the media ................................................................. 43 5.1.7 Destruction ........................................................................................ 43 5.1.8 Site of recovery ................................................................................. 43

5.2 Control of the procedures.................................................................... 43 5.2.1 Reliable roles..................................................................................... 43 5.2.2 Number of persons necessary for every task.................................... 44 5.2.3 Identification and authentication of the roles..................................... 44

5.3 Control of the staff............................................................................... 44 5.3.1 Professional, qualifications, requirements of capacitations...................... 45 5.3.2 Procedures of control of past professionel........................................ 45 5.3.3 Requirements of training ................................................................... 45 5.3.4 Frequency of the training courses..................................................... 45 5.3.5 Management of the RCAeer ............................................................. 45 5.3.6 Penalties for not authorized actions .................................................. 45 5.3.7 Control of the staffs of the contracting companies............................ 45 5.3.8 Documentation supplied to the staff.................................................. 45

6 Inspections of security........................... ........................................................ 47 6.1 Generation and installation of keys ..................................................... 47

6.1.1 Generation of keys ............................................................................ 47 6.1.2 Liberation of key deprived in a constituent........................................ 47 6.1.3 Liberation of key deprived to his(her) owner ..................................... 47 6.1.4 Delivery of public key in an RCA....................................................... 47 6.1.5 Supply of the public key of validation of the RCA in the

constituents ........................................................................................ 47 6.1.6 Supply of the public key of validation of RCA to the users ............... 47 6.1.7 Sizes of the keys ............................................................................... 48 6.1.8 Parameters of generation of the public keys..................................... 48 6.1.9 Quality control of the parameters of public keys ............................... 48 6.1.10 Mode of generation of key (material or software) ............................. 48 6.1.11 Usage of the private key.................................................................... 48

6.2 Protection of the private key................................................................ 48 6.2.1 Standards for the cryptographic modules ......................................... 49 6.2.2 Control of private key by several people .......................................... 49 6.2.3 Recovery of private key..................................................................... 49 6.2.4 Backup of private key........................................................................ 49



6.2.5 Archives of private key ...................................................................... 49 6.2.6 Initialization ofprivate key in the cryptographic module..................... 49 6.2.7 Method of activation of private key.................................................... 49 6.2.8 Method of deactivation of private key................................................ 50 6.2.9 Method of destruction of private key ................................................. 50

6.3 Other aspects of the management of the pairs of keys........................ 50 6.3.1 Archives of the public keys................................................................ 50 6.3.2 Public and private Life Cycle of the key ............................................ 50

6.4 Activation data .................................................................................... 50 6.4.1 Generation and installation of the data of activation ......................... 50 6.4.2 Protection of the data of activation.................................................... 50 6.4.3 Other aspects of the data of activation.............................................. 51

6.5 Security checks of jobs ....................................................................... 51 6.5.1 Specific Requirements of security on jobs ........................................ 51 6.5.2 Level of security jobs......................................................................... 51

6.6 Inspections of the system during its life cycle ...................................... 52 6.6.1 Controls of the developments of the systems ................................... 52 6.6.2 Controls of the management of the security ..................................... 52

6.7 Controls of the network security .......................................................... 52 6.8 Controls of the management of the cryptographic module................... 52

7 Profiles of certificates and CRL.................. ................................................... 53 7.1 Profile of certificates............................................................................ 53

7.1.1 Number of version ............................................................................. 53 7.1.2 Extensions of the certificate .............................................................. 53 7.1.3 Identifiers of objects algorithms......................................................... 53 7.1.4 Format of names ............................................................................... 53 7.1.5 Contrainst relative to names ............................................................. 53 7.1.6 Identifier of object of the policy of certification .................................. 53 7.1.7 Usage of extension of constraints of policy....................................... 54 7.1.8 Syntax and semantics of the qualifiers of policy ............................... 54 7.1.9 Semantics of treatment for the critical extension of the policy of

certification ......................................................................................... 54 7.2 Profile of CRL...................................................................................... 54

7.2.1 Number of version ............................................................................. 54 7.2.2 Extensions of the CRL....................................................................... 54

8 Administration of the specifications .............. ............................................... 56 8.1 Procedures of modification of PC........................................................ 56

8.1.1 Articles which can be modified without notice................................... 56 8.1.2 Change with notices .......................................................................... 56

8.2 Procedures of publication and announcement..................................... 57 8.3 Procedures of approval of CP ............................................................. 57



Documents of reference

Index Title Reference

Documentation PKI de Thales

[1] Dossier de Sécurité [SECU_CASIC]

[2] IEC 10181-1 (1996) - « Information Technology – Open Systems Interconnection – Security Frameworks for Open Systems : Overview First Edition. »

[10181-1]

[3] ISO/IEC 2382-8 (1998 E/F) : « Technologies de l'information - Vocabulaire - Partie 08 : Sécurité ».

[2382-8]

[4] ISO/IEC 7498-2 (1989) - « Systèmes de traitement de l’information – Interconnexion de systèmes ouverts – Modèle de référence de base – Partie 2 : Architecture de sécurité ».

[7498-2]

[5] ISO/IEC 8825-1 (1995) - « Information Technology – ASN.1 Encoding Rules : Specifications of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

[8825-1]

[6] ISO/IEC 9594-1 (1995) - « Information Technology – Open Systems Interconnection : The Directory : Overview of concepts, Models and Services » (Egalement Recommandation ITU-T X.500).

[9594-1]

[7] ISO/IEC 9594-8 (1995) - « Information Technology – Open Systems Interconnection : The Directory : Authentication Framework » (Egalement Recommandation ITU-T X.509 (1997)).

NF ISO/CEI 9594-8 (1996) – « Technologies de l’information – Interconnexions de systèmes ouverts (OSI) – L’annuaire : Cadre d’authentification ».

[9594-8]

[8] Format des certificats utilisés dans les infrastructures de gestion de clés – Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la CISSI.

[CERTIFICAT_PKI]

[9] Décret 98-102 du 24 Février 1998 précisant l’article 28 [L90-1170] relatif aux conditions dans lesquelles sont agréés les organismes gérant pour le compte d’autrui les conventions secrètes de cryptologie (en attendant l'adoption du nouveau décret depuis la LCEN).

[D98-102]

[10] Découpage fonctionnel des autorités d’une PKI - Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la CISSI.

[DECOUPAGE_PKI]

[11] Directive 1993/93/CE du Parlement européen et du Conseil du 13 décembre 1999 sur un cadre communautaire pour les

[DSE]




signatures électroniques – (JOCE du 19 janvier 2000).

[12] Directive du Parlement Européen et du Conseil du 24 Octobre 1995 95/46/CE sur la protection des personnes physiques à l’égard du traitement des données à RCAactère personnel et à la libre circulation de ces données (JOCE du 23 novembre 1995).

[DUE]

[13] Digital Signature and Confidentiality - Certificate Policies - Government of Canada Public Key Infrastructure - Version 2.0 - Août 1998.

[GOC]

[14] Instruction générale interministérielle sur la protection du secret et des informations concernant la défense nationale et la sûreté de l’état n 1300/SGDN/SSD du 12 mars 1982 (document en diffusion restreinte).

[IGI1300]

[15] Instruction générale interministérielle sur la sécurité des systèmes d’information qui font l’objet d’une classification de défense pour eux-mêmes ou pour les informations traitées n 900/SGDN/SSD/DR n 900 /DISSI/SCSSI/DR du 20 juillet 1993 (document en diffusion restreinte).

[IGI900]

[16] Loi n 2000-230 du 13 mars 2000 portant adaptation du droit de la preuve aux technologies de l'information et relative à la signature électronique (JO du 14 mars 2000).

[L00-230]

[17] Loi n 78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés modifiée par la loi n°2004 -801 du 6 août 2004.

[L78-19]

[18] Profil de protection pour une autorité de certification – Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la CISSI. Disponible sur demande à l’adresse donnée au chapitre 1.5.

[PP_AC]

[19] Profil de protection autorité d’enregistrement – Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la CISSI. Disponible sur demande à l’adresse donnée au chapitre 1.5.

[PP_RA]

[20] Profil de protection infrastructures de gestion des clés – Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la CISSI. Disponible sur demande à l’adresse donnée au chapitre 1.5.

[PP_PKI]

[21] Profil de protection sur les outils de sécurisation de message version 1.5 du 24 juin 1998 (PP/9804) – Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la CISSI. Disponible sur demande à l’adresse donnée au chapitre 1.5.

[PP_OSM]

[22] Profil de protection ressource cryptographique pour une infrastructure de gestion des clés – Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la CISSI. Disponible sur demande à l’adresse donnée au

[PP_RCPKI]




chapitre 1.5.

[23] Recommandation pour la protection des systèmes d’information traitant des informations sensibles non classifiées de défense n 901/DISSI/SCSSI du 2 mars 1994.

[R901]

[24] « Internet X.509 Public Key Infrastructure, Certificate and CRL Profile » (Janvier 1999) - Internet Engineering Task Force (IETF) - Network Working Group.

[RFC 2459]

[25] « Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practises Framework » (Mars 1999) - IETF - Network Working Group.

[RFC 2527]

[26] Rôles des exploitants d’une infrastructure de gestion de clés – Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la CISSI.

[ROLES_PKI]

[27] Décret n°2001-272 du 30 Mars 2001 pris pour a pplication de l’article 1316-4 du code civil et relatif à la signature électronique (en partie modifié par décret n°2002-5 35 du 18 Avril).

[DEC]

[28] loi n°2004-575 du 21 juin 2004 pour la confia nce dans l’économie numérique.

[LCEN]



Certification Policy PKI Thales

Without prejudice of reserved rights and authorizat ion, no part of this document can be either reproduced, or registered or introduced into a syst em of consultation, or delivered without the written permission of Thales Inc.

All other demand of permission to reproduce any cop ies of the present Certification Policy must be sent to Thales S.A by using the communications d efined in the paragraph 8.2.



1 Domain of application

A Certification Policy is a set of rules identified by a name, which indicates the conditions of applicability of a certificate for a given communit y, or for applications needing security.

The CP is defined independently of details concerni ng the environment of implementation of the public key infrastructure (PKI) to which it applies . CP establishes what is necessary to conform during the management of the certificates.

The management of a certificate includes all the ph ases of the life cycle of a certificate, from the request of a certificate at the end of life of this certificate (lapsing, revocation).

Thales S.A sets up an Infrastructure of Management of Keys (PKI for Public Key Infrastructure), named Thales PKI, allowing the delivery of digital certificates to the Subscribers of the Information system of the group.

General Presentation

1.1.1 General purpose

This document constitutes the Policy of Certificati on (CP) of the Authority of Certification Root Authority of the Keys Infrastructure Management f Thales.

The Policy expressed in this document is used withi n the framework of the certification of the Authorities of Certification delegated by the PKI o f Thales by the Root Certification Authority of the pki Thales Root CA.

THE RCA to manage the various delegated AC whom it certifies is identified in the following way:

· Thales Root CA

The Politics of Certification defined in the presen t document is intended to be used for the services of certification by the operators of the i nfrastructure of the RCA of the PKI of Thales as well as the delegated CA. i) covers the initialisat ion of the RCA, the administration of the infrastructure of the RCA of the PKI of Thales, the management and the use of keys and delivered certificates.

1.1.2 Policy views

The Policy of Certification applies to all the cert ificates of the PKI of Thales certified by the RCA .

This policy was conceived to be used in certain sit uations, and indicates by consequence the roles and the specific responsibilities of the RCA which delivers this type of certificate, and those of the Registry Authority which has to make the tas ks which are assigned to it by the RCA. The delegated CA (this term is defined in §1.2.1) also has specific obligations which are defined in this policy.

The Users of this document have to consult the RA o f the RCA to obtain more details of the implementation of this policy if it is necessary. The applicability of these certificates will depend on their envisaged uses.

This CP operates certificates such as define below:

The support of storage of the keys is physical and uses a cryptographic module of type smartRCAd .The associated certificates can be or no t stored in this module.



General Definitions

1.1.3 Definitions

Auditor Nominee by a authorized authorities. The role is to proceed in a regular way to controls the implementation of the policies of certification, policies practices statements and the services supplied by the constit uent of the PKI.

Authority Revocation List ( ARL) Lists certificates of delegated AC having been t he object of a revocation. An ARL is a CRL containing only certi ficates of AC.

Authority of Administration ( AA ) Responsible for the PKI possessing a decisionna ryg power within the PKI. It)defines and makes apply th e Policies and the Practices Statements by the PKI, as well as the policy of general security of t he PKI.

Certification Authority Authority that can create and attribute certifica tes. This entity is responsible for certificates signed on his behalf. This authority can, optionally, create the keys of the end users.

Delegated Certification Authority ( delegated CA) Authority, subordinate to the RCA, whom ca create and attribute certificates. In this document, the delegated CA is a applicant of certificates with the RCA.

Root Certification Authority(RCA ) CA taken as reference by a community of end use rs (including the other AC). It is an essential elemen t of the trust which can be granted to him in a given context.

Registry Authority Constituent of the infrastructure of the RCA whi ch verifies the data appropriate for the RCA as well as the constra ints in the use of a certificate, according to the policy of certification. THE RA must be recognized by the RCA for which it publishes requests of certificates and resqests of revocation.

Bi Keys One bi-key is a couple consisted of a private ke y (that must be kept secret and of a public key, necessary for the implementation of a service of cryptography based on asymmetric algorithms.

Trusted chain certificates needed to validate the genealogy of a certificate. Within the framework of this CP, the chain consists of the certificate of the delegated CA and the certificate of the RCA, CA to whom the delegated CA is subordinated.

Common Name ( CN) real Identity or pen name of the holder of the c ertificate (example CN = Jean Dupont).

Constituent of the PKI Platform constituted by at least an IT computer, an application, a cryptology module, a network support and playing a role within the PKI. A constituent can be the server RCA, the server RA, …

Certificate Revocation List ( CRL) List of certificates having been the object of a revocation.

Distinguished Name ( DN) distinctive Name (in the format X.500) for which the certificate is emitted.

Data of activation Pprivate data associates to a holder of pair of keys allowing to implement his private key.

Certification Practices Statement (CPS ) Statement of the procedures and the practices o f certification effectively respected by an RCA for t he management of certificates.



Object Identifier( OID) alphanumeric unique Identifier registered accord ing to the standard of recording ISO to appoint an object or a class of specific objects.

Public Key Infrastructure ( PKI) components, functions and procedures dedicated t o the management of keys and certificates used by securit y services based on the cryptography with public key.

Engineer System He is in charge of the started, the configuratio n and the technical maintenance of the IT platform of the constituent. He assures the administration of the system and the network of this platform.

Cryptographic module A cryptographic module is a material device, of the type smart RCAd, CPMCIA or other, allowing to protect the secr et elements such as the private keys or the data of activation, and to proceed to cryptographic calculations operating)these elements.

Service of Certification Operator ( SCO) Entity running for Thales S.A, the services of certification on the platform. it generates and emi ts certificates which users' community trusts.

Certification Policy (CP) Set of rules, defining the requirements to which the RCA conforms in the implementation of services adapted to certain types of applications. The Policy of Certification must be identified by an OID defin ed by the RA of the RCA.

Security Responsible (OSSI) The person in charge of security is responsible for the application of the policy of physical and functiona l security of a constituent of the PKI and for its environment. He manages the physical access control s to the platform, and is in charge of implementing the security policy.

Renewal (of a certificate) Operation made at the end of period of validity of a certificate and which consists in generating a new certificate for a holder. The re-generation of certificate after revocation is not a renewal.

Revocation (of a certificate) Operation asked by the delegated CA, a constitue nt of the infrastructure of the RCA of the PKI of Thales or a person authorized for that purpose, the result of which is the abolition of the pledge of the RCA on a given certificate, before the end of its period of validity. The request can be the conseque nce of various types of events such as the dishonest compromise of a key, the change of inform ation contained in a certificate, … The operation of revocation is considered ended when th e certificate is published in the list of the revoked certificates.

Service of publication The service of publication makes available the c ertificates of public keys emitted by an CA, to all the potential Users of these certificates. it publishes a list of certificates recognized as valid and a list of revo ked certificates ( CRL). This service can be returned by a ldap (for example, of type X.500), a server of information (Web), a delivery from hand to hand, an application of messaging, …

Certificate User (CU) Any entity (human User, body or technological en tity) having to use certificates of public key in purposes of check of signature. A User of Certificate does not hold necessarily appropriate certificate.

Validation (of certificate) Operation of control of the status of a certific ate or a chain of certification.

Check (of signature) Operation of control of a digital signature.

1.1.4 Definitions of the Policy on the Security

The policy security is all the applicable safety re gulations. We notably define:



Security definitions: defines the constraints of security applied to the infrastructure; this file is validated by the GTSSI.

Operational Procedure: procedure of the hosting sites which fixes main ru les in industrial protection and defines the behavior to be held in t he main special cases. This procedure applies to the whole reserved zone accommodating the CA and its constituents localized on the hosting sites, as well as the associated infrastructure.

Registry Zone : zone used for the operations of registry in mode face to face the access of which is checked by the staff authorized by the group Tha les.

Reserved zone : zone around whose access is restricted to the per sons who have their employment, holders of an access code delivered by the Security guard of the site.

Zone with high safety: zone around whose access is restricted to the pers ons authorized to make very sensitive operations connected to the sec urity of the PKI of Thales and its infrastructures to the SCO (Management of the CA, O peration of recovery, Audit). The Zone with high safety is included in the reserved zone.

List of the Acronyms

French RCAonym French Definition English RCAony m English Definition

AA Authority of Administration

AA Administration Authority

AC Authority of Certification

CA Certification Authority

RCA Authority of Certification Root

CA root Root Certification Authority

RA Authority of Recording

RA Registration Authority

CN usual Name CN Common Name

LAR Lists Authorities Revoked

ARL Authority Revocation List

DN distinctive Name DN Distinguish Name

DCP Statement(Declaration) relative to the Procedures of Certification

CPS Certificate Policy Statement

DSG Direction(Management) Security Groups Thales

DSG Thales Group Security Service

FIPS Standard of federal treatment of data. American governmental standard published by the NIST.

FIPS Federal Information Processing Standard



GTSSI Safety information system workgroup of Thales

GTSSI Security Information System Workgroup (from Thales)

ICP Infrastructure with Public Key

PKI Public Key Infrastructure

IETF Body aiming at the improvement of Internet

IETF Internet Engineering Task Force

PKI Infrastructure of Management of Keys

PKI Public Key Infrastructure

LCR Lists Revoked Certificates

CRL Certificate Revocation List

OC Operator of Certification

CO Certification Operator

OID Identifier of object OID Object to IDENTI FY

OSC Operator of Service of Certification

CSP Certification Provider service

OSSI To preside(Officiate) Security Information system / Person in charge security

ISSO Information Security System Officer

CP Policy of Certification CP Certificate Pol icy

CP2 Procedures and Policy of Certification

CPP Practices and Certificate Policy

PKCS Standards of cryptography with public key developed by Laboratories RSA

PKCS Public Key Cryptographic Standard

PKIX Infrastructure with public key (in compliance with the standard X.509)

PKIX Public Key Infrastructure exchanges X.509

RFC Document of specifications of technologies

RFC Request For Comments

RSA asymmetric Algorithm RSA Rivest Shamir Adelman

SHA-1 algorithm of secure hacking

SHA-1 Secure Hash Algorithm

IF Information system IS Information System

URL Internet Address URL Unique Resource



Locator

Identification ( OID)

The present Certification Policy is registered acco rding to the standard of recording ISO by a unique digital identifier. This OID is connected wi th the unique identifier of the company author of the document.

Every reader thus has the means to verify the membe rship of the document in Thales Inc.

The name of the identification object ( OID) for th e present policy)is: 1.2.250.1.108.1.2

This OID is present in certificates emitted by the RCAof the PKI of Thales.

Applications and concerned users groups

The process of certification and the management of the life cycle of the certificate appeal to a big variety of people in the trusted chain:

· The RCA and its own constituents or services.

· The AA.

· The RA.

· The delegated CA.

· The Users of Certificates.

1.1.5 Concerned Applications

The concerned application is the certification of C A delegated by the PKI of Thales.

1.1.6 Concerned users groups

1.1.6.1 Root Certification Authority (RCA) The RCA is responsible towards its delegated CA, bu t also towards every person trusting a certificate which it emitted, of the whole process of certification, and thus the validity of the certificates which it emits, according to the Polic y of Certification defined by the AA of the RCA and the Statement of the Practices of Certification validated by the AA of the RCA.

The guarantee brought by the RCA comes from the qua lity of the technology implementation, but also of the regulatory and contractual framework wh ich it defines and makes a commitment to make respect.

By this policy, the RCA is in charge:

· to create and to sign the certificates of the de legated CA and to manage the life cycle of these certificates.

· to become known the state of certificates throug h the ARL ( CRL).



The functions of the RCA must be executed by staffs authorized by the AA of the RCA, having knowledge and respecting rules, principles and proc edures expressed in CP and the CPS of the RCA.

The certificate of the RCA is auto-certified, that is the RCA signs itself its own certificate, what allows to arrange a reliable road for the interoper ability of the certificates of public keys of the C A delegated by the group Thales.

The function of registry of certificates is a part of indispensable functions of a PKI.

The function of registry is performed by a constitu ent of the RCA with which it collaborates or which is connected with it

THE RCA processes and confirms the request of regis try and revocation of the certificates of the Registry Authority (RA).

1.1.6.2 Administration Authority ( AA) The Authority of Administration is responsible for the PKI and possesses a decision-making power within the PKI. As such, it promulgates and c onfirms the Policy of Certification which has to identify the obligations of all the external ent ities participating in the services of the PKI and confirms the CPS.

It is a guarantor for the application of the policy of security which governs the PKI. The AA is in charge:

· to publish and make respect CP by the various co nstituents of the PKI and the holders of certificates.

· to validate and make respect the CPS by the vari ous constituents of the PKI and the holders of certificates.

· to check and to audit the PKI and the SCO.

THE AA of the RCA is embodied by the authority qual ified as Thales S.A, is the Information systems Manager of Thales Inc.

1.1.6.3 Registry Authority THE RA applies procedures of identification of the physical persons, according to rules defined by the Authority of Administration its purpose is:

· to coordinate the requests of certificates of th e delegated CA.

· to establish that applicant is represented by th e AA of the delegated CA or a person appointed by the AA of the delegated CA.

· to distribute the certificate in the AA of the d elegated CA or the person appointed by the of the CA delegated on a physical support (diskett e, CD-R).

· to manage and protect the security data of the d elegated AC.

· to maintain, manage, run and protect hardware an d software used to perform these functions

THE RA also has for task to receive the requests of revocation of certificates and has to handle)them.

The RA is a link in the trusted chain between the R CA and the delegated CA. A RA is responsible for all the tasks which are assigned it by the AA o f the RCA.



The functions of the RA must be executed by staffs having knowledge and respecting rules, principles and procedures expressed in CP and the C PS.

1.1.6.4 Delegated Certification Authority ( delegat ed CA) a delegated CA is a CA subordinate to the RCA from whom it obtains a certificate. A delegated CA is capable itself of generating and of managing the life cycle of certificates after obtain a certificate of the RCA.

THE AA of the delegated CA is responsible for the a uthenticity, for the exactness, and for the comprehensiveness of the data of identification sup plied in the RA during the recording.

THE delegated CA is responsible:

· Of the protection, the integrity and the confide ntiality of its private key, and the possible data of activation of certificates.

· Of the security of its material equipments, the software and its networks involved in the use of its certificates.

· Of the use of its private key and its certificat e, which has to be in accordance with the present Certification Policy.

The delegated CA has to communicate to the RCA, by the channels which it will have indicated, defined in the CPS, any information having for cons equence the revocation of its certificate.

1.1.6.5 Certification Service Operator ( CSO) Within the framework of the PKI of Thales, the CSO of the RCA is defined in the CPS.

THE CSO assures the technical, in particular crypto graphic services, necessary for the process of certification. it is in charge of the good funct ioning and of the security of the computing and technical means. It handles the security of the sta ffs, premises and more generally good respect for the procedures.

One of its first missions is to protect the RCA key against any dishonest compromise.

THE CSO knows and applies the procedures of CP and CPS.

Its responsibility can be engaged only by the AA of the RCA and limits itself to the respect for the procedures established in the CPS, validated by the Authority of Administration of the RCA. The Authority of Administration of the RCA has a duty o f control and audit of the CSO.

1.1.6.6 LDAP The deposit of the CRL appears under an entry of LD AP in compliance with the standard LDAP.

1.1.6.7 users The Users of certificates emitted by the RCA are th e delegated CA.

1.1.7 Applicability of the Policy

This Policy of Certification is applicable to the R CA, to the RA as well as to the running team of the RCA and to the delegated CA.



2 General disposition

This chapter contains disposition relative to the r espective obligations of the RCA, the staffs, all entities composing the infrastructure of the RCA an d the delegated CA. It also contains relative legal capacities notably in the applicable law and in the resolution of the disputes.

2.1 Obligations

Some of the obligations are common to all the const ituents which contribute to the fulfillment of the functions of the infrastructure of the RCA, oth er their are specific.

2.1.1 Obligations common to several constituents

The obligations common to the RCA, the RA and in th e delegated CA are the following ones:

· Protect and guarantee the integrity and the conf identiality of their private keys.

· use their public and private keys only in the on ly purposes for which they were emitted and with the authorized computing means.

· Accept the result and the consequences of a conf ormity control and in particular remedy the non-compliances which could be revealed.

The obligations common to the RCA, the RA and the C SO are the following ones:

· Respect and apply the obligations described in p resent CP and the associated CPS.

· Inform their internal procedures

· Implement the technical means and employ the hum an resources necessary for the realization of the services to which they commit in conditions guaranteeing quality and security.

2.1.2 Obligations of the RCA

2.1.2.1 Functions of management of certificates THE RCA must:

· Publish on a Web server accessible to the delega ted CA the certificate of the RCA.

· Publish on a Web site accessible to the delegate d CA the CP, and supply in the delegated CA the address of this site to guarantee that the delegated CA knows their rights and their obligations as regards the use and the manage ment of keys.

· Publish systematically in the LDAP the certifica tes of delegated CA emitted.

· Publish systematically in the CRL of LDAP the ce rtificates of delegated CA revoked.

2.1.2.2 Exactness of the information When the RCA publishes a certificate, the RCA guara ntees that it delivered the certificate in a delegated CA and that the information contained in the certificate in question was verified according to this CP.



THE RCA checks in every demand of certificate or re vocation that the demand emanates from an authorized operator.

THE RCA has to watch that the RA in compliance with all the relevant modalities of present CP, concerning the functioning of the RA.

2.1.2.3 Delay between the request and t he emission of the certificate There is no requirement over the delay between the request of a certificate and the manufacturing. The emission of a certificate is sub ordinated to the respect for the procedure of treatment of the requests.

2.1.2.4 Revocation and renewal of certificates In the case of a request of revocation of the certi ficate of a delegated CA, the RA which receives the request has to make checks before accepting the revocation and introducing the certificate in cause into the CRL protected in integrity and authe nticity.

The RCA has to make sure that all the procedures re lative to the expiration, to the revocation and to the renewal of a certificate are corresponding t o the stipulations of this CP and that they were mentioned in the delegated CA, or deposited in quit e other applicable document describing the modalities of use of the certificate.

2.1.2.5 Protection of the private keys THE RCA guarantees the protection of its private ke y by the storage and the exploitation of its private key through a material resource such as des cribed in §4 and 6.

The private key of the RCA has to be the object of a secure protection which is clarified in the CPS.

2.1.2.6 Limitation as for the use of privates key s of the broadcasting CA THE RCA makes a commitment to use its public and pr ivate keys only in the purposes for which they were emitted and with the specified tools, tha t is the signature of certificates and CRL.

2.1.2.7 Functions of escrow

2.1.3 Obligations of the RA

2.1.3.1 Functions of management of certificates THE RA must:

· Handle)the request of certificate and revocation .

· delivers certificates generated by the RCA in th e delegated CA.

· Protect in confidentiality and in integrity all the data with personal character and from identification collected during the procedures of r egistry.

2.1.3.2 Exactness of the information THE RA has to verify and guarantee the authenticity of the information of identity of the applicant of certificate of delegated CA.

THE RA has to verify that the applicant of certific ate of delegated CA is represented by the AA of the delegated CA or a person appointed by the AA of the delegated CA.



2.1.3.3 Protection of the private keys The RA makes a commitment to protect and to guarant ee the integrity and the confidentiality of its private key and the data of activation.

2.1.3.4 Limitation for the use of private keys of the RA The RA makes a commitment to use its public and pri vate keys only in the purposes for which they were emitted(uttered) and with the specified t ools, that is the authentication to the applications of the RA and the signature of request of certificate or revocation.

2.1.4 Obligations of the delegated CA

2.1.4.1 Functions of management of certificates THE delegated CA makes a commitment to prevent the RA of any dishonest compromises of private keys as soon as possible.

In case of revocation for change of identity, disco ntinuance of business, the AA of the delegated CA or the person appointed by the AA of the delegat ed CA makes a commitment to prevent the RA of the modifications in the change of the status of the certificate of the CA delegated for the compatible delays)with the modification.

2.1.4.2 Exactness of the information THE AA of the delegated CA or the person appointed by the AA of the delegated CA, guarantees the exactness of the information supplied in the RA in the request of certificate.

THE AA of the delegated CA or the person appointed by the AA of the delegated CA, guarantees the exactness of the information supplied in the RA in the request of revocation of a certificate.

2.1.4.3 Protection of private keys of the delegat ed CA The delegated CA guarantees the protection of their private key by the storage of their key deprived through a material cryptographic module of type smartRCAd

The delegated CA is responsible for private keys th at they generate in respect for §6 of present CP.

The delegated CA has to take the precautions of usa ge to avoid the loss, the disclosure, the dishonest compromise, the modification or the use n ot authorized by the private keys which they generate.

2.1.4.4 Limitation as for the use of private keys of the delegated CA THE delegated CA makes a commitment to use certific ates delivered by the RCA and the associated private keys only in the purposes for wh ich they were emitted and with the specified tools, that is the signature of certificates and CR L.

THE CA delegated by the PKI of Thales makes a commi tment to not accept the other certificates that those emitted by the RCA of the PKI of Thales.

2.1.4.5 Responsibility in check THE delegated CA makes a commitment to use the publ ic key extracted from the certificate of the issuer to verify an electronic signature.



2.1.4.6 Responsibility of the check of the revoca tion Theelegated CAakes a commitment to not use any more certificates and associated keys emitted by the RCA the AA of the RCA establishes an notice of dishonest compromise.

2.2 Responsibility

2.2.1 Requirements

In conformance with present CP, the RCA has a best effort undertaking. As a consequence, it returns to any part to prove that the RCA committe d a fault in exercising its duties to question the responsibility of the RCA.

2.2.2 Limits of the responsibility

The responsibility of the RCA would not know how to be questioned in case of resulting damages:

· of the certificates which it emitted, of a use o f these last ones in purposes and\or in conditions others than those were mentioned in pres ent CP;

· of a use of a revoked certificate;

· of a use of a certificate beyond its limit of va lidity;

· of a fault or a negligence of a third party;

· of the disregard by the CA delegated by the obli gations defined in CP;

· of a case of major fact such as aimed at the cla use 2.2.3.1 below.

2.2.3 Other modalities

THE RCA assumes no responsibility as for the damage s connected to the delays, the errors or the losses that could undergo in their transmission any electronic messages, letters, documents.

THE RCA does not guarantee the exactness, the authe nticity and the non-forgery of documents put back during the recording and thus assumes no r esponsibility as for the damages.

2.2.3.1 Major facts A party would not know how to be considered person in charge as any delay or interruption in the execution of its obligations or for any non-ful fillment of obligations resulting of present CP when circumstances giving it place recover from the major facts in the sense of the article 1148 of the Civil code.

2.3 Interpretation and application

It is expressly agreed that as is of the practice a nd the legislative and statutory texts current, the certificates are "simple" said certificates (not qu alified) terms of service of which are defined by present CP.



If an arrangement(measure, disposal) of reference C P turned out not applicable or incompatible with a law or a regulation current, it would be con sidered as null, but this nullity would affect in no way the validity of the other capacities of refe rence CP.

The not applicable character in a context given by an arrangement(measure, disposal) of the CP affect not at all the validity of the other capacit ies, or this arrangement(measure, disposal) except the aforementioned context. The CPS continues to ap ply in the absence of the not applicable arrangement(measure ,disposal) and it, while respec ting the intention of the parties.

2.3.1 Applicable right

Present CP is subjected to the French law.

2.3.2 Regulation of the disputes

For lack of opposite contractual conditions or of c apacities of law and order which would be applicable, any dispute concerning the validity, th e interpretation, the execution of present CP will be subjected to the French competent courts.

2.4 price

2.5 Publication and associated services

2.5.1 Published Information

CP, certain elements of the CPS and the other docum entations of the functioning of the RCA are available on the site http: // www.thalesgroup.com/ certification_polic it

The following elements must be included in the publ ished information, notably via present CP:

· The obligation to use for support of storage of certified keys a material cryptographic module of type smartRCAd.

· The limits of usage of the certificate.

· The limits of responsibility.

· The durations of filing.

· The procedure of regulation of dispute.

· The applicable laws.

· The information available to verify certificates .

The CPS, which gives, among others, the detail of t he procedures and the implementation to assure the protection of the installations of the R CA, is not published in its entirety for safety reasons evident. Elements published by the CPS have to allow to verify the correspondence of the practices of certification with CP.

However the AA of the RCA has to supply, if necessa ry, the version completes of its CPS, during a demand of a body authorized to know it about purp oses of check, audit or control, planned for that purpose in the present policy, as well as with in the framework of the respect for the law.



The service of publication supplies at least the fo llowing information:

· The certificate of the RCA.

· The list of the certificates of the delegated CA .

· The list of certificates revoked the most recent ( CRL).

The CPS has to clarify access modes in this informa tion.

2.5.2 Frequency of publication

The writing of an event giving place to the update and the publication of certificates has to be made in every operation of certification.

The writing of an event giving place to the update and the publication of the CRL has to be made in every operation of revocation, for the delay low er than a working day, if it is not possible to make it real-time. The new published CRL is complet e and is not defined as a delta of the previous CRL. The term of validity of the CRL is cl arified in the CPS.

Elements release mechanisms for the update and the publication of the CRL depend on the operation to be made:

· In the case of a request of revocation of the ce rtificate of a delegated CA, the event release mechanism is the acceptance, after check, a fter the requets of revocation.

· In the case of a major incident such as the loss , the suspicion of dishonest compromise, the dishonest compromise, the theft of the private key of the RCA, the event release mechanism is the observation of this incident by th e RCA.

THE AA of the RCA also has to make sure of the publ ication of information (notably CP) having made the object of a revision further to modificati on, for the period(delay) clarified in the DCP.

2.5.3 Control of the access

The access to the published information, for creati on or modification, will be authorized only to the only staff authorized by the RCA, and it throug h appropriate access controls.

The conditions of implementations of security measu res to check the access to the published information are within the competence of the servic e of publication.

2.5.4 Service of publication

The RCA is in charge to diffuse certificates emitte d to the delegated CA and the CRL through the service of publication.

The access to the CRL must be available 24 hours a day and 7 days a week within the limits of the availability of the system the maximal duration of unavailability of which is defined in the CPS.

2.6 Control of Compliance

THE RCA is responsible for the good functioning of its constituents, according to capacities expressed in the present document. The AA of the RC A will make regular controls of compliance and good functioning of the constituents of the inf rastructure of the RCA.

The audit of compliance is made at request of the A A of the RCA.

The audit includes among others:



· The examination of the validity of the process o f check which the RCA set up to validate the quality of its services.

· A comparison between the practices of the RCA an d its constituents, described in the CPS and the correspondence to these statements.

· A comparison between the practices of the RCA an d its constituents, and the requirements of the CP

The control of correspondence in CP aims at verifyi ng the admissibility of categories of certificates delivered) by an CA. The controls on t he functioning of the constituents of the RCA will be made in this only purpose. It is on no acco unt about the recognition of qualification of the RCA by a people accredited in the sense of the law n°2001-272 of March 30th, 2001 [DECEMBER] and of the law of July 26th, 2004.

2.6.1 Frequency of audit of compliance

The auditor can be also proceed to the audit of a c onstituent of the RCA within the framework of the regular functioning of the RCA. This audit will be made on advance notice, with a frequency to be defined in the CPS, or in a exceptional way.

2.6.2 Identity / quality of the auditor

THE AA of the CA has to approve the people or the e ntity asked to lead the audit of compmliance. This auditor must be able to bring the proof of his experience in the PKI and the technologies of cryptography.

2.6.3 Link between the auditor and the verified f unction

The auditor must connected in no way to the audited parts (RCA, CSO) and to the financial except the contract of audit.

2.6.4 Goal of the audit

The control of compliance will RCA among the follow ing points:

· General dispositions (cf. §2.2 and following one s)

· Identification and authentication (cf. §3)

· operational Needs (cf. §4)

· physical Security check, control of the procedur es, the control of the staff (cf. §5)

· Inspections of security (cf. §6)

· Profile of certificates and CRL (cf. §7)

· Specifications of administration (cf. §8)

2.6.5 Measures to be taken following the audit

The reception by Thales S.A of audit reports so est ablished by third parties does not constitute either the confirmation or the approval by Thales S .A of the contents, the conclusions or the recommendations of these reports. Thales S.A is not the author of audit reports and is not thus responsible for their contents.



At the conclusion of a control of correspondence, t he controller returns to the financier of the audit an notice among the following ones:

"Success", "Failure", " to confirm ".

2.6.6 Communication of the results

The results of the controls of correspondence are c ommunicated only with the AA of the controlled RCA.

It is up to the AA of the RCA to pass on to the ope rators and the administrators of the constituents of the RCA the results concerning them or concerning the delegated AC and to define if the delegated AC needs to be informed abo ut the led action.

In the case of a revocation of certificates emitted (uttered) by the RCA to constituents or to delegated CA, the AA of the RCA informs all the del egated CA informing them about the action. This notice can be emitted by electronic mail.

2.7 Policy of confidentiality

It is called back that the RCA, as administrator of data with personal character, is subjected to the law n°78-17 of January 6th, 1978 " Computing and Li berties " modified by the law n°2004-801 of August 6th, 2004. According to this law, every conc erned person - in this particular case every representative of AC delegate or User has the law)n otably to reach the information which relate to her and, if necessary, to make them rectify.

THE RCA will take all the necessary measures so tha t the obligations resulting from this law are scrupulously respected. This law can be applied thr ough the service agent, in particular the RA having collected this information, the e-mail addre ss appearing on the Web site of the RCA.

THE RCA has to respect strictly all the applicable legal prescriptions and explain on its Web site, the concrete modalities of application of the law. Notably, no personal piece of information collected by an RCA can be revealed without the ass ent of the concerned person, unless the law prescribes it.

2.7.1 Types of information considered as confiden tial

The following information is considered as confiden tial:

· keys deprived of the RCA and its constituents.

· keys deprived of signature of the delegated AC.

· The data of activation of the key deprived of th e RCA and its constituents.

· The newspapers of events of the RCA and its cons tituents.

The key was deprived of digital signature of every delegated AC, as well as the corresponding data of activation, have to remain confidential. Th e disclosure of this secret information by the delegated AC will be made at its risks and dangers, the RCA getting free then of any damage which can result from it.

The results of the controls of correspondence are c onsidered as confidential and cannot be spread(diffused), except when their publication was asked on court or administrative order.

The DCP has to bring precision concerning the types of information considered as confidential.



2.7.2 Types of information considered as confiden tial

The following information is not considered as conf idential:

· certificates;

· The CRL which contain only the numbers of record ing of certificates and dates them revocation.

2.7.3 Communication of the causes of revocation o f certificate

The causes of revocation of certificate can be comm unicated only with the RA by the AA of the delegated AC or the person appointed by the AA of t he delegated AC.

The causes of revocation are considered as confiden tial and protected as a consequence.

2.7.4 Delivery to the legal authorities

The disclosure of the confidential information will be made only in the legal authorities authorized to reach this information according to p resent CP or to the legislative and statutory texts current.

2.7.5 Delivery at the request of the owner

The disclosure of the confidential information can be made to the owner of this information or to the third(third party) authorized at the adequate l evel, at request of the owner.

2.7.6 Other circumstances of possible Delivery

The information relative to the AC delegated and de fined as confidential can be revealed in the AA of the RCA or in the third(third party) authoriz ed by the AA of the RCA.

2.8 Rights relative to the intellectual property

All the rights of intellectual property held(detain ed) by the RCA are protected by the applicable rule. Their disregard may pull civil and\or penal p ursuits.



3 Identification and authentication

3.1 Initial registry

3.1.1 Agreements of names

Names used in a certificate emitted(uttered) within the framework of the present Policy of Certification will be described according to the st andard IS0 / IEC 9594 ( Distinguished Names).

A certificate emitted( by the RCA has to contain in the field Subject: Distinguished Name, distinctive name easy to distinguish and compulsory for the delegated AC.

These names have to be under the shape of a printab le chain X.501 and have to be in accordance with the part(party) 1 of the standard PKIX. The di stinctive name ( DN) X.501, carried in the field Subject of the certificate was have to be empty.

3.1.2 Required to use explicit names

The distinctive name ( DN) X.501, RCAried(worn) in the field Subject of the certificate, has to be, not only easy to distinguish the other names, but a lso unique for the RCA.

The contents of the fields of name Subject and Issu er has to have an explicit link with the authenticated entity.

A distinctive name ( DN) has to consist at least of elements:

· Name of organization ( O )

· usual Name (CN = CommonName)

The distinctive name has to contain the term "Thale s" and a function or an organizational role.

Example: DN = {O = Thales, CN = Thales CA External}

3.1.3 Rules of interpretation of the various for ms of names

No requirement is stipulated.

3.1.4 Uniqueness of names

The uniqueness of a certificate is based on the uni queness of its serial number inside the domain of the RCA. However, the distinctive names must be unique within the PKI.

The uniqueness of names is obtained according to ru les described in §3.1.2.

3.1.5 Procedure of resolution of dispute on the de claration of name

A party which asks for a certificate AC delegated h as to have the law to use the name which she wishes to see representing there. She also has to b e capable of proving that she has the law to use this name in particular.



THE RCA makes a commitment as for the uniqueness of the names of his(her) carried defined in its policy of naming, according to §3.1.1 and §3.1. 2. She will propose procedures of amicable resolution of the individual disputes.

3.1.6 Recognition, authentification and role of the brand names of factory, business and services

The law to use a name which is a mark(of factory, b usiness or services either another distinguishing feature (trademark, signboard, regis tered company name) in the sense of articles L.711-1 and following ones of the Code of the Intel lectual property (codified by the law n°92-957 of July 1st, 1992 and its later modifications) belo ngs to the justifiable holder of this mark of factory, business or services, or this distinguishi ng feature or still to his graduates or transferees.

THE RCA loosens(kicks away) any responsibility in c ase of illicit use by the AC delegated by registered trademarks, notorious marks(brands) and distinguishing features, as well as names of domain.

3.1.7 Proof of ownership of a private key

THE RCA has to verify that the delegated AC is real ly in ownership of the deprived key associated with the public key of check of signature of certif icate which was registered in its certificate.

3.1.8 Check of the identity of Organistation

.

3.1.9 Check of the identity of an RCA or a consti tuent

The identity of the RCA or one of its constituents is verified through the authentication of the person in charge of constituent named(appointed) by the AA of the RCA.

The certificate of the RCA or one of its constituen ts always has to contain in its name an element identifying its function within the PKI in a unique and not ambiguous way.

3.1.10 Check of the identity of the delegated CA

The certificate must be delivered only on recording personally from the AA of the delegated CA or from a person appointed by the AA of the delegat ed AC, in a procedure opposite in face with an Authority of Recording, or more generally, by a representative of the RCA. The identity of the applicant of certificate is verified during this pr ocedure. THE RCA guarantees then the link between the holder of the certificate and the pair of keys.

THE RA has to accept only the demands of certificat es containing the exhaustive list of the required data.

Any demand of certificate of delegated AC must be s ent to the RA.

THE RA has to examine details and documents put bac k(handed) with a reasonable RCAe and verify if they present or not the appearance of cor respondence and validity.

Distribution of certificates by the RA can be direc tly made in the AA of the delegated AC or for one person appointed by the AA of the delegated AC.



3.2 Renewal of certificate at the end of validity

The key bi of the constituents of the infrastructur e of the RCA and the delegated AC must be periodically renewed to minimize the cryptographic attacks.

To facilitate the operation, a new certificate can be obtained while the common(current) certificate is still valid.

THE RCA has to renew its bi-keys at least every ten ( 10 ) years. In this occasion, it is necessary to verify that the demand of renewal results effect ively from the AA of the RCA.

The delegated AC has to renew their bi-keys of sign ature at least every ten ( 10 ) years. In this occasion, it is necessary to verify that the demand of renewal results effectively from the AA of the delegated AC or from a person appointed by the AA of the delegated AC.

Being given the obligation of the RCA to guarantee the correspondence of the information put back(handed) during the recording, he does not have to have of purely technical renewal for the delegated AC there. The check during a renewal or d uring a modification of information being a part of the file, has to be the same that during an initial recording, with the presentation of all th e details asked for this last one.

There is no renewal of keys without re-generation o f keys.

3.3 Renewal of keys after revocation

If a certificate was revoked, he cannot be reactiva ted. He can be the object also never of a renewal. It is necessary to proceed to the certific ation of new keys in the same way as for an initial recording.

After a revocation, the allocation(attribution) and the certification of new keys follow the procedure of initial recording (cf. §3.1). Accordin g to the type of revocation (dishonest compromise of the key, dishonest compromise of the signatory authority of the certificate) it is up to the AA of the delegated AC or the person appo inted by the AA of the AC delegated to formulate a new demand of generation of certificate .

3.4 request of revocation

THE AA of the RCA has to establish and make public the mechanism which it uses to handle) the demands of revocation and establish the validity.

THE RCA has to make sure of the good law)of the per son which makes a demand of revocation. it verifies the validity of the demand either by verif ying a set of information put down during the initial recording, or by means of a valid digital s ignature recognized by the RCA, or of quite other not ambiguous way.

By nature a demand of revocation must be handled as a matter of urgency.

A demand of revocation can be presented only by an authorized entity (cf. §4.4.2) and must be authenticated by the RA.



4 operational Requirements

A single type of certificates is proposed:

· certificates for the AC delegated with recording opposite to face with the AA of the delegated AC or the person appointed by the AA of t he delegated AC.

4.1 Request of certificate

THE RA has to make sure that the applicants of cert ificates of delegated AC follow and respect the procedures and the requirements published by th e AA of the RCA.

The following information has to appear at least in the demand of certificate of delegated AC:

· The name of the AC delegated to use in the certi ficate.

· The public key of the AC delegated, generated by this AC.

· The name of the AA of the delegated AC or the pe rson appointed by the AA of the delegated AC.

· The address of E-mail or the mailing address of the AA of the delegated AC or the person appointed by the AA of the delegated AC.

· The proof of ownership of the deprived key assoc iated with the public key to be certified.

· The proof that the applicant has the powers to m ake the demand in case it is not the AA of the delegated AC which makes the demand.

During a demand of certificate, the RA has to check the details of the demand presented by the AA of the delegated AC or the person appointed by t he AA of the delegated AC.

4.2 Issue of certificate

A demand of certificate obliges in no way the RCA t o emit a certificate.

The broadcast(emission,issue) of a certificate by t he RCA indicates that this one has definitively and completely approved the demand of certificate a ccording to the procedures described in the DCP. The certificate is considered as valid from th e moment when it is accepted by the AA of the delegated AC or the person appointed by the AA of t he delegated AC.

In the reception of a demand of certificate:

· THE RCA has to make sure that the demand was wel l uttered by the RA and that the RA handled the demand, and supplies a track attributab le of its notice.

· THE RCA has to generate and sign the certificate .

· THE RA has to notify to the AA of the delegated AC or to the person appointed by the AA of the AC delegated the provision of its certificat e and all the procedures to be followed to be capable of obtaining it and of using it in case of acceptance.



· THE RA has to give the certificate to the AA of the delegated AC or to the person appointed by the AA of the delegated AC, that is ma ke accessible by average physical appearances or logical the information allowing the obtaining of the certificate.

4.3 Acceptance of certificate

The interview of the AA of the delegated AC or the person appointed by the AA of the AC delegated with the RA is worth acceptance of its pa rt of the certificate and the obligations which connect them to the RCA.

4.4 Suspension, revocation and recovery of certif icate

4.4.1 Possible Causes of revocation

When the trust in a certificate (certificate of del egated AC or a constituent of the infrastructure of the RCA) is questioned, the concerned certificate m ust be revoked and placed in a list of revoked certificates ( CRL).

The following circumstances can be at the origin of the revocation of a certificate:

· Discontinuance of business of the delegated AC.

· Suspicion of dishonest compromise, dishonest com promise, loss or flight(theft) of the private key or the data of activation of the delega ted AC.

· Modification of an information contained in the certificate.

· Suspicion of dishonest compromise, dishonest com promise, loss or flight(theft) of the key deprived of the RCA, or more generally, revocat ion of the certificate of the RCA.

· Decision of change of constituent of the RCA or constituent of recording of the RCA continuation(suite) with non-compliance of the proc edures of the DCP.

Besides the cases of revocation of mentioned certif icates higher, the RCA and the RA can revoke a certificate since it is in ownership of natural i nformation to indicate a reliable loss in a certificate.

More generally, it is called back that the AA of th e RCA can, in its discretion, ask for the revocation of the certificate of a delegated AC or a constituent of the infrastructure of the RCA when it does not respect the obligations expressed in the present Policy of Certification as well as in any law and the applicable regulation.

4.4.2 people who can ask for a revocation

Only can ask for the revocation of a certificate (c ertificate of delegated AC or a constituent of the RCA):

· THE AA of the delegated AC.

· THE AA of the RCA.



4.4.3 Procedure of request of revocation

The various constituents of the RCA have to make su re that during the demand of revocation, all the procedures and the requirements published by th e AA of the RCA are respected.

In case the certificate of delegated AC owes be rev oked (see causes §4.4.1), the AA of the delegated AC has to inform as quickly as possible t he RA. THE delegated AC which can not any more authenticate by signature, the RA will authent icate the demand of revocation:

· Or by means of a valid digital signature recogni zed by the RCA.

· Or according to the same procedure as for the in itial recording (cf. §3.1), that is by a procedure opposite in face with the AA of the deleg ated AC or a person appointed by the AA of the delegated AC and the RA.

· Or by another manual procedure planned for that purpose (for example by verifying a set of information put down during the initial recordin g).

The demand of revocation has to contain explicitly the information of identification of the certificate and his(her) owner. The demand also has to contain when it is possible the cause of revocation and if necessary, the justificatory elem ents of this cause.

The causes of revocation mentioned in the revoked c ertificates have to contain on no account of information deprived on the persons and it accordin g to the national laws.

If the procedure of demand of revocation of a certi ficate is justified and accepted, the revocation is activated.

In every case of revocation of a certificate, the A A of the delegated AC must be informed about the revocation of the certificate. This announcemen t has to indicate the date to which the revocation of the certificate came into effect and can be made by electronic mail.

4.4.4 Time of treatment of a request of revocatio n

In the reception of a demand of revocation from the AA of the delegated AC or the person appointed by the AA of the delegated AC, the RA ana lyzes this demand by verifying the authenticity of the applicant, then passes on it in the constituent of the RCA asked to analyze the causes and possible documentary evidences of revoca tion. If the demand is justified, the RCA revokes the certificate by making introduce the ser ial number of the certificate and possibly the other information into a list of revocation.

The demands of revocation must be treated(handled) at once in reception of the demand.

THE AA of the RCA will be informed at on

THALES CA CERTIFICATION POLICY ROOT CAcrl.thalesgroup.com/certification_policy/A4284000-DOC... ·...

Documents

Transcript of THALES CA CERTIFICATION POLICY ROOT CAcrl.thalesgroup.com/certification_policy/A4284000-DOC... ·...