politique de certification de l'ac - ca … · 4.2.2 approbation ou rejet d'une demande...

Politique de Certification N° page : 1 /124

POLITIQUE DE CERTIFICATION DE L’AC :

CA LCL Certificat RGS Usage Separe

Ref :PC_ Sign_Auth_National_CA_RGS.pdf

____________________________________________________________________________________________________________________________

PC_Sign_Auth_National_CA_RGS v1.1.doc sur 124

CA&CP. Ce document est la propriété du Crédit Agricole Cards and Payment. Son usage est public.

Sa reproduction est régie par le Code de la propriété intellectuelle qui ne l’autorise qu’à l’usage privé du copiste.

POLITIQUE DE CERTIFICATION

DE L'AC :

CA LCL CERTIFICAT RGS USAGE SEPARE

Crédit Agricole Cards and Payments

Date : 29/11/2013

____________________________________________________________________________________________________________________________


CA&CP. Ce document est la propriété du Credit Agricole Cards and Payments. Son usage est public.


Organisation du document / Documents structures :

� Version Française / French version page 01 à page 65

� Version Anglaise / English version page 66 à page 127

Politique de Certification N° page : 3 /124

POLITIQUE DE CERTIFICATION DE L’AC :

CA LCL Certificat RGS Usage Separe

Ref :PC_ Sign_Auth_National_CA_RGS.pdf

____________________________________________________________________________________________________________________________


CA&CP. Ce document est la propriété du Crédit Agricole Cards and Payment. Son usage est public.


POLITIQUE DE CERTIFICATION : AC Objet: Ce document consiste en la politique de certification de l’AC

Numéro de version: 1.1 Nombre de pages : 124 Etat du document: Projet Version finale Rédacteur : OPENTRUST OPENTRUST Diffusion: Externe Interne OPENTRUST Public OPENTRUST

Historique: Date Version Rédacteur Commentaires Validé par 14/11/2013 0.1 EP Création du document 25/11/2013 0.1 EP Relecture GW / EM OPENTRUST 28/11/2013 0.1 EP Relecture Interne LCL/CA-CP 29/11/2013 1.0 EP Validation Les membres du CAP 01/12/2015 1.1 EP Révision annuelle / corrections mineures CA-CP 24/02/2016 1.1 EP Validation Les membres du CAP

____________________________________________________________________________________________________________________________




�

SOMMAIRE

1 INTRODUCTION ______________________________________________________________________ 10

1.1 Généralités ....................................... ......................................................................................................... 10

1.2 Nom du Document et Identification ................. ....................................................................................... 10

1.3 Les composantes de l’Infrastructure de Gestion de C lés ............................................... ..................... 11

1.3.1 Comité d'Approbation des Politiques (CAP) ........................................................................................ 11

1.3.2 Autorité de Certification (AC) ............................................................................................................... 12

1.3.3 Autorité de Certification et Certificats de Test : ................................................................................... 12

1.3.4 Autorité d’Enregistrement (AE) ............................................................................................................ 12

1.3.5 Autorité d’Enregistrement Décentralisées (AED) ................................................................................. 13

1.3.6 Service de Publication (SP) ................................................................................................................. 13

1.3.7 Opérateur de Certification (OC) ........................................................................................................... 13

1.3.8 Porteur ................................................................................................................................................. 13

1.3.9 Autres participants ............................................................................................................................... 13

1.3.9.1 Client ............................................................................................................................................. 14

1.3.9.2 Mandataire de Certification (MC) .................................................................................................. 14

1.3.9.3 Utilisateur de certificat (UC) .......................................................................................................... 14

1.4 Utilisation des certificats ....................... .................................................................................................. 14

1.4.1 Utilisation appropriée des certificats .................................................................................................... 14

1.4.1.1 Certificat de l’AC ............................................................................................................................ 14

1.4.1.2 Certificat de Porteur ..................................................................................................................... 14

1.4.2 Utilisation interdite des certificats ........................................................................................................ 14

1.5 Application de la politique ....................... ................................................................................................ 15

1.5.1 Organisme responsable de la présente politique ................................................................................ 15

1.5.2 Personne responsable ......................................................................................................................... 15

1.5.3 Personne déterminant la conformité de l’implémentation de la présente PC/DPC ............................. 15

1.5.4 Procédure d'approbation du présent document ................................................................................... 15

1.6 Définitions et Acronymes .......................... .............................................................................................. 15

1.6.1 Définitions ............................................................................................................................................ 15

1.6.2 Acronymes ........................................................................................................................................... 19

2 ANNUAIRES ET SERVICES DE PUBLICATION ______________ _______________________________ 20

2.1 Service de publication ............................ ................................................................................................. 20

2.2 Informations publiées ............................. ................................................................................................. 20

2.3 Heure et fréquence de publication ................. ........................................................................................ 20

2.4 Contrôle d'accès au service de publication ........ .................................................................................. 20

3 IDENTIFICATION ET AUTHENTIFICATION ________________ _________________________________ 21

3.1 Nommage ........................................... ....................................................................................................... 21

3.1.1 Types de noms .................................................................................................................................... 21

3.1.2 Utilisation de noms explicites ............................................................................................................... 22

3.1.3 Anonymat ou utilisation de pseudonyme ............................................................................................. 22

3.1.4 Règles d'interprétations des différentes formes de noms.................................................................... 22

3.1.5 Unicité des noms ................................................................................................................................. 22

3.1.6 Reconnaissance, vérification, et rôle des noms de marques déposées.............................................. 22

3.2 Vérification initiale d'identité .................. ................................................................................................. 22

3.2.1 Preuve de possession de la clé privée ................................................................................................ 22

3.2.2 Vérification de l’Identité d’un organisme .............................................................................................. 23

3.2.3 Vérification de l'identité des personnes ............................................................................................... 23

____________________________________________________________________________________________________________________________




3.2.3.1 Porteur ........................................................................................................................................... 23

3.2.3.2 AED et MC ..................................................................................................................................... 23

3.2.4 Informations non vérifiées .................................................................................................................... 23

3.2.5 Validation de l’autorité d’un porteur ..................................................................................................... 23

3.2.6 Critères de reconnaissance ................................................................................................................. 23

3.3 Vérifications aux fins de renouvellement de clés .. ............................................................................... 23

3.3.1 Vérifications aux fins de renouvellement de clés en situation normale ............................................... 23

3.3.2 Vérifications aux fins de renouvellement de clés après révocation du certificat ................................. 24

3.4 Vérifications aux fins de révocation .............. ......................................................................................... 24

4 EXIGENCES OPERATIONNELLES _________________________ ______________________________ 25

4.1 Types de certificat ............................... ..................................................................................................... 25

4.1.1 Origine de la demande de certificat ..................................................................................................... 25

4.1.2 Procédure d'enregistrement et responsabilités ................................................................................... 25

4.2 26

Traitement d'une demande de certificat ............ ................................................................................................. 26

4.2.1 Identification et authentification............................................................................................................ 26

4.2.2 Approbation ou rejet d'une demande de certificat ............................................................................... 26

4.2.3 Durée de traitement d'une demande de certificat ................................................................................ 26

4.3 Emission d'un certificat .......................... ................................................................................................. 26

4.3.1 Actions effectuées par l'AC pendant l'émission d'un certificat ............................................................. 26

4.3.1.1 Certificat Porteur ............................................................................................................................ 26

4.3.2 Notification de l'émission d'un certificat ............................................................................................... 27

4.4 Acceptation d'un certificat ....................... ............................................................................................... 27

4.4.1 Procédure d'acceptation d'un certificat ................................................................................................ 27

4.4.2 Publication d'un certificat par l'AC........................................................................................................ 27

4.4.3 Notification de l'émission d'un certificat par l'AC à d'autres entités ..................................................... 27

4.5 Utilisation des bi-clés et des certificats ........ ......................................................................................... 27

4.5.1 Utilisation des bi-clés et des certificats ................................................................................................ 27

4.5.2 Utilisation des clés publiques et des certificats par les tierces parties ................................................ 27

4.6 Demande d’un nouveau certificat ................... ........................................................................................ 27

4.7 Changement de clés (ou certification d'une nouvelle clé publique) .................................... ............... 27

4.8 Modification d'un certificat ...................... ................................................................................................ 28

4.9 Révocation d'un certificat ........................ ................................................................................................ 28

4.9.1 Motif de révocation d'un certificat ........................................................................................................ 28

4.9.1.1 Certificat Composante IGC ........................................................................................................... 28


4.9.2 Origine d'une demande de révocation ................................................................................................. 29

4.9.2.1 Composante d’IGC ........................................................................................................................ 29


4.9.3 Procédure de demande de révocation ................................................................................................. 29

4.9.3.1 Composante d’IGC ........................................................................................................................ 29

4.9.3.2 Porteur ........................................................................................................................................... 29

4.9.4 Délai accordé au porteur pour formuler la demande de révocation .................................................... 30

4.9.5 Délai de traitement d’une révocation ................................................................................................... 30

4.9.6 Exigences de vérification de révocation pour les tierces parties ......................................................... 30

4.9.7 Fréquences de publication des LCR .................................................................................................... 30

4.9.8 Délai maximum de publication d’une CRL ........................................................................................... 30

4.9.9 Disponibilité d'un système de vérification en ligne de la révocation et de l'état des certificats ........... 30

4.9.10 Exigences de vérification en ligne de la révocation des certificats par les utilisateurs de certificats .. 30

4.9.11 Autres moyens disponibles d'information sur les révocations ............................................................. 30

4.9.12 Exigences spécifiques en cas de compromission de la clé privée ...................................................... 30

4.10 Service d'état des certificats .................... ............................................................................................... 31

4.10.1 Caractéristiques opérationnelles.......................................................................................................... 31

____________________________________________________________________________________________________________________________




4.10.2 Disponibilité de la fonction ................................................................................................................... 31

4.11 Fin de la relation entre Le porteur et l'AC ....... ....................................................................................... 31

4.12 Séquestre et recouvrement de clés ................. ....................................................................................... 31

5 MESURES DE SECURITE PHYSIQUE, PROCEDURES ET MISE EN ŒUVRE _____________________ 32

5.1 Sécurité physique ................................. .................................................................................................... 32

5.1.1 Situation géographique ........................................................................................................................ 32

5.1.2 Accès physique .................................................................................................................................... 32

5.1.3 Energie et air conditionné .................................................................................................................... 32

5.1.4 Exposition aux liquides ........................................................................................................................ 32

5.1.5 Prévention et protection incendie ........................................................................................................ 32

5.1.6 Conservation des supports .................................................................................................................. 32

5.1.7 Mise hors service des supports ........................................................................................................... 32

5.1.8 Sauvegardes hors site ......................................................................................................................... 32

5.2 Mesures de sécurité procédurales .................. ....................................................................................... 33

5.2.1 Rôles de confiance .............................................................................................................................. 33

5.2.2 Nombre de personnes nécessaires à l’exécution de tâches sensibles ............................................... 33

5.2.3 Identification et authentification des rôles ............................................................................................ 33

5.2.4 Rôles exigeant une séparation des attributions ................................................................................... 33

5.3 Mesures de sécurité vis-à-vis du personnel ........ .................................................................................. 33

5.3.1 Qualifications, compétence et habilitations requises ........................................................................... 33

5.3.2 Procédures de vérification des antécédents ........................................................................................ 34

5.3.3 Exigences en matière de formation initiale .......................................................................................... 34

5.3.4 Exigences et fréquence en matière de formation continue ................................................................. 34

5.3.5 Gestion des métiers ............................................................................................................................. 34

5.3.6 Sanctions en cas d’actions non autorisées .......................................................................................... 34

5.3.7 Exigences vis-à-vis du personnel des prestataires externes ............................................................... 34

5.3.8 Documentation fournie au personnel ................................................................................................... 34

5.4 Procédures de constitution des données d’audit .... ............................................................................. 34

5.4.1 Type d’événements à enregistrer ........................................................................................................ 34

5.4.2 Processus de journalisation ................................................................................................................. 35

5.4.3 Protection des journaux d’événements ................................................................................................ 35

5.4.4 Procédures de sauvegarde des journaux d’événements .................................................................... 35

5.4.5 Système de collecte des journaux d’événements................................................................................ 36

5.4.6 Evaluation des vulnérabilités ............................................................................................................... 36

5.5 Archivage des données ............................. .............................................................................................. 36

5.5.1 Type de données archivées ................................................................................................................. 36

5.5.2 Période de conservation des archives ................................................................................................. 36

5.5.3 Protection des archives ........................................................................................................................ 36

5.5.4 Exigences d’horodatage des données ................................................................................................. 36

5.5.5 Système de collecte des archives ....................................................................................................... 36

5.5.6 Procédures de récupération et de vérification des archives ................................................................ 36

5.6 Renouvellement de bi-clé .......................... .............................................................................................. 37

5.6.1 Certificat d'AC ...................................................................................................................................... 37

5.6.2 Certificat de Porteur ............................................................................................................................. 37

5.7 Compromission et plan de reprise .................. ....................................................................................... 37

5.7.1 Procédures en cas d'incident et de compromission ............................................................................ 37

5.7.2 Corruption des ressources informatiques, des logiciels, et/ou des données ...................................... 38

5.7.3 Procédures en cas de compromission de la clé privée d'une entité .................................................... 38

5.7.4 Capacités de reprise d'activité à la suite d'un sinistre ......................................................................... 38

5.8 Fin de vie d'AC ................................... ....................................................................................................... 38

5.8.1 Transfert d’activité ou cessation d’activité affectant une composante de l’IGC .................................. 39

5.8.1.1 AC .................................................................................................................................................. 39

5.8.1.2 Cas spécifique de perte d’agrément :............................................................................................ 39

____________________________________________________________________________________________________________________________




5.8.1.3 AED ............................................................................................................................................... 40

5.8.2 Cessation d’activité affectant l'AC ........................................................................................................ 40

6 MESURES TECHNIQUES DE SECURITE __________________________________________________ 41

6.1 Génération et installation des bi-clés ............ ......................................................................................... 41

6.1.1 Génération des bi-clés ......................................................................................................................... 41

6.1.1.1 Bi-clés d’AC ................................................................................................................................... 41

6.1.1.2 Bi-clés de Porteurs ........................................................................................................................ 41

6.1.2 Fourniture de la clé privée au porteur .................................................................................................. 41

6.1.3 Fourniture de la clé publique à l'AC ..................................................................................................... 41

6.1.4 Fourniture de la clé publique d'AC aux tierces parties ........................................................................ 41

6.1.5 Taille de clés ........................................................................................................................................ 41

6.1.6 Production des paramètres des clés publiques et contrôle de qualité ................................................ 42

6.1.7 Utilisation de la clé (selon le champ "key usage" du certificat X 509 V3) ............................................ 42

6.2 Protection des clés privées et normes relatives au module cryptographique ............................ ...... 42

6.2.1 Normes applicables aux ressources cryptographiques et contrôles ................................................... 42

6.2.2 Contrôle de la clé privée par de multiples personnes .......................................................................... 42

6.2.3 Séquestre de clé privée ....................................................................................................................... 42

6.2.4 Sauvegarde de clé privée .................................................................................................................... 42

6.2.4.1 AC .................................................................................................................................................. 42

6.2.4.2 Porteur ........................................................................................................................................... 42

6.2.5 Archivage de clé privée ........................................................................................................................ 42

6.2.6 Importation / exportation d'une clé privée ............................................................................................ 43

6.2.7 Stockage d'une clé privée dans un module cryptographique .............................................................. 43

6.2.7.1 AC .................................................................................................................................................. 43

6.2.7.2 Porteur ........................................................................................................................................... 43

6.2.8 Méthode d'activation d'une clé privée .................................................................................................. 43

6.2.8.1 AC .................................................................................................................................................. 43

6.2.8.2 Porteur ........................................................................................................................................... 43

6.2.9 Méthode de désactivation d'une clé privée .......................................................................................... 43

6.2.9.1 AC .................................................................................................................................................. 43

6.2.9.2 Porteur ........................................................................................................................................... 43

6.2.10 Méthode de destruction d'une clé privée ............................................................................................. 43

6.2.10.1 AC .................................................................................................................................................. 43

6.2.10.2 Porteur ........................................................................................................................................... 44

6.2.11 Certification des ressources cryptographiques .................................................................................... 44

6.3 Autres aspects de la gestion des bi-clés .......... ..................................................................................... 44

6.3.1 Archivage des clés publiques .............................................................................................................. 44

6.3.2 Durée de validité opérationnelle des certificats et durée d'utilisation des bi-clés ................................ 44

6.3.2.1 AC .................................................................................................................................................. 44

6.3.2.2 Porteur ........................................................................................................................................... 44

6.4 Données d'activation .............................. ................................................................................................. 44

6.4.1 Génération et installation des données d'activation ............................................................................ 44

6.4.1.1 AC .................................................................................................................................................. 44

6.4.1.2 Porteur ........................................................................................................................................... 44

6.4.2 Protection des données d'activation .................................................................................................... 44

6.4.2.1 AC .................................................................................................................................................. 44

6.4.2.2 Porteur ........................................................................................................................................... 44

6.4.3 Autres aspects touchant aux données d'activation .............................................................................. 45

6.4.3.1 AC .................................................................................................................................................. 45

6.4.3.2 Porteur ........................................................................................................................................... 45

6.5 Mécanismes de sécurité des systèmes informatiques . ....................................................................... 45

6.5.1 Exigences techniques de sécurité des ressources informatiques ....................................................... 45

6.5.2 Indice de sécurité informatique ............................................................................................................ 45

____________________________________________________________________________________________________________________________




6.6 Contrôles techniques du système pendant son cycle d e vie ............................................. ................. 45

6.6.1 Contrôle des développements des systèmes ...................................................................................... 45

6.6.2 Contrôles de gestion de la sécurité ..................................................................................................... 46

6.6.3 Contrôle de sécurité du système pendant son cycle de vie ................................................................ 46

6.7 Mécanismes de sécurité du réseau .................. ...................................................................................... 46

6.8 Horodatage/Système de datation .................... ....................................................................................... 46

7 CERTIFICATS, CRL, ET PROFILS OCSP _________________ _________________________________ 47

7.1 Profil de Certificats ............................. ...................................................................................................... 47

7.1.1 Extensions de Certificats ..................................................................................................................... 47

7.1.1.1 Certificat AC .................................................................................................................................. 47


7.1.2 Identifiant d'algorithmes ....................................................................................................................... 50

7.1.3 Formes de noms .................................................................................................................................. 50

7.1.4 Identifiant d'objet (OID) de la Politique de Certification ....................................................................... 50

7.1.5 Extensions propres à l'usage de la Politique ....................................................................................... 50

7.1.6 Syntaxe et Sémantique des qualificateurs de politique ....................................................................... 50

7.1.7 Interprétation sémantique de l'extension critique "Certificate Policies" ............................................... 50

7.2 Profil de LCR ..................................... ........................................................................................................ 52

7.2.1 LCR et champs d'extensions des LCR ................................................................................................ 52

7.3 Profil OCSP ....................................... ........................................................................................................ 52

8 CONTROLES DE CONFORMITE ET AUTRES EVALUATIONS _____ ____________________________ 53

8.1 Fréquence et motifs des audits .................... .......................................................................................... 53

8.2 Identité / Qualification des auditeurs ............ ......................................................................................... 53

8.3 Lien entre l'auditeur et l'entité contrôlée ....... ........................................................................................ 53

8.4 Points couverts par l'évaluation .................. ........................................................................................... 53

8.5 Mesures prises en cas de non-conformité ........... ................................................................................. 53

8.6 Communication des résultats ....................... .......................................................................................... 53

9 AUTRES DISPOSITIONS COMMERCIALES ET JURIDIQUES ____ ______________________________ 54

9.1 Tarifs ............................................ .............................................................................................................. 54

9.1.1 Tarifs pour l'émission et le renouvellement de certificats .................................................................... 54

9.1.2 Tarifs pour l’accès aux certificats ......................................................................................................... 54

9.1.3 Tarifs pour l’accès aux LCR et aux informations d'état des certificats ................................................ 54

9.1.4 Tarifs pour d'autres services ................................................................................................................ 54

9.1.5 Politique de remboursement ................................................................................................................ 54

9.2 Responsabilité financière ......................... ............................................................................................... 54

9.2.1 Couverture par les assurances ............................................................................................................ 54

9.2.2 Autres ressources ................................................................................................................................ 54

9.2.3 Couverture et garantie concernant les entités utilisatrices .................................................................. 54

9.3 Confidentialité des informations et des données pro fessionnelles ..................................... .............. 54

9.3.1 Périmètre des informations confidentielles .......................................................................................... 54

9.3.2 Informations hors du périmètre des informations confidentielles ........................................................ 55

9.3.3 Obligations en terme de protection des informations confidentielles .................................................. 55

9.4 Protection des données à caractère personnel ...... .............................................................................. 55

9.4.1 Politique de protection des données personnelles .............................................................................. 55

9.4.2 Informations considérées comme personnelles .................................................................................. 55

9.4.3 Informations à caractère non personnel .............................................................................................. 55

9.4.4 Obligations en terme de protection des données personnelles ........................................................... 55

9.4.5 Consentement exprès et préalable à l'utilisation de données à caractère personnel ......................... 55

9.4.6 Obligations en terme de protection des données personnelles ........................................................... 55

9.4.7 Droits de la personne concernée : ....................................................................................................... 56

9.5 Droits relatifs à la propriété intellectuelle ..... ......................................................................................... 56

____________________________________________________________________________________________________________________________




9.6 Obligations et garanties........................... ................................................................................................ 56

9.6.1 Obligations communes ........................................................................................................................ 56

9.6.2 Obligations et garanties du CAP .......................................................................................................... 56

9.6.3 Obligations et garanties de l'AC ........................................................................................................... 57

9.6.4 Obligations de l’AE ............................................................................................................................... 57

9.6.5 Obligation et garanties de l’AED .......................................................................................................... 58

9.6.6 Mandataire de certification (MC) .......................................................................................................... 58

9.6.7 Obligations et garanties du Porteur ..................................................................................................... 58

9.6.8 Obligations et garanties du SP ............................................................................................................ 59

9.6.9 Obligations et garanties des autres participants .................................................................................. 59

9.6.9.1 Client ............................................................................................................................................. 59

9.6.9.2 Obligations et garanties de l’UC .................................................................................................... 59

9.7 Limite de garantie ................................ ..................................................................................................... 60

9.8 Limites de responsabilité ......................... ............................................................................................... 60

9.9 Indemnités ........................................ ......................................................................................................... 61

9.10 Durée et fin anticipée de validité de la PC ....... ...................................................................................... 61

9.10.1 Durée ................................................................................................................................................... 61

9.10.2 Résiliation ............................................................................................................................................. 61

9.10.3 Effets de la résiliation et survie ............................................................................................................ 61

9.11 Amendements ....................................... .................................................................................................... 61

9.11.1 Procédure pour apporter un amendement ........................................................................................... 61

9.11.2 Mécanisme et délais des notifications ................................................................................................. 61

9.11.3 Motifs selon lesquels un OID doit être changé .................................................................................... 61

9.12 Règlement des différends .......................... ............................................................................................. 62

9.13 Droit applicable .................................. ....................................................................................................... 62

9.14 Conformité au droit applicable .................... ........................................................................................... 62

9.15 Divers ............................................ ............................................................................................................. 62

9.15.1 Totalité de l'entente .............................................................................................................................. 62

9.15.2 Affectation ............................................................................................................................................ 62

9.15.3 Divisibilité ............................................................................................................................................. 62

9.15.4 Exonération des droits ......................................................................................................................... 62

9.15.5 Force majeure ...................................................................................................................................... 62

9.16 Autres dispositions ............................... ................................................................................................... 62

10 RÉFÉRENCES ________________________________________________________________________ 63

____________________________________________________________________________________________________________________________




1 INTRODUCTION

1.1 Généralités Le but de la présente Politique de Certification (PC) est de fournir aux Clients/Porteurs du Groupe Crédit Agricole les informations relatives aux garanties offertes par les certificats porteurs qu’il émet, ainsi que les conditions d’utilisation de ces certificats. Ce document décrit la PC inhérente à l’Autorité opérationnelle de Certification ci-après désignée comme AC opérationnelle (noté aussi AC) de l'Infrastructure à Clés Publiques du CREDIT AGRICOLE CARDS AND PAYMENTS gérée par la SNC CREDIT AGRICOLE CARDS AND PAYMENTS (anciennement GIE CEDICAM). La dénomination de l’Infrastructure à Clés Publiquement, anciennement CEDICAM, est modifiée depuis le 21 mars 2012 pour devenir SNC Crédit Agricole Cards & Payments. Ce changement de dénomination et de nature juridique n’emporte pas changement de la personne morale qui conserve le même numéro d’identification 723 001 467 RCS Paris, respecte les mêmes obligations et apporte les mêmes garanties en qualité d’Autorité de Certification. De ce fait et pour des raisons tant techniques que fonctionnelles et pratiques les « OU » (Organisation Unit présent dans les certificats) des AC comportant l’ancienne raison sociale seront conservées, jusqu’au renouvellement des AC. Une PC est définie indépendamment des modalités de mise en œuvre de l'Infrastructure à Clés Publiques (ICP) à laquelle elle s'applique. Elle décrit les exigences auxquelles l'ICP doit se conformer pour l'enregistrement et la validation des demandes de certificats, et pour la gestion des certificats. Les procédures de certification sont rassemblées dans un document appelé Déclaration des Pratiques de Certification (DPC), distinct de la PC, qui décrit comment ces exigences sont atteintes en pratique. La gestion des certificats couvre toutes les opérations relatives à la vie d'un certificat, depuis son émission jusqu'à la fin de vie de ce certificat (péremption, révocation). Dans la suite du document, seul le terme AC sera principalement utilisé. L’AC est une AC répondant répond aux exigences prévues :

� par la réglementation Européenne ETSI 102042, � par les normes RFC 5280 � par le Référentiel Général de Sécurité (RGS), PC type authentification et signature

pour les « Administrations et Entreprises au niveau ** (2 étoiles ) » pour ce qui concerne les certificats électronique X509v3 et les services de signature électronique et d’authentification.

1.2 Nom du Document et Identification La présente PC appelée : « CA LCL Certificat RGS Usage Separe » est la propriété de CREDIT AGRICOLE CARDS AND PAYMENTS. Cette PC est enregistrée par un numéro d'identifiant d'objet (OID) qui est : 1.2.250.1.104.3.1.1.1.1.9.1.1 La DPC correspondante est identifiée par un numéro d'identifiant d'objet (OID) qui est : 1.2.250.1.104.3.1.1.2.1.9.1.1 . Des éléments plus explicites comme le nom, le numéro de version, la date de mise à jour, permettent d’identifier la présente PC et la DPC, néanmoins le seul identifiant de la version applicable de la PC et de la DPC est l’OID associé. Les PC et DPC correspondantes aux OID ci-dessus sont ci-après désignées sous le nom de "PC" et de "DPC".

____________________________________________________________________________________________________________________________




1.3 Les composantes de l’Infrastructure de Gestion de Clés Pour délivrer les certificats, l’AC s’appuie sur les services suivants :

- Service d’enregistrement : ce service collecte et vérifie les informations d'identification du porteur qui demande un certificat, avant de transmettre la demande de certificat au service de demande de certificat ;

- Service de demande de certificat : ce service crée une demande de certificat, à l’aide des informations

fournies par le service d'enregistrement dans le but de créer et de transmettre une demande de certificat au service de génération de certificat ;

- Service de génération de certificat : ce service génère les certificats électroniques des porteurs à partir des

informations transmises par le service de demande de certificat ; - Service de personnalisation et de gestion des supports de bi-clés : ce service permet de personnaliser

graphiquement les supports de bi-clé(s) cryptographique(s) selon les données fournies par le service de génération de certificats. Ce service permet de définir un code de déblocage de support matériel ;

- Service de retrait et de révocation au porteur : ce service permet au porteur de retirer son certificat ainsi

que de le révoquer ;

- Service Client : ce service met en œuvre le service de déblocage des supports matériels des porteurs ;

- Service de révocation de certificats : ce service traite les demandes de révocation des certificats des porteurs et détermine les actions à mener, dont la génération des Liste de Certificats Révoqués (LCR) ;

- Service de Publication : ce service met à disposition des utilisateurs de certificat (UC) les informations

nécessaires à l’utilisation des certificats émis par l’AC (conditions générales d’utilisation, politique de certification publiée par l'AC, certificat d'AC, certificats porteurs, …), ainsi que les informations de validité des certificats issues des traitements du service de gestion des révocations (LCR, avis d’information, …) ;

- Service de journalisation et d’audit : ce service permet de collecter l’ensemble des données utilisées et ou

générées dans le cadre de la mise en œuvre des services d’IGC afin d’obtenir des traces d’audit consultables. Ce service est mis en œuvre par l’ensemble des composantes techniques de l’IGC.

La présente PC définit les exigences de sécurité pour tous les services décrits ci-dessus dans la délivrance des certificats par l’AC aux porteurs. La Déclaration des Pratiques de Certification (notée DPC) donnera les détails des pratiques de l’IGC dans cette même perspective. Les composantes de l'IGC mettent en œuvre leurs services conformément à la présente PC et la DPC associée.

1.3.1 Comité d'Approbation des Politiques (CAP) Comité qui est constitué de représentants du CREDIT AGRICOLE CARDS AND PAYMENTS, pour créer, contrôler le respect et faire évoluer la documentation des politiques régissant l’ICP. En tant qu’autorité, le CAP doit :

- Définir et valider l’organisation de l’IGC et autoriser la création d’AC et d’ACR ; - Définir et contrôler la présente PC et la DPC associée ; - Contrôler la mise en œuvre de la DPC ; - Valider les accords d’interopérabilité avec d’autres IGC ; - Arbitrer les litiges ; - Procéder, le cas échéant, aux demandes de révocation de l’ACR Opérationnelle et/ou de l’AC

Opérationnelle.

____________________________________________________________________________________________________________________________




1.3.2 Autorité de Certification (AC)

Autorité à laquelle le Client fait confiance pour émettre et gérer des certificats porteur et des LCR*. Afin de lever l’ambiguïté terminologique concernant l’Autorité de Certification, les conventions suivantes seront prises pour ce document :

- Le terme Autorité Certifiante désigne le concept d’autorité légale émettant des certificats pour une communauté ;

- Le terme Autorité opérationnelle de Certification (AC opérationnelle) correspond à l’entité organisationnelle

et technique qui reçoit la demande de certificat, constitue le gabarit de certificat et le signe avec sa clé privée. Lorsqu’il est question de certificat d’AC, c’est toujours l’AC opérationnelle qui est évoquée.

- Le terme d’Autorité de Certification (AC) désigne de manière indifférenciée ces deux concepts. L’AC met en œuvre une PC et une DPC afin de gérer des certificats porteurs. L’AC Opérationnelle possède un certificat d’AC gérer par une ACR Opérationnelle du CREDIT AGRICOLE CARDS AND PAYMENTS. L’AC authentifie et reconnaît plusieurs AE dans le cadre de la gestion des certificats porteur.

1.3.3 Autorité de Certification et Certificats de T est : Pour mener des tests, le CREDIT AGRICOLE CARDS AND PAYMENTS utilise des certificats de tests. Pour ce faire, le CREDIT AGRICOLE CARDS AND PAYMENTS utilise l’AC de production. La PC et de la DPC donne les détails de la gestion des certificats de test en fonction du choix de l’AC. Lorsqu’une différence existe alors elle est précisée dans la PC et la DPC. Les certificats de tests ne peuvent servir qu’à des fins de tests dans le cadre d’une application clairement identifiée dans la demande de certificat ou le protocole de test défini entre le porteur et l’AC. Les certificats de tests ne peuvent en aucun cas servir à engager le porteur et le responsable de l’application comme un certificat de production. Toutefois, les obligations de protection et d’utilisation du certificat pour le porteur et l’AC sont identiques à celles définies pour les certificats de production.

1.3.4 Autorité d’Enregistrement (AE) Entité responsable de l’identification et de l’authentification des sujets des certificats, mais qui ne signe ni ne délivre des certificats. L’AE réceptionne et traite les demandes de révocation de certificat. L’AE est utilisée pour la mise en œuvre des services d’enregistrement de demandes de certificats, de remise aux porteurs, de révocation de certificats et journalisation et d’audit. L’AE est chargée d’authentifier et d’identifier les porteurs. Toutefois, l’AE délègue l’enregistrement de demandes de certificats et de révocation à des AED. De même, un Client peut utiliser un Mandataire de Certification (MC). L’AE qui valide les demandes de certificat et de révocation des porteurs. La relation entre les AED et l'AC est formalisée par une convention de service liant l'AED avec l'AC précisant les droits et obligations des parties. La relation entre les MC et les AED est formalisée par un contrat liant le Client avec l'AED précisant les droits et obligations des parties et les modes de résolution des litiges. La PC ne spécifie la gestion du certificat porteur qu’en utilisant le terme générique AE et AED. La DPC précisera les différentes répartition des opérations et procédures entre, l’AE, l’AED et le MC pour la gestion d’un certificat porteur en fonction de l’entité qui met en œuvre l’AE et les AED. En effet, chaque AE peut avoir ses propres procédures afin de répondre aux exigences de la PC et de la DPC.

____________________________________________________________________________________________________________________________




Dans tous les cas, l’AE, l’AED et le MC agissent conformément à la PC et à la DPC associée.

1.3.5 Autorité d’Enregistrement Décentralisées (AED ) Les Autorités d’Enregistrement Décentralisées (AED) correspondent aux entités en relation directe avec les Clients. Elles correspondent à une décentralisation de la fonction enregistrement auprès des distributeurs de l’offre, chargés de sa commercialisation. Le rôle des AED consiste en particulier à enregistrer les demandes de certificats porteurs et à vérifier que les demandeurs et les porteurs de certificat sont identifiés, que leur identité est authentique et que les contraintes liées à l’usage d’un certificat sont remplies, tout cela conformément à la présente PC. Les AED réceptionnent et vérifient également, selon les critères établis dans la présente PC, des demandes de révocation de certificats et les transmettent à leur AE de rattachement pour traitement. En aucun cas, l’AED n’a accès aux moyens qui lui permettrait d'activer et d'utiliser la clé privée, associée à la clé publique contenue dans le certificat, délivré au porteur.

1.3.6 Service de Publication (SP) Le SP est utilisé pour la mise en œuvre du service de publication (Se reporter au § 2). Le SP agit conformément à la PC et à la DPC associée.

1.3.7 Opérateur de Certification (OC) L’Opérateur de Services certification assure des prestations techniques, en particulier cryptographiques, nécessaires au processus de certification, conformément à la présente PC et à la DPC associée que met en œuvre l’AC. L’OC est techniquement dépositaire de la clé privée de l’ACR utilisée pour la signature des certificats porteur. Sa responsabilité se limite au respect des procédures que l’AC définit afin de répondre aux exigences de la présente PC ainsi qu’à ses propres procédures. De plus, l’OC mène une analyse de risque permettant de déterminer les objectifs de sécurité propres à couvrir les risques métiers de l'ensemble de l'IGC et les mesures de sécurité techniques et non techniques correspondantes à mettre en œuvre. L’OC possède aussi un plan de continuité sur lequel s’appuie l’AC pour la continuité des services d’IGC. Cette analyse de risques et ce plan de continuité couvrent le seul périmètre de l’OC en tant qu’hébergeur de moyens qui permettent à l’AC de mettre en œuvre ses services d’IGC. Dans la présente PC, son rôle et ses obligations ne sont pas distingués de ceux de l’AC. Cette distinction sera précisée dans la DPC.

1.3.8 Porteur Un porteur est une personne physique qui met en œuvre la clé privée, correspondant à la clé publique certifiée par l’AC, afin de signer électroniquement un document avec des logiciels de signature et de procéder à des contrôle d’accès. Le porteur est une personne physique qui utilise un certificat au nom du Client. Le Client peut avoir un ou plusieurs Porteurs. Le Porteur peut également être désigné sous le nom de porteur de certificat. Dans la phase amont de certification il est un demandeur de certificat et dans le contexte du certificat X.509v3 il est un sujet.

1.3.9 Service Client (SC) : Le Service Client du CRÉDIT AGRICOLE CARDS AND PAYMENTS, est un service accessible par téléphone, qui permet au porteur de débloquer une situation technique liée à l’installation et à l’emploi de son certificat.

1.3.10 Autres participants

____________________________________________________________________________________________________________________________




1.3.10.1 Client Avant de procéder à des demandes de certificat et utiliser plus largement les services de certification de l’AC, le Client doit avoir préalablement établit un contrat de souscription au service de certification. Le Client contracte ce contrat de souscription au service de certification avec l’AED. Le Client peut mandater un ou plusieurs MC pour la gestion des certificats des Porteurs. Le Client est soit une « Entreprise » soit une « Administration ».

1.3.10.2 Mandataire de Certification (MC) Le MC est une personne physique, dûment identifiée, appartenant à l’entreprise et ayant délégation pour assurer au nom du Client la gestion des certificats porteurs, en particulier recueillir et valider les pièces du dossier d’enregistrement lors d’un face-à-face avec le demandeur (futur porteur). Les prérogatives du MC lui permettent de demander et/ou de révoquer les certificats porteurs des Porteurs du Client. Une seule et même personne peut tenir les rôles de Porteur et de MC simultanément. Un Client peut avoir un ou plusieurs Mandataires de Certification. Le Mandataire de Certification doit être en mesure de vérifier les pièces d’identité présentées par les Porteurs et de certifier les photocopies de ces pièces conformes.

1.3.10.3 Représentant d’Entreprise : Personne physique qui peut avoir le rôle de Mandataire de Certification et peut être nommément l’un des Représentants Légaux de l’Entreprise

1.3.10.4 Utilisateur de certificat (UC) Application utilisatrice*, personne physique ou morale, organisme administratif ou système informatique matériel qui utilisent un certificat de porteur, afin de valider les fonctions de sécurité mises en œuvre à l’aide des certificats (signature, chiffrement et authentification). Dans le cadre de cette PC, l'UC doit valider les certificats porteurs en utilisant les certificats d’AC et d’ACR et contrôler les LCR et LAR.

1.4 Utilisation des certificats

1.4.1 Utilisation appropriée des certificats

1.4.1.1 Certificat de l’AC Le certificat de l’AC sert à authentifier les certificats porteurs. La clé privée associé au certificat d’AC sert pour :

- La signature de certificat de porteur ; - La signature de LCR.

1.4.1.2 Certificat de Porteur La liste des applications utilisatrices dans le cadre desquelles les certificats numériques délivrés par l’AC peuvent être utilisés est publiée sur le site web des AE : http://www.ca-certificat-plus.com. En cas de modification de la liste des applications pouvant être utilisées par les certificats, le Client sera informé par l’AED et par tout moyen écrit de la mise en ligne de la nouvelle liste un mois avant son entrée en vigueur. Si le Client refuse la modification proposée, il aura le droit de résilier le contrat de souscription, sans frais, durant le mois précédant la date de son entrée en vigueur. A défaut de résiliation du contrat de souscription pendant le délai d’un mois, le Client sera réputé avoir accepté la nouvelle PC.

1.4.2 Utilisation interdite des certificats L’AED, l’AE et l’AC déclinent toute responsabilité dans l'usage que ferait un Porteur de son certificat dans le cadre d'une application non mentionnée dans le paragraphe précédent. En particulier, ne sera acceptée aucune plainte,

____________________________________________________________________________________________________________________________




de quelque sorte que ce soit, de Porteurs ou de Mandataires de Certification, liée à des litiges sans rapport avec les applications mentionnées dans le précédent paragraphe. Les utilisations de certificats émis par l'AC à d'autres fins que celles prévues au § 1.4.1 ci-dessus ne sont pas autorisées. En pratique, cela signifie que l'AC ne peut être en aucun cas tenue pour responsable d'une utilisation des certificats qu'elle émet autre que celles prévues dans la présente PC. Les certificats ne peuvent être utilisés que conformément aux lois applicables en vigueur, en particulier seulement dans les limites autorisées par les lois sur l'importation et l'exportation et les lois, décrets, arrêtés et directives propres à la signature électronique.

1.5 Application de la politique 1.5.1 Organisme responsable de la présente politiqu e

La présente PC est sous la responsabilité du CAP.

1.5.2 Personne responsable Coordonnées de la personne ou de la direction responsable de l’élaboration de la PC : Fonction, titre de l'entité responsable

Adresse mél Adresse courrier

Responsable Certification

[email protected] 83, boulevard des Chênes 78280 - GUYANCOURT Immeuble PROVENCE

1.5.3 Personne déterminant la conformité de l’implé mentation de la présente PC/DPC

La conformité de la Déclaration des Pratiques de Certification (DPC- CA LCL Certificat RGS Usage Separe) à la Politique de Certification (Politique de Certification CA LCL Certificat RGS Usage Separe) est déterminée par le Comité d’Approbation des Politiques de l’Autorité Certifiante sous la responsabilité de : Grégoire LUNDI . Pour des raisons de confidentialité les membres de ce Comité sont cités dans la DPC.

1.5.4 Procédure d'approbation du présent document Cette PC sera revue lors de modifications par le Comité d'Approbation des Politiques de l’Autorité Certifiante, notamment pour :

- Assurer sa conformité aux normes de sécurité attendues par les applications qui référencent des familles de certificats porteurs ;

- Adapter aux évolutions technologiques - Adapter aux évolutions organisationnelles.

Ce présent paragraphe indiquera les principales modifications de ce document en comparaison à la version antérieure.

1.6 Définitions et Acronymes 1.6.1 Définitions

Accord d'utilisation de LCR: Un accord spécifiant les termes et conditions sous lesquels une Liste de Certificats Révoqués ou les informations qu'elle contient peuvent être utilisées. Audit : Contrôle indépendant des enregistrements et activités d'un système afin d'évaluer la pertinence et l'efficacité des contrôles du système, de vérifier sa conformité avec les politiques et procédures opérationnelles

____________________________________________________________________________________________________________________________




établies, et de recommander les modifications nécessaires dans les contrôles, politiques, ou procédures. [ISO/IEC POSIX Security]. Autorité de Certification (AC) : Se reporter au § 1.3.2. Autorité d'Enregistrement (AE) : Se reporter au § 1.3.3. Autorité d'Enregistrement Décentralisée (AED) : Se reporter au § 1.3.4. Client : Se reporter au § 1.3.9.1 Communauté de l’utilisateur : Client(s) et/ou une classe d'applications possédant des exigences de sécurité communes. Critères Communs : ensemble d’exigences de sécurité qui sont décrites suivant un formalisme internationalement reconnu. Les produits et logiciels sont évalués par un laboratoire afin de s’assurer qu’ils possèdent des mécanismes qui permettent de mettent en œuvre les exigences de sécurité sélectionnées pour le produit ou le logiciel évalué. Cérémonie de clés : Une procédure par laquelle une bi-clé d'AC ou AE est générée, sa clé privée transférée éventuellement sauvegardée, et/ou sa clé publique certifiée. Certificat : clé publique d'une entité, ainsi que d'autres informations, rendues impossibles à contrefaire grâce au chiffrement par la clé privée de l'autorité de certification qui l'a émis [ISO/IEC 9594-8; ITU-T X.509]. Certificat d'AC : certificat pour une AC émis par une autre AC. [ISO/IEC 9594-8; ITU-T X.509]. Dans ce contexte, les certificats AC (certificat auto signé). Certificat auto signé : certificat d'AC signé par la clé privée de cette même AC. Chemin de certification : (ou chaîne de confiance, ou chaîne de certification) chaîne constituée de multiples certificats nécessaires pour valider un certificat. Clé privée : clé de la bi-clé asymétrique d'une entité qui doit être uniquement utilisée par cette entité [ISO/IEC 9798-1]. Clé publique : clé de la bi-clé asymétrique d'une entité qui peut être rendue publique. [ISO/IEC 9798-1] Compromission : violation, avérée ou soupçonnée, d'une politique de sécurité, au cours de laquelle la divulgation non autorisée, ou la perte de contrôle d'informations sensibles, a pu se produire. En ce qui concerne les clés privées, une compromission est constituée par la perte, le vol, la divulgation, la modification, l'utilisation non autorisée, ou d'autres compromissions de la sécurité de cette clé privée. Confidentialité : La propriété qu'a une information de n'être pas rendue disponible ou divulguée aux individus, entités, ou processus [ISO/IEC 13335-1:2004]. Contrat de souscription : contrat liant le Client à une AED pour la souscription au service de certification. Il contient l’ensemble des documents nécessaires à l’élaboration des Dossiers Client. La fourniture d’un Contrat de Souscription vierge se fait sur simple demande auprès des différentes AED. Déclaration des Pratiques de Certification (DPC) : une déclaration des pratiques qu'une entité (agissant en tant qu'Autorité de Certification) utilise pour approuver ou rejeter des demandes de certificat (émission, gestion, renouvellement et révocation de certificats). [RFC 3647].

____________________________________________________________________________________________________________________________




Demande de certificat : message transmis par l'AE à l'AC pour obtenir l'émission d'un certificat d'AC. Disponibilité : La propriété d'être accessible sur demande, à une entité autorisée [ISO/IEC 13335-1:2004]. Distributeur : Entité du Crédit Agricole ou de LCL en relation commerciale avec le Client. Les Distributeurs assurent la fonction d’AED (Autorité d’ Enregistrement Décentralisée). Données d'activation : Des valeurs de données, autres que des clés, qui sont nécessaires pour exploiter les modules cryptographiques ou les éléments qu'ils protègent et qui doivent être protégées (par ex. un PIN, une phrase secrète, …). Dossier client : ensemble des pièces justificatives (demande et éventuellement Contrat de Souscription y compris) à fournir à l'AED* afin de lui permettre de vérifier les informations demandées par l'AE pour l'émission d'un certificat CA Certificat, l’enregistrement d’un nouveau MC*, la modification des données concernant un Porteur ou un Mandataire de Certification, ou enfin pour révoquer le mandat d’un Mandataire de Certification. Ces pièces justificatives sont décrites dans le Contrat de Souscription. Émission (d'un certificat) : un certificat est émis (ou délivré) lorsqu’il a été généré et est exporté pour être remis à le Porteur* ou publié. Enregistrement (d'un Porteur) : opération qui consiste pour une Autorité d'Enregistrement* à extraire d’un Dossier Client les informations sur un demandeur de certificat à renseigner dans les champs du certificat, conformément à la Politique de Certification*. Fonction de hachage : fonction qui lie des chaînes de bits à des chaînes de bits de longueur fixe, satisfaisant ainsi aux deux propriétés suivantes : Il est impossible, par un moyen de calcul, de trouver, pour une sortie donnée, une entrée qui corresponde à cette sortie ; Il est impossible, par un moyen de calcul, de trouver, pour une entrée donnée, une seconde entrée qui corresponde à la même sortie [ISO/IEC 10118-1]; Il est impossible par calcul, de trouver deux données d'entrées différentes qui correspondent à la même sortie. Génération (d'un certificat) : action réalisée par une AC* opérationnelle et qui consiste à signer l'ensemble des champs contenus dans un certificat édité par l'AE*. Infrastructure de Gestion de Clés (IGC) : également appelée IGC (Infrastructure de Gestion de Clés), c'est l'infrastructure requise pour produire, distribuer, gérer et archiver des clés, des certificats et des Listes de Certificats Révoqués ainsi que la base dans laquelle les certificats et les LCR doivent être publiés. [2nd DIS ISO/IEC 11770-3 (08/1997)]. Intégrité : fait référence à l'exactitude de l'information, de la source de l'information, et au fonctionnement du système qui la traite. Interopérabilité : implique que le matériel et les procédures utilisés par deux entités ou plus sont compatibles; et qu'en conséquence il leur est possible d'entreprendre des activités communes ou associées. Journaux d'exploitation ou d’événement : journaux collectant toutes les traces d'exécution des traitements, transactions et programmes produites par un système d'information (dénommés aussi "logs" ou "journaux d'événements").

____________________________________________________________________________________________________________________________




Liste de Certificats Révoqués (LCR) : liste signée numériquement par une AC et qui contient des identités de certificats qui ne sont plus valides. La liste contient l'identité de la LCR d'AC, la date de publication, la date de publication de la prochaine LCR et les numéros de série des certificats révoqués. La durée de validité est de 7 jours. Mandataire de certification (MC) :Se reporter au § 1.3.8.2. Modules cryptographiques : Un ensemble de composants logiciels et matériels utilisés pour mettre en oeuvre une clé privée afin de permettre des opérations cryptographiques (signature, chiffrement, authentification, génération de clé …). Dans le cas d'une AC, le module cryptographique est une ressource cryptographique matérielle évaluée et certifiée (FIPS ou critères communs), utilisé pour conserver et mettre en oeuvre la clé privée AC. OC : Se reporter au § 1.3.6 Période de validité d'un certificat : La période de validité d'un certificat est la période pendant laquelle l'AC garantit qu'elle maintiendra les informations concernant l'état de validité du certificat. [RFC 2459]. PKCS #10 : (Public-Key Cryptography Standard #10) mis au point par RSA Security Inc., qui définit une structure pour une Requête de Signature de Certificat (en anglais: Certificate Signing Request: CSR). Plan de secours (après sinistre) : plan défini par une AC pour remettre en place tout ou partie de ses services d'IGC après qu'ils aient été endommagés ou détruits à la suite d'un sinistre, ceci dans un délai défini dans l'ensemble PC/DPC. Point de distribution de LCR : entrée de répertoire ou une autre source de diffusion des LCR; une LCR diffusée via un point de distribution de LCR peut inclure des entrées de révocation pour un sous-ensemble seulement de l'ensemble des certificats émis par une AC, ou peut contenir des entrées de révocations pour de multiples AC. [ISO/IEC 9594-8; ITU-T X.509]. Politique de Certification (PC) : ensemble de règles qui indique l'applicabilité d'un certificat à une communauté particulière et/ou une classe d'applications possédant des exigences de sécurité communes. [ISO/IEC 9594-8; ITU-T X.509]. Politique de sécurité : ensemble de règles édictées par une autorité de sécurité et relatives à l'utilisation, la fourniture de services et d'installations de sécurité [ISO/IEC 9594-8; ITU-T X.509]. Porteur : Se reporter au § 1.3.8. Porteur de secret : personnes qui détient une donnée d’activation liée à la mise en œuvre de la clé privée d’une AC à l’aide d’un module cryptographique. Qualificateur de politique : Des informations concernant la politique qui accompagnent un identifiant de politique de certification (OID) dans un certificat X.509. [RFC 3647] Révocation (d'un certificat) : opération de mise en opposition demandée par le Porteur, le Mandataire de Certification*, le Client, l’AE ou l’AC ou par toute autre personne autorisée par l'AC, dont le résultat est la suppression de la garantie d'engagement de l'AC* sur un certificat donné, avant la fin de sa période de validité. Par exemple, la compromission d'une clé ou le changement d'informations contenues dans un certificat doivent conduire à la révocation du certificat. L'opération de révocation est considérée comme terminée lorsque le numéro de certificat à révoquer et la date de révocation sont publiés dans la Liste des Certificats Révoqués (LCR*). RSA : algorithme de cryptographique à clé publique inventé par Rivest, Shamir, et Adelman.

____________________________________________________________________________________________________________________________




SP : Se reporter au § 1.3.5. Site Web : Site Web de l’AE dédié au service de l’AC. C’est un portail où le Porteur pourra trouver les informations suivantes : Information sur le service AC ; Accès à l’Assistance téléphonique AC. Le Porteur pourra effectuer les actions suivantes : Retrait des certificats, Révocation des certificats, Renouvellement des certificats, Contrôle de validité et test d’un certificat. Utilisateur de Certificat : Se reporter au §.1.3.8.1 Validation de certificat électronique : opération de contrôle permettant d’avoir l’assurance que les informations contenues dans le certificat ont été vérifiées par une ou des autorités de confiance et sont toujours valides. La validation d’un certificat inclut entre autres la vérification de sa période de validité, de son état (révoqué ou non), de l’identité des AC de la chaine de certification et la vérification de la signature électronique de l’ensemble des AC contenue dans le chemin de certification.

1.6.2 Acronymes

- AC : Autorité de Certification ; - AE : Autorité d'Enregistrement ; - CAP : Comité d’Approbation des Politiques ; - CC : Critères Communs ; - DN: Distinguished Name ; - DPC : Déclaration des pratiques de certification ; - EAL: Evaluation assurance level, norme ISO 15408 (Critères Communs) pour la certification des produits

de sécurité ; - HTTP: Hypertext Transport Protocol ; - IGC : Infrastructure de Gestion de Clés ; - IP: Internet Protocol ; - ISO: International Organization for Standardization ; - LCR : liste de certificats révoqués ; - LDAP: Lightweight Directory Access Protocol ; - OCSP: Online Certificate Status Protocol ; - OID: Object Identifier ; - PC : Politique de Certification ; - PIN: Personal Identification Number ; - PKCS: Public-Key Cryptography Standard ; - RFC: Request for comment ; - RSA: Rivest, Shamir, Adleman ; - SHA: Secure Hash Algorithm (norme fédérale américaine) ; - SP : Service de Publication ; - URL: Uniform Resource Locator.

____________________________________________________________________________________________________________________________




2 ANNUAIRES ET SERVICES DE PUBLICATION

2.1 Service de publication Le SP est en charge de la publication des données identifiées au § 2.2 ci-dessous.

2.2 Informations publiées L'AC, via le SP, rend disponibles les informations suivantes :

- La PC de l'AC : http://www.ca-certificat-plus.com/PC/09client/Sign_ Auth_National_CA_RGS.pdf ; - Le certificat de l’AC et de l’ACR http://www.ca-certificat-plus.com/04-client/telecharger_chaine.jsp; - Le formulaire de demande de certificat : - Réseau Crédit Agricole : http://www.ca-certificat-plus.com

. - Le formulaire et/ou les modalités de révocation d’un certificat : - Réseau Crédit Agricole : http://www.ca-certificat-plus.com

. - Les conditions générales d’utilisation : - Réseau Crédit Agricole : http://www.ca-certificat-plus.com

. La LCR : http://crl.ca-certificat.com/CreditAgricoleRGSUsageSepare/LatestCRL.crl

- et - ldap://ldap.ca-certificat.com/cn=CA%20LCL%20Certificat%20RGS%20

Usage%20Separe,ou=0002%20723001467,o=CEDICAM?certificaterevocationlist;binary?base?objectclass=pkiCA.

La DPC n’est pas publiée mais consultable auprès du CAP sur demande justifiée et autorisée par le CAP.Les coordonnées du CAP sont données au § 1.5.3. Il est à noter que l’information RGS citée dans le nom des certificats d’AC ou LCR est prévu pour répondre aux exigences prévues par le Référentiel Général de Sécurité (RGS) en ce qui concerne les Autorités de Certification, sans pour autant se prévaloir d’une qualification au titre de ce Référentiel. (voir paragraphe 1.1 ci-dessus). Ce sont des informations techniques. La qualification est définie par l’inclusion d’une AC au sein des listes de l’ANSSI. Cependant, l’AC peut faire l’objet d’une publication au sein des listes des Autorités Qualifiées indépendamment du son nom Technique.

2.3 Heure et fréquence de publication La PC de l’AC et le certificat de l’AC sont disponibles en permanence et mises à jour selon les besoins. Une nouvelle LCR est publiée toutes les 24 heures. Les taux de disponibilité sont précisés dans la DPC.

2.4 Contrôle d'accès au service de publication Le SP s'assure que les informations sont disponibles et protégées en intégrité contre les modifications non autorisées. L'AC s'assure que toute information conservée dans une base documentaire de son IGC et dont la diffusion publique ou la modification n'est pas prévue est protégée.

____________________________________________________________________________________________________________________________




L’ensemble des informations publiques et publiées (Se reporter au § 2.2) est libre d’accès en lecture et téléchargement sur Internet.

____________________________________________________________________________________________________________________________




3 IDENTIFICATION ET AUTHENTIFICATION

3.1 Nommage 3.1.1 Types de noms

Les identités utilisées dans un certificat sont décrites suivant la norme X.500. Dans chaque certificat X.509, le fournisseur (Issuer) et le porteur (subject) sont identifiés par un Distinguished Name (DN). Les attributs du DN sont encodés en « printableString » ou en « UTF8String » à l’exception des attributs emailAddress qui sont en « IA5String ». La construction de l’identité du porteur dans le certificat de l’AC de Production est la suivante : Champ de base Valeur

Issuer Identité de l’AC émettrice. Subject C = Code ISO du Pays de l'autorité compétente auprès de laquelle

l’organisation du Client est officiellement enregistré (tribunal de commerce, ministère, …). Ce code est inscrit en majuscules ; L=<Ville du demandeur> ; CN = Prénom et Nom du porteur ; O = Nom officiel complet de l’organisation cliente tel qu'enregistré auprès des autorités compétentes (tribunal de commerce, ministère, …) ; SérialNumber= Numéro de série choisie par l’AE afin de distinguer des CN identiques ; E=<Email demandeur> ; OU= constitué de

- L’ICD de l’organisation cliente sur 4 caractères ; - L'identification de l'organisation cliente sur 35 caractères

avec un séparateur entre les deux chaînes précédentes sous forme d’un espace (SIREN).

OU= <Nom de l’Offre> - CACertificatPlus : nom de l’Offre à fin d’identification du

réseau de distribution CRCAM, Caisse Régionale de Crédit Agricole Mutuel

-

La construction de l’identité du porteur dans le certificat TEST pour l’AC est la suivante : Champ de base Valeur

Issuer Identité de l’AC émettrice. Subject C = Code ISO du Pays de l'autorité compétente auprès de laquelle

l’organisation du Client est officiellement enregistré (tribunal de commerce, ministère, …). Ce code est inscrit en majuscules ; L=<Ville du demandeur> ; CN = Prénom précédé de la mention XXX TEST et Nom du porteur ; O = Nom officiel complet de l’organisation cliente tel qu'enregistré auprès des autorités compétentes (tribunal de commerce, ministère, …) ; SérialNumber= Numéro de série choisie par l’AE afin de distinguer des CN identiques ; E=<Email demandeur> ;

____________________________________________________________________________________________________________________________




OU= constitué de - L’ICD de l’organisation cliente sur 4 caractères ; - L'identification de l'organisation cliente sur 35 caractères

avec un séparateur entre les deux chaînes précédentes sous forme d’un espace (SIREN).

OU= <Nom de l’Offre> - CACertificatPlus : nom de l’Offre à fin d’identification du

réseau de distribution CRCAM, Caisse Régionale de Crédit Agricole Mutuel

- .

3.1.2 Utilisation de noms explicites Dans tous les cas, l’identité du porteur (Se reporter au § 3.1.1 est construite à partir des nom et prénom de son état civil tel que porté sur le document officiel d'identité présenté lors de son enregistrement. Lorsque le certificat est pour un porteur au sein d’une Entreprise ou d’une Administration, alors l’identité de l’Entreprise ou de l’Administration est aussi contenue dans le certificat.

3.1.3 Anonymat ou utilisation de pseudonyme L'identité utilisée pour les certificats de porteurs n'est ni un pseudonyme ni un nom anonyme (Se reporter au § 3.1.2).

3.1.4 Règles d'interprétations des différentes form es de noms Les UC peuvent se servir de l’identité incluse dans les certificats (Se reporter au 3.1.1) afin d’authentifier les porteurs. Toutefois, aucune interprétation particulière n'est à faire des informations portées dans le champ "Objet" des certificats porteur.

3.1.5 Unicité des noms Les identités portées par l’AC dans les certificats (Se reporter au § 3.1.1) sont uniques au sein du domaine de certification de l'AC. Durant toute la durée de vie de l'AC, une identité attribuée à un porteur (Se reporter au 3.1.1) de certificat ne peut être attribué à un autre porteur. A noter que l’unicité d’un certificat est basée sur l’unicité de son numéro de série à l’intérieur du domaine de certification de l’AC, mais que ce numéro est propre au certificat et non pas au porteur et ne permet donc pas d'assurer une continuité de l'identification dans les certificats successifs d'un porteur donné. L'AE assure cette unicité au moyen de son processus d'enregistrement et de la valeur unique du champ SN attribué à un porteur (se reporter au § 3.1.1. En cas de différent au sujet de l'utilisation d'un nom pour un certificat, l’AC a la responsabilité de résoudre le différent en question.

3.1.6 Reconnaissance, vérification, et rôle des nom s de marques déposées Sans objet car les certificats porteur ne contiennent pas des noms de marque. L’AC ne pourra voir sa responsabilité engagée en cas d’utilisation illicite par la communauté d’utilisateur et les Clients des marques déposées, des marques notoires et des signes distinctifs, ainsi que des noms de domaine.

3.2 Vérification initiale d'identité 3.2.1 Preuve de possession de la clé privée

____________________________________________________________________________________________________________________________




La preuve de la possession de la clé privée par le porteur est réalisée par les procédures de génération de la clé privée (se reporter au § 6.1.1.1 ci-dessous) correspondant à la clé publique à certifier et par le mode de transmission de la clé publique (se reporter au § 6.1.3 ci-dessous).

3.2.2 Vérification de l’Identité d’un organisme L’authentification d'une organisation repose sur la vérification des informations fournies dans le cadre de sa demande de certificat (Se reporter au § 4.1.2). Ces informations comprennent le nom et l'adresse de l'organisation ainsi que les documents ou les références de l'existence de celle-ci, ainsi que le nom de domaine qu'elle détient. L'entité qui procède à la vérification s'assure que l'organisation existe bien et est légalement autorisée à utiliser exclusivement son nom, en comparant les informations fournies dans la demande du certificat aux informations recueillies dans les bases de données officielles de référence. Les informations susceptibles d'être vérifiées pendant l'authentification de l'identité de l'organisation comprennent le numéro SIREN, le numéro de déclaration de TVA, le DUNS, etc. Dans tous les cas, la vérification de l’appartenance d’un porteur à l’organisation de « type » Administration et Entreprise dont il se réclame est effectuée.

3.2.3 Vérification de l'identité des personnes

3.2.3.1 Porteur Le porteur est identifié et authentifié lors d’un face à face avec un MC, de son entité légale de rattachement, ou l’AED. L’identification et l’authentification du porteur s’effectue sur la base de la présentation d’’une pièce d’identité officielle (carte nationale d’identité, passeport, …).

3.2.3.2 AED et MC L’AE procède à l’enregistrement des AED et les AED procèdent à l’enregistrement des MC. Les pièces justificatifs pour l‘enregistrement d’un MC sont les même que celles demandées à un porteur. Le MC fournit en plus un engagement signé de lui même à signaler à l’AED son départ de l’entreprise, et le départ des porteurs de l’entreprise. L’authentification des MC par les AED s’effectue lors d’un face à face. Les pièces justificatives demandées aux AED sont décrites dans la DPC. Les MC doivent avoir signé un contrat dans lequel le MC doit :

- Effectuer correctement et de façon indépendante les contrôles d'identité des futurs porteurs de l'entité pour laquelle il est MC ;

- Respecter les parties de la PC et de la DPC public de l'AC qui lui incombent.

3.2.4 Informations non vérifiées Les informations non vérifiées ne sont pas introduites dans les certificats.

3.2.5 Validation de l’autorité d’un porteur La validation de l’autorité d’un porteur correspond à la validation de l’appartenance à une organisation (se reporter au § 3.2.2 ci-dessus).

3.2.6 Critères de reconnaissance Un porteur qui obtient un certificat émis par l'AC à la garantie d’être authentifiable par les applications utilisatrices.

3.3 Vérifications aux fins de renouvellement de clé s 3.3.1 Vérifications aux fins de renouvellement de c lés en situation normale

____________________________________________________________________________________________________________________________




Le renouvellement de certificat s’apparente à un renouvellement de la bi-clé et l’attribution d’un nouveau certificat. L’authentification du porteur est réalisée sur la base de son certificat courant et valide et le porteur retire directement son certificat avec le service de retrait de l’AE comme expliqué au § 4.3. L’authentification pour le premier renouvellement est automatique est réalisée à partir du certificat valide du porteur. Le renouvellement suivant nécessite une authentification du porteur suivant les mêmes procédures que pour la délivrance du premier certificat.

3.3.2 Vérifications aux fins de renouvellement de c lés après révocation du certificat Le renouvellement de certificat s’apparente à un renouvellement de la bi-clé et l’attribution d’un nouveau certificat conformément aux procédures initiales (se reporter au § 3.2) ou doit être une procédure offrant un niveau de garantie équivalent.

3.4 Vérifications aux fins de révocation Les demandes de révocation sont authentifiées par l'AE à l’aide d’informations seulement connues du porteur et de l’AE. Lorsque le demandeur est une personne autre que le porteur, l’authentification est réalisée suivant des procédures définies dans la DPC.

____________________________________________________________________________________________________________________________




4 EXIGENCES OPERATIONNELLES

4.1 Types de certificat 4.1.1 Origine de la demande de certificat

Le MC ou le porteur dépose une demande de certificat auprès de l’AED.

4.1.2 Procédure d'enregistrement et responsabilités Les informations minimum suivantes doivent figurer dans la demande de certificat du porteur :

- Porteur au sein d’une Entreprise : o La demande de certificat est signée par le porteur et datée de moins de 3 mois. Si un MC fournit la

demande, alors cette demande est aussi signée du MC ; o Les conditions générales d’utilisation signée par le Responsable Légal; o Une photocopie, signée et datée de moins de 3 mois par le porteur, portant la mention « certifiée

conforme à l’originale », du document officiel d'identité du futur porteur (notamment carte nationale d'identité, passeport ou carte de séjour), en cours de validité, comportant une photographie d'identité, l'AE en conserve une copie ;

o Les informations qui permettent de construire l’identité du porteur (se reporter aux § 3.1.1. et § 3.1.2) ;

o Les Informations permettant de contacter le porteur (numéro de téléphone, courriel, …) ; o Un mandat signé, et daté de moins de 3 mois, par un représentant légal de l'entité désignant le

futur porteur auquel le certificat doit être délivré ou le MC autorisé à procéder à la demande de certificat. Ce mandat doit être signé pour acceptation par le futur porteur bénéficiaire ou le MC ;

o Toute pièce, valide lors de la demande de certificat (extrait Kbis ou Certificat d'Identification au Répertoire National des Entreprises et de leurs Etablissements ou inscription au répertoire des métiers, ...), attestant de l’existence de l'entreprise et portant le numéro SIREN de celle-ci, ou, à défaut, une autre pièce attestant l’identification unique de l’entreprise qui figurera dans le certificat ;

o Tout document attestant de la qualité du signataire de la demande de certificat ;

- Porteur au sein d’une Administration : o La demande de certificat est signée par le porteur et datée de moins de 3 mois ; Si un MC fournit

la demande, alors cette demande est aussi signée du MC ; o Les conditions générales d’utilisation signée par le Responsable Légal; o Une photocopie, signée et datée de moins de 3 mois par le porteur, portant la mention « certifiée

conforme à l’originale », du document officiel d'identité du futur porteur (notamment carte nationale d'identité, passeport ou carte de séjour), en cours de validité, comportant une photographie d'identité, l'AE en conserve une copie ;

o Les informations qui permettent de construire l’identité du porteur (se reporter aux § 3.1.1 et § 3.1.2) ;

o Les Informations permettant à l’AE de contacter le porteur (numéro de téléphone, courriel, …) ; o Un mandat signé, et daté de moins de 3 mois, par un représentant légal de l'entité désignant le

futur porteur auquel le certificat doit être délivré ou le MC autorisé à procéder à la demande de certificat. Ce mandat doit être signé pour acceptation par le futur porteur bénéficiaire ou le MC ;

o Une pièce, valide au moment de l'enregistrement, portant délégation ou subdélégation de l'autorité responsable de la structure administrative

- Porteurs de Certificats de test :

o Pour les certificats de test, la demande de certificat doit référencer un protocole de test ou indiquer de manière explicite dans le dossier de souscription que le certificat est délivré à titre de test. .

____________________________________________________________________________________________________________________________




Lors de la demande de certificat, le porteur renseigne des données d’authentification dont des réponses à une liste de questions qu’il choisit et des données secrètes. Ces données d’authentification permettront d’authentifier le porteur pour des opérations qui n’utilise pas de face à face. La DPC décrit le contenu exact de la demande de certificat.

4.2 Traitement d'une demande de certificat 4.2.1 Identification et authentification

L’AED authentifie la demande de certificat, transmise par le porteur ou le MC,et vérifie la demande de certificat (Se reporter au § 3.2.3). L’AED s’assure que le porteur a pris connaissance des conditions générales d’utilisation. L’AED transmet la demande de certificat à l’AE pour validation. L’AE conserve dans ses journaux l’ensemble des pièces qui composent la demande de certificat.

4.2.2 Approbation ou rejet d'une demande de certifi cat En cas d’approbation de la demande, l’AED (service de demande de certificat) transmet la demande à l’AE. L’AE vérifie et valide la demande de certificat et transmet la demande de certificat à l’AC (service de génération de certificat). L’AE transmet le support matériel au porteur et la donnée d’activation initiale associée. L’envoi s’effectue par courriers séparés dans le temps. L’AE notifie l’AED et le MC en charge du porteur. L’AE notifie le porteur et lui transmet des données d’authentification. En cas de rejet de la demande, l'AE en informe l’AED qui en informe le porteur en justifiant le rejet.

4.2.3 Durée de traitement d'une demande de certific at La demande de certificat est traitée dès la réception de la demande par l’AE dans un délai de 48 Heures.

4.3 Emission d'un certificat 4.3.1 Actions effectuées par l'AC pendant l'émissio n d'un certificat

4.3.1.1 Certificat Porteur L’AC (service de génération de certificat) authentifie l’AE et vérifie que la demande provient effectivement d’une AE autorisée par l’AC. Le porteur se connecte sur le service de retrait de certificat de l’AE. Le porteur s’authentifie auprès de l’AE. L’AE transmet la demande de génération de certificat à l’AC. Le porteur s’authentifie auprès du service de retrait de l’AE. L’AC génère le certificat du porteur. L’AC transmet le certificat au service de retrait de certificat de l’AE. Le porteur récupère le certificat porteur. Les communications, entre les différentes composantes de l’IGC citées ci-dessus, sont authentifiées et protégées en intégrité et confidentialité. Le porteur à un délai maximum de 3 mois pour retirer son certificat. Passé ce délai, l’AE annule la demande de certification et le porteur ne peut plus retirer son certificat. Il est aussi possible de régénérer un nouveau certificat dans les 72 heures suite à au retrait infructueux d’un certificat par le porteur et à la révocation de ce dernier par l’AE. Ce processus s’applique dans le cas où un porteur est confronté à un problème technique lors du chargement de son certificat. Il dispose dans ce cas de 72 heures ouvrées maximum pour prendre contact avec l’AE, sur le site de retrait, et demander la génération d’un nouveau certificat. Au-delà des 72 heures, le porteur devra faire une nouvelle demande de certificat comme pour un renouvellement classique, comme définit au § 3.3.1, de certificat. En ce cas, l’AE peut expédier un nouveau

____________________________________________________________________________________________________________________________




support matériel au porteur et l’ancien certificat est révoqué. Le porteur procède alors à un nouveau retrait de certificat comme expliqué ci-dessus.

4.3.2 Notification de l'émission d'un certificat Il n’y a pas de notification suite au retrait de certificat sur l’AE. L’information sur l’action réalisée de retrait de certificat est toutefois disponible auprès de l’AE.

4.4 Acceptation d'un certificat 4.4.1 Procédure d'acceptation d'un certificat

L'AC est automatiquement informée du retrait de chaque certificat par le Porteur correspondant. Le Porteur est tenu d’avertir l'AED, via les contacts qui lui sont fournis lors de l’enregistrement, de toute inexactitude ou défection d’un certificat dans les 7 jours ouvrés consécutifs au retrait du certificat, afin que celui-ci soit révoqué et qu’un autre certificat puisse lui être fourni. Le Porteur est réputé avoir accepté son certificat lorsque ce délai est dépassé. De plus, les CGU indique que le porteur est tenu d’utiliser son certificat dans le cadre du service de vérification du certificat offert à l’issue du processus de retrait. L’AE conserve une trace des résultats de l’utilisation de ce service par le porteur. En outre, l'acceptation d'un certificat vaut acceptation de la PC en référence (OID unique stocké dans le certificat).

4.4.2 Publication d'un certificat par l'AC Le certificat de l’AC est publié par le SP. Les certificats des porteurs ne sont pas publiés par le SP.

4.4.3 Notification de l'émission d'un certificat pa r l'AC à d'autres entités Sans objet.

4.5 Utilisation des bi-clés et des certificats 4.5.1 Utilisation des bi-clés et des certificats

L’utilisation des bi-clés et des certificats est définie au § 1.4 ci-dessus et restreint aux opérations de contrôle d’accès et de signature dans le cadre des applications autorisées. L’usage d’une bi-clé et du certificat associé est par ailleurs indiqué dans le certificat lui-même, via les extensions concernant les usages des bi-clés (se reporter au § 6.1.7). Le porteur s’engage à respecter ses usages de la bi-clé et du certificat en signant les conditions générales d’utilisation.

4.5.2 Utilisation des clés publiques et des certifi cats par les tierces parties L’utilisation des certificats par les UC est décrite dans les paragraphes 1.4 ci-dessus.

4.6 Demande d’un nouveau certificat Cette section concerne le processus de renouvellement du certificat porteur, sans que les clés publiques ou toute autre information incluse dans les certificats soient modifiées. Seule la période de validité et le numéro de série changent. Ce type d’opération n’est pas autorisé au titre de la présente PC ni pour le porteur ni pour le certificat d’AC.

4.7 Changement de clés (ou certification d'une nouv elle clé publique) Cette section concerne la génération d'un nouveau certificat avec changement de la clé publique associée. Le changement de la clé publique d'un certificat implique la création d'un nouveau certificat. Le porteur est averti par l’AE, avant la fin de validité de son certificat en cours, que son certificat courant va expirer. Le délai est fixé dans la DPC.

____________________________________________________________________________________________________________________________




Seul le premier renouvellement peut se faire de manière automatique comme décrit au § 3.3.1 pour un certificat en cours de validité. Le second renouvellement d’un certificat en cours de validité s’effectue toujours conformément aux procédures initiales pour l’attribution du premier certificat. Si un certificat est révoqué et que le porteur souhaite le renouveler, alors le renouvellement s’effectue comme la première demande du certificat initiale. Dès qu’un certificat et renouvelé et retiré, alors l’AC notifie le MC.

4.8 Modification d'un certificat Cette section concerne la génération d'un nouveau certificat porteur avec conservation de la même clé. Cette opération est rendue possible uniquement si la clé publique réutilisée dans le certificat est toujours conforme aux recommandations de sécurité cryptographique applicables en matière de longueur de la clé. Ce type d’opération n’est pas autorisé au titre de la présente PC ni pour le porteur ni pour le certificat d’AC.

4.9 Révocation d'un certificat 4.9.1 Motif de révocation d'un certificat

4.9.1.1 Certificat Composante IGC Les circonstances suivantes peuvent être à l’origine de la révocation d’un certificat d'une composante de l'IGC (y compris un certificat d'AC pour la génération de certificats, de LCR :

- Suspicion de compromission, compromission, perte ou vol de la clé privée de la composante ; - Décision de changement de composante de l'IGC suite à la détection d'une non-conformité des - Procédures appliquées au sein de la composante avec celles annoncées dans la DPC (par exemple, - Suite à un audit de qualification ou de conformité négatif) ; - Cessation d’activité de l'entité opérant la composante.

4.9.1.2 Certificat Porteur Un certificat de porteur est révoqué quand l'association la clé publique et le porteur qu'il certifie n'est plus considérée comme étant valide. Les motifs qui invalident cette association sont :

- La clé privée du Porteur est suspectée de compromission, est compromise, est perdue ou est volée (y compris perte ou vol du support matériel) ;

- Les Données d’Activation conditionnant l’utilisation de la clé privée ont été perdues, ou bien l’utilisation de la clé privée sur support matériel a été bloquée suite à la saisie consécutive d’un nombre déterminé de codes PIN erronés ;

- Le non respect des règles d'utilisation du certificat ; - Le non respect par le porteur de ses obligations découlant de la présent PC ; - Les informations du Porteur figurant dans son certificat ne sont pas ou plus exactes, ceci avant l'expiration

normale du certificat ; - Le départ, la mutation à un autre poste ou le décès du Porteur, ainsi que la cessation d'activité du Client ; - Le Porteur ou l'un des Mandataires de Certification en fait la demande (fin d’abonnement) ; - La résiliation du Contrat de Souscription ; - Le défaut de paiement des sommes dues au titre du Contrat de Souscription ; - Les informations figurant dans les Dossiers Clients ne sont pas ou plus exactes ; - Le changement de numéro de SIREN ou de la dénomination sociale du Client (par exemple en cas de

transfert du Contrat de Souscription par apport universel de patrimoine) ; - Le certificat de l'AC est révoqué (ce qui entraîne la révocation de tous les certificats signés par la clé privée

correspondante) ; - La modification de la taille des clés imposée par des institutions nationale ou internationale compétentes.

____________________________________________________________________________________________________________________________




Quand l'une de ces occurrences se produit, le certificat du porteur en question doit être révoqué.

4.9.2 Origine d'une demande de révocation

4.9.2.1 Composante d’IGC Le CAP est à l’origine de toutes demandes de révocation de composantes.

4.9.2.2 Certificat Porteur La révocation d'un certificat d'un Porteur peut émaner de :

- Le Porteur au nom duquel le certificat a été émis ; - L'un des MC ; - Le représentant légal du Client ; - L'AC émettrice du certificat ; - L'AC ayant autorisé l'émission du certificat ; - L'AED avec laquelle le Client a établi le "Contrat de Souscription".

4.9.3 Procédure de demande de révocation

4.9.3.1 Composante d’IGC Lorsque la décision est prise de révoquer l'une des AC opérationnelles appartenant à la chaîne de confiance d’un certificat de Porteur (soit l’AC, soit l’AC racine), les actions suivantes sont réalisées :

- Tous les certificats des Porteurs en cours de validité délivrés par cette AC sont révoqués et inclus dans la LCR ;

- Les responsables des applications utilisatrices autorisées, les MC et les Porteurs sont notifiés de la fin de la confiance ;

- Une demande de révocation pour le certificat de l’AC est transmise à l'AC racine à laquelle l'AC est subordonnée.

Lorsque la décision est prise de révoquer l'un des certificats de l’AC et que le motif de cette révocation est la compromission (avérée ou supposée) de la clé privée correspondante, les actions suivantes sont réalisées :

- Tous les certificats des Porteurs en cours de validité, délivrés depuis la date de compromission (assortie d’une période de sûreté) sur demande de l’AC, sont révoqués et inclus dans la LCR ;

- Les MC et les Porteurs concernés sont notifiés de la raison de la révocation de leur certificat ; - Une demande de révocation pour le certificat de l’AC est transmise à l'AC qui l’a émis.

S’il y a lieu, l’émission de certificats « de remplacement » pour les Porteurs sera assurée dans les meilleurs délais.

4.9.3.2 Porteur Une révocation peut être demandée :

- En ligne par le Porteur ou un MC, (via le site web de l’AE accessible 24h/24 7j/7) ; - Par téléphone(*) par le Porteur ou un MC, ou le Client (via l’Assistance téléphonique de l’AE) ; - Auprès de l’AED (durant ses heures d’ouverture) par le Porteur, un MC, ou le Client.

(*) Aux heures ouvrées, le demandeur est en ligne avec le Support ; Une demande de révocation contient les informations suivantes :

- L'identité du porteur du certificat utilisée dans le certificat (nom, prénom, ...) ;

____________________________________________________________________________________________________________________________




- Le nom du demandeur de la révocation ; - Toute information permettant de retrouver rapidement et sans erreur le certificat à révoquer (n° de série du

certificat,...). La demande de révocation est conservée par l’AE dans ses journaux. L'AE authentifie la demande de révocation qu’elle reçoit (se reporter au § 3.4). L’AE transmet la demande de révocation à l’AC. L’AC (service de révocation) authentifie l’AE et vérifie que la demande provient effectivement d’une AE autorisée par l’AC. L’AC (service de révocation) révoque le certificat du porteur en incluant le numéro de série du certificat dans la prochaine LCR qui sera émise par l’AC. Le demandeur de la révocation est informé de la révocation effective du certificat porteur. De plus, si le porteur du certificat n'est pas le demandeur, le porteur est également informé de la révocation effective du certificat. Le MC est informé de la révocation des certificats des porteurs qui lui sont rattachés. Les causes de révocation ne sont jamais publiées dans la LCR.

4.9.4 Délai accordé au porteur pour formuler la dem ande de révocation Dès que le demandeur a connaissance qu'une des causes possibles de révocation de son ressort, est effective, il formule sa demande de révocation sans délai.

4.9.5 Délai de traitement d’une révocation Le service de révocation est disponible 24 heures sur 24 et 7 jours sur 7 suivant un taux de disponibilité définie dans la DPC. L'AC traite les demandes de révocation dès que possible suivant sa réception et de préférence immédiatement et dans un délai maximum de 24H00.

4.9.6 Exigences de vérification de révocation pour les tierces parties Il appartient aux UC de vérifier l'état de validité d’un certificat à l’aide de l’ensemble des LCR émises par l’AC.

4.9.7 Fréquences de publication des LCR La LCR est émise toute les 24 Heures. La durée de validité de la LCR est de 7 jours.

4.9.8 Délai maximum de publication d’une CRL Le délai maximum de publication d'une LCR suite à sa génération est de 30 minutes.

4.9.9 Disponibilité d'un système de vérification en ligne de la révocation et de l'état des certificat s Sans objet.

4.9.10 Exigences de vérification en ligne de la rév ocation des certificats par les utilisateurs de certificats

Cf. chapitre 4.9.6 ci-dessus.

4.9.11 Autres moyens disponibles d'information sur les révocations Sans objet.

4.9.12 Exigences spécifiques en cas de compromissio n de la clé privée : Pour les certificats de porteur, les entités autorisées à effectuer une demande de révocation sont tenues de le faire dans les meilleurs délais après avoir eu connaissance de la compromission de la clé privée.

____________________________________________________________________________________________________________________________




Pour les certificats d'AC la révocation suite à une compromission de sa clé privée fait l'objet d'une information clairement diffusée au moins sur le site Internet de l'AC et éventuellement relayée par d'autres moyens (autres sites Internet institutionnels, journaux, etc.). En cas de révocation de l’AC, l’ensemble des certificats porteurs sont révoqués. Les conditions générales d’utilisation du certificat mentionnent clairement qu’en cas de compromission de la clé privée du porteur ou de connaissance de la compromission de la clé privée de l’AC ayant émis son certificat, le porteur s’oblige à interrompre immédiatement et définitivement l’usage de sa clé privée et de son certificat associé.

4.10 Service d'état des certificats 4.10.1 Caractéristiques opérationnelles

La fonction de consultation de l’état des certificats, mis à la disposition des utilisateurs de certificats, dispose d’un un mécanisme de consultation libre de LCR et LAR. Ces LCR et LAR sont des LCR au format V2, publiées au moins dans un annuaire accessible en protocole LDAP V3.

4.10.2 Disponibilité de la fonction Le service est disponible 24 heures sur 24 et 7 jours sur 7 suivant un taux de disponibilité préciser dans la DPC.

4.11 Fin de la relation entre Le porteur et l'AC En cas de fin de relation contractuelle, hiérarchique ou réglementaire entre l'AC et le porteur avant la fin de validité du certificat, pour une raison ou pour une autre, le certificat de porteur est révoqué. Un MC (ou le Porteur concerné) peut demander la fin d'un abonnement en révoquant le certificat d’un Porteur et en invoquant le motif adéquat. Aucune Re-génération ne sera alors possible, et l’abonnement ne sera plus facturé. La résiliation du Contrat de Souscription entraîne la révocation de tous les certificats des Porteurs du Client et met fin à leur abonnement.

4.12 Séquestre et recouvrement de clés Les bi-clés et les certificats des porteurs et d’AC émis conformément à la PC ne font pas l'objet de séquestre ni de recouvrement.

____________________________________________________________________________________________________________________________




5 MESURES DE SECURITE PHYSIQUE, PROCEDURES ET MISE EN ŒUVRE

5.1 Sécurité physique 5.1.1 Situation géographique

Le site d’exploitation de l’AC respecte les règlements et normes en vigueur et son installation tient compte des résultats de l'analyse de risques, du métier d'opérateur de certification selon la méthode EBIOS, par exemple certaines exigences spécifiques de type inondation, explosion (proximité d'une zone d'usines ou d'entrepôts de produits chimiques,...) réalisées par l’OC.

5.1.2 Accès physique Afin de limiter l’accès aux applications et aux informations de l’IGC et afin d’assurer la disponibilité du système d’exploitation de l’AC, l’OC met en place un périmètre de sécurité opéré pour ses besoins. La mise en œuvre de ce périmètre permet de respecter les principes de séparation des rôles de confiance telle que prévus dans cette PC. Les accès au site de l’OC, qui met en œuvre les services d’IGC, sont limités aux seules personnes nécessaires à la réalisation des services et selon leur besoin d'en connaître. Les accès sont nominatifs et leur traçabilité est assurée. La sécurité est renforcée par la mise en œuvre de moyens de détection d’intrusion passifs et actifs. Tout évènement de sécurité fait l'objet d'un enregistrement et d'un traitement.

5.1.3 Energie et air conditionné Des systèmes de protection de l'alimentation électrique et de génération d'air conditionné sont mis en œuvre par l’OC afin d'assurer la continuité des services délivrés. Les matériels utilisés pour la réalisation des services sont opérés dans le respect des conditions définies par leurs fournisseurs et ou constructeurs.

5.1.4 Exposition aux liquides Les systèmes de l’OC sont implantés de telle manière qu'ils ne sont pas sensibles aux inondations et autres projections et écoulements de liquides.

5.1.5 Prévention et protection incendie Les moyens de prévention et de lutte contre les incendies mis en œuvre par l’OC permettent de respecter les exigences et les engagements pris par l'AC dans la présente PC, en matière de disponibilité de ses fonctions.

5.1.6 Conservation des supports Les différentes informations intervenant dans les activités de l'IGC sont identifiées et leurs besoins de sécurité définis (en confidentialité, intégrité et disponibilité). Les supports (papier, disque dur, disquette, CD, etc.) correspondant à ces informations sont traités et conservés conformément à ces besoins de sécurité. Les précisions quant aux modalités de conservation des supports sont fournies dans le DPC.

5.1.7 Mise hors service des supports En fin de vie, les supports seront soit détruits soit réinitialisés en vue d’une réutilisation.

5.1.8 Sauvegardes hors site L’OC réalise des sauvegardes hors site permettant une reprise rapide des services d’IGC suite à la survenance d’un sinistre ou d’un événement affectant gravement et de manière durable la réalisation de ses services. Les précisions quant aux modalités des sauvegardes des informations sont fournies dans la DPC.

____________________________________________________________________________________________________________________________




5.2 Mesures de sécurité procédurales 5.2.1 Rôles de confiance

Les personnels doivent avoir connaissance et comprendre les implications des opérations dont ils ont la responsabilité. Les rôles de confiance de l’AC sont classés en 4 groupes :

- Les personnels d'exploitation, dont la responsabilité est le maintien de des systèmes qui supportent l’IGC en conditions opérationnelles de fonctionnement ;

- Les personnels d’administration, dont la responsabilité est l’administration technique des composantes de l’IGC ;

- Les personnels opérationnels dont la responsabilité est de mettre en œuvre les fonctions d’IGC ; - Les personnels de « sécurité », dont la responsabilité est de réaliser les opérations de vérification et

contrôle de la bonne application des mesures et de la cohérence de fonctionnement de la composante d’IGC ;

- Les personnels porteurs de données d’activation de clé.

5.2.2 Nombre de personnes nécessaires à l’exécution de tâches sensibles Plusieurs rôles peuvent être attribués à une même personne, dans la mesure où le cumul ne compromet pas la sécurité des fonctions mises en œuvre.

5.2.3 Identification et authentification des rôles

L’AC fait vérifier l’identité et les autorisations de tout membre de son personnel qui est amené à mettre en œuvre les services de l’IGC avant de lui attribuer un rôle et les droits correspondants, notamment :

- Que son nom soit ajouté aux listes de contrôle d’accès aux locaux de l'entité hébergeant la composante concernée par le rôle ;

- Que son nom soit ajouté à la liste des personnes autorisées à accéder physiquement à ces systèmes ;

- Le cas échéant et en fonction du rôle, qu’un compte soit ouvert à son nom dans ces systèmes ;

- Eventuellement, que des clés cryptographiques et/ou un certificat lui soient délivrés pour accomplir le rôle qui lui est dévolu au sein de l'IGC.

Ces contrôles sont décrits dans la DPC et sont conformes à la politique de sécurité de l’AC. Chaque attribution d’un rôle à un membre du personnel de l’IGC lui est notifiée par écrit ou équivalent.

5.2.4 Rôles exigeant une séparation des attribution s Plusieurs rôles peuvent être attribués à une même personne, dans la mesure où le cumul ne compromet pas la sécurité des fonctions mises en œuvre. Pour les rôles de confiance, il est néanmoins recommandé qu'une même personne ne détienne pas plusieurs rôles et, au minimum, les exigences ci-dessous de non cumul doivent être respectées. Les attributions associées à chaque rôle doivent être décrites dans la DPC.

5.3 Mesures de sécurité vis-à-vis du personnel 5.3.1 Qualifications, compétence et habilitations r equises

Chaque personne amenée à travailler au sein de l’AC est soumise à une clause de confidentialité vis-à-vis de son employeur. Il est également vérifié que les attributions de ces personnes correspondent à leurs compétences professionnelles. Toute personne intervenant dans les procédures de certification de l’IGC est informée de ses responsabilités relatives aux services de l’IGC et des procédures liées à la sécurité du système et au contrôle du personnel.

____________________________________________________________________________________________________________________________




5.3.2 Procédures de vérification des antécédents

L’AC met en œuvre tous les moyens légaux dont elle dispose pour s'assurer de l'honnêteté des personnels amenés à travailler au sein de la composante. Cette vérification est basée sur un contrôle des antécédents de la personne, il est notamment vérifié que chaque personne n'a pas fait l'objet de condamnation de justice en contradiction avec leurs attributions. Les personnes ayant un rôle de confiance ne doivent pas souffrir de conflit d’intérêts préjudiciables à l’impartialité de leurs tâches. Ces vérifications sont menées préalablement à l'affectation à un rôle de confiance et revues régulièrement (au minimum tous les 3 ans).

5.3.3 Exigences en matière de formation initiale Le personnel a été préalablement formé aux logiciels, matériels et procédures internes de fonctionnement et de sécurité qu'il met en œuvre et qu'il doit respecter, correspondants à la composante au sein de laquelle il opère. Le personnel a eu connaissance et compris les implications des opérations dont il a la responsabilité.

5.3.4 Exigences et fréquence en matière de formatio n continue Le personnel concerné reçoit une information et une formation adéquates préalablement à toute évolution dans les systèmes, dans les procédures, dans l'organisation, etc. en fonction de la nature de ces évolutions.

5.3.5 Gestion des métiers Des précisions sont fournies dans la DPC.

5.3.6 Sanctions en cas d’actions non autorisées Des précisions sont fournies dans la DPC.

5.3.7 Exigences vis-à-vis du personnel des prestata ires externes Des précisions sont fournies dans la DPC.

5.3.8 Documentation fournie au personnel Des précisions sont fournies dans la DPC.

5.4 Procédures de constitution des données d’audit La journalisation d’événements consiste à enregistrer les évènements manuellement ou électroniquement par saisie ou par génération automatique. Les fichiers résultants, sous forme papier et / ou électronique, doivent rendre possible la traçabilité et l’imputabilité des opérations effectuées.

5.4.1 Type d’événements à enregistrer L’IGC journalise les évènements concernant les systèmes liés aux fonctions qu'elles mettent en œuvre dans le cadre de l'IGC :

- Création / modification / suppression de comptes utilisateur (droits d'accès) et des données d'authentification correspondantes (mots de passe, certificats, etc.) ;

- Démarrage et arrêt des systèmes informatiques et des applications ; - Evènements liés à la journalisation : démarrage et arrêt de la fonction de journalisation, modification des

paramètres de journalisation, actions prises suite à une défaillance de la fonction de journalisation ; - Connexion / déconnexion des utilisateurs ayant des rôles de confiance, et des tentatives non réussies

correspondantes. D’autres évènements sont également recueillis. Il s’agit d’évènements concernant la sécurité qui ne sont pas produits automatiquement par les systèmes mis en œuvre :

____________________________________________________________________________________________________________________________




- Les accès physiques aux zones sensibles ; - Les actions de maintenance et de changements de la configuration des systèmes ; - Les changements apportés au personnel ayant des rôles de confiance ; - Les actions de destruction et de réinitialisation des supports contenant des informations confidentielles

(clés, données d’activation, renseignements personnels sur les Utilisateurs,...). En plus de ces exigences de journalisation communes à toutes les composantes et à toutes les fonctions de l'IGC, des évènements spécifiques aux différentes fonctions de l'GC sont également journalisés :

- Réception d'une demande de certificat (initiale et renouvellement) ; - Validation / rejet d'une demande de certificat ; - Evènements liés aux clés de signature et aux certificats d'AC (génération (cérémonie des clés),

sauvegarde / récupération, destruction,...) ; - Génération des certificats de porteurs ; - Transmission des certificats aux porteurs et selon les cas, acceptations / rejets par les Porteurs ; - Publication et mise à jour des informations liées à l'AC ; - Génération d’information de statut d’un certificat (porteur).

Chaque enregistrement d'un évènement dans un journal contient les champs suivants :

- Type de l'évènement ; - Nom de l’exécutant ou référence du système déclenchant l’évènement ; - Date et heure de l’évènement ; - Résultat de l’évènement (échec ou réussite).

L’imputabilité d’une action revient à la personne, à l’organisme ou au système l’ayant exécutée. Le nom ou l’identifiant de l’exécutant figure explicitement dans l’un des champs du journal d’évènements. Selon le type de l'évènement concerné, les champs suivants peuvent être enregistrés:

- Destinataire de l’opération ; - Nom ou identifiant du demandeur de l’opération ou référence du système effectuant la demande ; - Nom des personnes présentes (s’il s’agit d’une opération nécessitant plusieurs personnes) ; - Cause de l’évènement ; - Toute information caractérisant l'évènement (par exemple, pour la génération d'un certificat, le numéro de

série de ce certificat).

5.4.2 Processus de journalisation Les opérations de journalisation sont effectuées au cours du processus considéré. En cas de saisie manuelle, l’écriture se fera, sauf exception, le même jour ouvré que l’évènement. Des précisions sont fournies dans la DPC.

5.4.3 Protection des journaux d’événements La journalisation doit être conçue et mise en œuvre de façon à limiter les risques de contournement, de modification ou de destruction des journaux d’évènements. Des mécanismes de contrôle d'intégrité doivent permettre de détecter toute modification, volontaire ou accidentelle, de ces journaux. Les journaux d’évènements doivent être protégés en disponibilité (contre la perte et la destruction partielle ou totale, volontaire ou non). La définition de la sensibilité des journaux d’évènements dépend de la nature des informations traitées et du métier. Elle peut entraîner un besoin de protection en confidentialité.

5.4.4 Procédures de sauvegarde des journaux d’événe ments

____________________________________________________________________________________________________________________________




L’IGC mettent en place les mesures requises afin d'assurer l'intégrité et la disponibilité des journaux d'évènements pour la composante considérée, conformément aux exigences de la présente PC et en fonction des résultats de l'analyse de risques de l'AC.

5.4.5 Système de collecte des journaux d’événements Des précisions sont fournies dans la DPC.

5.4.6 Evaluation des vulnérabilités L’AC et l’AE doivent être en mesure de détecter toute tentative de violation de l’intégrité de la composante considérée. Les journaux d’évènements sont contrôlés régulièrement afin d'identifier des anomalies liées à des tentatives en échec. Les journaux sont analysés au moins à une fréquence mensuelle. Cette analyse donnera lieu à un résumé dans lequel les éléments importants sont identifiés, analysés et expliqués. Le résumé doit faire apparaître les anomalies et les falsifications constatées.

5.5 Archivage des données L’archivage des données permet d'assurer la pérennité des journaux constitués par les différentes composantes de l'IGC.

5.5.1 Type de données archivées Les données archivées au niveau de chaque composante, sont les suivantes :

- Les logiciels (exécutables) et les fichiers de configuration des équipements informatiques ; - La politique de certification ; - La déclaration des pratiques de certification ; - Les certificats tels qu’émis ou publiés ; - Les justificatifs d’identité des porteurs et, le cas échéant, de leur entité de rattachement (pour les

entreprises et les administrations) ; - Les dossiers complets de demandes de certificats ; - Les journaux d'évènements des différentes entités de l'IGC.

5.5.2 Période de conservation des archives

Certificats et LCR émis par l’AC Les certificats de porteur et d'AC sont archivés 10 ans après leur expiration. Journaux d’événements Les journaux d'évènements traités au chapitre 5.4 sont archivés pendant 10 ans après leur génération.

5.5.3 Protection des archives Pendant tout le temps de leur conservation, les archives et leurs sauvegardes :

- Seront protégées en intégrité ; - seront accessibles aux seules personnes autorisées ; - pourront être consultées et exploitées.

5.5.4 Exigences d’horodatage des données

Si un service d'horodatage est utilisé pour dater les enregistrements, il doit répondre aux exigences formulées à l'article 6.8.

5.5.5 Système de collecte des archives

____________________________________________________________________________________________________________________________




Le système assure la collecte des archives en respectant le niveau de sécurité relatif à la protection des données (Se reporter au 5.5.3).

5.5.6 Procédures de récupération et de vérification des archives Les archives papier sont récupérables dans un délai inférieur ou égal à 2 jours ouvrés. Les sauvegardes électroniques archivées sont récupérables dans un délai inférieur ou égal à 2 jours ouvrés.

5.6 Renouvellement de bi-clé 5.6.1 Certificat d'AC

La durée de vie d'un certificat d'AC est déterminée selon la période de validité de la clé privée associée, en conformité avec les recommandations cryptographiques de sécurité relatives aux longueurs de clés, notamment conformément aux recommandations des autorités nationale ou internationale compétentes en la matière. La DPC précise les standards utilisés. Une AC ne peut pas générer de certificats dont la durée de vie dépasse la période de validité de son certificat d'AC. C'est pourquoi, la bi-clé d'une AC est renouvelée au plus tard à la date d'expiration du certificat d'AC moins la durée de vie des certificats émis. Dès qu'une nouvelle clé privée est générée pour l'AC, seule celle-ci est utilisée pour générer de nouveaux certificats de porteurs. Le précédent certificat d'AC reste valable pour valider le chemin de certification des anciens certificats émis par la précédente clé privée d'AC, jusqu'à l'expiration de tous les certificats porteurs émis à l'aide de cette bi-clé.

Durée de vie d'un certificat porteur

Durée de vie du certificat d’AC en cours

Date au plus tard d'émission d'un certificat

Temps

Fin de vie du certificat d'AC

Date au plus tard de génération d'un certificat d'AC Durée de vie du certificat de la nouvelle AC

Par ailleurs, l'AC change sa bi-clé et le certificat correspondant quand la bi-clé cesse d'être conforme aux recommandations de sécurité cryptographique concernant la taille des clés ou si celle-ci est soupçonnée de compromission ou compromise.

5.6.2 Certificat de Porteur La durée de validité d'un certificat est de 3 ans maximum.

5.7 Compromission et plan de reprise 5.7.1 Procédures en cas d'incident et de compromiss ion

L’AC a établi un plan de continuité de service qui met en évidence les différentes étapes à exécuter dans l'éventualité de la corruption ou de la perte des ressources système, des logiciels et ou des données et qui pourraient perturber ou compromettre le bon déroulement des services d'AC.

____________________________________________________________________________________________________________________________




L’AC a conduit une analyse de risque pour évaluer les risques métier et déterminer les exigences de sécurité et procédures opérationnelles afin de rédiger un plan de reprise d'activité. Les risques pris en compte sont régulièrement revus et le plan est révisé en conséquence. Le plan de continuité de l'AC fait partie du périmètre audité, selon le paragraphe 8.4 ci-dessous. Les personnels de l'AC dans un rôle de confiance sont spécialement entraînés à réagir selon les procédures définies dans le plan de reprise d'activité qui concernent les activités les plus sensibles. Dans le cas où l’AC détecte une tentative de piratage ou une autre forme de compromission, elle mène une analyse afin de déterminer la nature des conséquences et leur niveau. Si l'un des algorithmes, ou des paramètres associés, utilisés par l'AC ou ses porteurs devient insuffisant pour son utilisation prévue restante, alors l'AC :

- Informe tous les porteurs et les tiers utilisateurs de certificats avec lesquels l'AC a passé des accords ou a d'autres formes de relations établies. En complément, cette information est mise à disposition des autres utilisateurs de certificats ;

- Révoque tous les certificats concernés. Si nécessaire, l'ampleur des conséquences est évalué par l’AC afin de déterminer si les services de l'AC doivent être rétablis, quels certificats porteurs doivent être révoqués, l'AC doit être déclarée compromise, certains services peuvent être maintenus (en priorité les services de révocation et de publication d'état des certificats porteurs) et comment, selon le plan de reprise d'activité. L'AC doit également prévenir directement et sans délai le point de contact identifié sur le site : www.ssi.gouv.fr.

5.7.2 Corruption des ressources informatiques, des logiciels, et/ou des données Si le matériel de l'AC est endommagé ou hors service alors que les clés de signature ne sont pas détruites, l'exploitation est rétablie dans les plus brefs délais, en donnant la priorité à la capacité de fourniture des service de révocation et de publication d'état de validité des certificats, conformément au plan de reprise d'activité de l'AC.

5.7.3 Procédures en cas de compromission de la clé privée d'une entité Si la clé de signature de l'AC est compromise, perdue, détruite, ou soupçonnée d'être compromise :

- Le CAP, après enquête sur l'évènement décide de révoquer le certificat de l'AC ; - Tous les Clients dont les certificats ont été émis par l'AC compromise, sont avisés dans les plus brefs

délais que le certificat d'AC a été révoqué ; - Le CAP décide ou non de générer un nouveau certificat d'AC ; - Une nouvelle bi-clé AC est générée et un nouveau certificat d'AC est émis ; - Les porteurs sont informés de la capacité retrouvée de l'AC de générer des certificats.

5.7.4 Capacités de reprise d'activité à la suite d' un sinistre

Le plan de reprise d’activité après sinistre traite de la continuité d'activité telle qu'elle est décrite au § 5.7.1. Le SP est installé afin d'être disponible 24 heures sur 24 et 7 jours sur 7.

5.8 Fin de vie d'AC Une ou plusieurs composantes de l'IGC peuvent être amenées à cesser leur activité ou à la transférer à une autre entité pour des raisons diverses. L’AC prend les dispositions nécessaires pour couvrir les coûts permettant de respecter ces exigences minimales dans le cas où l'AC serait en faillite ou pour d’autres raisons serait incapable de couvrir ces coûts par elle-même, ceci, autant que possible, en fonction des contraintes de la législation applicable en matière de faillite.

____________________________________________________________________________________________________________________________




Le transfert d’activité est défini comme la fin d’activité d’une composante de l’IGC ne comportant pas d’incidence sur la validité des certificats émis antérieurement au transfert considéré et la reprise de cette activité organisée par l’AC en collaboration avec la nouvelle entité. La cessation d’activité est définie comme la fin d’activité d’une composante de l’IGC comportant une incidence sur la validité des certificats émis antérieurement à la cessation concernée.

5.8.1 Transfert d’activité ou cessation d’activité affectant une composante de l’IGC

5.8.1.1 AC Afin d'assurer un niveau de confiance constant pendant et après de tels évènements, l’AC :

- Met en place des procédures dont l'objectif est d'assurer un service constant en particulier en matière d'archivage (notamment, archivage des certificats des porteurs et des informations relatives aux certificats) ;

Assure la continuité de la révocation (prise en compte d'une demande de révocation et publication des LCR), conformément aux exigences de disponibilité pour ses fonctions définies dans la PC.

Des précisions quant aux engagements suivants doivent ainsi être annoncées par l'AC dans sa PC :

- Dans la mesure où les changements envisagés peuvent avoir des répercussions sur les engagements vis à vis des porteurs ou des utilisateurs de certificats, l’AC les en avise aussitôt que nécessaire ;

- L'AC communique au point de contact identifié sur le site : www.ssi.gouv.fr [[email protected]] les principes du plan d'action mettant en œuvre les moyens techniques et organisationnels destinés à faire face à une cessation d’activité ou à organiser le transfert d’activité. Elle y présentera notamment les dispositifs mis en place en matière d'archivage (clés et informations relatives aux certificats) afin d’assurer ou faire assurer cette fonction sur toute la durée initialement prévue dans sa PC. L'AC communiquera à l’ANSSI, selon les différentes composantes de l’IGC concernées, les modalités des changements survenus. L'AC mesurera l'impact et fera l'inventaire des conséquences (juridiques, économiques, fonctionnelles, techniques, communicationnelles, etc.) de cet évènement. Elle présentera un plan d'action destiné à supprimer, ou réduire, le risque pour les applications et la gêne pour les porteurs et les utilisateurs de certificats ;

- L’AC tient informée l’ANSSI de tout obstacle ou délai supplémentaire rencontrés dans le déroulement du processus.

Les archives (de l’AC ou de l’AE) sont prises en charge par la société reprenant l'activité dans le cas d'un transfert d'activité, ou, dans le cas de la cessation d'activité, reprise par une société d'archivage spécialisée, fiable et reconnue par les responsables des applications utilisatrices autorisées. Les entités précitées sont avisées des coordonnées de ces sociétés. Si les fonctions de fourniture de certificats pour l'AC sont transférées à une autre entité (transfert de la maîtrise d’oeuvre des AC opérationnelles), l'Autorité Certifiante préviendra, s’il y lieu, les responsables des applications utilisatrices autorisées qui pourront alors vérifier si cette entité a un niveau d'assurance compatible avec leur Référencement. En outre, les dispositions techniques prises pour un tel transfert seront du ressort du Comité d’Approbation des Politiques. Si décision est prise de mettre un terme à la vie d’une AC opérationnelle, la clé privée de cette dernière qui lui a servi à signer les certificats précédemment émis est détruite, et l’Autorité Certifiante conserve ses obligations d’archivage, et s’oblige à :

- Communiquer avec un préavis de trois mois son intention de cesser l’activité de l’AC opérationnelle considérée ;

____________________________________________________________________________________________________________________________




- Mettre en oeuvre tous les moyens dont elle dispose pour informer ses partenaires de ses intentions ; - Révoquer le certificat de l’AC opérationnelle considérée ;

Révoquer tous les certificats valides qu'elle a signés

5.8.1.2 Cas spécifique de perte d’agrément : L’AC prend toutes les mesures appropriées pour modifier la présente PC, concernant cet aspect. L’AC informe ses AED qui relaieront cette information par le moyen quelles jugeront appropriés aux porteurs. L’AC modifie les documents afin qu’elle ne puisse plus se prévaloir de cet agrément. L’AC prend les mesures qui s’imposent en mettant en œuvre, dans les meilleurs délais et au besoin, un mécanisme qui permettra à terme pour les certificats émis de prévoir un dispositif de renouvellement ou de substitution sur un mécanisme technique susceptible de répondre à cet agrément. L’AC conserve comme prévue au 5.8.1.1 premier paragraphe les obligations qui en découle. A terme et au besoin, l’AC qui a perdu l’agrément sera remplacée au profit de la nouvelle structure ou AC agréé.

5.8.1.3 AED En cas de transfert d’activité d’une AED, cette dernière prévient tous ses Clients, par un moyen à sa discrétion avec un préavis de trois mois. En cas de cessation d'activité d’une AED, cette dernière prévient tous ses Clients, par un moyen à sa discrétion avec un préavis de trois mois, en lui proposant éventuellement une solution de remplacement.

5.8.2 Cessation d’activité affectant l'AC La cessation d’activité peut être totale ou partielle (par exemple : cessation d’activité pour une famille de certificats donnée seulement). La cessation partielle d’activité est progressive de telle sorte que seules les obligations visées ci-dessous soient à exécuter par l’AC, ou une entité tierce qui reprend les activités, lors de l’expiration du dernier certificat émis par elle. Dans l'hypothèse d'une cessation d'activité totale, l’AC ou, en cas d’impossibilité, toute entité qui lui serait substituée de par l’effet d’une loi, d’un règlement, d'une décision de justice ou bien d’une convention antérieurement conclue avec cette entité, assurera la révocation des certificats et la publication des LCR conformément aux engagements pris dans la PC. L’AC procède aux actions suivantes :

- La notification des entités affectées ; - Le transfert de ses obligations à d’autres parties ; - La gestion du statut de révocation pour les certificats non-expirés qui ont été délivrés.

Lors de l'arrêt du service, l'AC :

- S’interdit de transmettre la clé privée lui ayant permis d’émettre des certificats ; - Prend toutes les mesures nécessaires pour la détruire ou la rendre inopérante ; - Révoque son certificat ; - Révoque tous les certificats qu’elle a signés et qui seraient encore en cours de validité ; - Informe (par exemple par récépissé) tous les MC et/ou porteurs des certificats révoqués ou à révoquer,

ainsi que leur entité de rattachement le cas échéant.

____________________________________________________________________________________________________________________________




6 MESURES TECHNIQUES DE SECURITE

6.1 Génération et installation des bi-clés 6.1.1 Génération des bi-clés

6.1.1.1 Bi-clés d’AC Suite à l'accord du CAP pour la génération d'un certificat d'AC, une bi-clé est générée lors d'une cérémonie de clé à l’aide d'une ressource cryptographique matérielle. Les cérémonies de clés se déroulent sous le contrôle d'au moins trois personnes dans des rôles de confiance (maître de cérémonie et témoins) et sont impartiaux. Elle se déroule dans les locaux de l'OC. Les témoins attestent, de façon objective et factuelle, du déroulement de la cérémonie par rapport au script préalablement défini. Les rôles impliqués dans les cérémonies de clés sont précisés dans la DPC. Les cérémonies de clés se déroulent sous le contrôle d'au moins deux personnes ayant des rôles de confiance et en présence de plusieurs témoins dont au moins deux sont externes à l'AC et sont impartiaux. Les témoins attestent, de façon objective et factuelle, du déroulement de la cérémonie par rapport au script préalablement défini. Il est recommandé qu'il y ait parmi les témoins un officier public (huissier ou notaire). Suite à leur génération, les parts de secrets (données d’activation) sont remises à des porteurs de données d’activation désignés au préalable et habilités à ce rôle de confiance par l'AC. Quelle qu'en soit la forme (papier, support magnétique ou confiné dans une carte à puce ou une clé USB), un même porteur ne peut détenir plus d'une part de secrets d'une même AC à un moment donné. Chaque part de secrets doit être mise en œuvre par son porteur.

6.1.1.2 Bi-clés de Porteurs La génération de la bi-clé du porteur est réalisée directement dans le support matériel de la bi-clé par le porteur. Le processus de génération et la procédure de remise de la bi-clé et de son support au porteur permettent de garantir que seul profit le porteur peut en avoir l’utilisation. La génération s’effectue lors du retrait de certificat par le porteur.

6.1.2 Fourniture de la clé privée au porteur Sans objet.

6.1.3 Fourniture de la clé publique à l'AC La clé publique est transmise à l'AC par le porteur qui initie la demande de certificat auprès de l’AE, sous un format PKCS#10, et lors d'une connexion sécurisée de manière à garantir l’intégrité et la confidentialité de la communication et l’authentification entre l’AC et l’AE.

6.1.4 Fourniture de la clé publique d'AC aux tierce s parties Le certificat de l’AC est remis au porteur lors de la remise du certificat au porteur.

6.1.5 Taille de clés Les recommandations des organismes nationaux et internationaux compétents (relatives aux longueurs de clés, algorithmes de signature, algorithme de hachage…) sont périodiquement consultées afin de déterminer si les paramètres utilisés dans l'émission de certificats porteurs et AC doivent ou ne doivent pas être modifiés. L'utilisation de l'algorithme RSA avec la fonction de hachage SHA-256 est utilisée pour l'AC. La taille de la bi-clé de l’AC est d’au moins 2048 bits. La longueur des clés des certificats porteurs est de 2048 bits pour l'algorithme RSA avec la fonction de hachage SHA-256 au minimum.

____________________________________________________________________________________________________________________________




6.1.6 Production des paramètres des clés publiques et contrôle de qualité

Les équipements utilisés pour la génération des bi-clés d’AC sont des ressources cryptographiques matérielles évaluées certifiées EAL 4+. Les bi-clés des porteurs sont générées par le porteur à l’aide d’un support matériel évalué certifié EAL 4+.

6.1.7 Utilisation de la clé (selon le champ "key us age" du certificat X 509 V3) L'utilisation du champ "key usage" dans le certificat porteur et certificat AC est la suivante :

- AC : o Key CertSign ; o Key CRL Sign ;

- Porteur : o Non Repudiation ; o Digital signature.

6.2 Protection des clés privées et normes relatives au module cryptographique 6.2.1 Normes applicables aux ressources cryptograph iques et contrôles

La ressource cryptographique matérielle de l’AC utilise des générateurs d’aléas qui devront être conformes à l’état de l’art, aux standards en vigueur ou suivre les spécifications de la normalisation lorsqu’ils sont normalisés. Les algorithmes utilisés devront être conformes aux standards en vigueurs ou suivre les spécifications de la normalisation lorsqu’ils sont normalisés. L’AC fournit le support matériel au porteur, directement, et s’assure que :

- La préparation des dispositifs de création de signature est contrôlée de façon sécurisée par le prestataire de service ;

- Les supports matériels sont stockés et distribués de façon sécurisée dans l’OC.

6.2.2 Contrôle de la clé privée par de multiples pe rsonnes L'activation de la clé privée d'AC est contrôlée par au moins 2 personnes détenant des données d'activations et qui sont dans des rôles de confiance. Les personnes de confiance participant à l'activation de la clé privée d'AC font l'objet d'une authentification forte. L’AC est activée dans un boîtier cryptographique afin qu’elle puisse être utilisée par les seul rôles de confiances qui peuvent émettre des certificats. Le porteur est responsable de la protection et du contrôle de la clé privée à l’aide de sa donnée d’activation.

6.2.3 Séquestre de clé privée Les clés privées d'AC et des porteurs ne font jamais l'objet de séquestre.

6.2.4 Sauvegarde de clé privée

6.2.4.1 AC La bi-clé d'AC est sauvegardée sous le contrôle de plusieurs personnes à des fins de reprise d'activité. Les sauvegardes des clés privées sont réalisées à l'aide de ressources cryptographiques matérielles. Les sauvegardes sont rapidement transférées sur site sécurisé de sauvegarde délocalisé afin de fournir et maintenir la capacité de reprise d'activité de l'AC. Les sauvegardes de clés privées d'AC sont stockées dans des ressources cryptographiques matérielles ou sous forme de fichier chiffrée (AES ou 3DES).

6.2.4.2 Porteur Le porteur ne peut pas procéder à une copie de sauvegarde de sa clé privée.

____________________________________________________________________________________________________________________________




6.2.5 Archivage de clé privée

Les clés privées d'AC ne font jamais l'objet d'archives.

6.2.6 Importation / exportation d'une clé privée Les clés d'AC sont générées, activées et stockées dans des ressources cryptographiques matérielles ou sous forme chiffrées. Quand elles ne sont pas stockées dans des ressources cryptographiques ou lors de leur transfert, les clés privées d'AC sont chiffrées au moyen de l'algorithme AES ou 3DES. Une clé privée d'AC chiffrée ne peut être déchiffrée sans l'utilisation d'une ressource cryptographique matérielle et la présence de multiples personnes dans des rôles de confiance.

6.2.7 Stockage d'une clé privée dans un module cryp tographique

6.2.7.1 AC Les clés privées d'AC stockées dans des ressources cryptographique matérielles sont protégées avec le même niveau de sécurité que celui dans lequel elles ont été générées.

6.2.7.2 Porteur Le support matériel est expédié « vierge » au Client et est personnalisé électriquement (tirage de la bi-clé et stockage du certificat) par le Porteur lui-même au niveau du poste client.

6.2.8 Méthode d'activation d'une clé privée

6.2.8.1 AC Les clés privées d'AC ne peuvent être activées qu'avec un minimum de 2 personnes dans des rôles de confiance et qui détiennent des données d'activation de l'AC en question.

6.2.8.2 Porteur La clé privée d’un porteur est activable à l’aide d’une donnée d’activation. L’activation est nécessaire à chaque utilisation de la clé privée à l’aide du support matériel de la bi-clé.

6.2.9 Méthode de désactivation d'une clé privée

6.2.9.1 AC Les ressources cryptographiques matérielles dans lesquelles des clés d'AC ont été activées ne sont pas laissées sans surveillance ou accessible à des personnes non autorisées. Après utilisation, les ressources cryptographiques matérielles sont désactivées. Les ressources cryptographiques sont ensuite stockées dans une zone sécurisée pour éviter toute manipulation non autorisée par des rôles non fortement authentifiés. Les ressources cryptographiques de signature de l'AC sont en ligne uniquement afin de signer des certificats porteurs et des LCR après avoir authentifié la demande de certificat et la demande de révocation.

6.2.9.2 Porteur La désactivation de la clé privée du porteur est effectuée de façon à garantir que la clé privée, contenue dans le support matériel, est toujours sous le contrôle du porteur.

6.2.10 Méthode de destruction d'une clé privée

6.2.10.1 AC Les clés privées d'AC sont détruites quand elles ne sont plus utilisées ou quand les certificats auxquels elles correspondent sont expirés ou révoqués. La destruction d'une clé privée implique la destruction des copies de

____________________________________________________________________________________________________________________________




sauvegarde, des données d'activation et l'effacement de la ressource cryptographique qui la contient, de manière à ce qu'aucune information ne puisse être utilisée pour la retrouver.

6.2.10.2 Porteur La destruction de la clé privée du porteur est effectuée à l’aide du support matériel de la bi-clé en utilisant les fonctions logiques d’effacement pour le support matérielle de la bi-clé et/ou en détruisant le support matériel de la bi-clé.

6.2.11 Certification des ressources cryptographique s Se reporter au § 6.2.1.

6.3 Autres aspects de la gestion des bi-clés 6.3.1 Archivage des clés publiques

Les clés publiques sont archivées par archivage des certificats (Se reporter au § 5.5.2 ci-dessus).

6.3.2 Durée de validité opérationnelle des certific ats et durée d'utilisation des bi-clés

6.3.2.1 AC Comme une AC ne peut émettre de certificats porteurs d'une durée de vie supérieure à celle de son propre certificat, la bi-clé et le certificat auquel elle correspond sont renouvelés au plus tard à la date d'expiration du certificat d'AC moins la durée de vie des certificats porteurs émis.

6.3.2.2 Porteur La durée de vie opérationnelle d'un certificat est limitée par son expiration ou sa révocation. La durée de vie opérationnelle d'une bi-clé est équivalente à celle du certificat auquel elle correspond.

6.4 Données d'activation 6.4.1 Génération et installation des données d'acti vation

6.4.1.1 AC Les données d'activation des clés privées d'AC sont générées durant les cérémonies de clés (Se reporter au § 6.1.1.1). Les données d'activation sont générées automatiquement selon un schéma de type M of N. Dans tous les cas les données d'activation sont remises à leurs porteurs après génération pendant la cérémonie des clés. Les porteurs de données d'activation sont des personnes habilitées pour ce rôle de confiance.

6.4.1.2 Porteur La donnée d’activation du support est choisie par le porteur. L’AC définie et conserve la donnée de déblocage du support matériel du porteur. Le support matériel est transmis par l’AE au porteur sans aucune bi-clé dedans. Le porteur doit impérativement définir la donnée d’activation à la première utilisation de son support matériel. Le mot de passe choisit par le porteur doit au minimum comporter 6 caractères alphanumériques.

6.4.2 Protection des données d'activation

6.4.2.1 AC Les données d'activation sont protégées de la divulgation par une combinaison de mécanismes cryptographiques et de contrôle d'accès physique. Les porteurs de données d'activation sont responsables de leur gestion et de leur protection. Un porteur de données d'activation ne peut détenir plus d'une donnée d'activation d'une même AC à un même instant.

____________________________________________________________________________________________________________________________




6.4.2.2 Porteur Le porteur s'assure que la donnée d'activation de la clé privée est protégée en confidentialité de tel sorte qu’il soit le seul à pouvoir activer la clé privée contenue sur son support matériel.

6.4.3 Autres aspects touchant aux données d'activat ion

6.4.3.1 AC Les données d'activation sont changées dans le cas ou les ressources cryptographiques sont changées ou retournées au constructeur pour maintenance. Les autres aspects de la gestion des données d'activation sont précisés dans la DPC.

6.4.3.2 Porteur Si le porteur bloque son support matériel, alors il peut faire appel au service de personnalisation des supports pour débloquer son support matériel.

6.5 Mécanismes de sécurité des systèmes informatiqu es 6.5.1 Exigences techniques de sécurité des ressourc es informatiques

Les fonctions suivantes sont fournies par le système d'exploitation, ou par une combinaison du système d'exploitation, de logiciels et de protection physiques. Un composant d'une IGC comprend les fonctions suivantes :

- Authentification des rôles de confiance ; - Contrôle d'accès discrétionnaire ; - Interdiction de la réutilisation d'objets ; - Exige l'utilisation de la cryptographie lors des communications ; - Requiert l'identification des utilisateurs ; - Assure la séparation rigoureuse des tâches ; - Fournit une autoprotection du système d'exploitation.

Quand un composant d'IGC est hébergé sur une plateforme évaluée au regard d'exigences d'assurance de sécurité, il doit être utilisé dans sa version certifiée. Au minimum le composant utilise la même version de système d'exploitation que celle sur lequel le composant a été certifié. Les composants d'IGC sont configurés de manière à limiter les comptes et services aux seuls éléments nécessaires pour supporter les services d'AC.

6.5.2 Indice de sécurité informatique Les composants d'IGC utilisés pour supporter les services d'AC et qui sont hébergés par l’OC ont été conçus en suivant les recommandations du document du CEN CWA 14167-1 "Security requirement for trustworthy system managing digital certificates for electronic signatures".

6.6 Contrôles techniques du système pendant son cyc le de vie 6.6.1 Contrôle des développements des systèmes

Le contrôle des développements des systèmes s'effectue comme suit :

- Des matériels et des logiciels achetés de manière à réduire les possibilités qu'un composant particulier soit altéré ;

- Les matériels et logiciels mis au point l'ont été dans un environnement contrôlé, et le processus de mise au point défini et documenté. Cette exigence ne s'applique pas aux matériels et aux logiciels achetés dans le commerce ;

- Tous les matériels et logiciels doivent être expédiés ou livrés de manière contrôlée permettant un suivi continu depuis le lieu de l'achat jusqu'au lieu d'utilisation ;

- Les matériels et logiciels sont dédiés aux activités d'IGC. Il n'y a pas d'autre application, matériel, connexion réseau, ou composant logiciels installés qui ne soit pas dédiés aux activités d'IGC ;

____________________________________________________________________________________________________________________________




- Il est nécessaire de prendre soin de ne pas télécharger de logiciels malveillants sur les équipements de l'IGC. Seules les applications nécessaires à l'exécution des activités IGC sont acquises auprès de sources autorisées par politique applicable de l'AC. Les matériels et logiciels de l'AC font l'objet d'une recherche de codes malveillants dès leur première utilisation et périodiquement par la suite ;

- Les mises à jour des matériels et logiciels sont achetées ou mises au point de la même manière que les originaux, et seront installés par des personnels de confiance et formés selon les procédures en vigueur.

6.6.2 Contrôles de gestion de la sécurité

La configuration du système d'AC, ainsi que toute modification ou évolution, est documentée et contrôlée par l’AC. Il existe un mécanisme permettant de détecter toute modification non autorisée du logiciel ou de la configuration de l'AC. Une méthode formelle de gestion de configuration est utilisée pour l'installation et la maintenance subséquente du système d’IGC. Lors de son premier chargement, on vérifie que le logiciel de l'IGC est bien celui livré par le vendeur, qu'il n'a pas été modifié avant d'être installé, et qu'il correspond bien à la version voulue.

6.6.3 Contrôle de sécurité du système pendant son c ycle de vie En ce qui concerne les logiciels et matériels évalués, l'AC poursuit sa surveillance des exigences du processus de maintenance pour maintenir le niveau de confiance.

6.7 Mécanismes de sécurité du réseau L'AC est en ligne accessible par des postes informatiques sous contrôle. Les composantes accessibles de l'IGC sont connectées à l'Internet dans une architecture adaptée présentant des passerelles de sécurité et assurent un service continu (sauf lors des interventions de maintenance ou de sauvegarde). Les autres composantes de l’IGC de l'AC utilisent des mesures de sécurité appropriées pour s'assurer qu'elles sont protégées contre des attaques de déni de service et d'intrusion. Ces mesures comprennent l'utilisation de gardes, de pare-feu et de routeurs filtrants. Les ports et services réseau non utilisés sont coupés. Tout appareil de contrôle de flux utilisé pour protéger le réseau sur lequel le système IGC est hébergé refuse tout service, hormis ceux qui sont nécessaires au système IGC, même si ces services ont la capacité d'être utilisés par d'autres appareils du réseau.

6.8 Horodatage/Système de datation Il n’y a pas d’horodatage utilisé par l’AC mais une datation sûre. Tous les composants de l'AC sont régulièrement synchronisés avec un serveur de temps tel qu'une horloge atomique ou un serveur Network Time Protocol (NTP). Le temps fourni par ce serveur de temps doit être utilisé pour établir l'heure :

- Du début de validité d'un certificat de l'AC; - De la révocation d'un certificat de l'AC; - De l'affichage de mises à jour de LCR.

Des procédures automatiques ou manuelles peuvent être utilisées pour maintenir l'heure du système. Les réglages de l'horloge sont des événements susceptibles d'être audités.

____________________________________________________________________________________________________________________________




7 CERTIFICATS, CRL, ET PROFILS OCSP

7.1 Profil de Certificats Les certificats émis par l'AC sont des certificats au format X.509 v3 (populate version field with integer "2"). Les champs des certificats porteurs et AC sont définis par le RFC 5280.

7.1.1 Extensions de Certificats

7.1.1.1 Certificat AC -

Le certificat d’AC est constitué de la manière suivante : Certificat de base Valeur

Version 2 (=version 3) Serial number Défini par l’outil Issuer DN O = CEDICAM

OU= 0002 723001467 CN=AC Racine groupe CREDIT AGRICOLE v2 C = FR

Subject DN O = CEDICAM OU= 0002 723001467 CN= CA LCL Certificat RGS Usage Separe C = FR

NotBefore YYMMDD000000Z NotAfter YYMMDD235959Z + 10 ans Public Key Algorithm and signature

Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Parameters NULL Extensions standards OID Inclure Critique Valeur

Authority Info Access (1.3.6.1.5.5.7.1.1) n/a

Authority Key Identifier {id-ce 35} X FALSE

Select AKI field Key Identifier Basic Constraint {id-ce 19} X TRUE

CA Set

Maximum Path Length 0

Certificate Policies {id-ce 32} X FALSE

policyIdentifiers 1.2.250.1.104.3.1.1.1.1.1.4.1

policyQualifiers n/a

CPSpointer n/a

OID

value URI=http://www.ca -certificat.com/PC/v2client/AC_racine_CA_V2.pdf

User Notice n/a

OID n/a

____________________________________________________________________________________________________________________________




value n/a

noticeRef n/a

organization n/a

noticeNumbers n/a

explicitText n/a

CRL Distribution Points {id-ce 31} X FALSE

distributionPoint URI=http://crl.ca -certificat.com/CREDITAGRICOLE/ACRacineGroupeCAv2.crl

reasons n/a

cRLIssuer n/a

Extended Key Usage {id-ce 37} n/a

Issuer Alternative Name {id-ce 18} n/a

Key Usage {id-ce 15} X TRUE

Digital Signature Clear

Non Repudiation Clear

Key Encipherment Clear

Data Encipherment Clear

Key Agreement Clear

Key CertSign Set

Key CRL Sign Set

Private Key Usage Period {id-ce 16} n/a

Subject Alternative Name {id-ce 17} n/a

Subject Key Identifier {id-ce 14} X FALSE

Methods of generating key ID Methode 1

Other Extensions

7.1.1.2 Certificat Porteur

Le certificat porteur est constitué de la manière suivante : Certificat de base Valeur Version 2 (=version 3) Serial number Défini par l’outil Taille de la clé 2048 Durée de validité 3 ans Issuer DN O=CEDICAM

OU=0002 723001467 CN= CA LCL Certificat RGS Usage Separe C=FR

Subject DN C=FR

____________________________________________________________________________________________________________________________




L=<Ville du demandeur> O=<Entreprise du demandeur> OU=0002< SIREN entreprise> OU= <Nom de l’offre commerciale> CN=<Prénom NOM> SerialNumber=<Identifiant Abonné du BO> E=<Email demandeur>

NotBefore YYMMDDHHMMSSZ NotAfter YYMMDDHHMMSSZ +3 ans Public Key Algorithm Sha256WithRSAEncryption (1.2.840.113549.1.1.11) Parameters NULL Extensions standards OID Inclure Critique Valeur



Select AKI field Key Identifier

Basic Constraint {id-ce 19} X TRUE

CA False

Maximum Path Length n/a




CPSpointer n/a

OID

value URI=http://www.ca -certificat -plus.com/PC/09client/Sign_Auth_National_CA_RGS.pdf

User Notice n/a

OID n/a

value n/a

noticeRef n/a

organization n/a

noticeNumbers n/a

explicitText n/a


distributionPoint URI= http://crl.ca-certificat.com/CreditAgricoleRGSUsageSepare/LatestCRL.crl URI=ldap://ldap.ca-certificat.com/cn=CA%20LCL%20Certificat%20RGS%20 Usage%20Separe,ou=0002%20723001467,o=CEDICAM?certificaterevocationlist;binary?base?objectclass=pkiCA

reasons n/a

____________________________________________________________________________________________________________________________




cRLIssuer n/a



Subject Alternative Name X FALSE

Rfc822Name <Email demandeur>


Digital Signature Set

Non Repudiation Set



Key Agreement Clear

Key CertSign Clear

Key CRL Sign Clear




Pour des raisons de test dans les applications, des certificats porteurs de test peuvent être émis par l’AC de production. Le certificat porteur comporte la valeur « XXX TEST » apposé dans le CN avant le <Prénom NOM>. Ce terme est rajouté lorsque le certificat est émis par l’AC de production. .

7.1.2 Identifiant d'algorithmes L’identifiant d’algorithme utilisé est Sha-256WithRSAEncryption: {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}.

7.1.3 Formes de noms Les formes de noms respectent les exigences du § 3.1.1our l’identité des porteurs et de l’AC qui est portée dans les certificats émis par l’AC.

7.1.4 Identifiant d'objet (OID) de la Politique de Certification Les certificats émis par l’AC contiennent l'OID de la PC qui est donné au § 1.2.

7.1.5 Extensions propres à l'usage de la Politique Sans objet.

____________________________________________________________________________________________________________________________




7.1.6 Syntaxe et Sémantique des qualificateurs de p olitique Sans objet.

7.1.7 Interprétation sémantique de l'extension crit ique "Certificate Policies" Pas d'exigence formulée.

____________________________________________________________________________________________________________________________




7.2 Profil de LCR 7.2.1 LCR et champs d'extensions des LCR

La LCR émis par l’AC est de la forme suivante : Caractéristiques de la CRL Durée de validité : 7 jours

Périodicité de mise à jour : 24 Heures Version de la CRL : V2 Extension : Numéro AKI => 3F AA 87 D9 92 CE 13 F9 9A 43 CE D7 A9 DA 7A C8 E0 1B 27 1A Publication http : URL http://crl.ca-certificat.com/CreditAgricoleRGSUsageSepare/LatestCRL.crl Publication LDAP : URI=ldap://ldap.ca-certificat.com/cn=CA%20LCL%20Certificat%20RGS%20Usage%20Separe,ou=0002%20723001467,o=CEDICAM?certificaterevocationlist;binary?base?objectclass=pkiCA

7.3 Profil OCSP Sans objet.

____________________________________________________________________________________________________________________________




8 CONTROLES DE CONFORMITE ET AUTRES EVALUATIONS

8.1 Fréquence et motifs des audits Le CAP de l’AC a la responsabilité du bon fonctionnement des composantes de l'ICP de l’AC, conformément aux dispositions énoncées dans le présent document. Il effectuera des contrôles réguliers de conformité et de bon fonctionnement des composantes de l’AC.

8.2 Identité / Qualification des auditeurs Les auditeurs doivent démontrer leurs compétences dans le domaine des audits de conformité, ainsi qu'être familiers avec les exigences de la PC. Les auditeurs en charge de l'audit de conformité doivent effectuer l'audit de conformité comme tâche principale. Le CAP apporte une attention particulière quant à l'audit de conformité, notamment vis-à-vis de ses exigences en matière d'audit. Le contrôleur est désigné par le Comité d'Approbation des Politiques de l’Autorité Certifiante.

8.3 Lien entre l'auditeur et l'entité contrôlée Dans le cas où le contrôle est effectué à la demande d’un tiers, le contrôleur est choisi selon des critères d'indépendance et d'expertise dans le domaine de la sécurité informatique et, en particulier, des ICP. Dans les autres cas, le contrôleur désigné pourra éventuellement être une entité d’audit interne au Crédit Agricole experte dans le domaine de la sécurité informatique.

8.4 Points couverts par l'évaluation L'objectif de l'audit de conformité est de vérifier qu'une composante de l'AC opère ses services en conformité avec la présente PC et sa DPC.

8.5 Mesures prises en cas de non-conformité En cas de non-conformité, le Comité d'Approbation des Politiques décide de toute action correctrice nécessaire. En fonction du degré de non-conformité de la DPC à la PC, le CAP peut :

- Demander la mise en place d'actions correctrices dont la réalisation sera vérifiée lors du prochain audit ; - Demander la correction des non-conformités selon un calendrier précis à la suite duquel un contrôle de

mise en conformité sera effectué ; - Révoquer le certificat de l’AC opérationnelle, si besoin ; - Révoquer un ou des certificats de porteurs.

8.6 Communication des résultats Un Rapport de Contrôle de Conformité, incluant la mention des mesures correctives déjà prises ou en cours par la composante, est remis au CAP comme prévu au § 8.1 ci-dessus. Les non-conformités révélées par ces audits seront publiées aux responsables des applications utilisatrices autorisées, pour lesquelles l’Autorité Certifiante s’y oblige contractuellement. Eu égard au caractère confidentiel de ces informations, la publication des résultats est limitée et strictement contrôlée.

____________________________________________________________________________________________________________________________




9 AUTRES DISPOSITIONS COMMERCIALES ET JURIDIQUES

9.1 Tarifs 9.1.1 Tarifs pour l'émission et le renouvellement d e certificats

Les conditions tarifaires en vigueur à la date d’acquisition du certificat sont données dans les "Conditions de tarification du service" de l’AC en annexe du "Contrat de Souscription" établit.

9.1.2 Tarifs pour l’accès aux certificats Se reporter au § 9.1.1.

9.1.3 Tarifs pour l’accès aux LCR et aux informatio ns d'état des certificats Le service de publication de l'AC (qui contient la LCR pour les certificats porteur et le LAR pour les certificats d’AC) est accessible gratuitement sur Internet.

9.1.4 Tarifs pour d'autres services Se reporter au § 9.1.1.

9.1.5 Politique de remboursement La politique de remboursement applicable est définie dans les conditions générales d’utilisation du certificat.

9.2 Responsabilité financière 9.2.1 Couverture par les assurances

L'AC applique des niveaux de couverture d'assurance raisonnables et a souscrit à cet effet une assurance responsabilité civile au titre de la réalisation de son activité professionnelle.

9.2.2 Autres ressources L'AC dispose de ressources financières suffisantes à son bon fonctionnement et à l'accomplissement de sa mission.

9.2.3 Couverture et garantie concernant les entités utilisatrices En cas de dommage subi par une entité utilisatrice du fait d’un manquement par l’AC à ses obligations, l’AC pourra être amené à dédommager l’entité utilisatrice dans la limite de la responsabilité de l'AC définie dans les conditions générales d’utilisation et aux présentes.

9.3 Confidentialité des informations et des données professionnelles 9.3.1 Périmètre des informations confidentielles

Les informations considérées comme confidentielles sont les suivantes :

- La partie non-publique de la DPC de l'AC, - Les clés privées de l'AC, des composantes et des porteurs de certificats, - Les données d’activation associées aux clés privées d'AC et des porteurs, - Tous les secrets de l'IGC, - Les journaux d’évènements des composantes de l’IGC, - Le dossier d’enregistrement du porteur, - Les causes de révocations, sauf accord explicite du porteur - La politique de sécurité interne de l'AC - Les parties de la DPC considérées comme confidentielles.

Par ailleurs, l'AC garantit que seuls ses personnels dans des rôles de confiance autorisés, les personnels contrôleurs dans la réalisation des audits de conformité, ou d'autres personnes détenant le besoin d'en connaître, ont accès et peuvent utiliser ces informations confidentielles.

____________________________________________________________________________________________________________________________




9.3.2 Informations hors du périmètre des informatio ns confidentielles

Les données figurant dans le certificat ne sont pas considérées comme confidentielles.

9.3.3 Obligations en terme de protection des inform ations confidentielles L'AC a mis en place et respecte des procédures de sécurité pour garantir la confidentialité des informations caractérisées comme confidentielles au sens de l’article 9.3.1 ci-dessus. A cet égard, l'AC respecte notamment la législation et la réglementation en vigueur sur le territoire français. En particulier, il est précisé qu’elle peut devoir mettre à disposition les dossiers d’enregistrement des porteurs à des tiers dans le cadre de procédures légales. L’AC permet également l’accès à ces informations au porteur.

9.4 Protection des données à caractère personnel 9.4.1 Politique de protection des données personnel les

Les données à caractère personnel recueillies lors de l'identification du Client, du représentant légal, de l’enregistrement du Mandataire de Certification et du Porteur, de même que celles qui seront recueillies ultérieurement, sont collectées par l’AED aux fins de délivrance, de gestion et de conservation des certificats pour le compte de l'Autorité de Certification. La collecte et le traitement de ces données sont réalisés dans le strict respect de la législation et de la réglementation en vigueur sur le territoire français, en particulier de la loi n°78-17 du 6 janvier 1978 modifiée, dîte « Informatique et Libertés ».

9.4.2 Informations considérées comme personnelles L'AC considère que les informations suivantes sont des données à caractère personnel :

- Données d’identification du Client, du représentant légal, du Mandataire de Certification et du Porteur ; - Données d'identité du Client, du représentant légal, du Mandataire de Certification et du Porteur ; - Données renseignées sur la demande d’émission de certificat ; - Données renseignées sur la demande de révocation de certificat ; - Motif de révocation des certificats des porteurs.

9.4.3 Informations à caractère non personnel

Aucune exigence n’est prévue par les présentes.

9.4.4 Obligations en terme de protection des donnée s personnelles L'AC a mis en place et respecte des procédures de protection des données personnelles pour garantir la sécurité des informations caractérisées comme personnelles au sens de l’article 9.4.1 ci-dessus dans le cadre de la délivrance et la gestion d’un certificat de porteur. A cet égard, l'AC respecte notamment la législation et la réglementation en vigueur sur le territoire français, en particulier, la loi n°78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés révisée 2006.

9.4.5 Consentement exprès et préalable à l'utilisat ion de données à caractère personnel

Aucune des données à caractère personnel communiquées par un Client, un représentant légal, un Mandataire de Certification ou un Porteur ne peut être utilisée par l’AC, pour une utilisation autre que celle définie dans le cadre de la PC sans consentement exprès et préalable de la personne concernée.

9.4.6 Obligations en terme de protection des donnée s personnelles

____________________________________________________________________________________________________________________________




L'AC agit conformément aux réglementations européenne et française et dispose de procédures sécurisées pour permettre l'accès des autorités judiciaires sur décision judiciaire ou autre autorisation légale aux données à caractère personnel. Les procédures de l’AC CA LCL Certificat RGS Usage Separe relatives au traitement de la confidentialité sont conformes à la législation française.

9.4.7 Droits de la personne concernée : Les droits d'opposition, d'accès et de rectification peuvent être exercés :

CREDIT AGRICOLE CARDS AND PAYMENTS Batiment Alsace

SERVICE CA CERTIFICAT + 83, BOULEVARD DES CHENES

78280 GUYANCOURT - FRANCE

9.5 Droits relatifs à la propriété intellectuelle Lors de l’exécution des prestations de services définies dans le présent document et/ou le "Contrat de Souscription" de l’AC, il peut être livré des éléments protégés par la législation sur les droits d'auteur. Ces éléments, ainsi que les droits d'auteur qui y sont attachés, resteront la propriété du détenteur des droits correspondants. Le bénéficiaire de ces services aura le droit de reproduire ces éléments pour son usage interne. Mais il ne pourra, sans l'autorisation préalable du détenteur des droits d'auteur, mettre à la disposition de tiers, extraire ou réutiliser en tout ou en partie, ces éléments ou des œuvres dérivées ou copies de ceux-ci, en particulier logiciels ou bases de données. Sous réserve des dispositions du présent article, aucune licence, implicite ou explicite, n'est concédée par le détenteur des droits sur des inventions, brevets ou demandes de brevets lui appartenant et ayant été réalisés hors du présent document et/ou du "Contrat de Souscription" de l’AC.

9.6 Obligations et garanties Les composantes de l’IGC, les Clients et la communauté d’utilisateurs de certificats sont responsables pour tous dommages occasionnés en suite d’un manquement de leurs obligations respectives telles que définies aux termes de la PC. 9.6.1 Obligations communes Les obligations communes des différentes composantes de l’IGC sont :

- Assurer l’intégrité et la confidentialité des clés privées dont elles sont dépositaires, ainsi que des données d’activation desdites clés privées, le cas échéant ;

- N’utiliser les clés publiques et privées dont elles sont dépositaires qu’aux seules fins pour lesquelles elles ont été émises et avec les moyens appropriés ;

- Mettre en œuvre les moyens techniques adéquats et employer les ressources humaines nécessaires à la réalisation des prestations auxquelles elles s'engagent ;

- Documenter leurs procédures internes de fonctionnement à l’attention de leur personnel respectif ayant à en connaître dans le cadre des fonctions qui lui sont dévolues en qualité de composante de l’IGC ;

- Respecter et appliquer les termes de la présente PC qu’elles reconnaissent ; - Accepter les audits et les résultats et les conséquences d’un contrôle de conformité (interne et externe) et,

en particulier, remédier aux non-conformités qui pourraient être révélées ; - Respecter les conventions qui les lient aux autres entités composantes de l’IGC.

9.6.2 Obligations et garanties du CAP

____________________________________________________________________________________________________________________________




Les obligations du CAP sont les suivantes :

- L’élaboration de la PC et de la DPC ; - Documente les schémas de certification qu’elle entretient avec des AC tierces ; - L’établissement de la conformité entre la PC et la DPC ; - Le maintien de la PC et de la DPC.

9.6.3 Obligations et garanties de l'AC L'AC s'assure que toutes les exigences détaillées dans la présente PC et la DPC associée, sont satisfaites en ce qui concerne l'émission et la gestion de certificats porteurs. L'AC est responsable du maintien de la conformité aux procédures prescrites dans la présente PC. L'AC fournit tous les services de certification en accord avec sa DPC. Les obligations communes aux composantes de l'AC sont :

- Respecter et applique la PC et la DPC de l’ACR de l’ICP qui lui a délivré son certificat d’AC ; - Assurer par le certificat le lien entre l'identité d'un Porteur et sa clé publique ; - Protéger les clés privées et leurs données d'activation en intégrité et confidentialité ; - N'utiliser ses clés cryptographiques et certificats qu'aux seules fins pour lesquelles ils ont été générés et

avec les moyens appropriés, comme spécifié dans la DPC ; - Respecter et appliquer les dispositions de la partie de la DPC qui les concerne (cette partie de la DPC doit

être transmise à la composante concernée) afin de maintenir la conformité entre la PC et la DPC ; - Accepter que l'équipe de contrôle effectue les audits et lui communiquer toutes les informations utiles,

conformément aux intentions du CAP de contrôler et vérifier la conformité avec la PC ; - Documenter ses procédures internes de fonctionnement afin de compléter la DPC générale ; - Mettre en œuvre les moyens techniques et employer les ressources humaines nécessaires à la mise en

place et la réalisation des prestations auxquelles elle s'engage dans la PC/DPC ; - Prendre toutes les mesures raisonnables pour s’assurer que ses porteurs sont au courant de leurs droits et

obligations en ce qui concerne l’utilisation et la gestion des clés, des certificats ou encore de l’équipement et des logiciels utilisés aux fins de l’IGC ;

- Tenir à disposition des Porteurs et des applications la notification de révocation du certificat d'une composante de l'ICP ou d'un Porteur ;

- Protéger les données de déblocage des supports matériels des porteurs et mettre en place une procédure sécurisée pour le déblocage des supports matériels.

L’AC est responsable de la conformité de sa PC aux normes des certificats X509v3 et ETSI TS 102042.,. L’AC assume toute conséquence dommageable résultant du non-respect de sa PC et aux normes ci-dessus référencées.. Elle prend les dispositions nécessaires pour couvrir ses responsabilités liées à ses opérations et/ou activités et posséder la stabilité financière et les ressources exigées pour fonctionner en conformité avec la PC. De plus, l'AC reconnaît engager sa responsabilité en cas de faute ou de négligence, d'elle-même ou de l’une de ses composantes, quelle qu’en soit la nature et la gravité, qui aurait pour conséquence la lecture, l’altération ou le détournement des données personnelles des porteurs à des fins frauduleuses, que ces données soient contenues ou en transit dans les applications de gestion des certificats de l'AC. Par ailleurs, l’AC reconnaît avoir à sa charge un devoir général de surveillance, quant à la sécurité et l’intégrité des certificats délivrés par elle-même ou l’une de ses composantes. Elle est responsable du maintien du niveau de sécurité de l’infrastructure technique sur laquelle elle s’appuie pour fournir ses services. Toute modification ayant un impact sur le niveau de sécurité fourni doit être approuvée. 9.6.4 Obligations de l’AE Les obligations de l'AE sont les suivantes :

____________________________________________________________________________________________________________________________




- L'authentification de la demande de certificat ; - L'authentification de la demande de révocation ; - Accepter que l'équipe de contrôle effectue les audits et lui communiquer toutes les informations utiles,

conformément aux intentions du CAP de contrôler et vérifier la conformité avec la PC ; - Protéger les données d’activations des porteurs.

9.6.5 Obligation et garanties de l’AED Le contrôle effectif de la véracité des informations communiquées par les demandeurs (porteur ou MC) de certificats est réalisé par différentes AED. Les obligations de l'AED sont les suivantes :

- Authentifier les porteurs et les MC en fonction du choix du Client ; - Authentifier les MC ; - Etablir et contrôler les contrats de souscription signé par le Client ; - Garantir que la personne identifiée dans les dossiers d’ajout de MC transmis a prouvé son identité et

vérifier l’authenticité des pièces justificatives et l’exactitude des mentions qui établissent l’identité du MC et du Client ;

- Protéger la confidentialité et l’intégrité des dossiers clients transmises ; - Protéger les contrats de souscriptions ; - Transmettre les contrats de souscription et les dossiers Clients à l’AE ; - Recevoir les demandes formelles de certificat, en vérifier l’origine et l’exactitude, et les transmettre pour

traitement à la l'AE ; - Recevoir des demandes formelles de révocation, en vérifier l’origine et l’exactitude, et les transmettre pour

traitement à la l'AE ; - Maintenir les procédures de Contrôle Interne adéquates, afin de garantir la fiabilité des opérations dont

elles ont la charge ; - S'assurer que ses Clients connaissent leurs droits et obligations en ce qui concerne l'utilisation et la

gestion des clés et des certificats ; - Etablir l'identité du Client ; - Etablir l'identité des MC ; - Etablir l’identité des porteurs ; - Protéger les données d’activations des porteurs.

9.6.6 Mandataire de certification (MC) Les obligations du MC sont les suivantes :

- Communiquer des informations justes lors de la demande de certificat ; - Respecter les obligations d’un porteur lorsqu’il détient un certificat porteur ; - Faire respecter les conditions d'utilisation de la clé privée et du certificat correspondant ; - Informer sans délai l'AED en cas de compromission d'une clé privée ; - Révoquer en cas de besoin un certificat porteur ; - Garantir qu’un Porteur (porteur) identifié dans un dossier Client transmis a été authentifié par lui et que son

identité a été vérifié ainsi que l’exactitude des mentions qui établissent l’identité du Porteur ; - Authentifier et établir l'identité des Porteurs pour lesquels il demande des certificats ; - S'assurer que le futur Porteur a pris connaissance des modalités applicables pour l'utilisation du certificat ; - Choisir judicieusement et transmettre de façon confidentielle au Porteur une partie des éléments de retrait

du certificat ; - Avertir l'AED de toute inexactitude ou défection d’un certificat dans les trois jours ouvrés consécutifs au

retrait dudit certificat, afin que celui-ci soit révoqué et qu’un autre certificat puisse être fourni ; - Transmettre à l'AED le récépissé de la déclaration faite auprès des autorités de police en cas de

soustraction, piratage, intrusion, sabotage et fabrication de faux. 9.6.7 Obligations et garanties du Porteur Les obligations du porteur sont :

____________________________________________________________________________________________________________________________




- Protéger en confidentialité et intégrité les informations confidentielles qu’il détient (clé privée, donnée

d’activation et données d’authentification) ; - Transmettre la clé publique, correspondante à la clé privée, à l’AED ; - Se conformer à toutes les exigences de la PC et de la DPC associée ; - D’utiliser son certificat et la clé privée correspondante conformément à la liste des applications autorisées ; - Garantir que les informations qu'il fournit à l'AED et au MC sont complètes et correctes ; - Prendre toutes les mesures raisonnables pour éviter l'utilisation non autorisée de sa clé privée et en

protéger la confidentialité ; - Informer sans délai l'AED et le MC en cas de causes de révocation avérée ; - Révoquer sans délai son certificat en cas de causes de révocation avérée.

9.6.8 Obligations et garanties du SP Les obligations du SP sont :

- De publier les LCR ; - De publier les certificats d’AC ; - De publier la PC et les CGU associées ; - De garantir une publication H24 et 7J avec les taux de disponibilités prévues pour les informations

publiées ; - De protéger les accès au SP ; - De contrôler que les informations sont à jour et fiables ; - De protéger en intégrité les données.

9.6.9 Obligations et garanties des autres participa nts

9.6.9.1 Client Les obligations du Client sont les suivantes :

- Désigner, sous sa responsabilité, ses MC et les Porteurs auxquelles sera délivré un certificat ; - Effectuer par écrit le contrat de souscription au service de certification ; - Garantir l’authenticité, le caractère complet et à jour des informations communiquées lors de la demande

de certificat ainsi que des documents qui accompagnent ces informations ; - Notifier au Porteur les restrictions d'usage du certificat décrit dans les Conditions Générales d’Utilisation ; - Informer sans délai l'AED de toute modification relative à ces informations et/ou documents ; - Assurer l’information des Porteurs sur les conditions d’utilisation des certificats, de la gestion des clés ou

encore de l’équipement et des logiciels permettant de les utiliser ; - Faire assurer l’acceptation du certificat par chaque Porteur ainsi que les vérifications préalables à cette

acceptation ; - Faire protéger la clé privée de chaque Porteur par des moyens appropriés à son environnement ; - Faire protéger les Données d'Activation de chaque Porteur par des moyens appropriés à son

environnement ; - Faire respecter les conditions d'utilisation de la clé privée et du certificat correspondant par chaque

Porteur, notamment l’utilisation dans le strict cadre des applications autorisées ; - Faire demander la révocation d’un certificat dès lors qu’elle est nécessaire ; - Faire informer sans délai l'AED en cas de suspicion de compromission ou de compromission de la clé

privée d’un de ses Porteurs ; - Répond au premier chef envers la Banque des obligations à la charge de ses préposés, Porteurs et MC.

9.6.9.2 Obligations et garanties de l’UC Les obligations de l’UC sont :

- De valider un certificat porteur à l’aide des informations rendues disponibles par le SP ;

____________________________________________________________________________________________________________________________




- Respecter l'usage pour lequel un certificat a été émis lorsque cet usage a été déclaré critique ; - Vérifier la signature numérique de l'AC émettrice du certificat ; - Contrôler la validité des certificats (dates de validité et statut de révocation).

9.7 Limite de garantie L'AC garantit au travers de ses services d’IGC :

- L'identification et l'authentification de l'AC avec son certificat auto signé ; - L'identification et l'authentification des porteurs avec les certificats générés par l'AC ; - La gestion des certificats correspondants et des informations de validité des certificats selon la présente

PC. Ces garanties sont exclusives de toute autre garantie de l'AC. Il est expressément entendu que le CREDIT AGRICOLE CARDS AND PAYMENTS ne saurait être tenu pour responsable ni d’un dommage résultant d’une faute ou négligence d’un Client et/ou de son(ses) Mandataire(s) de Certification habilité(s) et/ou de ses Porteurs ni d’un dommage causé par un fait extérieur ou un cas de force majeur, notamment en cas de :

- Utilisation d’un certificat pour une autre application que les Applications autorisées ; - Utilisation d’un certificat pour garantir un autre objet que l’identité du Porteur ; - Utilisation d’un certificat révoqué ; - Mauvais modes de conservation de la clé privée du certificat du Porteur ; - Utilisation d’un certificat au-delà de sa limite de validité ; - Non respect des obligations des autres Intervenants (se reporter au § 9.6.9) ; - Faits extérieurs à l’émission du certificat tel qu’une défaillance de l’application pour laquelle il peut être

utilisé ; - Cas de force majeur tels que définis par les tribunaux français.

9.8 Limites de responsabilité L’AC est responsable des exigences et des principes édictés dans la présente PC, ainsi que de tout dommage causé à un porteur ou une application / utilisateur de certificat en suite par un manquement aux procédures définies dans la PC et la DPC associée. L'AC décline toute responsabilité à l'égard de l'usage des certificats émis par elle ou des bi-clés publiques/privées associées dans des conditions et à des fins autres que celles prévues dans la PC ainsi que dans tout autre document contractuel applicable associé. L’AC décline toute responsabilité quant aux conséquences des retards ou pertes que pourraient subir dans leur transmission tous messages électroniques, lettres, documents, et quant aux retards, à l’altération ou autres erreurs pouvant se produire dans la transmission de toute télécommunication. L’AC ne saurait être tenue responsable, et n’assume aucun engagement, pour tout retard dans l’exécution d’obligations ou pour toute inexécution d’obligations résultant de la présente politique lorsque les circonstances y donnant lieu et qui pourraient résulter de l’interruption totale ou partielle de son activité, ou de sa désorganisation, relèvent de la force majeure au sens de l’Article 1148 du Code civil. De façon expresse, sont considérés comme cas de force majeure ou cas fortuit, outre ceux habituellement retenus par la jurisprudence des cours et tribunaux français, les conflits sociaux, la défaillance du réseau ou des installations ou réseaux de télécommunications externes.

____________________________________________________________________________________________________________________________




L’AC n’est en aucun cas responsable des préjudices indirects subis par les entités utilisatrices, ceux-ci n’étant pas préqualifiés par les présentes. En cas de prononcé d’une quelconque responsabilité de l’AC, les dommages, intérêts et indemnités à sa charge toutes causes confondues, et quel que soit le fondement de sa responsabilité, sont limités par certificat à la somme prévue au titre de limite de responsabilité dans les conditions générales d’utilisation applicable audit certificat.

9.9 Indemnités Les parties conviennent qu’en cas de prononcé d’une quelconque responsabilité de l’AC vis-à-vis d’un tiers utilisateur, les dommages, intérêts et indemnités à sa charge seront déterminés lors de la procédure prévue à l’article 9.3 des présentes.

9.10 Durée et fin anticipée de validité de la PC 9.10.1 Durée

La PC devient effective une fois approuvée par le CAP. La PC reste en application au moins jusqu'à la fin de vie du dernier certificat émis au titre de cette PC.

9.10.2 Résiliation Selon l'importance des modifications apportées à la PC, le CAP décidera soit de faire procéder à un audit de la PC/DPC des AC concernées, soit de donner instruction à l'AC de prendre les mesures nécessaires pour se rendre conforme dans un délai fixé.

9.10.3 Effets de la résiliation et survie La fin de validité de la PC entraîne la cessation de toutes les obligations et responsabilités de l'AC pour les certificats émis conformément à la PC.

9.11 Amendements 9.11.1 Procédure pour apporter un amendement

Le CAP révise sa PC et sa DPC lors de changements tels que décrits dans le paragraphe 1.3.1 décrivant les obligation du CAP. D'autres révisions peuvent être décidées à tout moment à la discrétion du CAP. Les corrections de fautes d'orthographe ou de frappe qui ne modifient pas le sens de la PC sont autorisées sans avoir à être notifiées.

9.11.2 Mécanisme et délais des notifications Le CAP donne un préavis d’1 mois au moins aux composantes de l'IGC de son intention de modifier sa PC/DPC avant de procéder aux changements et en fonction de l'objet de la modification. Ce délai ne vaut que pour des modifications qui porteraient sur le fond (changement de taille de clé, changement de procédure, changement de profil de certificat, …) et non sur la forme de la PC et de la DPC. En cas de projet de modification des spécifications, les cas suivants sont envisageables pour l'ACR :

- Des changements typographiques ne donnant pas lieu à notification et à modification de l'OID de la PC/DPC ou de l'URL ;

- Des changements sur le niveau de qualité et de sécurité des fonctions de l'ACR vis-à-vis des certificats d’AC, sans pour autant perdre la conformité de ces derniers avec la PC, et moyennant une période de notification d’un mois avant le début des changements et ne donnant pas lieu à modification de l'OID de la PC/DPC ou de l'URL ;

- Des changements entraînant la perte de la conformité des certificats porteurs avec la PC et impliquant la modification de l'OID de la PC/DPC et de l'URL de téléchargement.

Les modifications définitives sont soumises aux responsables des applications utilisatrices autorisées avant d'être publiées.

____________________________________________________________________________________________________________________________




Les modifications sont publiées le jour où l'on en donne notification. Par ailleurs, l’AC avertit les AED qui reportent par tous moyenà leurs convenance les informations vers leurs Clients des modifications.

9.11.3 Motifs selon lesquels un OID doit être chang é Si l’AAK estime qu'une modification de la PC modifie le niveau de confiance assuré par les exigences de la PC ou par le contenu de la DPC, elle peut instituer une nouvelle politique avec un nouvel identifiant d'objet (OID).

9.12 Règlement des différends En cas de réclamation de la part du Client, les parties suivront la procédure de réclamations clients prévue dans les conditions générales de souscription signées par le Client. A défaut de résolution du problème rencontré par le Client et de règlement amiable, le litige sera porté devant les juridictions désignées par les conditions générales de souscription..

9.13 Droit applicable Les dispositions de la politique de certification sont régies par le droit français. En cas de litige relatif à l’interprétation, la formation ou l’exécution de la présente politique, et faute d’être parvenues à un accord amiable ou à une transaction, les parties donnent compétence expresse et exclusive aux tribunaux compétents de Paris, nonobstant pluralité de défendeurs ou d’action en référé ou d’appel en garantie ou de mesure conservatoire.

9.14 Conformité au droit applicable La PC est sujette aux lois, règles, règlements, ordonnances, décrets et ordres nationaux, d'état, locaux et étrangers concernant les, mais non limités aux, restrictions à l'importation et à l'exportation de logiciels ou de matériels cryptographiques ou encore d'informations techniques. Les textes législatifs et réglementaires applicables à la PC sont, notamment, ceux indiqués au chapitre 10 ci-dessous.

9.15 Divers 9.15.1 Totalité de l'entente

Le cas échéant, la DPC précisera les exigences spécifiques.

9.15.2 Affectation Sauf si spécifié dans d'autres contrats, seul le cAP a le droit d'affecter et de déléguer la PC à une partie de son choix.

9.15.3 Divisibilité Le caractère inapplicable dans un contexte donné d’une disposition de la Politique de Certification n’affecte en rien la validité des autres dispositions, ni de cette disposition hors du dit contexte. La Politique de Certification continue à s’appliquer en l’absence de la disposition inapplicable et ce tout en respectant l’intention de ladite Politique de Certification. Les intitulés portés en tête de chaque Article ne servent qu’à la commodité de la lecture et ne peuvent en aucun cas être le prétexte d’une quelconque interprétation ou dénaturation des clauses sur lesquelles ils portent.

9.15.4 Exonération des droits

____________________________________________________________________________________________________________________________




Les exigences définies dans la PC/DPC doivent être appliquées selon les dispositions de la PC et de la DPC associée sans qu'aucune exonération des droits, dans l'intention de modifier tout droit ou obligation prescrit, soit possible.

9.15.5 Force majeure L'AC ne saurait être tenue pour responsable de tout dommage indirect et interruption de ses services relevant de la force majeure, laquelle aurait causé des dommages directs aux porteurs.

9.16 Autres dispositions Le cas échéant, la DPC en fournira les détails.

10 REFERENCES Les documents référencés sont les suivants :

- [CNIL] 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 ;

- [DIRSIG] Directive 1999/93/CE du Parlement européen et du Conseil, du 13 décembre 1999, sur un cadre

communautaire pour les signatures électroniques ;

- [ORDONNANCE] Ordonnance n° 2005-1516 du 8 décembre 2005 relative aux échanges électronique entre les usagers et les autorités administratives et entre les autorités administratives ;

CE Page No: 65 /124

CERTIFICATE POLICY OF THE CA:

CA LCL RGS certificate Separated Use

Ref :PC_ Sign_Auth_National_CA_RGS.v1.0

____________________________________________________________________________________________________________________________

PC_Sign_Auth_National_CA_RGS v1.1.doc of 124

CA&CP. This document is the property of Crédit Agricole Cards and Payments. It is in the public domain.

Its reproduction is governed by the Intellectual Property Code which only authorizes the private use of the person making the copy.


CA LCL RGS CERTIFICATE (FRENCH GENERAL SECURITY GUIDELINES)

SEPARETED USE

Crédit Agricole Cards and Payments

Date: 29/11/2013

CE Page No: 66 /124


CA LCL RGS certificate Separated Use Ref : PC_ Sign_Auth_National_CA_RGS. V0.01

.


CA&CP. This document is the property of Credit Agricole Cards and Payments. It is in the public domain.


CERTIFICATE POLICY: CA Purpose: This document comprises the certificate policy of the CA

Version number: 1.1 Number of pages: 124 Document Status: Project Final version Drafted by: OPENTRUST OPENTRUST Distribution: External Internal OPENTRUST Public OPENTRUST

PAC: Date Version Drafted by Comments Checked by 14/11/2013 0.1 EP Document creation 25/11/2013 0.1 EP Proofreading GW / EM OPENTRUST 28/11/2013 0.1 EP PAC Proofreading LCL/CA-CP 29/11/2013 1.0 EP Validation PAC Members 01/12/2015 1.1 EP Annual revision / minors changes CA-CP 24/02/2016 1.1 EP Validation PAC Members




CONTENTS

1 INTRODUCTION ______________________________________________________________________ 71 1.1 Overview .......................................... .......................................................................................................... 71 1.2 Document Name and Identification .................. ...................................................................................... 72 1.3 The Public Key Infrastructure Components .......... ................................................................................ 72

1.3.1 Policy Approval Committee (PAC) ....................................................................................................... 73 1.3.2 Certification Authority (CA) .................................................................................................................. 73 1.3.3 Certificate Authority and Test Certificates: .......................................................................................... 73 1.3.4 Registration Authority (RA) .................................................................................................................. 74 1.3.5 Decentralized Registration Authority (DRA) ........................................................................................ 74 1.3.6 Publication Service (PS) ...................................................................................................................... 74 1.3.7 Certification Operator (CO) .................................................................................................................. 74 1.3.8 End User .............................................................................................................................................. 75 1.3.9 Other participants ................................................................................................................................. 75

1.3.9.1 Customer ....................................................................................................................................... 75 1.3.9.2 Certification Representative (CR) .................................................................................................. 75 1.3.9.3 Certificate User (CU) ..................................................................................................................... 75

1.4 Certificate usage ................................. ...................................................................................................... 76 1.4.1 Appropriate certificate uses ................................................................................................................. 76

1.4.1.1 CA certificate ................................................................................................................................. 76 1.4.1.2End User Certificate .............................................................................................................................. 76

1.4.2 Prohibited Certificate Use .................................................................................................................... 76 1.5 Policy Application ................................ .................................................................................................... 76

1.5.1 Organization managing this policy ....................................................................................................... 76 1.5.2 Contact Person .................................................................................................................................... 76 1.5.3 Person Determining the Implementation Compliance for this CP / CPS ............................................. 76 1.5.4 Approval Procedure for this Document ................................................................................................ 77

1.6 Definitions and Acronyms .......................... ............................................................................................. 77 1.6.1 Definitions ............................................................................................................................................ 77 1.6.2 Acronyms ............................................................................................................................................. 80

2 DIRECTORIES AND PUBLICATION SERVICES ______________ _______________________________ 82 2.1 Publication Service ............................... ................................................................................................... 82 2.2 Published information.............................. ................................................................................................ 82 2.3 Time and Frequency of Publication ................. ....................................................................................... 82 2.4 Publishing Service Access Control ................. ....................................................................................... 82

3 IDENTIFICATION AND AUTHENTICATION _________________ ________________________________ 82 3.1 Naming ............................................ .......................................................................................................... 82

3.1.1 Types of Names ................................................................................................................................... 82 3.1.2 Using explicit names ............................................................................................................................ 84 3.1.3 Anonymity or using pseudonyms ......................................................................................................... 84 3.1.4 Rules for Interpreting Various Name Forms ........................................................................................ 84 3.1.5 Uniqueness of Names .......................................................................................................................... 84 3.1.6 Recognition, Verification, and role of Trademarks ............................................................................... 84

3.2 Initial Identity Validation ....................... ................................................................................................... 84 3.2.1 Proof of Possession of the Private Key ............................................................................................... 84 3.2.2 Checking an Organisation's Identity .................................................................................................... 84 3.2.3 Checking the identity of natural persons .............................................................................................. 85




3.2.3.1 End User ........................................................................................................................................ 85 3.2.3.2 DRA and CR .................................................................................................................................. 85

3.2.4 Non-verified information ....................................................................................................................... 85 3.2.5 Validation of the authority of an End User ........................................................................................... 85 3.2.6 Criteria for recognition .......................................................................................................................... 85

3.3 Identification and Authentication for Key renewal R equests ........................................... ................... 85 3.3.1 Identification and Authentication for Routine Re-keying ...................................................................... 85 3.3.2 Identification and Authentication for Re-keying After Revoking a Certificate ...................................... 85

3.4 Identification and Authentication for a Revocation Request ........................................... .................... 85

4 OPERATIONAL REQUIREMENTS __________________________ ______________________________ 86 4.1 Types of certificate .............................. ..................................................................................................... 86

4.1.1 Origin of the certificate request ............................................................................................................ 86 4.1.2 Registration process and responsibilities ............................................................................................ 86

4.2 Certificate Application Processing ................ ......................................................................................... 87 4.2.1 Identification and authentication .......................................................................................................... 87 4.2.2 Approval or Rejection of Certificate Applications ................................................................................. 87 4.2.3 Processing Time for Certificate Applications ....................................................................................... 87

4.3 Certificate Issuance .............................. .................................................................................................... 87 4.3.1 CA Actions during Certificate Issuance ............................................................................................... 87

4.3.1.1 End User Certificate ...................................................................................................................... 87 4.3.2 Notification of the issuance of a certificate .......................................................................................... 88

4.4 Certificate Acceptance ............................ ................................................................................................. 88 4.4.1 Certificate Acceptance Procedure ....................................................................................................... 88 4.4.2 Publication of a certificate by the CA ................................................................................................... 88 4.4.3 Notification of Certificate Issuance by the CA to Other Entities ........................................................... 88

4.5 Key Pair and Certificate Usage .................... ........................................................................................... 88 4.5.1 Key Pair and Certificate Usage ............................................................................................................ 88 4.5.2 Public Key and certificate usage by third parties ................................................................................. 88

4.6 Requesting a New Certificate ...................... ............................................................................................ 88 4.7 Changing keys (or a new public key certificate) ... ................................................................................ 88 4.8 Amending a Certificate ............................ ................................................................................................ 89 4.9 Revoking a Certificate ............................ .................................................................................................. 89

4.9.1 Reasons for revoking a certificate ....................................................................................................... 89 4.9.1.1 PKI Component certificate ............................................................................................................. 89 4.9.1.2 End User Certificate ...................................................................................................................... 89

4.9.2 The Origin of a Revocation Request .................................................................................................... 89 4.9.2.1 PKI Component ............................................................................................................................. 89 4.9.2.2 End User Certificate ...................................................................................................................... 90

4.9.3 Procedure for revocation request ........................................................................................................ 90 4.9.3.1 PKI Component ............................................................................................................................. 90 4.9.3.2 End User ........................................................................................................................................ 90

4.9.4 Time allowed for the End User to make a revocation application ........................................................ 91 4.9.5 Processing time for a revocation ......................................................................................................... 91 4.9.6 Revocation checking requirements for third parties............................................................................. 91 4.9.7 CRL Publication Frequency ................................................................................................................. 91 4.9.8 Maximum period of publication of a CRL ............................................................................................. 91 4.9.9 Availability of an online verification system for revocation and certificate status ................................ 91 4.9.10 Online Verification Requirements for revoking certificates by the certificate users ............................. 91 4.9.11 Other means of information available on revocations ......................................................................... 91 4.9.12 Specific requirements for End User certificates if a private key is compromised. The entities

authorized to request a revocation are required to do so as soon as possible after becoming aware of the compromised private key. .............................................................................................................. 91

4.10 Certificate Status Service ........................ ................................................................................................ 91




4.10.1 Operational characteristics .................................................................................................................. 91 4.10.2 Service Availability ............................................................................................................................... 92

4.11 End of relationship between the End User and the CA ........................................................................ 92 4.12 Escrow and key recovery ........................... ............................................................................................. 92

5 PHYSICAL SECURITY MEASURES, PROCEDURES AND IMPLEMEN TATION ____________________ 93 5.1 Physical security ................................. ..................................................................................................... 93

5.1.1 Geographic location ............................................................................................................................. 93 5.1.2 Physical access ................................................................................................................................... 93 5.1.3 Energy and air conditioning ................................................................................................................. 93 5.1.4 Exposure to liquids ............................................................................................................................... 93 5.1.5 Fire prevention and protection ............................................................................................................. 93 5.1.6 Storing media devices .......................................................................................................................... 93 5.1.7 Decommissioning media devices......................................................................................................... 93 5.1.8 Offsite backups .................................................................................................................................... 93

5.2 Procedural security measures ...................... .......................................................................................... 94 5.2.1 Trust-based Roles ................................................................................................................................ 94 5.2.2 Number of people required to perform sensitive tasks ........................................................................ 94 5.2.3 Identification and authentication of roles ............................................................................................. 94 5.2.4 Roles requiring separation of allocation ............................................................................................... 94

5.3 Staff Security Measures ........................... ................................................................................................ 94 5.3.1 Required qualifications, skills and authorizations ................................................................................ 94 5.3.2 Background check procedures ............................................................................................................ 94 5.3.3 Initial training requirements .................................................................................................................. 95 5.3.4 The requirements and frequency of continuous training ..................................................................... 95 5.3.5 Skills Management ............................................................................................................................... 95 5.3.6 Penalties for unauthorized actions ....................................................................................................... 95 5.3.7 Requirements of staff employed by external service providers ........................................................... 95 5.3.8 Documentation provided to staff .......................................................................................................... 95

5.4 Procedures for the establishment of audit data .... ................................................................................ 95 5.4.1 Type of events to be recorded ............................................................................................................. 95 5.4.2 Logging process ................................................................................................................................... 96 5.4.3 Protecting event logs ........................................................................................................................... 96 5.4.4 Event log back-up procedures ............................................................................................................. 96 5.4.5 Event log collection system .................................................................................................................. 96 5.4.6 Vulnerability Assessment ..................................................................................................................... 96

5.5 Archiving data .................................... ....................................................................................................... 97 5.5.1 Type of archived data .......................................................................................................................... 97 5.5.2 Archive conservation period ................................................................................................................. 97 5.5.3 Archive protection ................................................................................................................................ 97 5.5.4 Data time stamping requirements ........................................................................................................ 97 5.5.5 Archive Collection System ................................................................................................................... 97 5.5.6 Archive retrieval and verification procedures ....................................................................................... 97

5.6 Renewal of key pair ............................... ................................................................................................... 97 5.6.1 CA certificate ........................................................................................................................................ 97 5.6.2 End User Certificate ............................................................................................................................. 98

5.7 Recovery following compromise or disaster ......... ............................................................................... 98 5.7.1 Incident and Compromise Procedures ................................................................................................ 98 5.7.2 Corruption of IT resources, hardware, software and / or data ............................................................. 99 5.7.3 Procedures if the private key of an entity is compromised .................................................................. 99 5.7.4 Capabilities of resuming business following a disaster ....................................................................... 99

5.8 CA Expiry ......................................... ......................................................................................................... 99 5.8.1 Transfer or cessation of an activity affecting a PKI component ........................................................... 99

5.8.1.1 CA .................................................................................................................................................. 99




5.8.1.2 Compliance Loss ......................................................................................................................... 100 5.8.1.3 DRA ............................................................................................................................................. 100

5.8.2 Cessation of activity affecting the CA ................................................................................................ 100

6 TECHNICAL SECURITY MEASURES _______________________ _____________________________ 102 6.1 Generation and Installation of Key Pairs .......... ................................................................................... 102

6.1.1 Generation of key pairs ...................................................................................................................... 102 6.1.1.1 CA Key Pairs ............................................................................................................................... 102 6.1.1.2 End User Key Pairs ..................................................................................................................... 102

6.1.2 Provision of the private key to the End User ...................................................................................... 102 6.1.3 Provision of the public key to the CA ................................................................................................. 102 6.1.4 Provision of the CA's public key to third parties ................................................................................. 102 6.1.5 Key size .............................................................................................................................................. 102 6.1.6 Production of Public Key Parameters and Quality Control ................................................................ 103 6.1.7 Key Usage (according to the X 509 V3 Certificate "key usage") ....................................................... 103

6.2 Private Key Protection and Standards relating to Cr yptographic Modules ............................... ...... 103 6.2.1 Standards and security measures for cryptographic modules ........................................................... 103 6.2.2 Control of the private key by several persons .................................................................................... 103 6.2.3 Private key escrow ............................................................................................................................. 103 6.2.4 Back-up copy of the private key ......................................................................................................... 103

6.2.4.1 CA ................................................................................................................................................ 103 6.2.4.2 End User ...................................................................................................................................... 103

6.2.5 Private key archiving .......................................................................................................................... 103 6.2.6 Importing / exporting a private key ..................................................................................................... 104 6.2.7 Storing a private key in a cryptographic module ................................................................................ 104

6.2.7.1 CA ................................................................................................................................................ 104 6.2.7.2 End User ...................................................................................................................................... 104

6.2.8 Method for activating a private key .................................................................................................... 104 6.2.8.1 CA ................................................................................................................................................ 104 6.2.8.2 End User ...................................................................................................................................... 104

6.2.9 Method of deactivating a private key ................................................................................................. 104 6.2.9.1 CA ................................................................................................................................................ 104 6.2.9.2 End User ...................................................................................................................................... 104

6.2.10 Private key destruction method.......................................................................................................... 104 6.2.10.1 CA ................................................................................................................................................ 104 6.2.10.2 End User ...................................................................................................................................... 105

6.2.11 Certification of cryptographic resources ............................................................................................ 105 6.3 Other Aspects of Key Pair Management .............. ................................................................................ 105

6.3.1 Public key archiving ........................................................................................................................... 105 6.3.2 Operational Validity of Certificates and Life of Key Pairs .................................................................. 105

6.3.2.1 CA ................................................................................................................................................ 105 6.3.2.2 End User ...................................................................................................................................... 105

6.4 Activation data ................................... ..................................................................................................... 105 6.4.1 Generation and installation of activation data .................................................................................... 105

6.4.1.1 CA ................................................................................................................................................ 105 6.4.1.2 End User ...................................................................................................................................... 105

6.4.2 Protection of activation data ............................................................................................................... 105 6.4.2.1 CA ................................................................................................................................................ 105 6.4.2.2 End User ...................................................................................................................................... 105

6.4.3 Other aspects affecting activation data .............................................................................................. 105 6.4.3.1 CA ................................................................................................................................................ 106 6.4.3.2 End User ...................................................................................................................................... 106

6.5 IT System Security Measures ....................... ......................................................................................... 106 6.5.1 Technical security requirements for IT resources .............................................................................. 106




6.5.2 IT Security Rating .............................................................................................................................. 106 6.6 Technical controls of the system during its life cy cle ............................................... ......................... 106

6.6.1 System developments control ............................................................................................................ 106 6.6.2 Controls for Security Management .................................................................................................... 106 6.6.3 Inspecting the security system during its life cycle ............................................................................ 107

6.7 Network security mechanisms ....................... ....................................................................................... 107 6.8 Timestamp / system dating ......................... .......................................................................................... 107

7 CERTIFICATES, CRL AND OCSP PROFILES _______________ _______________________________ 108 7.1 Certificate Profiles .............................. .................................................................................................... 108

7.1.1 Certificate Extensions ........................................................................................................................ 108 7.1.1.1 CA Certificate .............................................................................................................................. 108 7.1.1.2 End User Certificate .................................................................................................................... 109

7.1.2 Algorithm Identifiers ........................................................................................................................... 111 7.1.3 Name Forms ...................................................................................................................................... 111 7.1.4 Object identifier (OID) of the Certification Policy ............................................................................... 111 7.1.5 Policy Extensions ............................................................................................................................... 111 7.1.6 Policy Qualifier Syntax and Semantics .............................................................................................. 111 7.1.7 Semantic interpretation of the critical extension "Certificate Policies" ............................................... 112

7.2 CRL profile ....................................... ....................................................................................................... 113 7.2.1 CRL and CRL extension fields ........................................................................................................... 113 7.2.2 CRL and TEST CRL extension fields ......................................................... Erreur ! Signet non défini.

7.3 OCSP Profile ...................................... ..................................................................................................... 113

8 COMPLIANCE CONTROLS AND OTHER ASSESSMENTS _________ __________________________ 114 8.1 Frequency and reasons for audits .................. ...................................................................................... 114 8.2 Identity / Qualifications of Auditors ............. ......................................................................................... 114 8.3 Connection between the auditor and the assessed ent ity ............................................... .................. 114 8.4 Points covered by the assessment .................. .................................................................................... 114 8.5 Actions taken in the event of non-compliance ...... .............................................................................. 114 8.6 Communication of results .......................... ........................................................................................... 114

9 OTHER COMMERCIAL AND LEGAL PROVISIONS _____________ ____________________________ 115 9.1 Rates ............................................. ........................................................................................................... 115

9.1.1 Rates for the issuance and renewal of certificates ............................................................................ 115 9.1.2 Rates for access to certificates .......................................................................................................... 115 9.1.3 Rates for access to CRLs and certificate status information ............................................................. 115 9.1.4 Rates for other services ..................................................................................................................... 115 9.1.5 Refund Policy ..................................................................................................................................... 115

9.2 Financial responsibility........................... ............................................................................................... 115 9.2.1 Insurance coverage ........................................................................................................................... 115 9.2.2 Other Resources ................................................................................................................................ 115 9.2.3 Cover and warranty for user entities .................................................................................................. 115

9.3 Confidentiality of information and business data .. ............................................................................. 115 9.3.1 Scope of confidential information ....................................................................................................... 115 9.3.2 Information outside the scope of confidential information ................................................................. 116 9.3.3 Obligations in terms of protection of confidential information ............................................................ 116

9.4 Protection of personal data.................... ...................................................................................................... 116 9.4.1 Personal Data Protection Policy ........................................................................................................ 116 9.4.2 Personal information .......................................................................................................................... 116 9.4.3 Non-personal information ................................................................................................................... 116 9.4.4 Obligations in terms of personal data protection ............................................................................... 116 9.4.5 Prior express consent for using personal data .................................................................................. 116 9.4.6 Obligations in terms of personal data protection ............................................................................... 116




9.4.7 Rights of the person concerned: ........................................................................................................ 117 9.5 Intellectual property rights ...................... .............................................................................................. 117 9.6 Obligations and guarantees ........................ .......................................................................................... 117

9.6.1 Common obligations .......................................................................................................................... 117 9.6.2 PAC obligations and guarantees ....................................................................................................... 117 9.6.3 CA Obligations and Guarantees ........................................................................................................ 118 9.6.4 The RA's Obligations ......................................................................................................................... 118 9.6.5 The DRA's Obligation and Guarantees .............................................................................................. 119 9.6.6 Certification Representative (CR) ...................................................................................................... 119 9.6.7 The End User's obligations and guarantees ...................................................................................... 119 9.6.8 The PS's obligations and guarantees ................................................................................................ 120 9.6.9 Obligations and guarantees of other participants .............................................................................. 120

9.6.9.1 Customer ..................................................................................................................................... 120 9.6.9.2 CU's obligations and guarantees ................................................................................................ 120

9.7 Limitation of Guarantee ........................... .............................................................................................. 121 9.8 Limits of Liability ............................... ..................................................................................................... 121 9.9 Compensation ...................................... ................................................................................................... 122 9.10 Duration and termination before the due validity da te of the CP ...................................... ................ 122

9.10.1 Duration .............................................................................................................................................. 122 9.10.2 Cancellation ....................................................................................................................................... 122 9.10.3 Effect of Termination and Survivorship .............................................................................................. 122

9.11 Amendments ........................................ ................................................................................................... 122 9.11.1 Procedure for providing an amendment ............................................................................................ 122 9.11.2 Mechanism and deadlines for notifications ........................................................................................ 122 9.11.3 Reasons that an OID should be changed .......................................................................................... 122

9.12 Settlement of Disputes............................. .............................................................................................. 123 9.13 Applicable Law .................................... ................................................................................................... 123 9.14 Compliance with applicable law .................... ....................................................................................... 123 9.15 Miscellaneous ..................................... .................................................................................................... 123

9.15.1 The Entire Agreement ........................................................................................................................ 123 9.15.2 Assignment ........................................................................................................................................ 123 9.15.3 Divisibility ........................................................................................................................................... 123 9.15.4 Waiver of Rights ................................................................................................................................. 123 9.15.5 Force majeure .................................................................................................................................... 123

9.16 Other provisions .................................. ................................................................................................... 123

10 REFERENCES _______________________________________________________________________ 124

1 INTRODUCTION

1.1 Overview The purpose of this Certificate Policy (CP) is to provide Customers and End Users of the Credit Agricole Group with the information about the guarantees given by the End User certificates that it issues, and the terms and conditions for using these certificates. This document describes the CP (Certification Policy) inherent to the Operational Certification Authority hereinafter referred to as an operational CA (denoted as CA) for the CREDIT AGRICOLE CARDS AND PAYMENTS Public Key Infrastructure administered by the SNC CREDIT AGRICOLE CARDS AND PAYMENTS.




This change of name and legal nature does not take change of the legal entity which keeps the same number of identification 723 001 467 RCS Paris, respects the same obligations and brings the same guarantees as Certification Authority. For these reasons so technical as functional and practical "OU" shown in the AC certificate containing the former company name will be kept, until the renewal of the AC. A CP is defined independently of the implementation modes for the Public Key Infrastructure (PKI) to which it applies. It describes the requirements that the PKI must comply with for registering and checking certificate applications, and for certificate management. The certification procedures are compiled in a document called the Certification Practice Statement (CPS) and is distinct from the CP, which describes how these requirements are achieved in practice. The certificate management covers all operations relating to the life of a certificate from its issuance until the end of life of the certificate (expired or revoked). In the rest of document, only the term CA will be used. The CA is a qualified CA as required under European ETSI TS 102 042 Standard, RFC 5280 standard, and is RGS (Référentiel Général de Sécurité) compliant for publics services and company ** in the scope of x509v3 certificate law relating to the electronic signature.

1.2 Document Name and Identification This CP named: "CA LCL certificate RGS Separated Use "is the property of CREDIT AGRICOLE CARDS AND PAYMENTS. This CP has a registered object identifier (OID) that is: 1.2.250.1.104.3.1.1.1.1.9.1.1 The corresponding CPS is identified by an object identifier number (OID) that is: 1.2.250.1.104.3.1.1.2.1.9.1.1 . More explicit items such as name, version number, date of update, identify this CP and the CPS. However, the only identifier for the applicable version of the CP and the CPS is the associated OID. The CP and CPS corresponding to the OIDs above are hereinafter referred to as "CP" and "CPS".

1.3 The Public Key Infrastructure Components To issue certificates, the CA is based on the following services:

- Registration Service: this service collects and checks the identification information of the End User requesting a certificate, before sending the certificate request to the certificate application service;

- Certificate Application Service: this service creates a certificate application, using information supplied by

the registration service, to create and send a certificate application to the certificate generation service;

- Certificate Generation Service: This service generates electronic certificates for End Users from the information provided by the certificate application service;

- Personalization Service and Key Pair Hardware Management: This service is for graphically personalizing

the cryptographic key pair(s) hardware based on data provided by the certificate generation service. This service is for entering an enabling code for the hardware;

- Download and Revocation Service for the End User: This service is for the End User to download the

certificate and to revoke it;

- Customer Service: This service implements the enabling service for the End User's hardware;




- Certificate Revocation Service: This service processes End Users certificate revocation applications and determines the actions to be taken and generating the Certificate Revocation List (CRL);

- Publication Service: This service makes the required information available to Certificate Users (CU) issued

by the CA (terms of use, certification policy issued by the CA, CA certificate, certificate End Users...) to the certificate users including information for checking certificates issued from the revocation management service (CRL, information notice, etc.);

- Audit and Log Service: This service is for collecting all the data used and or generated within the PKI

implementation services to obtain reference audit trails. This service is implemented by all the PKI technical components.

This CP defines the security requirements for all the services described above in the issuance of certificates by the CA to End Users. The Certification Practice Statement (CPS) will detail the practices of the PKI in the same way. The PKI components provide their services in accordance with this CP and the associated CPS.

1.3.1 Policy Approval Committee (PAC) A committee comprising CREDIT AGRICOLE CARDS AND PAYMENTS representatives, for creating, monitoring compliance and developing policies governing the PKI documentation. As an authority, the PAC must:

- Define and validate the PKI organization and authorize the creation of the CA and RCA; - Define and control this CP and the associated CPS; - Monitor the implementation of the CPS; - Validate the interoperability agreements with other PKIs; - Mediate disputes; - Proceed, where appropriate, with revocation applications for the Operational RCA and / or Operational CA.

1.3.2 Certification Authority (CA)

The Customer trusts this authority to issue and manage End User certificates and CRLs*. In order to eliminate any terminological ambiguity concerning the Certification Authority, the following conventions will be used in this document:

- The term Certification Authority is the legal authority issuing the certificates for a community;

- The term Operational Certification Authority (operational CA) corresponds to the organizational and technical entity that receives the certificate request, comprising the template for the certificate and signs it with its private key. When dealing with a CA certificate, this always refers to the operational CA.

- The term Certification Authority (CA) refers to these two concepts in an undifferentiated way. The CA drafts a CP and a CPS for administering End User certificates. The Operational CA has a CA certificate managed by an Operational RCA from CREDIT AGRICOLE CARDS AND PAYMENTS. The CA authenticates and recognizes several RAs as part of administering End User certificates.

1.3.3 Certificate Authority and Test Certificates: CREDIT AGRICOLE CARDS AND PAYMENTS uses test certificates to carry out tests. To do this, CREDIT AGRICOLE CARDS AND PAYMENTS uses the production CA to manage of test certificates. The CP and CPS give details for managing test certificates according to the CA selection. Where there is a difference, it is then specified in the CP and the CPS.




The test certificates can only be used for testing as part of an application clearly identified in the certificate application or testing protocol defined between the End User and the CA. The test certificates cannot under any circumstances be used as a production certificate for the End User and the application manager. However, the obligations of protection and use of the certificate for the End User and the CA are identical to those defined for the production certificates.

1.3.4 Registration Authority (RA) An entity that identifies and authenticates certificates, but does not sign nor issues certificates. The RA receives and processes applications for revoking certificates. The RA is used for registering certificate applications, sending to End Users, revoking certificates, logging and auditing. The RA is responsible for identifying and authenticating End Users. However, the RA delegates the registration of certificate applications and revocation to the DRAs. Likewise, a Customer can use a Certification Representative (CR). It is the RA that validates End Users certificate and revocation requests. The relationship between the FDAs and the CA is formalized by a service agreement binding the DRA to the CA specifying the rights and obligations of the parties. The relationship between the CRs and the DRAs is formalized by a contract binding the Customer to the DRA specifying the rights and obligations of the parties and the dispute resolution methods. The CP only specifies the management for the certificate End User by using the generic terms RA and DRA. The CPS will specify the various allocation of operations and procedures between the RA, the DRA and the CR for managing an End User certificate based on the entity that implemented the RA and DRA. In fact, each RA could have their own procedures to meet the requirements of the CP and the CPS. In all cases, the RA, the DRA and CR act in accordance with the CP and the associated CPS.

1.3.5 Decentralized Registration Authority (DRA) The Decentralized Registration Authorities (DRA) are the entities directly related to the Customers. They correspond to a decentralization of the registration function with the distributors responsible for marketing the offer. The role of the DRAs is to register applications for End User certificates and to check that the applicants and the certificate End Users are identified, that their identity is authentic and that the constraints binding on using a licence are complied with and in accordance with this CP. Based on the criteria in this CP, the DRAs also receive and check the certificate revocation requests and forward them to their particular RA for processing. Under no circumstances would the DRA have access to the means which would allow it to activate and use the private key associated with the public key contained in the certificate issued to the End User.

1.3.6 Publication Service (PS) The PS is used for implementing the publication service (See § 2). The PS acts in accordance with the CP and the associated CPS.

1.3.7 Certification Operator (CO) The Certification Services Operator provides, in particular, cryptographic technical services, required in the certification process, according to this CP and the associated CPS that implements the CA. The CO is technically the custodian of the RCA's private key used for signing End User certificates. Its liability is limited to compliance procedures that the CA defines to meet the requirements of this CP and its own procedures.




In addition, the CO conducts a risk analysis to determine the specific security objectives to cover all the PKI business risks and the corresponding non-technical and technical security measures to be implemented. The CO also has a continuity plan which is based on the CA for the PKI service continuity. This risk analysis and continuity plan covers the only perimeter of the CO as a resources host that enables the CA to implement its PKI services. In this CP, its role and obligations are not distinguished from those of the CA. This distinction will be specified in the CPS.

1.3.8 End User An End User is a natural person who uses the private key corresponding to the public key certified by the CA to digitally sign a document with signature software and to carry out access controls. The End User is a natural person who uses a certificate in the name of the Customer. The Customer can have one or more End Users. The End User can also be referred to under the name of the certificate End User. In the preliminary certification phase he is a certificate applicant and in the context of an X.509 certificate he is a subject.

1.3.9 Customer Service : The Credit Agricole Cards and Payments customers payment is reachable by phone and is dedicated to technical support, PUK code delivery and help to retrieval processes. This service is done in French language only.

1.3.10 Other participants

1.3.10.1 Customer Before applying for certificates and mostly using the certification services of the CA, the Customer must have previously established a subscription agreement with the certification service. The Customer takes out the subscription agreement with the DRA certificate service. The Customer may appoint one or more CRs to manage the End User's Certificates. The Customer is either a "Company" or an "Administration".

1.3.10.2 Certification Representative (CR) The CR is a natural person, duly identified, belonging to the company and delegated on behalf of the Customer to manage End User certificates, in particular to collect and validate the registration documents during a face-to-face meeting with the applicant (prospective End User). The CR's privileges allow it to request and / or revoke the End User certificates for the Customer's End Users. One and the same person can simultaneously be both End User and CR. A Customer can have one or more Certification Representatives. The Certification Representative must be able to check the identity documents presented by the End Users and to certify photocopies of these compliant documents.

1.3.10.3 Legal Representative : A physical person which could cumulate the Certification Representative role and must be one of the Legal Company’s Representatives.

1.3.10.4 Certificate User (CU) User application*, a natural or legal person, administrative organisation or computer system hardware that use an End User certificate, to validate the implemented security functions by using certificates (signature, encryption and authentication). As part of this CP, the CU must validate the End Users certificates by using the CA and RCA certificates and control the CRLs and LARs.




1.4 Certificate usage

1.4.1 Appropriate certificate uses

1.4.1.1 CA certificate The CA certificate is used to authenticate the End User certificates. The private key associated with the CA certificate is used for:

- Signing the End User's certificate; - Signing a CRL.

1.4.1.2End User Certificate The list of user applications in which digital certificates issued by the CA can be used is published on the RA's website: http://www.ca-certificat-plus.com. If there are any changes to the applications list that can be used by the certificates, the Customer will be informed by the DRA and in any written form for publishing the new list one month before its effective date. If the Customer refuses the proposed amendment, it will have the right to terminate the subscription agreement, without charge, during the month preceding the date of its effective date. If the subscription contract is not cancelled during the one month period, the Customer shall be deemed to have accepted the new CP.

1.4.2 Prohibited Certificate Use The DRA, the RA and CA do not accept any liability when an End User uses his certificate as part of an application not mentioned in the preceding paragraph. In particular, no claims of any kind will be accepted, of End Users or Certification Representatives, regarding any litigation not connected with the applications mentioned in the previous paragraph. The certificates issued by the CA that are used for purposes other than those specified in § 1.4.1 above are prohibited. In practice this means that the CA cannot be held responsible for any use of the certificates it issues other than those specified in this CP. Certificates can only be used in accordance with current, applicable laws, in particular to the extent permitted by laws on import and export and the laws, decrees, orders and directives specific to the electronic signature.

1.5 Policy Application 1.5.1 Organization managing this policy

The PAC is responsible for this CP.

1.5.2 Contact Person Contact details for the person or management drafting the CP: Entity title, name and job function

Email address Postal address

Certification Manager

[email protected] 83, boulevard des Chênes 78280 - GUYANCOURT Immeuble PROVENCE

1.5.3 Person Determining the Implementation Complia nce for this CP / CPS

Certification Practice Statement Compliance (CPS-CA certificate) with the Certificate Policy (CA Certificate Policy Certificate) is determined by the Policy Approval Committee of the Certificate Authority under the responsibility of: Gregoire LUNDI. For confidentiality requirements me mbers are only mentioned in CPS.




1.5.4 Approval Procedure for this Document This CP will be reviewed periodically by the Policy Approval Committee of the Certificate Authority, notably for:

- Ensuring compliance with security standards expected by the applications that itemise the families of End User certificates;

- - Adapting to CA organizational changes; - Adapting to technological developments.

This paragraph shows the main amendments in this document compared to the previous version.

1.6 Definitions and Acronyms 1.6.1 Definitions

CRL User Agreement: An agreement specifying the terms and conditions under which a Certificate Revocation List or the information that it contains may be used. Audit: An independent control of records and activities of a system to assess the relevance and effectiveness of system controls, to check its conformity against established policies and operational procedures, and recommend any changes required in controls, policies, or procedures. [ISO/IEC POSIX Security]. Certificate Authority (CA): See § 1.3.2. Registration Authority (RA): See § 1.3.3. Decentralized Registration Authority (DRA): See § 1.3.4. Customer : See § 1.3.9.1 User Community : Customer(s) and / or a class of applications having common security requirements. Common Criteria: a set of security requirements that are described according to an internationally recognized format. Products and software are assessed by a laboratory to ensure that they have mechanisms to implement selected security requirements for the evaluated product or software. Key ceremony: A procedure by which a key-pair of CA or RA is generated, its private key transferred and saved, and / or its public key certified. Certificate: public key and other information belonging to an entity, rendered impossible to counterfeit by encrypting the private key of the certification authority that issued it [ISO/IEC 9594-8; ITU-T X.509]. CA certificate: certificate for a CA issued by another CA. [ISO/IEC 9594-8; ITU-T X.509]. In this context, the CA certificates them (self-signed certificate). Self-signed certificate: CA certificate signed by the private key of the same CA. Certification path: (or chain of trust, or certificate chain) a chain comprising multiple certificates that are required to validate a certificate. Private key : key of an entity's asymmetric key pair which should only be used by that entity [ISO/IEC 9798-1].




Public key: key of an entity's asymmetric key pair which can be made public. [ISO/IEC 9798-1] Compromise: a violation of the security policy of a system in which unauthorized intentional or unintentional disclosure or loss of sensitive information may have occurred. Regarding private keys, a compromise occurs if the private key is lost, stolen, disclosed, altered, used without authorization, or other security compromise. Confidentiality: property that information is not made available or disclosed to unauthorised individuals, entities, or processes [ISO / IEC 13335-1:2004]. Subscription agreement : contract binding the Customer to a DRA for subscribing to the certification service. It contains all the documents required to prepare the Customer Records. A blank Subscription Agreement is available on request from the various DRAs. Certification Practice Statement (CPS): a statement of the practices which a Certification Authority employs in issuing, approving or rejecting certificate requests (transmission, management, renewal and revocation of certificates) [RFC 3647]. Certificate request: message sent by the RA to the CA for the issuance of a CA certificate. Availability: The property being accessible and usable upon demand by an authorised entity [ISO/IEC 13335-1:2004]. Distributor : An entity from Crédit Agricole, or LCL in a business relationship with the Customer. The Distributors act as the DRA (Decentralized Registration Authority). Activation data: Data values, other than the keys, that are required to work with cryptographic modules or items that they protect and which must be protected (e.g. A PIN, a passphrase etc.). Customer record : all documents (application and possibly including the Subscription Agreement) to be provided to the DRA* so that it can check the information requested by the RA to issue a ‘CA Certificat’ certificate, the registration of a new CR* (Certification Representative), changing data about a Certification End User or Representative, or finally revoking the mandate of a Certification Representative. These documents are described in the Subscription Agreement. Issuing a certificate : a certificate is issued (or sent) when it was generated and exported for delivery to the End User* or published. Registration (of an End User) : an operation which involves a Registration Authority* to retrieve from a Customer Record the information on an applicant for a certificate to be completed in the certificate fields in accordance with the Certification Policy*. Hash function: a function which maps strings of bits to fixed-length strings of bits, satisfying the two following properties: It is computationally infeasible to find for a given output, an input which maps to this output; It is computationally infeasible to find for a given input, a second input which maps to the same output. [ISO/IEC 10118-1]; It is computationally infeasible to find two different input data corresponding to the same output. Generation (of a certificate) : an action carried out by an operational CA* which signs all the fields in a certificate published by the RA*.




Public Key Infrastructure (PKI): the infrastructure required to produce, distribute, manage and store keys, certificates and Certificate Revocation Lists and the basis in which the certificates and CRLs must be published. [2nd DIS ISO/IEC 11770-3 (08/1997)]. Integrity: refers to the accuracy and source of the information and operation of the system which processes it. Interoperability: implies that the equipment and procedures used by two or more entities are compatible, and consequentially enables them to operate effectively together. Logs : logs collecting every item carried out by processes, transactions and programs produced by an information system (also called "event logs"). Certificate Revocation List (CRL): A list of revoked public key certificates created and digitally signed by a CA. The list contains the identity of the CA's CRL, the publication date, the publication date of the next CRL and the serial numbers of revoked certificates. The validity period is 7 days. Certification Representative (CR) : See § 1.3.8.2. Cryptographic modules: A set of software and hardware components used to implement a private key to allow cryptographic operations (signing, encryption, authentication, key generation etc.). For a CA, the cryptographic module is an evaluated and certified cryptographic hardware resource (FIPS or Common Criteria), used to keep and implement the CA private key. CO: See § 1.3.6 Certificate Validity Period: The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the certificate. [RFC 2459]. PKCS #10: (Public-Key Cryptography Standard #10) a standard from RSA Security Inc., which defines a structure for a Certificate Signing Request. Contingency plan (after a loss): plan defined by a CA to replace all or part of its PKI services after they have been damaged or destroyed as a result of a loss, outage or failure and within the time defined in CP / CPS. CRL distribution point: directory entry or other CRL distribution source; a CRL distributed via a CRL distribution point could include revocation entries for only a subset from all certificates issued by a CA, or could contain revocation entries for multiple CAs. [ISO/IEC 9594-8; ITU-T X.509]. Certificate Policy (CP): a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. [ISO/IEC 9594-8; ITU-T X.509]. Security Policy: a set of rules issued by the security authority and related to the use, service delivery and security installations [ISO/IEC 9594-8; ITU-T X.509]. End User : See § 1.3.8. Secret Holder : people who hold activation data bound to the implementation of the private key from a CA by using a cryptographic module. Policy Qualifier: information about the policy that accompanies an Object Identifier (OID) in an X.509 certificate. [RFC 3647] Revocation (of a certificate) : a stop or revoking operation requested by the End User, the Certification Representative*, the Customer, the RA, or CA or any other person authorized by the CA, which results in




cancelling the CA's * warrantee on a given certificate, before the end of its validity period. For example, if the key is compromised or information contained in a certificate has changed then the certificate must be revoked. The revocation operation is considered completed when the certificate number to be revoked and the date of revocation is published in the Certificate Revocation List (CRL*). RGS : Référentiel Général de Sécurité or RGS. French general IT security requirements RSA: a public-key cryptosystem developed by Rivest, Shamir, and Adelman. PS: See § 1.3.5. Web site : RA website dedicated to the service of the CA. This is a portal where the End User can find the following information: Information on electronic procedures; CA service information; Access to CA telephone support. The End User can carry out the following actions: Download certificates, Revoke certificates, Renew certificates, Check and test the validity of a certificate. End User Certificate : See §.1.3.8.1 Digital Certificate Validation : a verification method to ensure that the information contained in the certificate has been checked by one or more trusted authorities and are still valid. The validation of a certificate includes amongst other things, the verification of its validity period, its status (revoked or not), the identity of the CA certification chain and verification of the digital signature of all the CAs contained in the certification path.

1.6.2 Acronyms

- CA: Certification Authority; - RA: Registration Authority; - PAC: Policy Approval Committee; - CC: Common Criteria; - CNIL: Commission Nationale de l'informatique et des Libertés (National Commission for Information

Technology and Civil Liberties) - DN: Distinguished Name; - CPS: Certification Practice Statement; - EAL: Evaluation assurance level, ISO 15408 standard (Common Criteria) for certifying security products; - HTTP: Hypertext Transport Protocol; - IGC: Public Key Infrastructure; - IP: Internet Protocol; - ISO: International Organization for Standardization; - CRL: Certificate Revocation List; - LDAP: Lightweight Directory Access Protocol; - OCSP: Online Certificate Status Protocol; - OID: Object Identifier; - CP: Certification Policy;




- PIN: Personal Identification Number; - PKCS: Public-Key Cryptography Standard; - RFC: Request for comment; - RGS: Référentiel Général de Sécurité (French General IT Security requirements) - RSA: Rivest, Shamir, Adleman; - SHA: Secure Hash Algorithm (U.S. Federal standard); - PS: Publication Service; - URL: Uniform Resource Locator.




2 DIRECTORIES AND PUBLICATION SERVICES

2.1 Publication Service The PS is responsible for publishing data identified in § 2.2 below.

2.2 Published information The CA, via the PS, makes the following information available:

- The CA's CP: http://www.ca-certificat-plus.com/PC/09client/Sign_ Auth_National_CA_RGS.pdf ; - The CA and the RCA certificate http://www.ca-certificat-plus.com/04- Customer/telecharger_chaine.jsp; - The Certificate application form: - Crédit Agricole network: http://www.ca-certificat-plus.com

- The format and / or methods for revoking a certificate: - Crédit Agricole network: http://www.ca-certificat-plus.com

. - General Conditions for Use: - Crédit Agricole network: http://www.ca-certificat-plus.com

.

- The CRL: http://crl.ca-certificat.com/CreditAgricoleRGSUsageSepare/LatestCRL.crl and - ldap://ldap.ca-certificat.com/cn=CA%20LCL%20Certificat%20RGS%20

Usage%20Separe,ou=0002%20723001467,o=CEDICAM?certificaterevocationlist;binary?base?objectclass=pkiCA.

The CPS is not published but available on justified and authorized request from the PAC by the PAC. The PAC contact details are given in § 1.5.3.

2.3 Time and Frequency of Publication The CA's CP and the CA certificate are always available and updated as required. A new CRL is published every 24 hours. Availability rates are specified in the CPS.

2.4 Publishing Service Access Control The PS ensures that the information is available and protected in integrity against unauthorized amendments. The CA ensures that all information is stored in a document database and that its PKI public distribution or unforeseen amendment is protected.

3 ALL PUBLIC AND PUBLISHED INFORMATION (SEE § 2.2) IS FREE TO DOWNLOAD AND IS ACCESSED OVER THE INTERNET.IDENTIFICATION AN D AUTHENTICATION

3.1 Naming 3.1.1 Types of Names

Identities used are described in a certificate according to the X.500 standard. In each X.509 certificate, the supplier (Issuer) and the End User (subject) are identified by a Distinguished Name (DN).




DN attributes are encoded in a "PrintableString" or "UTF8String" except for email Address attributes which are in "IA5String". The construction of the End User's identity in the Production CA certificate is the following: Stand ard field Value

Issuer Identity of the issuing CA. Subject C = ISO Country code of the competent authority to which the

Customer's organization is officially registered (Commercial Court, Ministry,...). This code is written in capital letters; L=<City of the applicant>; CN = Full name of the End User; O = Full official name of the customer organization as registered with the competent authorities (Commercial Court, Ministry,...) ; SérialNumber= Serial number selected by the RA to distinguish identical CNs; E=<applicant Email>; OU= consisting of

- The 4-character ICD of the customer organization; - The identification of the customer organization in 35

characters with a separator between the two previous chains in the form of a space (SIREN).

OU= <Name of the Offer> - CACertificatPlus: name of the Offer so as to identify the

CRCAM, Caisse Régionale de Crédit Agricole Mutuel distribution network

- The format for the End User's identity in the TEST certificate is the following: Standard field Value

Issuer Identity of the issuing CA. Subject C = ISO Country code of the competent authority to which the

Customer's organization is officially registered (Commercial Court, Ministry,...). This code is written in capital letters; L=<City of the applicant>; CN = First name preceded by the comment XXX TEST and End User's name ; O = Full official name of the customer organization as registered with the competent authorities (Commercial Court, Ministry,...) ; SerialNumber= Serial number selected by the RA to distinguish identical CNs; E=<applicant Email>; OU= consisting of

- The 4-character ICD of the customer organization; - The identification of the customer organization in 35

characters with a separator between the two previous chains in the form of a space (SIREN).

OU= <Name of the Offer> - CA Certificat Plus: name of the Offer so as to identify the

CRCAM, Caisse Régionale de Crédit Agricole Mutuel distribution network

-




3.1.2 Using explicit names In all cases, the End User's identity (See § 3.1.1) is made up from the full name of his civil status as reported on the official identity document presented during registration. When the certificate is for an End User within a Company or an Administration, then the identity of the Company or the Authority is also contained in the certificate.

3.1.3 Anonymity or using pseudonyms The identity used for End User certificates cannot be a pseudonym or an anonymous name (See § 3.1.2).

3.1.4 Rules for Interpreting Various Name Forms The CUs can use the identity included in the certificates (See 3.1.1) to authenticate the End Users. However, no particular interpretation is to be done for the information in the "Subject" field in End User certificates.

3.1.5 Uniqueness of Names Identities in the CA certificates (See § 3.1.1) are unique within the domain of the CA's Certificate. Throughout the lifetime of the CA, an identity allocated to an End User (See 3.1.1) of a certificate cannot be allocated to another End User. Note that the uniqueness of a certificate is based on the uniqueness of its serial number within the CA certification field, but this number is unique to the certificate and not to the End User and does not ensure continuity of identification in successive certificates of a given End User. The RA ensures this uniqueness through its registration process and the unique value of the SN field allocated to an End User (See § 3.1.1.) Where there is a dispute about a name for a certificate, the CA has the responsibility to resolve the dispute in question.

3.1.6 Recognition, Verification, and role of Tradem arks Not applicable because the End User certificates do not contain brand names. The CA cannot be held liable in case of misuse by the user community and the customers of registered trademarks, famous trademarks and distinctive signs, including domain names.

3.2 Initial Identity Validation 3.2.1 Proof of Possession of the Private Key

The proof of possession of the private key by the End User is done via the procedures of generating the private key (please see § 6.1.1.1 below) corresponding to the public key to be certified and via the public key transmission mode (see § 6.1.3 below).

3.2.2 Checking an Organisation's Identity Authentication of an organization is based on the checking of information supplied as part of its certificate application (See § 4.1.2). This information includes the organization’s name, address and documentation or references to show that the organization exists including the domain name it owns. The entity carrying out the verification ensures that the organization properly exists and is legally authorized to exclusively use his name, by comparing the information supplied in the certificate application to the information collected in the official reference databases.




Information that is subject to verification during the authentication of the organization identity includes the SIREN number, VAT declaration number, DUNS etc. In all cases, the association of an End User to the Company and Administration organization to which he claims he belongs to is checked.

3.2.3 Checking the identity of natural persons

3.2.3.1 End User The End User is identified and authenticated in a face to face meeting with a CR, his legal affiliation entity, or the DRA. The identification and authentication of the End User is done by providing an official identification document (identity card, passport, etc.).

3.2.3.2 DRA and CR The RA shall register the DRA and the DRAs will register the CRs. The supporting documents for registering a CR are the same as those required from an End User. The CR further provides a signed commitment from him even to report to the DRA his departure from the company, and the End User leaving the company. Authenticating the CRs by the DRAs is done during a face to face meeting. The supporting documents requested from the DRA are described in the CPS. The CR must have signed a contract in which the CR must:

- Verify identities of prospective entity End Users in a proper and independent manner, where he is the CR; - Observe his obligations in the sections of the CP and the CA's public CPS.

3.2.4 Non-verified information

Unverified information is not entered in the certificates.

3.2.5 Validation of the authority of an End User Validating the authority of an End User checks that he acts on behalf of an organization (see § 3.2.2 above).

3.2.6 Criteria for recognition An End User who obtains a certificate issued by the CA is guaranteed to be authenticated by the user applications.

3.3 Identification and Authentication for Key renew al Requests 3.3.1 Identification and Authentication for Routine Re-keying

Certificate renewal is similar to renewing the key pair and allocating a new certificate. The End User authentication is done on the basis of his current and valid certificate and the End User downloads his certificate directly from the RA download service as explained in § 4.7. Authentication for the first renewal is automatic and is done from the End User's valid certificate. The next renewal requires the End User's authentication by following the same procedures for issuing the first certificate.

3.3.2 Identification and Authentication for Re-keyi ng After Revoking a Certificate Certificate renewal is similar to a renewal of the key pair and allocating a new certificate in accordance with the original procedures (see § 3.2) or must be a procedure offering an equivalent guarantee level.

3.4 Identification and Authentication for a Revocat ion Request Revocation requests are authenticated by the RA using only the information known to the End User and the RA. Where the applicant is a person other than the End User, authentication is done using procedures defined in the CPS.




4 OPERATIONAL REQUIREMENTS

4.1 Types of certificate 4.1.1 Origin of the certificate request

The CR or the End User applies for a certificate from the DRA.

4.1.2 Registration process and responsibilities The following minimum information should be in the application for the End User's certificate:

- End User within a company: o The certificate application is signed by the End User and dated within 3 months. If a CR provides

the application, then this application is also signed the CR; o The General Conditions for Use signed by the Legal Manager; o A photocopy, signed and dated within 3 months by the End User, marked "Certified to be a true

copy of the original," the current official identity document of the prospective End User (in particular, national identity card, passport or residence permit, the network of Regional Banks of Crédit Agricole also accepts driving licenses), including a passport photograph and the RA will keep a copy;

o The information used to prepare the identity of the End User (See § 3.1.1. and § 3.1.2); o The End User's contact details (telephone number, email, etc.); o A mandate signed and dated within three months, by a legal representative of the entity

designating the prospective End User to whom the certificate should be issued or the CR authorized to process the certificate request. This mandate must be signed for acceptance by the prospective End User or the CR;

o Any valid document when applying for the certificate (Kbis, SIRENE Certificate or entry in the business directory, etc.), proving that the company exists and has a SIREN number, or, failing that, another document showing the unique identification of the business that will be entered in the certificate;

o Any documents proving the quality of the person signing the certificate application;

- End User within an Administration: o The certificate request is signed by the End User and dated within 3 months; If a CR provides the

application, then this application is also signed by the CR; o The General Conditions for Use signed by the Legal Manager; o A photocopy, signed and dated within 3 months by the End User, marked "Certified to be a true

copy of the original," the current official identity document of the prospective End User (in particular, national identity card, passport or residence permit, including a passport photograph and the RA will keep a copy;

o The information used to prepare the identity of the End User (See § 3.1.1. and § 3.1.2); o The End User's contact details for the RA (telephone number, email, etc.); o A mandate signed and dated within three months, by a legal representative of the entity

designating the prospective End User to whom the certificate should be issued or the CR authorized to process the certificate request. This mandate must be signed for acceptance by the prospective End User or the CR;

o A document, valid at the time of registration, with the delegation or sub delegation of the authority responsible for the administrative structure

- End User Test Certificates:

o The certificate application should state the test protocol or explicitly show in the subscription record that the certificate is issued as a test.




The End User enters the authentication data during the certificate application, which is a list of answers to questions that he selects and the secret information. This authentication information is to authenticate the End User for operations that are not done in face to face meetings. The CPS describes the exact contents of the certificate application.

4.2 Certificate Application Processing 4.2.1 Identification and authentication

The DRA authenticates the certificate application, sent by the End User or the CR, and verifies the certificate application (See § 3.2.3). The DRA ensures that the End User has read the General Conditions for Use. The DRA sends the certificate application to the RA for validation. The RA keeps all the documents in the certificate application in its logs.

4.2.2 Approval or Rejection of Certificate Applicat ions On approving the application, the DRA (certificate application service) sends the application to the RA. The RA verifies and validates the certificate application and sends the certificate application to the CA (certificate generation service). The RA sends the hardware to the End User together with the associated initial activation data. The delivery is done by time-separated letters. The RA notifies the DRA and the CR in charge of the End User. The RA notifies the End User and sends him the authentication data. If the application is rejected, the RA will inform the DRA who informs the End User by justifying the rejection.

4.2.3 Processing Time for Certificate Applications The certificate application is processed upon receipt of the request by the RA within 48 hours.

4.3 Certificate Issuance 4.3.1 CA Actions during Certificate Issuance

4.3.1.1 End User Certificate The CA (certificate generation service) authenticates the RA and checks that the request actually comes from an RA authorized by the CA. The End User connects to the RA's certificate download service. The End User authenticates himself to the RA. The RA sends the certificate generation request to the CA. The End User authenticates himself to the RA's download service. The CA generates the End User's certificate. The CA sends the certificate to the RA's download service. The End User downloads the End User's certificate. Communications between the various components of the PKI cited above, are authenticated and protected in integrity and confidentiality. The End User has a maximum period of 3 months to download his certificate. After this period, the RA cancels the certificate application and the End User can no longer download his certificate. It is also possible to regenerate a new certificate within 72 hours after the unsuccessful download of a certificate by the End User and revoke the unsuccessful certificate by the RA. This process applies if an End User has a technical problem downloading his certificate. In this case he has a maximum of 72 working hours to contact the RA, on their download site, and ask for a new certificate to be generated. Over 72 hours, the End User must reapply for a certificate in the same way as for a normal certificate renewal, as defined in § 3.3.1, for the certificate. In this case, the RA can send a new media support (hardware) to the End User and the old certificate is revoked. The End User then downloads a new certificate as explained above.




4.3.2 Notification of the issuance of a certificate

There is no notification after downloading a certificate from the RA. However, the information concerning the certificate download is available from the RA.

4.4 Certificate Acceptance 4.4.1 Certificate Acceptance Procedure

The CA is automatically informed when each certificate is downloaded by the corresponding End User. The End User must notify the DRA, by using the contact details provided on registration, of any inaccuracy or defect in a certificate within 7 consecutive working days of downloading the certificate so that it is revoked and another certificate can be issued. The End User is deemed to have accepted the certificate when this deadline has passed. In addition, the General Conditions for Use (GCU) states that the End User is required to use the certificate in the certificate verification service offered at the end of the download process. The RA logs the results of the use of this service by the End User. In addition, the acceptance of a certificate constitutes acceptance of the CP (unique OID saved on the certificate).

4.4.2 Publication of a certificate by the CA The CA certificate is published by the PS. The End User certificates are not published by the PS.

4.4.3 Notification of Certificate Issuance by the C A to Other Entities Not applicable.

4.5 Key Pair and Certificate Usage 4.5.1 Key Pair and Certificate Usage

Key pair and certificate usage is defined in § 1.4 above and limited to access control operations and signature as part of the authorised applications. The key pair and associated certificate usage is also indicated in the certificate itself, by using the extensions about using key pairs (see § 6.1.7). The End User agrees to comply with the use of the key pair and certificate by signing the General Conditions for Use.

4.5.2 Public Key and certificate usage by third par ties The use of licenses by the CU is described in the paragraphs 1.4 above.

4.6 Requesting a New Certificate This section describes the End User certificate renewal, without changing the public keys or any other information included in the certificates. Only the validity period and serial number change. This type of operation is not authorised in this CP nor for the End User or for the CA certificate.

4.7 Changing keys (or a new public key certificate) This section deals with the generation of a new certificate and changing the associated public key. Changing the public key of a certificate involves creating a new certificate. The End User is alerted by the RA that his current certificate will expire before the expiry of his current certificate. The deadline is set out in the CPS. Only the first renewal can be done automatically as described in § 3.3.1 for a certificate during validation. The second renewal of a certificate during validation is always done in accordance with the original procedures for allocating the first certificate. If a certificate is revoked and the End User wishes to renew it, then the renewal is done in the same way as the first application for the initial certificate. Once a certificate is renewed and downloaded, then the CA notifies the CR.




4.8 Amending a Certificate This section deals with the generation of a new End User certificate keeping the same key. This operation is only possible if the public key re-used in the certificate is still compliant with the applicable cryptographic security recommendations for the length of the key. This type of operation is not authorised in this CP nor for the End User or for the CA certificate.

4.9 Revoking a Certificate 4.9.1 Reasons for revoking a certificate

4.9.1.1 PKI Component certificate The following circumstances may cause the revocation of a certificate from a PKI component (including a CA certificate for generating certificate and a CRL:

- Suspicion of compromise, compromise, loss or theft of the component private key ; - Decision to change the PKI component after detecting non-compliance of - Procedures applied within the component with those announced in the CPS (e.g. - Following a qualification audit or non-compliance); - The entity operating the component is no longer operational.

4.9.1.2 End User Certificate An End User certificate is revoked when the public key association and the End User who certifies that it is no longer considered as valid. The reasons that invalidate this association are:

- The private key is suspected to be compromised or it is compromised, lost or is stolen (including loss or theft of the hardware support);

- The Activation Data processing the use of the private key has been lost, or the use of the private key on a media support has been disabled due to the consecutive input of a predetermined number of incorrect PIN codes;

- Failure to follow the rules for using the certificate; - Failure by the End User of his obligations under this CP; - The End User's information contained in the certificate are not or no longer correct, and before the normal

expiration of the certificate; - Leaving his job, transfer to another job or the death of the End User, and the termination of the Customer's

business; - The End User or any of the Certification Representatives upon request (end of subscription); - Termination of the Subscription Agreement; - Failure to pay the sums due under the Subscription Agreement; - The information in the Customer Record are not or no longer correct; - Changing the SIREN number or the Customer's business name (e.g. if transferring the Subscription

Agreement by universal contribution of assets); - The CA certificate is revoked (which results in the revocation of all certificates signed by the corresponding

private key); - Changing the size of the keys required by national or international organizations.

When one of these instances occurs, the End User certificate in question must be revoked.

4.9.2 The Origin of a Revocation Request

4.9.2.1 PKI Component The PAC is behind all the requests for revoking components.




4.9.2.2 End User Certificate Revocation of an End User certificate can come from:

- The End User in whose name the certificate was issued; - One of the CRs; - The Customer's legal representative; - The CA issuing the certificate; - The CA that authorized the issuance of the certificate; - The DRA with which the Customer has established the "Subscription Agreement".

4.9.3 Procedure for revocation request

4.9.3.1 PKI Component When the decision is made to revoke one of the operational CAs in the chain of trust for an End User certificate (either CA or root CA), the following actions are carried out:

- All the unexpired End User certificates issued by this CA are revoked and included in the CRL; - The managers of authorized user applications, the CRs and the End Users are notified from the end of the

chain of trust; - An application to revoke the CA certificate is sent to the root CA linking the subordinate CA.

When the decision is made to revoke a CA certificate and the reason for revocation is known or the corresponding private key is presumed to be compromised, the following actions are carried out:

- All the valid End User certificates, issued from the compromise date (within a safety period) upon request from the CA, are removed and included in the CRL;

- The CRs and respective End Users are notified of the reason for revoking their certificate; - An application to revoke the CA certificate is sent to the CA that issued it.

If necessary, replacement certificates for the End Users will be issued as soon as possible.

4.9.3.2 End User A revocation can be requested:

- Online by the End User or a CR (via the RA's website online 24/7); - By telephone(*) by the End User or a CR, or the Customer (via the RA's Hotline); - With the DRA (during business hours) by the End User, a CR, or the Customer.

(*) During business hours, the applicant is online with the Support service; A revocation request contains the following information:

- The identity of the End User used in the certificate (full name, etc.); - The name of the person requesting the revocation; - All information is used to quickly and accurately revoke the certificate (certificate serial number, etc.).

An application for revocation is kept by the RA in its logs. The RA authenticates the revocation request it receives (see § 3.4). The RA sends the revocation request to the CA. The CA (revocation service) authenticates the RA and checks that the request actually comes from an RA authorized by the CA. The CA (revocation service) revokes the End User certificate including the certificate serial number in the next CRL that will be issued by the CA.




The revocation applicant is notified of the effective cancellation date for the End User certificate. Additionally, if the End User of the certificate is not the applicant, the End User is also notified of the effective revocation date of the certificate. The CR is informed about the revoked End User certificates linked to him. The revocation reasons are never published in the CRL.

4.9.4 Time allowed for the End User to make a revoc ation application Once the applicant knows about a possible cause for revocation that is his responsibility and is effective, he drafts his revocation application as soon as possible.

4.9.5 Processing time for a revocation The revocation service is available 24 / 7 according to the availability defined in the CPS. The CA processes revocation applications as soon as possible after receiving it (preferably immediately) and within a maximum period of 24 hours.

4.9.6 Revocation checking requirements for third pa rties It is up to the CU to check the validity status of a certificate by using all the CRLs issued by the CA.

4.9.7 CRL Publication Frequency The CRL is issued every 24 hours. The validity of the CRL is 7 days.

4.9.8 Maximum period of publication of a CRL The maximum publication deadline for a CRL after it has been generated is 30 minutes.

4.9.9 Availability of an online verification system for revocation and certificate status Not applicable.

4.9.10 Online Verification Requirements for revokin g certificates by the certificate users See section 4.9.6 above.

4.9.11 Other means of information available on revo cations Not applicable.

4.9.12 Specific requirements for End User certifica tes if a private key is compromised. The entities authorized to request a revocation are required to do so as soon as possible after becoming aware of the compromised private key.

CA holding certificates that must be revoked if its private key is compromised, must, at the very least, publish clear information on the CA website and possibly send by other means (other institutional websites, newspapers, etc.). If a CA is revoked, all End Users certificates are revoked too. The terms and conditions of the certificate clearly state that in case of compromise of the End User's private key, or he discovers that the private key of the CA that issued the certificate has been compromised; the End User must stop using his private key and its associated certificate immediately and definitely.

4.10 Certificate Status Service 4.10.1 Operational characteristics

There is a communication mechanism for checking the status of certificates and is available to certificate users from the CRL and ARL. The CRL and ARL are in V2 CRL format and are published in at least one directory that can be accessed using the LDAP V3 protocol.




4.10.2 Service Availability

The service is available 24/ 7 in accordance with the availability rate defined in the CPS.

4.11 End of relationship between the End User and t he CA If the contractual, hierarchical or regulatory relationship between the CA and the End User terminates prior to the end of the certificate validity period, for any reason, the End User certificate is revoked. A CR (or the End User) can apply to terminate a subscription by revoking the End User certificate and invoking the appropriate grounds. No Re-generation will be possible, and the subscription will no longer be invoiced. Termination of the Subscription Agreement will revoke all of the Customer's End User certificates and ends their subscription.

4.12 Escrow and key recovery The key-pairs and certificates of End Users and CAs issued in conformity with the CP cannot be escrowed or recovered.




5 PHYSICAL SECURITY MEASURES, PROCEDURES AND IMPLEM ENTATION

5.1 Physical security 5.1.1 Geographic location

The CA facility complies with the regulations and standards in force and its installation takes account of the results of risk analysis, to the certificate operator business, according to the EBIOS method, e.g. specific requirements such as flood, explosion (near an area containing factories or chemical storage premises, etc.) conducted by the CO.

5.1.2 Physical access To limit access to PKI applications and information and to ensure the availability of the CA operating system, the CA establishes a security perimeter for its specific needs. The use of this perimeter enables compliance with the principles relating to the separation of trust-based roles as set out in this CP. Access to the CO site supplying the PKI services is restricted to those persons required to perform the services and is based on their need-to-know requirements. Access is nominative and traceability is guaranteed. Security is reinforced through the use of passive and active intrusion detection methods. All security incidents are recorded and processed.

5.1.3 Energy and air conditioning Systems designed to protect the electrical power supply and provide air conditioning are deployed by the CO to ensure service continuity. The materials used to deliver services are operated according to the terms and conditions defined by their suppliers or manufacturers.

5.1.4 Exposure to liquids CO systems have been installed in such a way so as to avoid all risk of flooding and other projections or liquid outflows.

5.1.5 Fire prevention and protection The resources implemented by the CO to prevent and fight fire meet the requirements and undertakings made by the CA in this CP with regard to the availability of its functions.

5.1.6 Storing media devices The various Information involved in the PKI activities are identified and their security requirements defined (in confidentiality, integrity and availability). The media (paper, hard disk, diskette, CD, etc.) corresponding to this information are processed and kept in accordance with these security requirements. The details about storing media devices are provided in the CPS.

5.1.7 Decommissioning media devices At the end of their lifecycle, the media devices will be either destroyed or reinitialized for reuse.

5.1.8 Offsite backups The CO conducts offsite backups to rapidly recover PKI services after a disaster or an event that seriously and lastingly affects the performance of these services. The details concerning the back-up methods are provided in the CPS.




5.2 Procedural security measures 5.2.1 Trust-based Roles

Staff must be aware of and understand the implications of the operations for which they are responsible. Trust-based roles of the CA are divided into four groups:

- Operational staff, responsible for maintaining the PKI support systems in good working order - Administrative staff, responsible for the technical administration of the PKI components; - Operational staff, responsible for implementing the PKI services; - 'Security' staff, responsible for checking and controlling that measures are properly applied and that the

PKI component functions properly; - The personnel holding key activation data.

5.2.2 Number of people required to perform sensitiv e tasks

Several roles can be assigned to the same person, provided that this does not compromise the security of the functions being performed.

5.2.3 Identification and authentication of roles

The CA checks the identity and authorisations of each member of staff implementing the PKI services before assigning him/her a role and the attendant rights, in particular:

- That his/her name be added to the lists of persons granted controlled access to the site of the entity hosting the component concerned by the role;

- That his/her name be added to the list of persons authorized to physically access these systems;

- Depending on the role and as required, that an account be opened in his/her name in these systems;

- Cryptographic keys and/or a certificate might have to be delivered to him/her to fulfil the role that has been assigned within the PKI

These controls are described in the CPS and comply with the security policy of the CA. Each assignment of a role to a PKI staff member is notified in writing or equivalent.

5.2.4 Roles requiring separation of allocation Several roles can be assigned to the same person, provided that this does not compromise the security of the functions being performed. For the trusted roles, it is nevertheless recommended that the same person does not hold many roles and, as a minimum, the following requirements of non-accumulation must be respected. The functions associated with each role must be described in the CPS.

5.3 Staff Security Measures 5.3.1 Required qualifications, skills and authoriza tions

Each person working within the CA is subject to a confidentiality clause with regard to their employer. Verification is performed to ensure that the roles assigned to staff match their professional skills. All persons involved in PKI certification procedures are informed of their responsibilities with regard to PKI services, and of all system security and staff verification procedures.

5.3.2 Background check procedures The CA implements all the legal means at its disposal to verify the honesty of all staff working within the component. This verification is based on a background check of the person, In particular, checks are carried out to ensure staff have not been sentenced for a criminal offence in contradiction with the role(s) he/she has been assigned.




People who have been assigned a trust-based role must not have a conflict of interests that would be harmful to the impartiality of their tasks. Background checks are conducted prior to the assignment of a trust-based role and are reviewed regularly (at least every three years).

5.3.3 Initial training requirements At the start of their employment, staff receives training on the software, hardware and internal operating and security procedures that they implement and must respect, and which correspond to the component in which they operate. Staff is informed of and understand the implications of the operations for which they are responsible.

5.3.4 The requirements and frequency of continuous training The relevant staff receives the necessary information and training prior to any changes in the systems, procedures, organization, etc. and based on the nature of these changes.

5.3.5 Skills Management Details are provided in the CPS.

5.3.6 Penalties for unauthorized actions Details are provided in the CPS.

5.3.7 Requirements of staff employed by external se rvice providers Details are provided in the CPS.

5.3.8 Documentation provided to staff Details are provided in the CPS.

5.4 Procedures for the establishment of audit data Event logging consists of recording events manually or electronically. Information can be entered or automatically generated. The resulting files, in paper and/or electronic format, must guarantee the traceability and accountability of the operations carried out.

5.4.1 Type of events to be recorded The PKI logs the events concerning the systems involved in the functions it implements as part of the PKI.

- Creation / modification / deletion of user accounts (access rights) and corresponding authentication data (passwords, certificates, etc.).

- Starting and shutting down IT systems and applications; - Events related to logging: start and stop the logging function, changing logging settings and actions taken

following a failure of the logging function; - Connection / disconnection of users with trust-based roles, and the associated unsuccessful attempts.

Other events are also recorded. This is for security-related events that are not automatically generated by the implemented systems:

- Physical access to sensitive areas; - Maintenance actions and changes to system configuration; - Changes made by staff with trust-based roles; - Actions to destroy or reinitialize devices containing confidential information (keys, activation data, personal

information on the Users, etc.).




In addition to these logging requirements, which apply to all PKI components and functions, events specific to the various PKI functions are also logged:

- Receiving a certificate request (initial and renewal); - Validation / denial of a certificate request; - Events related to signature keys and CA certificates (generation (key ceremony), backup / recovery,

destruction, etc.); - Generation of End User certificates; - Transmission of certificates to End Users as appropriate, acceptances / refusals by the End Users; - Publication and update of information relating to the CA; - Generation of status information of a certificate (End User).

Each record of an event in a log contains the following fields:

- Type of event; - Name of the operator or reference of the system triggering the event; - Date and time of the event; - Result of the event (success or failure).

All actions are the responsibility of the person, organization or system having executed it. The name or ID of the executor is explicitly indicated in a field in the event log. Depending on the event concerned, the following fields can be recorded:

- Recipient of the operation; - Name of the applicant of the operation or reference of the system executing the request; - Names of those present (in case of an operation requiring several people); - Cause of the event; - All Information characterizing the event (for example, for generating a certificate, the serial number of this

certificate).

5.4.2 Logging process Logging operations are carried out during the process in question. If information is entered manually, it will be logged on the working day on which the event occurred, without exception. Details are provided in the CPS.

5.4.3 Protecting event logs Logging must be designed and implemented so as to limit the risk of event logs being by-passed, modified or destroyed. Integrity control mechanisms must detect any modification of these logs – whether deliberate or accidental. Event log availability must be protected (against partial or total loss and destruction, whether deliberate or accidental). The definition of event log sensitivity depends on the nature of the information processed and the line of business. It could require specific protection for confidentiality.

5.4.4 Event log back-up procedures The PKI implements the required measures to ensure the integrity and availability of the event logs for the component in question, complying with the requirements of this CP and based on the results of the CA risk analysis.

5.4.5 Event log collection system Details are provided in the CPS.

5.4.6 Vulnerability Assessment




The CA and RA must be able to detect any attempt to violate the integrity of the component in question. Event logs are regularly monitored in order to identify any anomalies resulting from failed attempts. The logs are analysed at least once a month. This analysis produces a summary in which the important elements are identified, analysed and explained. The summary must indicate any anomalies or tampering noted.

5.5 Archiving data Archiving data ensures the longevity of the logs established by the various PKI components.

5.5.1 Type of archived data For each component, the following data is archived:

- IT equipment software (executable) and configuration files; - The certificate policy; - The certification practice statement; - Certificates as issued or published; - The End User identity documents and, where relevant, their assigned entity (for businesses and

administrations); - Complete files of certificate applications; - The event logs of the various PKI entities.

5.5.2 Archive conservation period

Certificates and CRLs issued by the CA End User and CA certificates are archived for 10 years after their expiration. Event logs The event logs discussed in Chapter 5.4 are archived for ten years after their generation.

5.5.3 Archive protection Throughout their conservation period, archives and their back-ups:

- Will be protected in their integrity; - will be accessible only to authorized persons; - Can be read and searched.

5.5.4 Data time stamping requirements

If a time-stamping service is used to date the records, it must meet the requirements specified in section 6.8.

5.5.5 Archive Collection System The system collects the archives by observing the security level regarding data protection (See 5.5.3).

5.5.6 Archive retrieval and verification procedures Paper archives can be retrieved within a maximum timeframe of two working days. Electronic back-ups can be retrieved within a maximum timeframe of two working days.

5.6 Renewal of key pair 5.6.1 CA certificate

The lifetime of a CA certificate is determined by the validity period of the associated private key, in accordance with the recommendations for the safety of cryptographic key sizes, such as recommended by national or international authorities competent in the matter. The CPS specifies the standards used.




A CA cannot generate certificates whose lifetime exceeds the validity period of its CA certificate. This is why the key pair of a CA is renewed on or before the expiry date of the CA certificate, at least the lifetime of the certificates issued. Once a new private key is generated for the CA, only one is used to generate new End User certificates. The previous CA certificate remains valid to validate the certification path of the old certificates issued by the previous private key of the CA, until the expiration of all certificates issued to End Users using this key pair.

Otherwise, the CA changes its key pair and the corresponding certificate when the key pair ceases to comply with security recommendations concerning cryptographic key size or if it is compromised or suspected of being compromised.

5.6.2 End User Certificate The validity of a certificate is a maximum of 3 years.

5.7 Recovery following compromise or disaster 5.7.1 Incident and Compromise Procedures

The CA has established a business continuity plan that outlines the steps to be executed in the event of corruption or loss of system resources, and software or data that could disrupt or compromise the correct operation of the CA services. The CA has carried out a risk analysis to assess the business risks and determines the security requirements and operational procedures in order to draft a recovery plan. The risks taken into account are regularly reviewed and the plan is revised accordingly. The continuity plan is part of the CA's audit, in accordance with section 8.4 below. Personnel from the CA having a trusted role are specially trained to respond according to the procedures defined in the disaster recovery plan involving the most sensitive activities. Where the CA detects a hacking attempt or other form of compromise, it conducts an analysis to determine the nature of the consequences and their level. If any of the algorithms, or associated parameters, used by the CA or its End Users becomes insufficient for its intended remaining use, then the CA:

- Informs all the End Users and third party users of certificates with which the CA has agreements or other forms of relationships. In addition, this information is made available to other users of certificates;

- Revokes all the relevant certificates.




If necessary, the magnitude of the consequences is assessed by the CA to determine if the CA services should be restored and which End User certificates must be revoked. The CA must be declared as compromised and some services can be maintained (as a priority the revocation and publishing the status of End User certificate services) and how, depending on the business recovery plan. The CA will also directly and immediately inform the point of contact identified on the site: www.ssi.gouv.fr.

5.7.2 Corruption of IT resources, hardware, softwar e and / or data If the CA's equipment is damaged or not working when the signature keys are not destroyed, the operation is restored as soon as possible, giving priority to the capability of the revocation service and the publication of certificate validity status, according to the CA's business recovery plan.

5.7.3 Procedures if the private key of an entity is compromised If the CA's signature key is compromised, lost, destroyed, or suspected of being compromised:

- The PAC, after investigating the event, decides to revoke the CA's certificate; - All the Customers whose certificates were issued by the compromised CA, are notified as soon as possible

that the CA certificate has been revoked; - The PAC decides whether or not to generate a new CA certificate; - A new CA key pair is generated and a new CA certificate is issued; - The End Users are informed that the CA can now generate certificates.

5.7.4 Capabilities of resuming business following a disaster

The Business Recovery Plan following a disaster deals with business continuity as described in § 5.7.1. The PS is installed so as to be continuously available 24 / 7.

5.8 CA Expiry One or more PKI components might be required to discontinue its activity or transfer to another entity for various reasons. The CA will arrange to cover the costs for meeting these minimum requirements where the CA would become insolvent or for other reasons would be unable to cover these costs by itself, and this, as much as possible, according to the constraints of the applicable insolvency law. The transfer of an activity is defined as the discontinuation of the activity of a PKI component bearing no impact on the validity of certificates issued prior to the transfer in question, and the taking over of this activity organized by the CA in collaboration with the new entity The cessation of an activity is defined as the discontinuation of the activity of a PKI component having an impact on the validity of certificates issued prior to the cessation in question.

5.8.1 Transfer or cessation of an activity affectin g a PKI component

5.8.1.1 CA To ensure a constant level of trust during and after such events, the CA will:

- Set up procedures whose purpose is to ensure consistent service, in particular with regard to archiving (especially archiving of End User certificates and information relative to certificates);

- Ensure revocation continuity (registration of revocation requests and publication of CRLs), complying with the availability requirements for its functions defined in this CP.




Clarification on the following commitments should be clearly indicated by the CA in its CP:

- To the extent that the proposed changes could have an impact on the commitments to certificate End Users or users, the CA shall notify them as soon as necessary;

- The CA communicates with the point of contact identified on the site: www.ssi.gouv.fr the principles of the Action Plan implementing the technical and organizational means for dealing with a cessation or to organize the transfer of activity. It will particularly have such devices installed for archiving (key and certificate information) so as to carry out this function over the duration originally planned in its CP. The CA will inform the ANSSI of the methods for the changes that will occur, according to the various PKI components in question. The CA will measure the impact and draft a list of consequences of this event (legal, economic, functional, technical, communication, etc...). It will present an action plan designed to eliminate or reduce the risk for the applications and inconvenience to End Users and users of certificates;

- The CA will keep the ANSSI informed of any obstacles or additional delay encountered in carrying out the process.

The archives (CA or RA) are covered by the company taking on the activity in the event of a transfer of activity, or, in the case of cessation of activity, taken over by a company specializing in archiving, that is reliable and recognized by the managers of the authorized application users. The above entities are advised of the contact details of these companies. If the functions of supplying certificates for the CA are transferred to another entity (transferring project management for operational CAs), the Certification Authority, if necessary, will notify the managers of authorized application users who can then determine whether that entity has an assurance level compatible with their indexing. In addition, the technical provisions taken for such a transfer will be the responsibility of the Policy Approval Committee. If decision is made to terminate an operational CA, the private key of this CA which it used to sign previously issued certificates is destroyed, and the Certification Authority keeps its archiving obligations, and is required to:

- Inform with three months' notice of its intention to cease the activity of the operational CA in question; - Implement all the means at its disposal to inform its partners of its intentions; - Revoke the operational CA certificate in question; - Revoke all the valid certificates it has signed.

5.8.1.2 Compliance Loss The CA will take all the necessary and appropriate measures to modify the CP. The CA will inform its DRA which will notify all the customers by any appropriate means they will choose. The CA will suppress all the references to the lost compliance. The CA will respect the commitments indicated in the above paragraph 5.8.1.1. If CA judges it as necessary, eventually, the CA can propose a renewal or a transfers process to a compliant infrastructure. Later, a new compliant CA could replace the non compliant CA.

5.8.1.3 DRA If a DRA transfers its business, it notifies all of its customers, by a means at its discretion with a notice of three months. Where a DRA ends its business, it notifies all of its customers, by a means at its discretion with a notice of three months and perhaps offers an alternative.

5.8.2 Cessation of activity affecting the CA




Cessation of business may be total or partial (for example: stopping a family of given certificates only). Partial termination of an activity is gradual so that only the obligations listed below are to be performed by the CA, or a third party entity takes over the activities at the expiration of the last certificate it issued. Assuming a total cessation of activity, the CA or, if this is not possible, any entity that would be substituted by using a law, regulation, judicial decision or an agreement previously concluded with this entity, will guarantee the certificate revocation and CRL publications in accordance with the commitments undertaken in the CP. The CA carries out the following actions:

- Notification of affected entities; - The transfer of its obligations to other parties; - Management of revocation status for non-expired certificates that were issued.

When stopping the service, the CA:

- Will not send the private key it used to issue certificates; - Take all necessary measures to destroy or disable this key; - Revoke its certificate; - Revoke all the certificates it has signed and which are still valid; - Inform (e.g. with a receipt) all the CRs and / or End Users of revoked or to be revoked End User

certificates, and their assignment entity as appropriate.




6 TECHNICAL SECURITY MEASURES

6.1 Generation and Installation of Key Pairs 6.1.1 Generation of key pairs

6.1.1.1 CA Key Pairs Following the agreement of the PAC to generate a CA certificate, a key pair is generated during a key ceremony using cryptographic hardware. Key ceremonies take place under the supervision of at least three people in trust-based roles (supervisor of ceremonies and witnesses) and are impartial. It takes place in the premises of the CO. In an objective and factual manner, the witnesses attest that the ceremony is conducted according to a previously defined script. The roles involved in the key ceremonies are specified in the CPS. Key ceremonies take place under the supervision of at least two persons who have been assigned trust-based roles and in the presence of several witnesses, at least two of whom are external to the CA and are impartial. In an objective and factual manner, the witnesses attest that the ceremony is conducted according to a previously defined script. It is recommended that there is a public officer among the witnesses (bailiff or notary). Following their generation, parts of the secrets (activation data) are given to activation data End Users who are previously designated and authorized for this trust-based role by the CA. Whatever the format (paper, magnetic media or stored on a smart card or USB key), a same End User cannot keep more than one part of the secrets from the same CA at any given moment. Each part of the secrets must be implemented by its End User.

6.1.1.2 End User Key Pairs Key pair generation for the End User is done directly in the hardware token of the key pair by the End User. The generation process and the procedure to return the key pair and its token to the End User guarantees that only the End User can use it. The generation is done when the End User downloads the certificate.

6.1.2 Provision of the private key to the End User Not applicable.

6.1.3 Provision of the public key to the CA The public key is transferred to the CA by the End User who initiates the certificate request through the RA, in PKCS #10 format, and during a secure connection to ensure the integrity and confidentiality of the communication and authentication between the CA and the RA.

6.1.4 Provision of the CA's public key to third par ties The CA certificate is given to the End User when giving the certificate to the End User.

6.1.5 Key size The recommendations of national and international organisations (relating to key sizes, signature algorithms and hash algorithms) are periodically consulted to determine if the parameters used in the issuance of End User and CA certificates should or should not be changed. The use of the RSA algorithm with the SHA-256hash function is used for CA. The size of the CA key pairs is at least 2048 bits. The size of the End User certificate keys is 2048 bits for the RSA algorithm with the SHA-256 hash function as a minimum.




6.1.6 Production of Public Key Parameters and Quali ty Control The equipment used for the generation of CA key pairs are cryptographic hardware resources that are EAL 4 + certified. The End User key pairs are generated by the End User using equipment that is EAL 4 + certified.

6.1.7 Key Usage (according to the X 509 V3 Certific ate "key usage") Using the "key usage" field in the End User certificate and CA certificate is as follows:

- CA: o Key CertSign; o Key CRL Sign;

- End User: o No Repudiation; o Digital signature.

6.2 Private Key Protection and Standards relating t o Cryptographic Modules 6.2.1 Standards and security measures for cryptogra phic modules

The CA cryptographic hardware uses state of the art randomizers, to current standards or follows the specifications of standardization where they are standardized. The algorithms used must comply with current standards or follow the specifications of standardization where they are standardized. The CA provides the End User with the hardware directly and ensures that:

- The preparation of signature creation devices is securely controlled by the service provider; - The hardware is securely stored and distributed in the CO.

6.2.2 Control of the private key by several persons

Enabling the CA's private key is supervised by at least two people possessing the activation data and are in trust-based roles. The trusted people involved in the activation of the CA's private key are subject to strong authentication. The CA is activated in a cryptographic box so that it can be used only by the trust-based roles who can issue certificates. The End User is responsible for the protection and supervision of the private key by using his activation data.

6.2.3 Private key escrow The private keys of the CA and End Users are never held in escrow.

6.2.4 Back-up copy of the private key

6.2.4.1 CA The CA's key pair has a back-up copy under the supervision of several people for the purposes of disaster recovery. Backups of private keys are made using cryptographic hardware resources. The backups are quickly transferred to the relocated backup secure site to provide and maintain the recovery capability of the CA's activity. The backups of the CA's private keys are stored in cryptographic hardware resources or as an encrypted file (AES or 3DES).

6.2.4.2 End User The End User cannot make a backup copy of his private key.

6.2.5 Private key archiving The CA private keys are never archived.




6.2.6 Importing / exporting a private key

The CA keys are generated, activated and stored in cryptographic hardware resources or in an encrypted format. When they are not stored in the cryptographic resources or when being transferred, the CA private keys are encrypted using AES or 3DES algorithms. An encrypted CA private key cannot be decrypted without using cryptographic hardware and the presence of several people in trust-based roles.

6.2.7 Storing a private key in a cryptographic modu le

6.2.7.1 CA CA private keys stored in cryptographic hardware are protected with the same security level in which they were generated.

6.2.7.2 End User The hardware is delivered "blank" to the Customer and is electrically personalized (issuing the key pair and certificate storage) by the End User himself at the customers computer workstation.

6.2.8 Method for activating a private key

6.2.8.1 CA The CA private keys can only be activated with a minimum of two people in trust-based roles and possessing activation data for the CA in question.

6.2.8.2 End User The private key for an End User can be activated using activation data. The activation is required for each use of the private key using the hardware for the key pair.

6.2.9 Method of deactivating a private key

6.2.9.1 CA The cryptographic hardware resources in which the CA keys have been activated are not left unattended without supervision or accessible to unauthorized persons. After use, the cryptographic hardware resources are disabled. The cryptographic resources are then stored in a secure area to prevent tampering by people without strongly authenticated roles. The cryptographic resources for CA signature are online only to sign End User certificates and the CRLs after authenticating the certificate request and the request for revocation.

6.2.9.2 End User Disabling the End User's private key is done in such a way as to ensure that the private key contained in the hardware, is still under the control of the End User.

6.2.10 Private key destruction method

6.2.10.1 CA The CA private keys are destroyed when they are no longer used or when the certificates to which they correspond have expired or have been revoked. The destruction of a private key involves the destruction of backup copies, activation data and deletion of the cryptographic resource that contains it, so that no information can be used to find it.




6.2.10.2 End User The destruction of the End User's private key is done using the key pair hardware by using the deletion logic functions for the key pair media support and / or destroying the key pair hardware.

6.2.11 Certification of cryptographic resources See§ 6.2.1.

6.3 Other Aspects of Key Pair Management 6.3.1 Public key archiving

The public keys are archived by archiving certificates (See § 5.5.2 above).

6.3.2 Operational Validity of Certificates and Life of Key Pairs

6.3.2.1 CA Just as a CA cannot issue End User certificates with a lifetime greater than its own certificate, the key pair and certificate to which it corresponds are renewed on or before the expiration date of the CA certificate less the lifetime of the End User certificates issued.

6.3.2.2 End User The operational lifetime of a certificate is limited by its expiration or its revocation. The operational life of a key pair is equivalent to the certificate to which it corresponds.

6.4 Activation data 6.4.1 Generation and installation of activation dat a

6.4.1.1 CA The activation data for CA private keys are generated during the key ceremonies. (See § 6.1.1.1). The activation data is generated automatically according to an M of N format. In all cases the activation data is delivered to their End Users after generation during the key ceremony. The End Users of activation data are people authorized for this trust-based role.

6.4.1.2 End User The activation data for the hardware is selected by the End User. The CA defines and stores the End User's hardware enabling data. The hardware support is sent by the RA to the End User without any key pair in it. The End User must define the activation data on the first use of his hardware. The password chosen by the End User must include at least six alphanumeric characters.

6.4.2 Protection of activation data

6.4.2.1 CA The activation data is protected from disclosure by a combination of cryptographic mechanisms and physical access control. The activation data End Users are responsible for their management and protection. An activation data End User cannot possess more than one activation data set from the same CA at the same time.

6.4.2.2 End User The End User will ensure that the private key activation data is confidentially protected so that he is the only person who can activate the private key stored on his hardware support.

6.4.3 Other aspects affecting activation data




6.4.3.1 CA The activation data is changed where the cryptographic resources are changed or returned to the manufacturer for maintenance. Other aspects of activation data management are specified in the CPS.

6.4.3.2 End User If the End User disables his hardware, then he can call to the hardware personalization service to enable his hardware support.

6.5 IT System Security Measures 6.5.1 Technical security requirements for IT resour ces

The following functions are provided by the operating system, or with a combination of operating systems, software and physical protection. A PKI component includes the following functions:

- Authentication of trust-based roles; - Discretionary access control; - Banning the reuse of objects; - Require cryptography to be used during communications; - Require user identification; - Ensure strict segregation of tasks; - Provide protection for the operating system.

Where a PKI component is hosted on a platform assessed from a security requirement point of view, it should be used in its certified version. As a minimum requirement the component uses the same version of operating system as that on which the component has been certified. The PKI components are configured in such a way so as to limit the accounts and services to those elements required to support the CA services.

6.5.2 IT Security Rating PKI components used to support the CA services and that are hosted by the CO were designed following the recommendations of the document CEN CWA 14167-1 "Security Requirement for trustworthy digital system managing certificates for electronic signatures".

6.6 Technical controls of the system during its lif e cycle 6.6.1 System developments control

The control for system developments is as follows:

- Hardware and software purchased in such a way so as to reduce the chances of a particular component being changed;

- The hardware and software have been upgraded in a controlled environment, and the upgrading process defined and documented. This requirement does not apply to hardware and software purchased commercially;

- All hardware and software must be shipped or delivered in a controlled manner to provide continuous tracking from the point of purchase to the place of use;

- The hardware and software are dedicated to PKI activities. There is no other application, hardware, network connection, or software component installed which is not dedicated to the PKI activities;

- Extreme care should be taken so as not to download malicious software onto PKI equipment. Only applications required to carry out PKI activities are acquired from sources approved by the CA policy. The CA hardware and software will be scanned for malicious code on its first use and periodically thereafter;

- Updates for hardware and software are purchased or upgraded in the same way as the originals, and will be installed by trusted and trained personnel according to current procedures.

6.6.2 Controls for Security Management




The configuration of the CA system, and any amendments or changes are documented and controlled by the CA. There is a mechanism to detect any unauthorized changes to the software or configuration of the CA. A formal method of configuration management is used for installation and subsequent maintenance of the PKI system. When the PKI software is loaded for the first time, it is checked that it is the software version delivered by the seller, that it has not been modified before being installed, and that it matches the desired version.

6.6.3 Inspecting the security system during its lif e cycle With regard to the assessed software and hardware, the CA continues to monitor the requirements of the maintenance process to maintain the level of trust.

6.7 Network security mechanisms The CA is available online by controlled computer workstations. Accessible PKI components are connected to the Internet in a suitable architecture with security gateways and guarantees continuous service (except during maintenance or backup operations). The other CA's PKI components use the appropriate security measures to ensure they are protected against denial of service attacks and intrusion. These measures include the use of monitors, firewalls and filtering routers. The ports and unused network services are switched off. All flow control equipment used to protect the network on which the PKI system is hosted refuses any service other than those necessary to the PKI system, even though these services have the ability to be used by other network devices.

6.8 Timestamp / system dating There is no time stamp used by the CA but a reliable dating system is used. All the CA's components are regularly synchronized with a time server such as an atomic clock or a Network Time Protocol server (NTP). The time provided by this time server must be used for setting the time:

- From the start of the validity period of a CA certificate; - From revoking a CA certificate; - On displaying CRL updates.

Automatic or manual procedures can be used to maintain the system time. The clock settings are auditable events.




7 CERTIFICATES, CRL AND OCSP PROFILES

7.1 Certificate Profiles Certificates issued by the CA are X.509 v3 format certificates (populate version field with integer "2"). The fields in End Users and CA certificates are defined by the RFC 5280.

7.1.1 Certificate Extensions

7.1.1.1 CA Certificate -

The CA certificate is made up as follows: Certificat de base Valeur Version 2 (=version 3) Serial number Défini par l’outil Issuer DN O = CEDICAM

OU= 0002 723001467 CN=AC Racine groupe CREDIT AGRICOLE v2 C = FR

Subject DN O = CEDICAM OU= 0002 723001467 CN= CA LCL Certificat RGS Usage Separe C = FR

NotBefore YYMMDD000000Z NotAfter YYMMDD235959Z + 10 ans Public Key Algorithm and signature

Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Parameters NULL Extensions standards OID Inclure Critique Valeur



Select AKI field Key Identifier Basic Constraint {id-ce 19} X TRUE

CA Set

Maximum Path Length 0




CPSpointer n/a

OID

value URI=http://www.ca -certificat.com/PC/v2client/AC_racine_CA_V2.pdf




User Notice n/a

OID n/a

value n/a

noticeRef n/a

organization n/a

noticeNumbers n/a

explicitText n/a


distributionPoint URI=http://crl.ca -certificat.com/CREDITAGRICOLE/ACRacineGroupeCAv2.crl

reasons n/a

cRLIssuer n/a




Digital Signature Clear

Non Repudiation Clear



Key Agreement Clear

Key CertSign Set

Key CRL Sign Set


Subject Alternative Name {id-ce 17} n/a



Other Extensions

7.1.1.2 End User Certificate -

The certificate End User is made up as follows: Certificat de base Valeur Version 2 (=version 3) Serial number Défini par l’outil Taille de la clé 2048 Durée de validité 3 ans Issuer DN O=CEDICAM

OU=0002 723001467 CN= CA LCL Certificat RGS Usage Separe




C=FR Subject DN C=FR

L=<Ville du demandeur> O=<Entreprise du demandeur> OU=0002< SIREN entreprise> OU= <Nom de l’offre commerciale> CN=<Prénom NOM> SerialNumber=<Identifiant Abonné du BO> E=<Email demandeur>

NotBefore YYMMDDHHMMSSZ NotAfter YYMMDDHHMMSSZ +3 ans Public Key Algorithm Sha256WithRSAEncryption (1.2.840.113549.1.1.11) Parameters NULL Extensions standards OID Inclure Critique Valeur



Select AKI field Key Identifier

Basic Constraint {id-ce 19} X TRUE

CA False

Maximum Path Length n/a




CPSpointer n/a

OID

value URI=http://www.ca -certificat -plus.com/PC/09client/Sign_Auth_National_CA_RGS.pdf

User Notice n/a

OID n/a

value n/a

noticeRef n/a

organization n/a

noticeNumbers n/a

explicitText n/a


distributionPoint URI= http://crl.ca-certificat.com/CreditAgricoleRGSUsageSepare/LatestCRL.crl URI=ldap://ldap.ca-certificat.com/cn=CA%20LCL%20Certificat%20RGS%20 Usage%20Separe,ou=0002%20723001467,o=CEDICAM?certificaterevocationlist;binary?base?objectclass=pkiCA




reasons n/a

cRLIssuer n/a



Subject Alternative Name X FALSE

Rfc822Name <Email demandeur>


Digital Signature Set

Non Repudiation Set



Key Agreement Clear

Key CertSign Clear

Key CRL Sign Clear




For testing purposes in the applications, End User test certificates can be issued by the production has the value "TEST XXX" inserted in the CN before <FirstName NAME>. This term is added when the certificate is issued by the production CA. .

7.1.2 Algorithm Identifiers The algorithm identifier used is Sha-256WithRSAEncryption: {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}.

7.1.3 Name Forms The name forms meet the requirements of § 3.1.1 where the identity of the End Users and the CA that is in the certificates issued by the CA.

7.1.4 Object identifier (OID) of the Certification Policy Certificates issued by the CA contain the OID of the CP which is given in § 1.2.

7.1.5 Policy Extensions Not applicable.

7.1.6 Policy Qualifier Syntax and Semantics




Not applicable.

7.1.7 Semantic interpretation of the critical exten sion "Certificate Policies" No requirement formulated.




7.2 CRL profile 7.2.1 CRL and CRL extension fields

The CRL issued by the CA is in the following format: Characteristics of the CRL Period of validity: 7 days

Frequency of update: 24 hours Version of the CRL: V2 Extension: Number +

AKI => 3F AA 87 D9 92 CE 13 F9 9A 43 CE D7 A9 DA 7A C8 E0 1B 27 1A Publication http : URL http://crl.ca-certificat.com/CreditAgricoleRGSUsageSepare/LatestCRL.crl Publication LDAP : URI=ldap://ldap.ca-certificat.com/cn=CA%20LCL%20Certificat%20RGS%20 Usage%20Separe,ou=0002%20723001467,o=CEDICAM?certificaterevocationlist;binary?base?objectclass=pkiCA

.

7.3 OCSP Profile Not applicable.




8 COMPLIANCE CONTROLS AND OTHER ASSESSMENTS

8.1 Frequency and reasons for audits The PAC of the CA is responsible for the correct operation of the CA's PKI components, in accordance with the provisions set out in this document. It will conduct regular compliance controls and check the correct working of the CA's components. Recognition of compliance by the CA of the requirements in this CP is made through the qualification scheme of trust services established and administered by the COFRAC in France (See [PROG_ACCRED]) complying with [QPSCe] and [décretRGS]. The process and requirements for qualification audits are defined in [PROG_ACCRED] and are therefore not repeated here.

8.2 Identity / Qualifications of Auditors Auditors must demonstrate their competence within the scope of compliance audits, as well as be familiar with the requirements of the CP. The auditors in charge of the compliance audit should carry out a compliance audit as their main job. The PAC pays particular attention during the compliance audit, especially about its audit requirements. The controller is designated by the Policy Approval Committee for the Certification Authority.

8.3 Connection between the auditor and the assessed entity Where the control is made at the request of a third party, the controller is chosen according to criteria of independence and expertise within the scope of IT security and, in particular, the PKIs. In other cases, the designated controller could be an internal audit entity at Credit Agricole who is an expert in IT security.

8.4 Points covered by the assessment The objective of the compliance audit is to check that a CA component operates its services in accordance with this CP and its CPS.

8.5 Actions taken in the event of non-compliance In the event of non-compliance, the Policy Approval Committee decides any necessary corrective action. Depending on the degree of non-compliance from the CPS to the CP, the PAC can:

- Ask for the implementation of corrective actions where the implementation will be checked during the next audit;

- Request the correction of the non-compliance within a strict timetable that results in a compliance control being carried out;

- Revoke the CA operational certificate; if necessary; - Revoke an End User certificate or certificates.

8.6 Communication of results A Compliance Control Report, including the mention of corrective actions already taken or under way by the component, is given to the PAC as provided in § 8.1 above. Non-compliance revealed by these audits will be published to authorized users responsible for applications for which the Certifying Authority is contractually required to do so. Given the confidentiality of such information, the publication of results is limited and strictly controlled.




9 OTHER COMMERCIAL AND LEGAL PROVISIONS

9.1 Rates 9.1.1 Rates for the issuance and renewal of certifi cates

The price conditions current at the acquisition date of the certificate is given in the CA's "Terms of service pricing" in the appendix of the drafted "Subscription Agreement".

9.1.2 Rates for access to certificates See § 9.1.1.

9.1.3 Rates for access to CRLs and certificate stat us information The CA Publishing Service (which contains the CRL for the End User certificates and the ARL for the CA certificates) is available free on the Internet.

9.1.4 Rates for other services See § 9.1.1.

9.1.5 Refund Policy The refund policy is defined in the applicable terms and conditions of the certificate.

9.2 Financial responsibility 9.2.1 Insurance coverage

The CA implements reasonable levels of insurance cover and has subscribed with this effect a public liability insurance in respect of carrying out its professional activity.

9.2.2 Other Resources The CA has sufficient financial resources for its proper operation and performance of its duties.

9.2.3 Cover and warranty for user entities In the event of damage to a user entity due to a failure by the CA to its obligations, the CA may be required to compensate the user entity in the CA's limit of liability as defined in the general conditions for use and this document.

9.3 Confidentiality of information and business dat a 9.3.1 Scope of confidential information

The information considered to be confidential is the following:

- The non-public part of the CA's CPS, - The CA's private keys, components and End User certificates, - The activation data associated with the CAs and End Users private keys, - All the secrets of the PKI, - The event log of the PKI components, - The End User's registration file, - The reasons of revocation, unless explicitly agreed by the End User - The internal security policy of the CA - Parts of the CPS considered to be confidential.

Otherwise, the CA guarantees that only his authorised staff in trust-based roles, the staff controllers in carrying out compliance audits, or other people on a need-to-know basis, have access and can use such confidential information.




9.3.2 Information outside the scope of confidential information The data in the certificate is not considered to be confidential.

9.3.3 Obligations in terms of protection of confide ntial information The CA has implemented and observes security procedures to ensure confidentiality of information marked as confidential within the meaning of section 9.3.1 above. In this regard, the CA particularly observes the laws and regulations on French territory. In particular, it is mentioned that it might have to make End Users registration files available to third parties within the scope of legal proceedings. The CA also provides the End User with access to this information.

9.4 Protection of personal data 9.4.1 Personal Data Protection Policy

The personal data collected during the identification of the Customer, the legal representative, the Certification Representative and the End User, as well as the data to be collected later, is collected by the DRA for the issuance, management and storage of certificates on behalf of the Certification Authority. The collection and processing of this data is carried out in strict compliance with the legislation and regulations on French territory, in particular Act No. 78-17 of the 6th January 1978, called "Data Protection".

9.4.2 Personal information The CA considers that the following information is personal data:

- Customer identification data, the legal representative, the Certification Representative and End User; - The data containing the Customer's, legal representative's, Certification Agent's and End User's identity; - Data entered on application of a certificate to be issued; - Data entered on application of a certificate to be revoked; - Reason for revoking End User certificates.

9.4.3 Non-personal information

No requirements are provided herein.

9.4.4 Obligations in terms of personal data protect ion The CA has implemented and observes procedures to protect personal data to ensure the security of personal information as defined in section 9.4.1 above in connection with the issuance and management of an End User certificate. In this regard, the CA observes the laws and regulations on French territory, in particular, Law No. 78-17 of the 6th January 1978 relating to IT, files and liberties revised in 2006.

9.4.5 Prior express consent for using personal data

None of the personal data communicated by a Customer, legal representative, a certification Representative or End User can be used by the CA other than those defined as part of the CP without the prior express consent of the person concerned.

9.4.6 Obligations in terms of personal data protect ion




The CA complies with the applicable European and French laws and has secure procedures for access to judicial authorities by a court ruling or other legal authorization to personal data. The procedures of the CA CA LCL RGS certificate Separated Use relating to handling confidentiality comply with French law.

9.4.7 Rights of the person concerned: The rights of appeal, access and rectification can be exercised: For the Regional Banks of Crédit Agricole on request from:

CREDIT AGRICOLE CARDS AND PAYMENTS Batiment Alsace

SERVICE CA CERTIFICAT +

83, BOULEVARD DES CHENES 78280 GUYANCOURT - FRANCE

9.5 Intellectual property rights During the execution of services as defined herein and / or the CA's "Subscription Agreement", material protected by the legislation on copyright could be delivered. These items, including copyright attached thereto, shall remain the property of the relevant copyright owner. The beneficiary of these services has the right to reproduce these items for his internal use. But he cannot, without the prior permission of the copyright owner, make available to third parties, extract or reuse in whole or in part thereof or derivative works or copies thereof, especially software or databases. Subject to the provisions of this section, no license, expressly or implied, is granted by the copyright owner of inventions, patents or patent applications owned by it/him/her and having been made outside of this document and / or the CA's "Subscription Agreement".

9.6 Obligations and guarantees The PKI components, the Customers and the community of certificate users are responsible for any damage caused in response to a breach of their respective obligations as defined under the terms of the CP. 9.6.1 Common obligations The common obligations of the various PKI components are:

- Guaranteeing the integrity and the confidentiality of private keys to which they are entrusted, including the activation data of aforementioned private keys, if necessary;

- Only to use the public and private keys where they are custodians for the purpose for which they were issued and by the appropriate means;

- Implement the suitable technical equipment and employ the required human resources to achieve the benefits to which they are committed;

- Document their internal operating procedures to the attention of their respective staff on a need-to-know basis in connection with the duties assigned to it as a component of the PKI;

- Observe and implement the terms of this CP that they acknowledge; - Accept the audits and the results and consequences of a compliance control (internal and external) and, in

particular, address the non-conformities that may be revealed; - Observe the conventions that bind them to other component entities of the PKI.

9.6.2 PAC obligations and guarantees The obligations of the PAC are the following:




- The drafting of the CP and CPS; - ; - Document the certification schemes that it has with third party CAs; - Establishing compliance between the CP and the CPS; - Maintaining the CP and CPS.

9.6.3 CA Obligations and Guarantees The CA checks that all the requirements detailed in this CP and the associated CPS are satisfied in respect to the issuance and management of End User certificates. The CA is responsible for maintaining the compliance with the procedures prescribed in this CP. The CA provides certification services in accordance with its CPS. The common obligations to the CA components are:

- Observe and apply the CP and the CPS of the PKI RCA that issued its CA certificate; - Ensure with the certificate the connection between the identity of an End User and his public key; - Protect the private keys and their activation data in integrity and confidentiality; - Only use its cryptographic keys and certificates for the purposes for which they were generated and by

appropriate means, as specified in the CPS; - Observe and implement the provisions of the part of the CPS that concern it (this part of the CPS must be

sent to the component in question) so as to maintain compliance between the CP and the CPS; - Accept that the audit team carries out audits and communicates to the RA all relevant information in

accordance with the intentions of the PAC to monitor and check it complies with the CP; - Document its internal operating procedures to complete the General CPS; - Implement the technical equipment and employ the human resources required to implement and carry out

services to which it committed itself in the CP / CPS; - Take all reasonable steps to ensure that its End Users are aware of their rights and obligations regarding

the use and management of keys, certificates or equipment and software used for the PKI; - Keep available for End Users and the applications the notification for revoking the certificate of a PKI

component or an End User; - Protect the End User's hardware enabling data and implement a secure procedure for enabling the

hardware. The CA is responsible for the compliance of his CP, with the requirements issued in the ETSI TS 102042 standard and RFC 5280 for X509v3 certificate. The CA assumes any harmful consequences resulting from failure to comply with its CP, complying with the requirements of the CP and standard above mentioned, by itself or one of its components. It takes all the necessary measures to meet its responsibilities connected with its operations and / or activities and has the financial stability and resources required to operate in accordance with the CP. In addition, the CA acknowledges liability in the event of liability or negligence, of itself or one of its components, whatever the nature and severity, which would result in the reading, alteration or misuse of the End User's personal data for fraudulent purposes, that this data being contained in or in transit in the management applications for CA certificates. Moreover, the CA acknowledges that it has a general duty of care and supervision, for the security and integrity of certificates issued by itself or one of its components. It is responsible for maintaining the security level of the technical infrastructure on which it uses to provide its services. Any changes affecting the level of security provided must be approved. 9.6.4 The RA's Obligations The RA's obligations are the following:

- Authenticating the certificate application;




- Authenticating the certificate revocation; - Accept that the audit team carries out audits and communicates to the RA all relevant information in

accordance with the intentions of the PAC to monitor and check it complies with the CP; - Protect End User data activation.

9.6.5 The DRA's Obligation and Guarantees The effective control of the accuracy of information provided by applicant (End User or CR) certificates is carried out by various DRAs. The DRA's obligations are the following:

- Authenticating End Users and CRs depending on the Customer's choice; - Authenticating the CRs; - Draft and control subscription agreements signed by the Customer; - Ensure that the person identified in the CR's additional files sent to prove his identity and check the

authenticity of documents and the accuracy of the statements that establish the identity of the CR and the Customer;

- Protect the confidentiality and integrity of customer records sent out; - Protect subscription agreements; - Send the subscription agreements and the customer files to the RA; - Acknowledging formal certificate applications, by checking the origin and accuracy, and forwarding them for

processing to the RA; - Acknowledging formal certificate revocations, by checking the origin and accuracy, and forwarding them for

processing to the RA; - Maintain adequate internal control procedures to ensure reliability of operations for which they are

responsible; - Ensure that its customers know their rights and obligations regarding the use and management of keys and

certificates; - Establish the identity of the Customer; - Establish the identity of the CRs; - Establish the identity of the End Users; - Protect End User data activation.

9.6.6 Certification Representative (CR) The CR's obligations are the following:

- Communicate accurate information when applying for a certificate; - Observe the obligations of an End User while he holds an End User certificate; - Enforce the terms of use of the private key and corresponding certificate; - Immediately notify the DRA if a private key has been compromised; - If necessary revoke an End User certificate; - Guarantee that an End User identified in a transmitted Customer file has been authenticated by him and

that his identity has been confirmed and the accuracy of the statements that establish the End User's identity;

- Authenticate and establish the identity of the End Users requesting certificates; - Ensure that the prospective End User has read the terms applicable to using the certificate; - Judiciously select and confidentially send to the End User some of the items for downloading the certificate; - Warn the DRA about any inaccuracy or abandonment of a certificate within three consecutive working days

of downloading the certificate so that it can be revoked and another certificate can be provided; - Send the police statement receipt to the DRA in the event of any embezzlement, hacking, intrusion,

tampering and forgery. 9.6.7 The End User's obligations and guarantees The obligations of the End User are:




- To protect the integrity of confidential information held by him in confidence (private key, activation data and authentication data);

- Transmitting the public key, corresponding to the private key to the DRA; - Comply with all the requirements of the CP and the associated CPS; - To use his certificate and corresponding private key according to the list of authorized applications; - Ensure that the information he provides to the DRA and the CR is complete and correct; - Take all reasonable steps to prevent unauthorized use of his private key and keep the information

confidential; - Immediately notify the DRA and the CR if causes for revocation are known; - Revoke his certificate immediately if causes for revocation are known.

9.6.8 The PS's obligations and guarantees The obligations of the PS are:

- To publish the CRLs; - To publish the CA certificates; - To publish the CP and associated GCUs; - Guarantee publication 24/7 with availability rates provided for the published information; - Protect access to the PS; - To check that the information is up to date and reliable; - Protect the integrity of data.

9.6.9 Obligations and guarantees of other participa nts

9.6.9.1 Customer The Customer's obligations are the following:

- Designate, under his responsibility, its CRs and the End Users who will be issued with a certificate; - Draft the agreement to the certification subscription service; - Guarantee the authenticity and the complete and up to date information provided in the certificate

application together with the documents that accompany this information; - Notify the End User of the restrictions for using the certificate described in the General Conditions for Use; - Immediately notify the DRA of any changes to this information and / or documents; - Provide information to End Users on the terms for using the certificates, key management or equipment

and software used to operate them; - To ensure the acceptance of the certificate by each End User and the checks before acceptance; - Protect the private key of each End User by the appropriate means to his environment; - Protect the Activation Data for each End User by the appropriate means to his environment; - Enforce the terms of use of the private key and certificate corresponding to each End User, including the

use within the strict framework of the authorised applications; - Request the revocation of a certificate if it is necessary; - Inform the DRA immediately in the event of suspected compromise or compromise of the private key of one

of its End Users; - Primarily fulfil the Bank's obligations for its employees, End Users and CR.

9.6.9.2 CU's obligations and guarantees The obligations of the CU are:

- To check an End User certificate using the information made available by the PS; - Meet the purpose for which a certificate was issued when such use has been declared critical; - Check the digital signature of the CA issuing the certificate; - Check the validity of certificates (validity dates and revocation status).




9.7 Limitation of Guarantee The CA provides its PKI services:

- Identification and authentication of the CA with its self-signed certificate; - The identification and authentication of End Users with the certificates generated by the CA; - The management of corresponding certificates and certificate validity information according to this CP.

These guarantees are exclusive of any other CA guarantee. It is expressly understood that CREDIT AGRICOLE CARDS AND PAYMENTS cannot be held responsible for any damage resulting from fault or negligence of a Customer and / or his (their) authorised Certification Representatives and / or its End Users or for any damage caused by an external act or force majeure, particularly in cases of:

- Using a certificate for an application other than the authorised applications; - Using a Certificate to guarantee another item other than the identity of the End User; - Using a revoked certificate; - Poor storage methods for the private key of the End Users certificate; - Using an expired certificate; - Non-compliance of other participants (see § 9.6.9); - External acts to the issuance of the certificate such as a failure of the application for which it can be used; - Force majeure such as defined by the French courts.

9.8 Limits of Liability The CA is responsible for the requirements and principles outlined in this CP, as well as any damage caused to an End User or an application / user certificate following a breach of the procedures as defined in the CP and the associated CPS. The CA declines any responsibility for using certificates issued by it or associated public / private key pairs in the conditions and for purposes other than those provided in the CP and any other associated applicable contractual document. The CA is not responsible for the consequences of delays or losses that may incur in transit of any e-mails, letters, documents, and regarding any delay, alteration or other errors that may occur in the transmission of any telecommunication. The CA cannot be held liable, nor acknowledge any liability for any delay in carrying out its obligations or for any breach of obligations under this policy where the circumstances giving rise to and which may result from total or partial interruption of its business, or its disruption, force majeure within the meaning of Article 1148 of the Civil Code. Explicitly, considered as force majeure or unforeseeable circumstances, beyond those usually used by the decisions of French courts, are social conflict, network failure or facilities or external telecommunications networks. The CA is not responsible for consequential damages suffered by user entities, they are not prequalified hereby. In case of imposition of any liability of the CA, the damages, interests and indemnities at its responsibility irrespective of all causes, and whatever the basis of liability, are limited per certificate to the amount provided under the limit of responsibility in the GCU applicable to that certificate.




9.9 Compensation The parties agree that in the event of imposition of any liability of the CA concerning a third party user, the damages, interests and compensation in its responsibility will be determined during the procedure provided for in Section 9.3 of this document.

9.10 Duration and termination before the due validi ty date of the CP 9.10.1 Duration

The CP becomes effective once approved by the PAC. The CP remains in force at least until the end of the life of the last certificate issued under this CP.

9.10.2 Cancellation Depending on the extent of changes to the CP, the PAC will decide whether to carry out an audit of the CP / CPS of the CAs concerned, or to instruct the CA to take the measures necessary to conform within a fixed time limit.

9.10.3 Effect of Termination and Survivorship The expiry of the CP leads to the termination of all obligations and responsibilities of the CA for the certificates issued pursuant to the CP.

9.11 Amendments 9.11.1 Procedure for providing an amendment

The PAC reviews its CP and its CPS when revelants changes as describe on the 1.3.1 paragraph for the PAC mandatory obligations occurs. Further revisions may be undertaken at any time at the discretion of the PAC. Corrections of spelling or typing errors that do not change the sense of the CP are authorised without having to be notified.

9.11.2 Mechanism and deadlines for notifications The PAC gives at least one month’s notice to the PKI components of its intention to amend its CP / CPS before making any changes and depending on the purpose of the amendment. This deadline applies only to changes which would be in substance (change of key size, procedural change, changing certificate profile etc.) and not on the format of the CP and the CPS. If proposed changes to specifications then the following cases are possible for the RCA:

- Typographical changes do not give rise to notification and modification of the OID for the CP / CPS or the URL;

- Changes on the level of quality and security of the RCA functions concerning the CA certificates, without losing the compliance thereof with the CP, and with a notice period of one month before the changes and not giving rise to any change in the OID of the CP / CPS or the URL;

- Changes leading to loss of compliance of the End Users certificates with the CP involving the amendment of the OID for the CP / CPS and the download URL.

The final amendments are subject to the managers of authorized user applications before being published. The changes are published on the day they should be notified. Besides , CA notifies DRA that will inform by any convenient means the Customersor End User..

9.11.3 Reasons that an OID should be changed If the AAK (Administrative Authority OPENTRUST) assesses that amending the CP will change the level of trust provided by the requirements of the CP or the content of the CPS, it can institute a new policy with a new object identifier (OID).




9.12 Settlement of Disputes In the event of a claim by the Customer, the parties will follow the complaints procedure provided for customers in the General Subscription Conditions signed by the Customer. Failing resolution of the problem encountered by the Customer and an amiable settlement, the dispute shall be brought before the courts designated by the General Subscription Conditions.

9.13 Applicable Law The provisions of the Certification Policy are governed by French law. In the event of dispute concerning the interpretation, the formation or performance of this policy, and if an amicable agreement or transaction has not been reached; the parties expressly confer jurisdiction and exclusive to the competent courts of Paris, notwithstanding multiple defendants or summary proceedings or appeal or for precautionary measures. Please note that, certificate policies in English a re for reference purposes and that only the French version is legally binding .

9.14 Compliance with applicable law The CP is subject to the laws, rules, regulations, orders, decrees and national, state, local and foreign orders concerning, but not limited to, the restrictions on import and export of cryptographic software or hardware or further technical information. The laws and regulations are applicable to the CP, including those listed in Chapter 10 below.

9.15 Miscellaneous 9.15.1 The Entire Agreement

Where applicable, the CPS will state the specific requirements.

9.15.2 Assignment Unless specified in other contracts, only the PAC has the right to assign and delegate the CP to a party of its choice.

9.15.3 Divisibility The unenforceability in a given context of a provision of the Certification Policy will not affect the validity of the remaining provisions, or this provision outside of said context. The Certification Policy continues to apply in the absence of this inapplicable provision and by respecting the intention of the aforementioned Certificate Policy. The titles at the top of each Article are only for the convenience of reading and can never be a pretext for any interpretation or distortion of the clauses to which they relate.

9.15.4 Waiver of Rights The requirements defined in the CP / CPS must be applied under the provisions of the CP and the associated CPS with no waiver of rights, with the intent to change any right or required or possible obligation.

9.15.5 Force majeure The CA cannot be held liable for any consequential loss and interruption of its services relating to force majeure, which would have caused direct damage to the End Users.

9.16 Other provisions Where applicable, the CPS will provide the details.




10 REFERENCES The listed documents are the following:

- [CNIL] Law No. 78-17 of 6 January 1978 relating to IT, to files and liberties, as amended by the law of. 2004-801, 6th August 2004;

- [DIRSIG] Directive 1999/93/EC of the European Parliament and Council, 13th December 1999, on a

Community framework for electronic signatures;

- [ORDER] Order No. 2005-1516, 8th December 2005 on electronic exchanges between users and administrative authorities and between the administrative authorities;