Politique de Certification CA LCL certificat RGS - CA

Transcription

Politique de Certification
POLITIQUE DE CERTIFICATION DE L’AC :
CA LCL Certificat RGS Usage Separe
N° page : 1/124
Ref :PC_
Sign_Auth_National_CA_RGS
.pdf
POLITIQUE DE CERTIFICATION
DE L'AC :
CA LCL CERTIFICAT RGS USAGE SEPARE
Crédit Agricole
Cards and Payments
Date : 29/11/2013
____________________________________________________________________________________________________________________________
PC_Sign_Auth_National_CA_RGS v1.1.doc
Page 1 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.
Organisation du document / Documents structures :
Version Française / French version
page 01 à page 65
Version Anglaise / English version
page 66 à page 127
____________________________________________________________________________________________________________________________
Page 2 sur 124
CA&CP. Ce document est la propriété du Credit Agricole Cards and Payments. Son usage est public.
copiste.
Politique de Certification
POLITIQUE DE CERTIFICATION DE L’AC :
CA LCL Certificat RGS Usage Separe
N° page : 3/124
Ref :PC_
Sign_Auth_National_CA_RGS
.pdf
POLITIQUE DE CERTIFICATION : AC
Objet:
Ce document consiste en la politique de certification de l’AC
Numéro de version:
Etat du document:
Rédacteur :
Diffusion:
1.1
Projet
OPENTRUST
Externe
Nombre de pages:
124
Version finale
OPENTRUST
Interne OPENTRUST
Public
Historique:
Date
14/11/2013
25/11/2013
28/11/2013
29/11/2013
01/12/2015
24/02/2016
Version
0.1
0.1
0.1
1.0
1.1
1.1
Rédacteur
EP
EP
EP
EP
EP
EP
Commentaires
Création du document
Relecture
Relecture Interne
Validation
Révision annuelle / corrections mineures
Validation
OPENTRUST
Validé par
GW / EM OPENTRUST
LCL/CA-CP
Les membres du CAP
CA-CP
Les membres du CAP
____________________________________________________________________________________________________________________________
Page 3 sur 124
CA&CP. Ce document est la propriété du Crédit Agricole Cards and Payment. Son usage est public.
copiste.
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 Clé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
2.1
2.2
2.3
2.4
3
ANNUAIRES ET SERVICES DE PUBLICATION _____________________________________________20
Service de publication .............................................................................................................................20
Informations publiées ..............................................................................................................................20
Heure et fréquence de publication .........................................................................................................20
Contrôle d'accès au service de publication ..........................................................................................20
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
____________________________________________________________________________________________________________________________
Page 4 sur 124
copiste.
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.1.2
4.9.2
Origine d'une demande de révocation .................................................................................................29
4.9.2.1
Composante d’IGC ........................................................................................................................29
4.9.2.2
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
____________________________________________________________________________________________________________________________
Page 5 sur 124
copiste.
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
____________________________________________________________________________________________________________________________
Page 6 sur 124
copiste.
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
____________________________________________________________________________________________________________________________
Page 7 sur 124
copiste.
6.6
Contrôles techniques du système pendant son cycle de 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.1.2
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
8.1
8.2
8.3
8.4
8.5
8.6
9
CONTROLES DE CONFORMITE ET AUTRES EVALUATIONS _________________________________53
Fréquence et motifs des audits ..............................................................................................................53
Identité / Qualification des auditeurs .....................................................................................................53
Lien entre l'auditeur et l'entité contrôlée ...............................................................................................53
Points couverts par l'évaluation .............................................................................................................53
Mesures prises en cas de non-conformité ............................................................................................53
Communication des résultats .................................................................................................................53
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 professionnelles ...................................................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
____________________________________________________________________________________________________________________________
Page 8 sur 124
copiste.
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
____________________________________________________________________________________________________________________________
Page 9 sur 124
copiste.
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 ciaprè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".
____________________________________________________________________________________________________________________________
124
Page 10 sur
copiste.
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.
____________________________________________________________________________________________________________________________
124
Page 11 sur
copiste.
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 Test :
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.
____________________________________________________________________________________________________________________________
124
Page 12 sur
copiste.
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
____________________________________________________________________________________________________________________________
124
Page 13 sur
copiste.
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,
____________________________________________________________________________________________________________________________
124
Page 14 sur
copiste.
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 politique
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
responsable
de
l'entité
Adresse mél
Responsable Certification
[email protected]
Adresse courrier
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
____________________________________________________________________________________________________________________________
124
Page 15 sur
copiste.
é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].
____________________________________________________________________________________________________________________________
124
Page 16 sur
copiste.
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").
____________________________________________________________________________________________________________________________
124
Page 17 sur
copiste.
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.
____________________________________________________________________________________________________________________________
124
Page 18 sur
copiste.
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.
____________________________________________________________________________________________________________________________
124
Page 19 sur
copiste.
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 :
.
Les conditions générales d’utilisation :
.
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.
____________________________________________________________________________________________________________________________
124
Page 20 sur
copiste.
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.
____________________________________________________________________________________________________________________________
124
Page 21 sur
copiste.
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
Issuer
Subject
Valeur
Identité de l’AC émettrice.
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> ;
____________________________________________________________________________________________________________________________
124
Page 22 sur
copiste.
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 formes 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 noms 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
____________________________________________________________________________________________________________________________
124
Page 23 sur
copiste.
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 clés en situation normale
____________________________________________________________________________________________________________________________
124
Page 24 sur
copiste.
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 clé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.
____________________________________________________________________________________________________________________________
124
Page 25 sur
copiste.
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.
.
____________________________________________________________________________________________________________________________
124
Page 26 sur
copiste.
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 certificat
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 certificat
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'émission 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
____________________________________________________________________________________________________________________________
124
Page 27 sur
copiste.
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 par 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 certificats 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 nouvelle 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.
____________________________________________________________________________________________________________________________
124
Page 28 sur
copiste.
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.
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.
____________________________________________________________________________________________________________________________
124
Page 29 sur
copiste.
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.
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 :
(*) Aux
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.
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, ...) ;
____________________________________________________________________________________________________________________________
124
Page 30 sur
copiste.
-
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 demande 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 certificats
Sans objet.
4.9.10 Exigences de vérification en ligne de la révocation 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 compromission 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.
____________________________________________________________________________________________________________________________
124
Page 31 sur
copiste.
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.
____________________________________________________________________________________________________________________________
124
Page 32 sur
copiste.
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.
____________________________________________________________________________________________________________________________
124
Page 33 sur
copiste.
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 attributions
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 requises
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.
____________________________________________________________________________________________________________________________
124
Page 34 sur
copiste.
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 formation 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
5.3.7 Exigences vis-à-vis du personnel des prestataires externes
5.3.8 Documentation fournie au personnel
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 :
____________________________________________________________________________________________________________________________
124
Page 35 sur
copiste.
-
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énements
____________________________________________________________________________________________________________________________
124
Page 36 sur
copiste.
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
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
____________________________________________________________________________________________________________________________
124
Page 37 sur
copiste.
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é.
Fin de vie du certificat d'AC
Date au plus tard d'émission d'un certificat
Durée de vie d'un certificat porteur
Durée de vie du certificat d’AC en cours
Temps
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 compromission
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.
____________________________________________________________________________________________________________________________
124
Page 38 sur
copiste.
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.
____________________________________________________________________________________________________________________________
124
Page 39 sur
copiste.
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 ;
____________________________________________________________________________________________________________________________
124
Page 40 sur
copiste.
- 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.
____________________________________________________________________________________________________________________________
124
Page 41 sur
copiste.
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 tierces 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.
____________________________________________________________________________________________________________________________
124
Page 42 sur
copiste.
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 usage" du certificat X 509 V3)
L'utilisation du champ "key usage" dans le certificat porteur et certificat AC est la suivante :
-
-
6.2
AC :
o Key CertSign ;
o Key CRL Sign ;
Porteur :
o Non Repudiation ;
o Digital signature.
Protection des clés privées et normes relatives au module cryptographique
6.2.1 Normes applicables aux ressources cryptographiques 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 personnes
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.
____________________________________________________________________________________________________________________________
124
Page 43 sur
copiste.
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 cryptographique
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
____________________________________________________________________________________________________________________________
124
Page 44 sur
copiste.
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 cryptographiques
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 certificats 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'activation
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.
____________________________________________________________________________________________________________________________
124
Page 45 sur
copiste.
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'activation
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 informatiques
6.5.1 Exigences techniques de sécurité des ressources 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 cycle 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 ;
____________________________________________________________________________________________________________________________
124
Page 46 sur
copiste.
-
-
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 cycle 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.
____________________________________________________________________________________________________________________________
124
Page 47 sur
copiste.
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
Version
Serial number
Issuer DN
Subject DN
NotBefore
NotAfter
Public
Key
signature
Parameters
Algorithm
Valeur
2 (=version 3)
Défini par l’outil
O = CEDICAM
OU= 0002 723001467
CN=AC Racine groupe CREDIT AGRICOLE v2
C = FR
O = CEDICAM
OU= 0002 723001467
CN= CA LCL Certificat RGS Usage Separe
C = FR
YYMMDD000000Z
YYMMDD235959Z + 10 ans
and Sha256WithRSAEncryption (1.2.840.113549.1.1.11)
NULL
Extensions standards
OID
Authority Info Access
(1.3.6.1.5.5.7.1.1)
Inclure Critique Valeur
Authority Key Identifier
{id-ce 35}
X
FALSE
{id-ce 19}
X
TRUE
n/a
Select AKI field
Basic Constraint
Key Identifier
Set
CA
0
Maximum Path Length
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
URI=http://www.cacertificat.com/PC/v2client/AC_racine_CA_V2.pdf
n/a
value
User Notice
OID
n/a
____________________________________________________________________________________________________________________________
124
Page 48 sur
copiste.
value
n/a
noticeRef
n/a
organization
n/a
noticeNumbers
n/a
explicitText
CRL Distribution Points
n/a
{id-ce 31}
X
FALSE
URI=http://crl.cacertificat.com/CREDITAGRICOLE/ACRacineGroupe
CAv2.crl
n/a
distributionPoint
reasons
cRLIssuer
n/a
Extended Key Usage
{id-ce 37}
Issuer Alternative Name
{id-ce 18}
Key Usage
{id-ce 15}
n/a
n/a
X
TRUE
Digital Signature
Clear
Non Repudiation
Clear
Key Encipherment
Clear
Data Encipherment
Clear
Key Agreement
Clear
Key CertSign
Set
Set
Key CRL Sign
Private Key Usage Period
{id-ce 16}
Subject Alternative Name
{id-ce 17}
Subject Key Identifier
{id-ce 14}
n/a
n/a
X
FALSE
Methode 1
Methods of generating key ID
Other Extensions
7.1.1.2
Certificat Porteur
Le certificat porteur est constitué de la manière suivante :
Certificat de base
Version
Serial number
Taille de la clé
Durée de validité
Issuer DN
Subject DN
Valeur
2 (=version 3)
2048
3 ans
O=CEDICAM
OU=0002 723001467
C=FR
C=FR
____________________________________________________________________________________________________________________________
124
Page 49 sur
copiste.
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>
YYMMDDHHMMSSZ
YYMMDDHHMMSSZ +3 ans
Sha256WithRSAEncryption (1.2.840.113549.1.1.11)
NULL
NotBefore
NotAfter
Public Key Algorithm
Parameters
OID
(1.3.6.1.5.5.7.1.1)
{id-ce 35}
n/a
X
FALSE
Select AKI field
Basic Constraint
Key Identifier
{id-ce 19}
X
TRUE
False
CA
n/a
Maximum Path Length
{id-ce 32}
X
FALSE
policyIdentifiers
1.2.250.1.104.3.1.1.1.1.9.1.1
policyQualifiers
n/a
CPSpointer
n/a
OID
URI=http://www.ca-certificatplus.com/PC/09client/Sign_Auth_National_CA_
RGS.pdf
n/a
value
User Notice
OID
n/a
value
n/a
noticeRef
n/a
organization
n/a
noticeNumbers
n/a
explicitText
n/a
{id-ce 31}
distributionPoint
X
FALSE
URI= http://crl.cacertificat.com/CreditAgricoleRGSUsageS
epare/LatestCRL.crl
URI=ldap://ldap.cacertificat.com/cn=CA%20LCL%20Certific
at%20RGS%20
Usage%20Separe,ou=0002%207230014
67,o=CEDICAM?certificaterevocationlist;
binary?base?objectclass=pkiCA
reasons
n/a
____________________________________________________________________________________________________________________________
124
Page 50 sur
copiste.
cRLIssuer
n/a
Extended Key Usage
{id-ce 37}
{id-ce 18}
n/a
n/a
X
FALSE
Rfc822Name
<Email demandeur>
Key Usage
{id-ce 15}
X
TRUE
Digital Signature
Set
Non Repudiation
Set
Key Encipherment
Clear
Data Encipherment
Clear
Key Agreement
Clear
Key CertSign
Clear
Clear
Key CRL Sign
{id-ce 16}
{id-ce 14}
n/a
X
FALSE
Methode 1
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.
____________________________________________________________________________________________________________________________
124
Page 51 sur
copiste.
7.1.6 Syntaxe et Sémantique des qualificateurs de politique
Sans objet.
7.1.7 Interprétation sémantique de l'extension critique "Certificate Policies"
Pas d'exigence formulée.
____________________________________________________________________________________________________________________________
124
Page 52 sur
copiste.
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.cacertificat.com/CreditAgricoleRGSUsageSepare/LatestCRL.crl
Publication LDAP :
URI=ldap://ldap.cacertificat.com/cn=CA%20LCL%20Certificat%20RGS%20Usa
ge%20Separe,ou=0002%20723001467,o=CEDICAM?certific
aterevocationlist;binary?base?objectclass=pkiCA
7.3
Profil OCSP
Sans objet.
____________________________________________________________________________________________________________________________
124
Page 53 sur
copiste.
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 :
-
8.6
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.
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.
____________________________________________________________________________________________________________________________
124
Page 54 sur
copiste.
9
AUTRES DISPOSITIONS COMMERCIALES ET JURIDIQUES
9.1
Tarifs
9.1.1 Tarifs pour l'émission et le renouvellement de 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
9.1.3 Tarifs pour l’accès aux LCR et aux informations 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
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.
____________________________________________________________________________________________________________________________
124
Page 55 sur
copiste.
9.3.2 Informations hors du périmètre des informations 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 informations 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 personnelles
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ées 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'utilisation 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ées personnelles
____________________________________________________________________________________________________________________________
124
Page 56 sur
copiste.
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 :
9.6.2
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.
Obligations et garanties du CAP
____________________________________________________________________________________________________________________________
124
Page 57 sur
copiste.
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 :
____________________________________________________________________________________________________________________________
124
Page 58 sur
copiste.
-
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 :
____________________________________________________________________________________________________________________________
124
Page 59 sur
copiste.
-
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 :
9.6.9
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.
Obligations et garanties des autres participants
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
Les obligations de l’UC sont :
-
Obligations et garanties de l’UC
De valider un certificat porteur à l’aide des informations rendues disponibles par le SP ;
____________________________________________________________________________________________________________________________
124
Page 60 sur
copiste.
-
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.
____________________________________________________________________________________________________________________________
124
Page 61 sur
copiste.
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.
____________________________________________________________________________________________________________________________
124
Page 62 sur
copiste.
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 cidessous.
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
____________________________________________________________________________________________________________________________
124
Page 63 sur
copiste.
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 ;
____________________________________________________________________________________________________________________________
124
Page 64 sur
copiste.
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
CERTIFICATE POLICY
OF THE CA:
CA LCL RGS CERTIFICATE (FRENCH
GENERAL SECURITY GUIDELINES)
SEPARETED USE
Crédit Agricole
Cards and Payments
Date: 29/11/2013
____________________________________________________________________________________________________________________________
Page 65 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.
CE
Page No: 66/124
CERTIFICATE POLICY OF THE CA:
Ref :
PC_
Sign_Auth_National_CA_RGS.
V0.01
CA LCL RGS certificate Separated Use
.
CERTIFICATE POLICY: CA
Purpose:
This document comprises the certificate policy of the CA
Version number:
Document Status:
Drafted by:
Distribution:
1.1
Project
OPENTRUST
External
Number of pages:
124
Final version
OPENTRUST
Internal OPENTRUST
Public
PAC:
Date
14/11/2013
25/11/2013
28/11/2013
29/11/2013
01/12/2015
24/02/2016
Version
0.1
0.1
0.1
1.0
1.1
1.1
Drafted by
EP
EP
EP
EP
EP
EP
Comments
Document creation
Proofreading
PAC Proofreading
Validation
Annual revision / minors changes
Validation
OPENTRUST
Checked by
GW / EM OPENTRUST
LCL/CA-CP
PAC Members
CA-CP
PAC Members
Page 66 of 124
CA&CP. This document is the property of Credit Agricole Cards and Payments. It is in the public domain.
making the copy.
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
2.1
2.2
2.3
2.4
3
DIRECTORIES AND PUBLICATION SERVICES _____________________________________________82
Publication Service ..................................................................................................................................82
Published information..............................................................................................................................82
Time and Frequency of Publication........................................................................................................82
Publishing Service Access Control ........................................................................................................82
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
Page 67 of 124
making the copy.
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 Requests ..............................................................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
4.9.2
The Origin of a Revocation Request ....................................................................................................89
4.9.2.1
PKI Component .............................................................................................................................89
4.9.2.2
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
Page 68 of 124
making the copy.
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 IMPLEMENTATION ____________________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
Page 69 of 124
making the copy.
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 Cryptographic 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
Page 70 of 124
making the copy.
6.5.2
IT Security Rating ..............................................................................................................................106
6.6
Technical controls of the system during its life cycle........................................................................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
8.1
8.2
8.3
8.4
8.5
8.6
9
COMPLIANCE CONTROLS AND OTHER ASSESSMENTS ___________________________________114
Frequency and reasons for audits ........................................................................................................114
Identity / Qualifications of Auditors......................................................................................................114
Connection between the auditor and the assessed entity .................................................................114
Points covered by the assessment ......................................................................................................114
Actions taken in the event of non-compliance ....................................................................................114
Communication of results .....................................................................................................................114
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
Page 71 of 124
making the copy.
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 date 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.
Page 72 of 124
making the copy.
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;
Page 73 of 124
making the copy.
-
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.
Page 74 of 124
making the copy.
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.
Page 75 of 124
making the copy.
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.
Page 76 of 124
making the copy.
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
Certification Manager
[email protected]
Postal address
83, boulevard des Chênes
78280 - GUYANCOURT
Immeuble PROVENCE
1.5.3 Person Determining the Implementation Compliance 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 members are only mentioned in CPS.
Page 77 of 124
making the copy.
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].
Page 78 of 124
making the copy.
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 133351: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*.
Page 79 of 124
making the copy.
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
Page 80 of 124
making the copy.
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;
Page 81 of 124
making the copy.
-
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.
Page 82 of 124
making the copy.
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:
.
General Conditions for Use:
.
-
-
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 AND 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).
Page 83 of 124
making the copy.
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:
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 = 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
Issuer
Subject
Value
Identity of the issuing CA.
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
-
Page 84 of 124
making the copy.
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 Trademarks
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.
Page 85 of 124
making the copy.
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 renewal 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-keying 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 Revocation 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.
Page 86 of 124
making the copy.
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.
Page 87 of 124
making the copy.
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 Applications
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.
Page 88 of 124
making the copy.
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 CA 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 parties
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.
Page 89 of 124
making the copy.
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.
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.
Page 90 of 124
making the copy.
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.
Page 91 of 124
making the copy.
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 revocation 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 parties
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 revoking certificates by the certificate users
See section 4.9.6 above.
4.9.11 Other means of information available on revocations
Not applicable.
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.
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.
Page 92 of 124
making the copy.
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 the 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.
Page 93 of 124
making the copy.
5
PHYSICAL SECURITY MEASURES, PROCEDURES AND IMPLEMENTATION
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.
Page 94 of 124
making the copy.
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 sensitive 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 authorizations
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.
Page 95 of 124
making the copy.
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
5.3.7 Requirements of staff employed by external service providers
5.3.8 Documentation provided to staff
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.).
Page 96 of 124
making the copy.
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
5.4.6
Vulnerability Assessment
Page 97 of 124
making the copy.
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.
Page 98 of 124
making the copy.
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.
Page 99 of 124
making the copy.
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, software 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 affecting 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.
124
Page 100 of
making the copy.
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
124
Page 101 of
making the copy.
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.
124
Page 102 of
making the copy.
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 parties
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.
124
Page 103 of
making the copy.
6.1.6 Production of Public Key Parameters and Quality 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 Certificate "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 to Cryptographic Modules
6.2.1 Standards and security measures for cryptographic 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 trustbased 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.
124
Page 104 of
making the copy.
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 module
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.
124
Page 105 of
making the copy.
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 data
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
124
Page 106 of
making the copy.
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 resources
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 life 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
124
Page 107 of
making the copy.
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 life 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.
124
Page 108 of
making the copy.
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
Version
Serial number
Issuer DN
Subject DN
NotBefore
NotAfter
Public
Key
signature
Parameters
Algorithm
Valeur
2 (=version 3)
O = CEDICAM
OU= 0002 723001467
CN=AC Racine groupe CREDIT AGRICOLE v2
C = FR
O = CEDICAM
OU= 0002 723001467
C = FR
YYMMDD000000Z
YYMMDD235959Z + 10 ans
and Sha256WithRSAEncryption (1.2.840.113549.1.1.11)
NULL
OID
(1.3.6.1.5.5.7.1.1)
{id-ce 35}
X
FALSE
{id-ce 19}
X
TRUE
n/a
Select AKI field
Key Identifier
Basic Constraint
Set
CA
0
Maximum Path Length
{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
URI=http://www.cacertificat.com/PC/v2client/AC_racine_CA_V2.pdf
value
124
Page 109 of
making the copy.
User Notice
n/a
OID
n/a
value
n/a
noticeRef
n/a
organization
n/a
noticeNumbers
n/a
explicitText
n/a
X
{id-ce 31}
FALSE
reasons
URI=http://crl.cacertificat.com/CREDITAGRICOLE/ACRacineGroupe
CAv2.crl
n/a
cRLIssuer
n/a
distributionPoint
Extended Key Usage
{id-ce 37}
n/a
{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
{id-ce 16}
n/a
{id-ce 17}
n/a
{id-ce 14}
X
FALSE
Methode 1
Other Extensions
7.1.1.2
-
End User Certificate
The certificate End User is made up as follows:
Certificat de base
Version
Serial number
Taille de la clé
Durée de validité
Issuer DN
Valeur
2 (=version 3)
2048
3 ans
O=CEDICAM
OU=0002 723001467
124
Page 110 of
making the copy.
C=FR
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>
YYMMDDHHMMSSZ
YYMMDDHHMMSSZ +3 ans
Sha256WithRSAEncryption (1.2.840.113549.1.1.11)
NULL
Subject DN
NotBefore
NotAfter
Public Key Algorithm
Parameters
OID
(1.3.6.1.5.5.7.1.1)
{id-ce 35}
X
FALSE
{id-ce 19}
X
TRUE
n/a
Select AKI field
Key Identifier
Basic Constraint
CA
False
Maximum Path Length
n/a
{id-ce 32}
X
FALSE
policyIdentifiers
1.2.250.1.104.3.1.1.1.1.9.1.1
policyQualifiers
n/a
CPSpointer
n/a
OID
URI=http://www.ca-certificatplus.com/PC/09client/Sign_Auth_National_CA_
RGS.pdf
n/a
value
User Notice
OID
n/a
value
n/a
noticeRef
n/a
organization
n/a
noticeNumbers
n/a
explicitText
n/a
{id-ce 31}
distributionPoint
X
FALSE
URI= http://crl.cacertificat.com/CreditAgricoleRGSUsageS
epare/LatestCRL.crl
URI=ldap://ldap.cacertificat.com/cn=CA%20LCL%20Certific
at%20RGS%20
Usage%20Separe,ou=0002%207230014
67,o=CEDICAM?certificaterevocationlist;
binary?base?objectclass=pkiCA
124
Page 111 of
making the copy.
reasons
n/a
cRLIssuer
n/a
Extended Key Usage
{id-ce 37}
{id-ce 18}
n/a
n/a
X
FALSE
Rfc822Name
<Email demandeur>
Key Usage
{id-ce 15}
X
TRUE
Digital Signature
Set
Non Repudiation
Set
Key Encipherment
Clear
Data Encipherment
Clear
Key Agreement
Clear
Key CertSign
Clear
Clear
Key CRL Sign
{id-ce 16}
{id-ce 14}
n/a
X
FALSE
Methode 1
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
124
Page 112 of
making the copy.
Not applicable.
7.1.7 Semantic interpretation of the critical extension "Certificate Policies"
No requirement formulated.
124
Page 113 of
making the copy.
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;bin
ary?base?objectclass=pkiCA
.
7.3
OCSP Profile
Not applicable.
124
Page 114 of
making the copy.
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:
-
8.6
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.
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.
124
Page 115 of
making the copy.
9
OTHER COMMERCIAL AND LEGAL PROVISIONS
9.1
Rates
9.1.1 Rates for the issuance and renewal of certificates
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 status 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 data
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.
124
Page 116 of
making the copy.
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 confidential 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 protection
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 protection
124
Page 117 of
making the copy.
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:
124
Page 118 of
making the copy.
-
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;
124
Page 119 of
making the copy.
-
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:
124
Page 120 of
making the copy.
-
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:
9.6.9
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.
Obligations and guarantees of other participants
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).
124
Page 121 of
making the copy.
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.
124
Page 122 of
making the copy.
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 validity 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).
124
Page 123 of
making the copy.
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 are 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.
124
Page 124 of
making the copy.
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;
125
Page 125 of
making the copy.

Politique de Certification CA LCL certificat RGS - CA

Transcription

Documents pareils

SASU CARLO ERBA REAGENTS

Certificat - EFI Automotive

Community Shares “RBC for the Community” Raffle 20

Impeto Médical sas Directive 93/42/EEC Directive 93/42/EEC

Attestations – événements spéciaux dans la vie : Baptême

McAfee Firewall Enterprise v8.2.0 and McAfee Firewall Enterprise

CERTIFICAT D`ANALYSE / CERTIFICATE OF ANALYSIS

100 % Natural Latex Foam Sheets

Cork Flooring - eco