Autorit de Certification AC PSA Peugeot Citron...

POLITIQUE DE

CERTIFICATION AC PSA Peugeot Citroën

Programs Partners

Rédacteur: L. SCHREIBER HOMOLOGATION

Autorité de Certification AC PSA Peugeot Citroën

Programs Partners

Politique de Certification Date : 24 octobre 2008 Version : PKI_PC07_V01 Autorité de Certification opérée par le Groupe PSA Peugeot Citroën

Annule et remplace:

Aucun

DSIN / INSI / ISSI

/51

PKI_PC07_V01 USAGE INTERNE

INSI / ISSI

A. BELIGNE

POLITIQUE DE


Programs Partners

/51 USAGE INTERNE PKI_PC07_V01 Date: 24 oct 2008

Historique des modifications Version Date Objet de la modification

01

24/10/2008 Version initiale

POLITIQUE DE


Programs Partners


TABLE DES MATIERES 1 CONTEXTE ................................................................................................................10

1.1 INTRODUCTION ......................................................................................................10 1.2 CONCEPTS ............................................................................................................10

1.2.1 Politique de certification ...................................................................................10 1.2.2 Déclaration des pratiques de certifications ......................................................10 1.2.3 Lien entre PC et DPC ......................................................................................11

1.3 RÔLE DES DIFFÉRENTS ACTEURS DANS LE CADRE DE L’ICP PSA ...............................11 2 ENONCE DE LA POLITIQUE DE CERTIFICATION..................................................12

2.1 INTRODUCTION ......................................................................................................12 2.1.1 Définitions générales .......................................................................................12 2.1.2 Sigles ...............................................................................................................14 2.1.3 Identification.....................................................................................................15 2.1.4 Audience visée.................................................................................................15

2.1.4.1 Autorité de Certification (AC) représentée par l’ASA ................................15 2.1.4.2 Autorité d’Enregistrement .........................................................................15 2.1.4.3 Publication des informations .....................................................................16 2.1.4.4 Composants techniques tiers....................................................................17 2.1.4.5 Parties utilisatrices....................................................................................17 2.1.4.6 Domaine d’application ..............................................................................17

2.1.5 Personnes en charges .....................................................................................18 2.1.5.1 Organisation en charge de la PC..............................................................18 2.1.5.2 Personne en charge de la PC...................................................................18 2.1.5.3 Organisation en charge de la DPC ...........................................................18 2.1.5.4 Personne en charge de la DPC ................................................................18

2.2 DISPOSITIONS GÉNÉRALES .....................................................................................19 2.2.1 Obligations.......................................................................................................19

2.2.1.1 Obligations de l’AC ...................................................................................19 2.2.1.2 Exactitude des représentations.................................................................19 2.2.1.3 Obligations et fonctions de l’ASA..............................................................20 2.2.1.4 Obligation du propriétaire du composant technique tiers ..........................21 2.2.1.5 Obligation de la partie utilisatrice ..............................................................21

2.2.2 Responsabilité .................................................................................................22

POLITIQUE DE


Programs Partners


2.2.2.1 Exigences de moyens...............................................................................22 2.2.2.2 Limites de responsabilité de l’AC..............................................................22 2.2.2.3 Responsabilité de l’ASA............................................................................22

2.2.3 Responsabilité financière.................................................................................23 2.2.4 Interprétation et application..............................................................................23

2.2.4.1 Législation applicable ...............................................................................23 2.2.4.2 Divisibilité, survie, fusion, avis ..................................................................23 2.2.4.3 Procédure de règlement des différents.....................................................23

2.2.5 Frais.................................................................................................................23 2.2.6 Publication et référentiels de publication..........................................................23 2.2.7 Vérification de la conformité.............................................................................24

2.2.7.1 Objet de la vérification de la conformité....................................................24 2.2.7.2 Fréquence de la vérification de la conformité ...........................................24 2.2.7.3 Identité/qualité du vérificateur de l’AC ......................................................24 2.2.7.4 Lien entre le vérificateur et l’AC vérifiée ...................................................24 2.2.7.5 Objets de la vérification.............................................................................24 2.2.7.6 Mesures prises à la suite de la vérification ...............................................24 2.2.7.7 Communication des résultats....................................................................24

2.2.8 Confidentialité de l’information .........................................................................25 2.2.9 Droits de propriété intellectuelle.......................................................................25

3 IDENTIFICATION ET AUTHENTIFICATION .............................................................26

3.1 ENREGISTREMENT INITIAL .......................................................................................26 3.1.1 Types de nom ..................................................................................................26 3.1.2 Les noms doivent être significatifs ...................................................................26 3.1.3 Règles d’interprétation des diverses formes de noms .....................................26 3.1.4 Caractère unique des noms.............................................................................27 3.1.5 Procédure de règlement des différents au sujet des noms ..............................27 3.1.6 Méthode pour prouver la possession de clés privées ......................................27 3.1.7 Authentification de l’identité de l’organisation ..................................................27 3.1.8 Authentification des entités individuelles..........................................................27 3.1.9 Authentification aux fins de renouvellement périodique des clés .....................27

3.2 AUTHENTIFICATION AUX FINS DE RENOUVELLEMENT DES CLÉS APRÈS RÉVOCATION......28 3.3 AUTHENTIFICATION D’UNE DEMANDE DE RÉVOCATION................................................28

4 EXIGENCES OPÉRATIONNELLES ..........................................................................29

POLITIQUE DE


Programs Partners


4.1 DEMANDE DE CERTIFICAT........................................................................................29 4.1.1 Origine de la demande.....................................................................................29 4.1.2 Composition de la demande ............................................................................29 4.1.3 Gestion de la demande....................................................................................29

4.2 ACCEPTATION DU CERTIFICAT .................................................................................29 4.3 ÉMISSION D’UN CERTIFICAT.....................................................................................29 4.4 SUSPENSION ET RÉVOCATION D’UN CERTIFICAT ........................................................30

4.4.1 Motifs de révocation.........................................................................................30 4.4.2 Qui peut demander une révocation ?...............................................................30

4.4.2.1 Révocation du certificat de l’AC ................................................................30 4.4.2.2 Révocation d’un certificat d’ASA...............................................................30 4.4.2.3 Révocation d’un certificat d’un composant technique tiers .......................30

4.4.3 Procédure à suivre pour demander la révocation d’un certificat ......................31 4.4.4 Délai de grâce pour une demande de révocation ............................................31 4.4.5 Circonstances justifiant la suspension .............................................................31 4.4.6 Qui peut demander une suspension ? .............................................................31

4.4.6.1 Suspension d’un certificat d’ASA ..............................................................31 4.4.6.2 Suspension d’un certificat de composant technique tiers .........................31

4.4.7 Procédure à suivre pour demander la suspension d’un certificat.....................32 4.4.8 Limites de la période de suspension................................................................32 4.4.9 Fréquence de publication des LCR..................................................................32 4.4.10 Vérification des LCR – Exigences ................................................................32

4.4.10.1 Révocation/ vérification de l’état en ligne..................................................32 4.4.10.2 Révocation/vérification de l’état en ligne – Exigences ..............................32 4.4.10.3 Autres formes de diffusion des avis de révocation....................................32

4.4.11 Publication des motifs de révocation ou de suspension ...............................33 4.4.12 Exigences spéciales concernant la compromission des clés .......................33

4.5 PROCÉDURES DE VÉRIFICATION DE LA SÉCURITÉ DES SYSTÈMES................................33 4.5.1 Types d’événements consignés.......................................................................33 4.5.2 Traitement des listes de vérification – Fréquence............................................34 4.5.3 Période de conservation des journaux.............................................................34 4.5.4 Protection des journaux ...................................................................................34 4.5.5 Procédures de sauvegarde des journaux ........................................................34 4.5.6 Système de collecte des données de vérification ............................................34

POLITIQUE DE


Programs Partners


4.5.7 Avis à la personne, à l’organisation, à l’application..........................................34 4.5.8 Évaluations de la vulnérabilité..........................................................................34

4.6 ARCHIVAGE ...........................................................................................................35 4.6.1 Archivage - Exigences .....................................................................................35 4.6.2 Archivage des clés et des certificats ................................................................35 4.6.3 Archivage des dossiers....................................................................................35

4.7 RENOUVELLEMENT DES CLÉS ..................................................................................35 4.8 COMPROMISSION ET PLAN ANTI-SINISTRE .................................................................36

4.8.1 Corruption des ressources informatiques, des logiciels et (ou) des données ..36 4.8.2 Révocation du certificat de signature de l’AC ..................................................36 4.8.3 Compromission des clés privées de signature de l’AC ....................................36 4.8.4 Sécurisation d’une installation après une catastrophe naturelle, un sinistre ....36

4.9 FIN DES ACTIVITÉS DE L’AC.....................................................................................37 5 SÉCURITÉ PHYSIQUE ET SÉCURITÉ DES PROCÉDURES ET DU PERSONNEL 38

5.1 MÉCANISMES DE CONTRÔLE DE LA SÉCURITÉ PHYSIQUE DES LIEUX.............................38 5.1.1 Emplacement, construction et accès physique ................................................38 5.1.2 Système électrique et système de conditionnement d’air ................................38 5.1.3 Dégâts causés par l’eau ..................................................................................38 5.1.4 Prévention et protection–incendie....................................................................38 5.1.5 Stockage des supports ....................................................................................39 5.1.6 Mise au rebut du matériel ................................................................................39 5.1.7 Sauvegarde à l’extérieur ..................................................................................39

5.2 MÉCANISMES DE CONTRÔLE DE LA SÉCURITÉ DES PROCÉDURES ................................39 5.2.1 Rôles de confiance ..........................................................................................39

5.2.1.1 Rôles de confiance de l’AC.......................................................................39 5.2.1.2 Rôles de confiance de l’ASA.....................................................................39

5.2.2 Nombre de personnes requises par tâche .......................................................40 5.2.3 Identification et authentification pour chacun des rôles....................................40

5.3 PROCÉDURES DE CONTRÔLE DE LA SÉCURITÉ DU PERSONNEL....................................40 5.3.1 Antécédents, qualités, expérience et exigences d’attestation de sécurité ......40 5.3.2 Procédures de vérification des antécédents ....................................................41 5.3.3 Exigences en matière de formation..................................................................41 5.3.4 Fréquence et exigences de formation..............................................................41 5.3.5 Rotation des emplois .......................................................................................41

POLITIQUE DE


Programs Partners


5.3.6 Sanctions en cas d’actions non autorisées ......................................................41 5.3.7 Contrôle des personnels des entreprises co-contractantes .............................41 5.3.8 Documentation fournie au personnel ...............................................................41

6 MÉCANISMES TECHNIQUES DE SÉCURITÉ..........................................................42

6.1 PRODUCTION ET INSTALLATIONS DES BI-CLÉS ...........................................................42 6.1.1 Production des bi-clés......................................................................................42 6.1.2 Remise des clés privées de confidentialité à l’AC............................................42 6.1.3 Remise de la clé publique d’un composant technique tiers à l’AC...................42 6.1.4 Remise de la clé publique de l’AC aux utilisateurs...........................................42 6.1.5 Tailles des clés asymétriques ..........................................................................42 6.1.6 Production des paramètres des clés publiques................................................42 6.1.7 Vérification de la qualité des paramètres .........................................................43 6.1.8 Production de clés par matériel et (ou) logiciel ................................................43

6.1.8.1 Clé publique de vérification de signature ..................................................43 6.1.8.2 Clé publique de chiffrement ......................................................................43

6.2 PROTECTION DES CLÉS PRIVÉES..............................................................................43 6.2.1 Normes relatives au cryptomodule de l’AC ......................................................43 6.2.2 Contrôle par plusieurs personnes des clés privées de l’AC .............................43 6.2.3 Clés privées en main tierce..............................................................................44 6.2.4 Sauvegarde des clés privées ...........................................................................44

6.2.4.1 Sauvegarde des clés privées de l’AC .......................................................44 6.2.4.2 Sauvegarde des clés privées du composant technique tiers ....................44

6.2.5 Archivage des clés privées ..............................................................................44 6.2.6 Entrée de la clé privée dans le module cryptographique .................................44 6.2.7 Méthode d’activation des clés privées .............................................................44

6.2.7.1 Méthode d’activation des clés privées de l’AC..........................................44 6.2.7.2 Méthode d’activation des clés privées du composant technique tiers.......44 6.2.7.3 Méthode de désactivation des clés privées de l’AC..................................45 6.2.7.4 Méthode de désactivation des clés privées du composant technique tiers 45

6.2.8 Méthode de destruction des clés privées.........................................................45 6.3 AUTRES ASPECTS DE LA GESTION DES BI-CLÉS .........................................................45

6.3.1 Archivage des clés publiques...........................................................................45 6.3.2 Périodes d’utilisation des clés publiques et privées .........................................45

POLITIQUE DE


Programs Partners


6.4 DONNÉES D’ACTIVATION .........................................................................................45 6.4.1 Production et installation des données d’activation..........................................45 6.4.2 Protection des données d’activation ................................................................45 6.4.3 Autres aspects touchant les données d’activation ...........................................45

6.5 MÉCANISMES DE SÉCURITÉ INFORMATIQUE ..............................................................46 6.5.1 Sécurité informatique – Exigences techniques spécifiques .............................46 6.5.2 Indice de sécurité informatique ........................................................................46

6.6 MÉCANISMES DE CONTRÔLE TECHNIQUE DU CYCLE DE VIE DES SYSTÈMES DE L’AC .....46 6.6.1 Mécanismes de contrôle de mise au point des systèmes de l’AC....................46 6.6.2 Mécanismes de contrôle de la gestion et de la sécurité de l’AC ......................46

6.7 MÉCANISMES DE CONTRÔLE DE LA SÉCURITÉ RÉSEAU ...............................................46 6.8 MÉCANISMES DE CONTRÔLE TECHNIQUE DU MODULE CRYPTOGRAPHIQUE...................47

7 PROFILS DES CERTIFICATS ET DES LCR.............................................................48

7.1 PROFIL DES CERTIFICATS........................................................................................48 7.1.1 Numéro de version...........................................................................................48 7.1.2 Champs additionnels du certificat ....................................................................48 7.1.3 Identificateurs des objets algorithmes..............................................................48 7.1.4 Forme des noms ..............................................................................................48 7.1.5 Contraintes touchant les noms.........................................................................48 7.1.6 Politique de certification – Identificateur d’objet (OID) .....................................48 7.1.7 Utilisation du champ additionnel policyConstraints ..........................................48 7.1.8 Syntaxe et sémantique des qualificatifs des politiques ....................................48 7.1.9 Interprétation sémantique des champs critiques de la PC ...............................49

7.2 PROFIL DES LCR ...................................................................................................49 7.2.1 Champs additionnels des LCR et des entrées des LCR ..................................49

8 ADMINISTRATION DES SPÉCIFICATIONS .............................................................50

8.1 PROCÉDURES DE MODIFICATION DES SPÉCIFICATIONS...............................................50 8.1.1 Articles pouvant être modifiés sans avis ..........................................................50 8.1.2 Changement avec avis ....................................................................................50 8.1.3 Liste des articles ..............................................................................................50 8.1.4 Mécanisme de notification ...............................................................................50 8.1.5 Période de commentaires ................................................................................50 8.1.6 Mécanisme de traitement des commentaires ..................................................50 8.1.7 Période pour l’avis final de modification...........................................................50

POLITIQUE DE


Programs Partners


8.1.8 Articles dont la modification nécessite la formulation d’une nouvelle politique 50 8.2 PROCÉDURES DE PUBLICATION ET DE NOTIFICATION..................................................51 8.3 PROCÉDURES D’APPROBATION DE LA DPC...............................................................51

POLITIQUE DE


Programs Partners


1 CONTEXTE

1.1 Introduction Le présent document constitue la Politique de Certification (PC) de l’Autorité de Certification (AC) : AC PSA Peugeot Citroën Programs Partners. Il expose la politique appliquée par le Groupe PSA Peugeot Citroën en qualité d’Autorité de Certification (AC), lors de l’émission, la gestion du cycle de vie et la publication de certificats de classe Programs Partners.

1.2 Concepts

1.2.1 Politique de certification

La politique de certification définit le niveau de confiance que l’on peut accorder à un certificat émis par cette dernière et le type d’applications pour lequel il peut être utilisé. Lorsque l’Autorité de Certification (AC) émet un certificat, elle indique de ce fait à l’utilisateur de ce certificat qu’une clé publique spécifique est associée à une entité spécifique. Divers certificats sont émis selon des pratiques et des procédures différentes, et peuvent convenir à des applications et (ou) à des fins diverses. Une politique est un ensemble précis de règles qui prescrivent l’applicabilité d’un certificat à une communauté et (ou) à une classe d’applications particulières ayant des exigences communes en matière de sécurité. La politique de certification a une forte importance pour établir la confiance à l’égard d’un certificat à clé publique, il est donc primordial que la politique soit bien comprise et soit consultée non seulement par les propriétaires de composants techniques tiers, mais également par les parties utilisatrices. La politique de certification sert de point de départ pour d’éventuelles accréditations des AC. Les politiques de certification servent également à établir une relation de confiance entre des AC (on parle alors de cross-certification). Lors d’un processus de cross-certification entre deux AC, l’AC qui cross-certifie évalue et valide la PC de l’AC cross-certifiée.

1.2.2 Déclaration des pratiques de certifications

Il s’agit d’un énoncé des pratiques utilisées par une Autorité de Certification pour émettre des certificats. C’est donc une description détaillée de l’implantation effective des services offerts et des procédures associés à la gestion du cycle de vie des certificats. Cette Déclaration est plus détaillée que la Politique de Certification.

POLITIQUE DE


Programs Partners


1.2.3 Lien entre PC et DPC

Une PC indique le niveau d’assurance que l’on peut attribuer à un certificat. Une DPC indique la façon dont une AC établit ce niveau d’assurance. Une PC peut s’appliquer à plusieurs AC, tandis qu’une DPC s’applique à une seule AC.

1.3 Rôle des différents acteurs dans le cadre de l’ICP PSA Afin de garantir le fonctionnement d’une autorité de certification, on doit attribuer certains rôles, avec des responsabilités correspondantes. La DPC doit indiquer clairement les personnes qui ont des rôles spécifiques au sein de l’organisation, ainsi que leurs responsabilités respectives. ‘AC PSA Peugeot Citroën Programs Partners’ est une Autorité déléguée de l’AC ‘AC PSA Peugeot Citroën Racine’. L’AC ‘AC PSA Peugeot Citroën Racine’ possède d’autres autorités déléguées. La PC de l’AC ‘AC PSA Peugeot Citroën Racine’ est disponible à l’URL suivant :

Autorité de Certification AC PSA Peugeot Citroën Programs Partners

L’AC ‘AC PSA Peugeot Citroën Programs Partners’ s’organise suivant le schéma suivant :

Valide

Demande Demande Demande

Serveur tiers

Signature de code

tiers

VPN, Wifi, Routeur

tiers

Demande

ASA

Contact PSA

Traite les demandes de certificats

Enregistrent et gèrent les demandes de certificats

Emet et signe les certificats de classe Programs Partners

http://reunis.inetpsa.com/autorite/PC-AC-Racine.pdf

Composant technique du tiers

POLITIQUE DE


Programs Partners


2 ENONCE DE LA POLITIQUE DE CERTIFICATION

2.1 Introduction

2.1.1 Définitions générales

Administrateur de Sécurité Applicatif (ASA) – Personne qui assure la fonction d’enregistrement, pour le compte de l’AC, des composants techniques tiers entrant en relation avec le groupe PSA Peugeot Citroën. Autorité de Certification (AC) - Autorité de confiance reconnue par des parties utilisatrices, qui délivre et gère les certificats de clé publique et des Listes de Certificats Révoqués (LCR ou CRL) conformes à la recommandation X.509. Autorité d’Enregistrement (AE) – Personne ou organisation responsable de l’identification et de l’authentification d’un propriétaire de composants techniques tiers avant l’émission de certificats à son intention, mais qui ne signe, ni n’émet les certificats. Une AE se voit déléguer certaines tâches par l’AC. Bi-clé : un bi-clé est un couple composé d’une clé privée (devant être conservée secrète) et d’une clé publique, nécessaire à la mise en œuvre d’opérations de cryptographie basées sur des algorithmes de chiffrement asymétriques. On peut distinguer trois types de bi-clés :

• Les bi-clés de signature dont la clé privée est utilisée à des fins de signature et la clé publique à des fins de vérification ;

• Les bi-clés de chiffrement (ou de confidentialité) dont la clé publique est utilisée à des fins de chiffrement des données destinées au porteur de certificat et la clé privée à des fins de déchiffrement ;

• Les bi-clés de certification nécessaires au fonctionnement d’une ICP ; Certificat – Passeport numérique comprenant la Clé Publique d’un composant technique tiers, ainsi que certaines autres informations dont l’intégrité et l’infalsifiabilité sont assurées par la signature numérique de l’Autorité de Certification qui l’a délivré. Chaîne de confiance – Ensemble des certificats nécessaires pour valider la généalogie d’un certificat d’un composant technique tiers. Clé (privée) de confidentialité ou de chiffrement – Clé privée du bi-clé de chiffrement Clé (publique) de vérification – Clé publique du bi-clé de signature Dispositif ou application – Matériel ou logiciel pouvant faire usage des certificats pour établir automatiquement un contexte de sécurité qui lui est propre. Par exemple, un serveur web ou un routeur utilisant un certificat pour s’authentifier lors des échanges. Distinguished Name (DN) – Nom distinctif X.500 du composant technique tiers pour lequel le certificat est émis.

POLITIQUE DE


Programs Partners


Données d’activation – Données privées associées à un Porteur de certificat ou un composant technique tiers permettant de mettre en œuvre sa clé privée. Internet Engineering Task Force (IETF) – Organisme pilotant les travaux de spécifications des technologies Internet. Entité – Tout élément autonome au sein de l’ICP, par exemple l’AC, l’AE, les ASA ou une entité finale. Entité finale – Entité qui utilise les clés et les certificats créés au sein de l’ICP à des fins autres que la gestion des clés et des certificats. Il peut s’agir d’un porteur, d’une partie utilisatrice, d’un composant technique ou d’une application. Identificateur d’Objet (OID) – Identificateur alphanumérique unique enregistré conformément à la norme d’enregistrement IANA/AFNOR ou ISO pour désigner un objet ou une classe d’objets spécifiques. Dans le cadre de l’ICP PSA, les identificateurs OID servent à identifier chacune des Politiques de Certification, ainsi que les algorithmes de chiffrement acceptés. Infrastructure à Clé Publique (ICP) – Ensemble des composantes, fonctions et procédures dédiées à la gestion des clés et des certificats utilisés par des services basés sur la cryptographie à clé publique. Intégrité des données – Assurance que les données n’ont pas été modifiées entre leur création, leur réception et leur utilisation. Liste des Certificats Révoqués (LCR ou CRL) – Liste comprenant les numéros de série des certificats ayant fait l’objet d’une révocation et signée par l’AC émettrice. MD5 – Algorithme de hachage élaboré par RSA Data Security Inc. Niveau de confidentialité des informations – Classification PSA • Information classée ‘usage interne’ (C1) : l’information est accessible à l’ensemble du

personnel PSA et aux partenaires autorisés ;

• Information classée ‘confidentiel’ (C2) : L’information est réservée aux personnes, entités, partenaires qui en ont besoin pour agir ;

• Information ‘confidentiel restreint’ (C3) : L’information est réservée aux personnes nommément désignées qui en ont besoin pour agir.

Module cryptographique – Un module cryptographique est un dispositif matériel permettant de protéger les éléments secrets tels que les clés privées ou les données d’activation et de procéder à des calculs cryptographiques mettant en œuvre ces éléments. Partie utilisatrice – Entité finale qui utilise le certificat d’un composant technique tiers, signé par l’AC, en particulier pour s’assurer de son identité, de l’authenticité d’une signature numérique ou du chiffrement des données. Porteur – Personne dont la clé publique est attestée par un certificat de clé publique. Les porteurs peuvent détenir un ou plusieurs certificats émis par une AC à laquelle ils sont associés ; les porteurs pourront posséder deux certificats : un pour leur clé de signature numérique et l’autre pour leur clé de chiffrement (confidentialité)

POLITIQUE DE


Programs Partners


Publication (d’un certificat) - Opération consistant à mettre un certificat à disposition de parties utilisatrices pour leur permettre de vérifier une signature ou de chiffrer des informations. Référentiel – Base de données ou annuaire de publication d’un certificat ou d’une LCR (ex. annuaire LDAP) Renouvellement (d’un certificat) – Opération effectuée à la demande d’un propriétaire de composants techniques tiers ou en fin de période de validité d’un certificat et qui consiste à générer un nouveau certificat pour un composant technique tiers. La re-génération de certificat après révocation n’est pas un renouvellement. Révocation (d’un certificat) – Opération de suppression de la caution de l’AC sur un certificat donné, avant la fin de période de validité. La demande peut être la conséquence de différents types d’événements tels que la compromission d’une clé, le changement d’informations contenues dans un certificat, etc. L’opération de révocation est considérée terminée quand le certificat mis en cause est publié dans la Liste de Certificats Révoqués. Service de recouvrement – Service d’archivage des clés privées de confidentialité. SHA-1 – Algorithme de hachage élaboré pat RSA Data Security Inc. Validation (de certificat) – Opération de contrôle de statut d’un certificat et de la chaîne de confiance associée. Vérification (de certificat) – Opération de contrôle d’une signature numérique.

2.1.2 Sigles

AC Autorité de Certification AE Autorité d’Enregistrement ASA Administrateur de Sécurité Applicatif CN Nom usuel {Common Name} Cx Classe x CSSI Coordination de la Sécurité des Systèmes d’Information DIC Disponibilité / Intégrité / Confidentialité DN Nom distinctif {Distinguished Name} DPC Déclaration des Pratiques de Certification DPGR Direction de la Prévention et de la Gestion du Risque DSIN Direction des Systèmes d’Information ICP Infrastructure à Clé Publique IETF Internet Engineering Task Force INSI Infrastructure des Systèmes d’Information ISSI Infrastructure de Sécurité des Systèmes d’Information LCR Liste des Certificats Révoqués (ou CRL) OID Identificateur d’objet {Objet identifier}

POLITIQUE DE


Programs Partners


PC Politique de Certification PKIX Infrastructure à clé publique (conforme à la norme X.509) PSAid Identifiant PSA SHA-1 Secure Hash Algorithm – One (type d’algorithme) URL Adresse web

2.1.3 Identification

La présente PC est désignée par le nom suivant :

Politique de Certification de l’Autorité de Certification AC PSA Peugeot Citroën Programs

La présente Politique de Certification est identifiée par l’OID suivant : 1.2.250.1.23.10000.1.1.7

2.1.4 Audience visée

La présente Politique de Certification a été élaborée pour l’émission, la gestion du cycle de vie de certificats de classe Programs destinés à des composants techniques tiers en relation avec le Groupe PSA Peugeot Citroën.

2.1.4.1 Autorité de Certification (AC) représentée par l’ASA

L’AC est responsable des certificats signés en son nom et de l’ensemble de l’ICP qu’elle a mise en place. En particulier l’AC assure les fonctions suivantes :

• Mise en application de la PC et des procédures énoncées dans la DPC ;

• Enregistrement ;

• Emission des certificats ;

• Gestion du cycle de vie des certificats ;

• Publication du certificat et de la Liste des Certificats Révoqués (LCR) ;

• Journalisation et archivage des événements et informations relatives au fonctionnement de l’ICP.

L’AC assure ces fonctions directement ou en les sous-traitant, tout ou partie. Dans tous les cas, l’AC en garde la responsabilité.

2.1.4.2 Autorité d’Enregistrement

L’ASA assurera le rôle d’Autorité d’Enregistrement pour les composants techniques tiers pour le compte de l’AC et sera responsable de toutes les tâches qui lui seront assignées par l’AC.

POLITIQUE DE


Programs Partners


• Administration des demandes de certificats o Réception des demandes de certificats o Evaluation de la pertinence d’une demande o Vérification de l’identité du demandeur o Validation d’une demande

• Notification d’émission et de délivrance de certificat

• Administration de la révocation, du renouvellement et de la suspension des certificats

2.1.4.3 Publication des informations

2.1.4.3.1 Publication de la PC

La PC est publiée sous format électronique à l’adresse suivante :

http://reunis.inetpsa.com/autorite/PC-AC-Programs-Partners.pdf

Le certificat indique l’adresse de la version électronique de la présente PC. Une indisponibilité momentanée d’accès ne dispense pas les utilisateurs d’effectuer le contrôle de la PC, en consultant la version imprimée ou électronique disponible sur demande à :

INSI / ISSI [email protected]

2.1.4.3.2 Publication de la DPC

La DPC n’est pas publiée. Elle n’est consultable qu’aux fins de vérification ou accréditation sur demande à PSA Peugeot Citroën :




mailto:[email protected]



POLITIQUE DE


Programs Partners


2.1.4.3.3 Publication de la LCR

La Liste des Certificats Révoqués est publiée sous format électronique aux adresses suivantes :

http://infocert.psa-peugeot-citroen.com/AC-PSA-Peugeot-Citroen-Programs-Partners.crl

ldap://annuaire.inetpsa.com/ou=certificate authorities,o=psa?certificaterevocationlist;binary?sub?(cn=

AC PSA Peugeot Citroen Programs Partners)

2.1.4.4 Composants techniques tiers

Le composant technique tiers est en relation avec un composant technique ou un collaborateur du Groupe PSA Peugeot Citroën. Les certificats de classe Programs Partners PSA Peugeot Citroën seront délivrés à la demande du propriétaire du composant technique tiers et avec l’autorisation d’un ASA assurant le rôle d’Autorité d’Enregistrement (AE). Néanmoins, des certificats pourront être délivrés en masse pour un parc donné.

2.1.4.5 Parties utilisatrices

Une partie utilisatrice est une entité finale qui utilise le certificat d’un composant technique tiers, en particulier pour s’assurer de son identité, de l’authenticité d’une signature numérique ou du chiffrement des données.

2.1.4.6 Domaine d’application

2.1.4.6.1 Domaine d’application

Le domaine d’application définit les applications listées ci-dessous pour lesquelles le certificat émis dans le cadre de la PC associée peut être utilisé :

• Authentification ;

• Chiffrement ;

• Signature électronique ; Les certificats seront utilisés uniquement dans le cadre des activités du Groupe PSA Peugeot Citroën. La responsabilité de leur usage est portée par le propriétaire du composant technique tiers dans les limites des responsabilités définies contractuellement entre le tiers ou son employeur et le Groupe PSA Peugeot Citroën. Le présent domaine pourra être modifié, si nécessaire, dans les conditions de la section 2.1.5.1, pour intégrer toute nouvelle application.

POLITIQUE DE


Programs Partners


2.1.4.6.2 Applications hors domaine

Il s’agit de toute application qui ne figure pas dans le périmètre du domaine d’application. Le Groupe PSA Peugeot Citroën ne saurait être responsable dans le cadre d’une application hors domaine du fait que tout utilisateur a, conformément aux usages en la matière, l’obligation d’identifier et de contrôler la PC en vertu de laquelle, le certificat qu’il utilise, est émis.

2.1.5 Personnes en charges

2.1.5.1 Organisation en charge de la PC

INSI/ISSI au sein du Groupe PSA Peugeot Citroën est responsable de l’élaboration, du suivi et de la modification de la présente PC. A cette fin elle doit mettre en œuvre une organisation dédiée coordonnée par un Responsable de la Certification. Coordonnées de l’Organisation en charge de la PC :

2.1.5.2 Personne en charge de la PC

Coordonnées d’un contact au sein de l’organisation en charge de la PC :


Laurent SCHREIBER [email protected]

2.1.5.3 Organisation en charge de la DPC

INSI/ISSI au sein du Groupe PSA Peugeot Citroën détermine la conformité de la DPC avec la présente PC. Coordonnées de l’Organisation en charge de la DPC :

2.1.5.4 Personne en charge de la DPC

Coordonnées d’un contact au sein de l’organisation en charge de la DPC :

Laurent SCHREIBER [email protected]








POLITIQUE DE


Programs Partners


2.2 Dispositions Générales

2.2.1 Obligations

2.2.1.1 Obligations de l’AC

L’AC a pour obligation de :

• Publier la PC et établir la DPC associée ;

• Mettre en place les mécanismes et procédures permettant de garantir que les AC, les AE, les propriétaires des composants techniques tiers, les personnes responsables des dispositifs et organisations, sont au courant des stipulations de cette politique qui les concernent et qu’ils acceptent de les respecter ;

• Effectuer les contrôles de conformité, en respecter les conclusions et mettre en œuvre les actions nécessaires pour remédier aux non-conformités qu’ils révéleraient.

2.2.1.1.1 Avis d’émission et de révocation des certificats

L’AC doit tenir à disposition du propriétaire du certificat du composant technique tiers la notification de :

• L’émission et délivrance d’un certificat portant le DN du composant technique tiers

• La révocation ou la suspension d’un certificat portant le DN du composant technique tiers

• L’expiration et le renouvellement d’un certificat portant le DN du composant technique tiers

L’AC doit tenir à disposition des parties utilisatrices la notification de :

• Toute émission et délivrance d’un certificat

• Toute révocation ou suspension d’un certificat Afin de remplir ces obligations, l’AC doit mettre en œuvre les moyens les plus appropriés (par ex. annuaires de publication, LCR, etc.) afin de tenir ces informations à disposition des propriétaires des certificats des composants techniques tiers et des parties utilisatrices.

2.2.1.2 Exactitude des représentations

Quand une AC publie un certificat, elle garantit qu’elle a délivré un certificat pour un composant technique tiers et que l’information contenue dans le certificat en question a été vérifiée conformément à la PC.

2.2.1.2.1 Délai entre la demande et l’émission

Il n’est précisé aucun délai entre la réception d’une demande de certificat et la production des clés relatives à l’émission de ce certificat

2.2.1.2.2 Révocation et renouvellement des certificats

POLITIQUE DE


Programs Partners


L’AC doit s’assurer que toutes les procédures relatives à l’expiration, à la révocation et au renouvellement d’un certificat sont conformes aux dispositions de la PC et qu’elles sont expressément mentionnées dans son entente avec le propriétaire du composant technique tiers, et dans tout autre document applicable décrivant les modalités d’utilisation du certificat. L’AC doit s’assurer que les procédures de renouvellement des clés sont conformes à la section 4.7. L’AC doit s’assurer que l’avis de révocation d’un certificat est affiché dans la LCR dans les limites de temps prescrites aux sections 4.4.4 et 4.4.9. L’adresse de la LCR doit figurer dans le certificat.

2.2.1.2.3 Protection des clés privées

L’AC se doit de protéger ses clés privées et ses données d’activation conformément aux articles 4 et 6.

2.2.1.2.4 Restriction quant à l’utilisation de la clé privée de l’AC émettrice

L’AC doit s’assurer que l’utilisation de sa clé privée n’est réservée qu’aux seules fins de signature des certificats des composants techniques tiers et des LCR. L’AC doit s’assurer que les clés privées délivrées à son personnel, pour accéder aux applications de l’AC et les utiliser, sont employées uniquement à cette fin. S’il y a lieu, on remettra au personnel un ensemble de clés et de certificats à des fins autres que celles liées à l’utilisation de l’AC.

2.2.1.3 Obligations et fonctions de l’ASA

2.2.1.3.1 Avis d’émission et de révocation des certificats

L’ASA n’est pas tenu d’informer une partie utilisatrice de l’émission ou de la révocation d’un certificat, ces fonctions et ces obligations incombant à l’AC (publication des certificats et des LCR).

2.2.1.3.2 Exactitude des représentations

Lorsque l’ASA fournit à l’AC de l’information au sujet des composants techniques tiers, il doit certifier à l’AC qu’il a vérifié qu’il existe un lien contractuel entre PSA et le propriétaire du composant technique tiers, conformément aux sections 3 et 4.

2.2.1.3.3 Protection des clés privées de l’ASA

Toute ASA qui remplit la fonction d’AE, doit s’assurer que ses clés privées sont protégées conformément aux sections 5 et 6.

2.2.1.3.4 Restriction quant à l’utilisation des clés privées de l’ASA

Sans objet.

POLITIQUE DE


Programs Partners


2.2.1.4 Obligation du propriétaire du composant technique tiers

L’AC doit s’assurer que le propriétaire du composant technique tiers respecte une politique d’utilisation acceptable qui explique les modalités d’utilisation, y compris les applications et les fins autorisées.

2.2.1.4.1 Exactitude des représentations

Toute information concernant un certificat et devant être soumise par le propriétaire du composant technique tiers à une AC doit être complète et exacte. Le propriétaire du composant technique tiers doit s’assurer de l’exactitude des informations mentionnées dans son certificat et informer son contact PSA en cas d’erreur.

2.2.1.4.2 Protection des clés privées du composant technique tiers

Le propriétaire du composant technique tiers doit protéger les clés privées du composant technique tiers, conformément aux dispositions de la section 6, et prendre toutes les mesures raisonnables pour en éviter la perte, la divulgation, la modification ou l’utilisation non autorisée.

2.2.1.4.3 Restriction quant à l’utilisation des clés privées du composant technique tiers

Le propriétaire du composant technique tiers utilisera ses clés et certificats uniquement aux fins indiquées dans la section 2.1.4.6 de la PC et la DPC associée.

2.2.1.4.4 Avis en cas de compromission des clés privées

Si un propriétaire du composant technique tiers soupçonne la compromission ou la perte de ses clés privées, il doit en aviser sans tarder l’AC émettrice selon les instructions données par celle-ci à la section 4.4

2.2.1.5 Obligation de la partie utilisatrice

La présente politique énonce les droits et obligations d’une partie utilisatrice qui participe à l’ICP PSA.

2.2.1.5.1 Utilisation des certificats à des fins pertinentes

Avant d’utiliser le certificat d’un composant technique tiers, la partie utilisatrice se doit de vérifier que le certificat est utilisé à des fins pertinentes et conformément aux applications autorisées mentionnées dans la présente PC et dans la DPC associée à la section 2.1.4.6.

2.2.1.5.2 Responsabilité de la vérification de la révocation

Avant d’utiliser le certificat d’un composant technique tiers, en fonction des niveaux de vérification et de sécurité exigés, la partie utilisatrice peut en vérifier la validité et/ou le statut, en consultant par exemple, l’annuaire de publication des certificats et/ou la base de révocation. La consultation de la base de révocation implique la vérification, par la partie utilisatrice, de la signature de la LCR par l’AC ainsi que la chaîne de confiance associée.

2.2.1.5.3 Obligation concernant la publication de l’information

POLITIQUE DE


Programs Partners


Les référentiels de publication doivent être accessibles 24h/24h. Les certificats et les LCR doivent être mis à disposition des parties utilisatrices, conformément aux exigences de la section 4.4.9.

2.2.2 Responsabilité

2.2.2.1 Exigences de moyens

Une AC doit s’assurer que ses services de certification, d’émission et de révocation de certificats, de publication des LCR sont conformes à la PC. Elle mettra également tout en œuvre pour garantir que l’ASA et les propriétaires des composants techniques tiers respectent les exigences de la PC et de la DPC lorsqu’ils utilisent les certificats contenant l’OID de cette politique et les clés publiques associées. L’AC est tenue pour responsable des fonctions déléguées à l’ASA dans la mesure où elle s’assure régulièrement du bon respect par celui-ci des procédures décrites dans la PC et dans la DPC. L’administrateur de l’AC est également responsable de l’AE en termes d’installation de matériel et de paramétrage de la machine.

2.2.2.2 Limites de responsabilité de l’AC

L’AC émettrice ne saurait être tenue pour responsable de :

• L’utilisation d’un certificat par une partie utilisatrice autre que les parties citées dans la présente PC et dans la DPC associée à la section 2.1.4.5;

• L’utilisation d’un certificat pour une autre application que les applications définies à la section 2.1.4.6;

• L’utilisation d’un certificat pour un usage autre que celui spécifié dans le champ Keyusage ;

• L’utilisation d’un certificat révoqué ou suspendu ;

• L’utilisation d’un certificat au-delà de sa limite de validité.

2.2.2.3 Responsabilité de l’ASA

L’ASA remplit la fonction d’AE et est responsable en interne de :

• La vérification de l’identité du demandeur de certificat ;

• L’évaluation de la pertinence de la demande, avec les moyens appropriés ;

• L’exactitude des informations fournies à l’AC ;

• La validation de la demande de certificat auprès de l’AC ;

• La notification au propriétaire du composant technique tiers de l’émission et de la délivrance de son certificat

• La mise à disposition au propriétaire du composant technique tiers de l’information concernant l’expiration et le renouvellement de son certificat ;

POLITIQUE DE


Programs Partners


• Le traitement dans les plus brefs délais de toute demande de révocation qui lui est adressée.

2.2.3 Responsabilité financière

Sans objet.

2.2.4 Interprétation et application

2.2.4.1 Législation applicable

La PC est soumise au droit français. La rédaction et l’application de la PC doivent être conformes à la pratique et aux textes législatifs et réglementaires en vigueur. Ainsi la PC sera adaptée si nécessaire, en fonction de toute évolution législative et réglementaire qui pourra avoir un impact sur les conditions d’émission, de gestion de cycle de vie des certificats ou sur les obligations respectives des intervenants. De telles modifications pourront intervenir dans les conditions prévues à la section 2.1.5.1.

2.2.4.2 Divisibilité, survie, fusion, avis

L’AC doit s’assurer que toutes les ententes qu’elle conclut contiennent des dispositions appropriées au sujet de la divisibilité, de la survie, de la fusion ou des avis.

2.2.4.3 Procédure de règlement des différents

La PC s’appliquant exclusivement à la distribution de certificats à des composants techniques tiers et à leur utilisation par des parties appartenant à l’ICP PSA, les différents seront réglés selon les procédures prévues au contrat.

2.2.5 Frais

Sans objet.

2.2.6 Publication et référentiels de publication

L’AC doit :

• Inclure dans tout certificat qu’elle émet l’adresse URL d’un site entretenu par l’AC ou en son nom et contenant notamment la PC ;

• Diffuser sa Politique de Certification, signée numériquement par un représentant autorisé de l’AC, sur un site maintenu par l’AC ou en son nom, et dont l’adresse doit être indiquée conformément à la section 8.2 ;

• S’assurer que les mécanismes de contrôle et d’accès au système d’exploitation des référentiels de publication seront configurés de telle sorte que seul le personnel autorisé de l’AC puisse rédiger ou modifier la version en ligne de la PC ;

• Fournir au besoin la version complète de la DPC, aux fins de vérification, d’inspection, d’accréditation ou de co-certification.

POLITIQUE DE


Programs Partners


2.2.7 Vérification de la conformité

2.2.7.1 Objet de la vérification de la conformité

Une vérification de conformité permet de déterminer si le fonctionnement réel de l’AC correspond de manière effective aux exigences de la PC et aux normes établies dans sa DPC.

2.2.7.2 Fréquence de la vérification de la conformité

Cette vérification est effectuée au minimum tous les deux ans.

2.2.7.3 Identité/qualité du vérificateur de l’AC

Le vérificateur sera une entité habilitée par l’AC.

2.2.7.4 Lien entre le vérificateur et l’AC vérifiée

Le vérificateur ne doit pas être impliqué dans l’administration de l’AC.

2.2.7.5 Objets de la vérification

La vérification de conformité porte notamment sur les points suivants :

• Dispositions générales ;

• Organisation dédiée à la PC et à sa mise à jour ;

• Respect des obligations ;

• Conformité de la DPC à la PC ;

• Confidentialité des informations ;

• Règles d’identification et d’authentification ;

• Règles opérationnelles ;

• Règles d’archivage ;

• Contrôles de sécurité physique, contrôle des procédures, contrôle du personnel ;

• Profils des certificats et des LCR.

2.2.7.6 Mesures prises à la suite de la vérification

A l’issue de la vérification de conformité, l’AC s’engage à mettre en œuvre les moyens nécessaires afin de remédier à ses défaillances dans les plus brefs délais.

2.2.7.7 Communication des résultats

Les résultats des vérifications de conformité ne sont communiqués qu’à l’AC contrôlée. Il lui appartient de transmettre à ses composantes et à l’ASA les résultats les concernant.

POLITIQUE DE


Programs Partners


2.2.8 Confidentialité de l’information

Les certificats et les LCR, ainsi que les informations qui y figurent ne sont pas considérés comme étant de l’information sensible et sont publics. Toute autre information sur un propriétaire d’un composant technique tiers ou sur une organisation détenue par l’AC ou l’ASA (par ex. Données sur l’enregistrement, motifs de révocation, données archivées, événements consignés, correspondance entre le propriétaire du composant technique tiers et l’AC, rapport d’audit, etc.) est classée ‘C3’ PSA.

2.2.9 Droits de propriété intellectuelle

Dans le cadre de la présente PC et de l’émission de certificats, PSA Peugeot Citroën n’entend conférer le transfert d’aucun droit, de quelque nature que ce soit, protégé par le code de la propriété intellectuelle.

POLITIQUE DE


Programs Partners


3 IDENTIFICATION ET AUTHENTIFICATION

3.1 Enregistrement initial

3.1.1 Types de nom

Chaque composant technique tiers doit avoir, dans le champ Subject du certificat, un nom distinctif (DN) X.501 facile à distinguer et unique. Ce nom doit être conforme à la partie 1 de la norme PKIX. Le DN doit être sous la forme d’une chaîne imprimable (printableString) X.501, et ne doit pas être vide. Chaque composant technique tiers peut avoir, en plus de son nom distinctif, un nom de remplacement, en utilisant pour ce faire le champ SubjectAlternateName, lequel doit être conforme à la partie 1 de la norme PKIX. Le champ Subject est composé comme suit :

E = [e-mail] excepté si le composant technique ne le permet pas* CN = ‘[compte technique]’ ou ‘FDQN’ ou ‘[application] - [état**] - [champ libre]’ OU = programs O = psa L = [Ville] S = [Pays] C = [Code pays]

** si aucune adresse mail n’est précisée dans le champ Subject, les notifications d’expiration du certificat ne seront pas délivrées. * ne rien préciser si application en production sinon ‘dev’ ou ‘preprod’ Pour des besoins particuliers le CN pourra avec accord de l’AC prendre une valeur autre que celles précisées ci-dessus.

3.1.2 Les noms doivent être significatifs

Le contenu des champs de nom Subject et Issuer doit avoir un lien explicite avec le composant technique tiers et l’AC authentifiés.

3.1.3 Règles d’interprétation des diverses formes de noms

Sans objet.

POLITIQUE DE


Programs Partners


3.1.4 Caractère unique des noms

Le champ Subject doit permettre d’identifier de façon unique un composant technique tiers.

3.1.5 Procédure de règlement des différents au sujet des noms

Sans objet.

3.1.6 Méthode pour prouver la possession de clés privées

L’AC doit s’assurer de la détention de la clé privée par le propriétaire du composant technique tiers avant de certifier la clé publique.

3.1.7 Authentification de l’identité de l’organisation

Ces certificats ne sont pas destinés à être utilisés par des organisations mais par des porteurs individuels ou des composants techniques.

3.1.8 Authentification des entités individuelles

Une demande de certificat est formulée individuellement par le propriétaire du composant technique tiers auprès d’un contact PSA nominativement identifié. A des fins d’identification, le demandeur doit fournir sur demande de l’ASA une preuve d’appartenance à l’organisation PSA ou à une entité en relation avec le Groupe PSA.

3.1.9 Authentification aux fins de renouvellement périodique des clés

Une demande de renouvellement de clés ne peut-être faite que par l’AC au nom de laquelle les clés ont été émises. Toutes les demandes de renouvellement de clés doivent être authentifiées par l’AC. Si le certificat est expiré, la demande de renouvellement doit être authentifiée de la même façon que pour l’enregistrement initial.

POLITIQUE DE


Programs Partners


3.2 Authentification aux fins de renouvellement des clés après révocation

Si l’information figurant sur un certificat change ou s’il y a suspicion de compromission, de perte ou de vol de la clé privée, l’AC doit authentifier le renouvellement de la clé de la même façon que pour l’enregistrement initial tel que décrit à la section 3.1.8.

3.3 Authentification d’une demande de révocation L’AC ou l’ASA agissant au nom de celle-ci doivent authentifier la demande de révocation d’un certificat. L’AC doit établir et rendre public le mécanisme qu’elle utilise pour traiter ces demandes et en établir la validité. Les demandes de révocation de certificats doivent être consignées. Toute révocation entraîne la mise à jour automatique de la LCR et l’enregistrement des demandes de révocation.

POLITIQUE DE


Programs Partners


4 EXIGENCES OPÉRATIONNELLES

4.1 Demande de certificat L’AC doit s’assurer que toutes les procédures et les exigences concernant une demande de certification sont énoncées dans la DPC.

4.1.1 Origine de la demande

Tout tiers ayant un lien contractuel avec le Groupe PSA et toute personne en relation avec le groupe PSA peut faire une demande de certificat pour un composant technique tiers auprès de son contact PSA nominativement identifié. La mise en œuvre de la délivrance en masse de certificats devra être validée par l’AC.

4.1.2 Composition de la demande

Toute demande sera appuyée par une preuve de l’existence d’un lien contractuel avec le Groupe PSA Peugeot Citroën ou à une organisation rattachée.

4.1.3 Gestion de la demande

A charge de l’ASA de :

• Evaluer la pertinence de la demande

• Valider cette demande

• Initialiser le processus d’émission et de délivrance du certificat

4.2 Acceptation du certificat L’AC définit dans la DPC, la procédure applicable ainsi que les délais à respecter entre la communication du certificat et l’acceptation définitive du certificat par le propriétaire du composant technique tiers. L’acceptation du certificat indique que le demandeur a vérifié la conformité des informations figurant sur ce certificat.

4.3 Émission d’un certificat L’émission d’un certificat par l’AC, indique que celle-ci a définitivement et entièrement approuvé la demande de certificat.

POLITIQUE DE


Programs Partners


4.4 Suspension et révocation d’un certificat

4.4.1 Motifs de révocation

Un certificat doit être révoqué en cas de :

• Non-conformité des informations figurant sur le certificat lors de l’acceptation ;

• Changement d’une information figurant sur le certificat : o Changement de CN

• Non-respect par le propriétaire du composant technique tiers des modalités applicables à l’utilisation du certificat ;

• Destruction du composant technique tiers ;

• Fin de validité du lien contractuel (quel qu’en soit le motif)

• Suspension de certificat excédant 6 mois ;

• Suspicion de compromission, perte ou vol de la clé privée du composant technique tiers ;

• Suspicion de compromission, perte ou vol de la clé privée de l’AC ou d’une de ses composantes ;

• Révocation du certificat de l’AC ;

• Décision motivée par la structure de sécurité. Par ailleurs, si le certificat n’est plus utilisé, celui-ci pourra être révoqué.

4.4.2 Qui peut demander une révocation ?

Toute personne estimant nécessaire la révocation d’un certificat pour un des motifs cités à la section 4.4.1 peut s’adresser aux personnes responsables citées ci-dessous.

4.4.2.1 Révocation du certificat de l’AC

Seule l’AC ‘AC PSA Peugeot Citroën Racine’ est habilitée à révoquer le certificat de l’AC émettrice.

4.4.2.2 Révocation d’un certificat d’ASA

Peuvent demander la révocation d’un certificat d’ASA

• L’AC émettrice ;

• Les acteurs responsables de rang supérieur dans la structure sécurité de PSA ;

• L’ASA lui même

4.4.2.3 Révocation d’un certificat d’un composant technique tiers

Peuvent demander la révocation d’un certificat d’un composant technique tiers :


POLITIQUE DE


Programs Partners



• L’ASA ;

• Le propriétaire du composant technique tiers.

4.4.3 Procédure à suivre pour demander la révocation d’un certificat

L’AC doit s’assurer que toutes les procédures et exigences concernant la révocation du certificat figurent dans la DPC. La demande de révocation d’un certificat est faite auprès de l’AC, de l’ASA ou des acteurs de rang supérieur dans la structure sécurité de PSA. Elle doit contenir explicitement les informations d’identification du certificat et de son propriétaire et en détail, les motifs de révocation. Toute demande de révocation doit être authentifiée, consignée et conservée, ainsi que toutes les mesures prises par l’AC à cet égard.

4.4.4 Délai de grâce pour une demande de révocation

Toute demande de révocation devra être traitée dans les délais les plus brefs. La prise en compte des demandes de révocation se fera au fil de l’eau par les ASA.

4.4.5 Circonstances justifiant la suspension

Les circonstances justifiant la suspension d’un certificat sont les suivantes :

• Décision motivée par la structure de sécurité.

4.4.6 Qui peut demander une suspension ?

4.4.6.1 Suspension d’un certificat d’ASA

Peuvent demander la suspension d’un certificat d’ASA :



• L’ASA lui même.

4.4.6.2 Suspension d’un certificat de composant technique tiers

Peuvent demander la suspension d’un certificat d’un composant technique tiers :



• L’ASA ;

• Le propriétaire du composant technique tiers.

POLITIQUE DE


Programs Partners


4.4.7 Procédure à suivre pour demander la suspension d’un certificat

L’AC doit s’assurer que toutes les procédures et exigences concernant la suspension du certificat figurent dans la DPC. La demande de suspension d’un certificat est faite auprès de l’AC. Elle doit contenir explicitement les informations d’identification du certificat et de son propriétaire et en détail, les motifs de sa suspension Toute demande de suspension doit être authentifiée, consignée et conservée, ainsi que toutes les mesures prises par l’AC à cet égard.

4.4.8 Limites de la période de suspension

Une période de suspension ne devra pas excéder 6 mois. En cas de dépassement de cette limite, le certificat devra être révoqué.

4.4.9 Fréquence de publication des LCR

L’AC doit s’assurer qu’elle publie dans l’annuaire une LCR à jour au moins toutes les 2 heures. L’AC doit également s’assurer que la publication de la LCR est synchronisée avec le point de distribution de la LCR référencée dans les certificats, afin de garantir que les parties utilisatrices auront accès à la LCR la plus récente.

4.4.10 Vérification des LCR – Exigences

La partie utilisatrice peut avant toute utilisation, valider le statut d’un certificat en consultant la LCR. Dans ce cas, la partie utilisatrice doit aussi vérifier l’authenticité et l’intégrité de la LCR (signature numérique) et la chaîne de confiance associée. La LCR est consultable par toute partie utilisatrice 24h/24h, 7j/7j à l’URL précisée à la section 2.1.4.3.3. Une partie utilisatrice est responsable si elle ne procède pas aux vérifications nécessaires

4.4.10.1 Révocation/ vérification de l’état en ligne

Aucune exigence n’est stipulée. La mise en place d’un service de vérification de l’état en ligne dans le cadre d’une application donnée sera préférable à un mode de vérification par téléchargement de la LCR.

4.4.10.2 Révocation/vérification de l’état en ligne – Exigences

Aucune exigence n’est stipulée.

4.4.10.3 Autres formes de diffusion des avis de révocation


POLITIQUE DE


Programs Partners


4.4.11 Publication des motifs de révocation ou de suspension


4.4.12 Exigences spéciales concernant la compromission des clés

En cas de suspicion de compromission, perte ou vol de la clé privée de signature de l’AC, l’AC doit en aviser sans tarder l’AC ‘AC PSA Peugeot Citroën Racine’. En cas de suspicion de compromission, perte ou vol de la clé privée de signature de l’ASA, il doit en aviser sans tarder toutes les AC de l’ICP PSA pour lesquelles il remplit la fonction d’AE. En cas de suspicion de compromission, perte ou vol de la clé de signature d’un composant technique tiers, le propriétaire du composant technique tiers doit en aviser sans tarder l’AC émettrice, soit directement, soit par le biais de son contact PSA.

4.5 Procédures de vérification de la sécurité des systèmes

4.5.1 Types d’événements consignés

L’AC doit consigner dans les registres de vérification tous les événements ayant trait à la sécurité de son système, notamment :

• Démarrage ou arrêt du système ;

• Démarrage et arrêt de l’application AC ;

• Changements des caractéristiques et (ou) des clés de l’AC ;

• Changements des politiques de création des certificats, par ex. période de validité ;

• Tentatives d’ouverture ou de fermeture de session ;

• Génération des clés de l’AC et des clés des entités subalternes ;

• Création et révocation de certificats ;

• Tentatives d’initialiser, d’extraire, de valider et d’invalider des porteurs, de mettre à jour et de récupérer des clés ;

• Opérations non réussies de lecture et d’écriture dans l’annuaire des certificats et des LCR ;

Tous les registres et journaux, qu’ils soient électroniques ou manuels, doivent contenir la date et l’heure de l’événement, prise auprès d’une source de temps suffisamment fiable, et indiquer l’entité en cause. L’AC doit aussi recueillir et colliger, par des moyens électroniques ou manuels, de l’information sur la sécurité qui n’est pas produite par le système de l’AC, notamment :

• Journaux des accès physiques ;

• Maintenance et changements de la configuration du système ;

• Changements apportés au personnel ;

POLITIQUE DE


Programs Partners


• Rapports sur les écarts et compromissions ;

• Registres sur la destruction des supports contenant des clés ou des données d’activation.

L’AC doit s’assurer que la DPC indique le type d’information qu’il faut consigner. Afin de faciliter le processus décisionnel, toutes les ententes et toute la correspondance touchant les services de l’AC doivent être recueillies et consignées, par des moyens électroniques ou manuels, et regroupés en un seul et même endroit.

4.5.2 Traitement des listes de vérification – Fréquence

L’AC doit s’assurer que ses journaux sont revus par son personnel une fois par semaine au minimum, et que tous les éléments importants sont expliqués dans un résumé. A cette fin, on doit notamment vérifier si la liste a été falsifiée, et on doit vérifier brièvement les entrées et, plus en détail, les mises en garde et les irrégularités. On doit comparer les listes manuelles et électroniques connexes de l’AC et de l’ASA si une mesure est suspecte. Il faut documenter les mesures prises à la suite de ces examens.

4.5.3 Période de conservation des journaux

L’AC doit conserver sur place ses journaux pendant au moins deux mois et ensuite les archiver conformément aux exigences des sections 4.6.1 et 4.6.3.

4.5.4 Protection des journaux

Le système des journaux électroniques doit comprendre des mécanismes de protection contre les tentatives non autorisées d’affichage, de modification et de destruction.

4.5.5 Procédures de sauvegarde des journaux

Les journaux et leur résumé doivent être sauvegardés ou copiés s’ils sont sur support papier.

4.5.6 Système de collecte des données de vérification

L’AC doit indiquer dans la DPC quels systèmes elle utilise pour recueillir les données de vérification.

4.5.7 Avis à la personne, à l’organisation, à l’application

Lorsqu’un événement est consigné par le système de collecte des données de vérification, il n’est pas requis d’en aviser la personne, l’organisation, le dispositif ou l’application qui en est la cause.

4.5.8 Évaluations de la vulnérabilité

Les événements qui sont consignés lors de la vérification, sont utilisés en partie, à des fins de contrôle des points vulnérables du système. L’AC doit s’assurer qu’une évaluation de

POLITIQUE DE


Programs Partners


ces points vulnérables est effectuée, revue et révisée. Cette évaluation est effectuée par le RPGR de DSIN.

4.6 Archivage

4.6.1 Archivage - Exigences

Une copie de tout matériel archivé ou sauvegardé doit être entreposée ailleurs que dans les locaux de l’AC, et doit être protégée soit par des mesures de sécurité physique seulement, soit par une combinaison de mesures physiques et cryptographiques. Tout site d’archivage secondaire doit protéger adéquatement le matériel contre les dangers naturels, par exemple les excès de température, d’humidité et de magnétisme. On doit vérifier périodiquement l’intégrité des données entreposées en un lieu autre que les locaux de l’AC.

4.6.2 Archivage des clés et des certificats

Les certificats de signature numérique, les clés privées de confidentialité enregistrées par l’AC, ainsi que les LCR produites par l’AC doivent être archivés pendant au moins cinq ans après l’expiration des clés. Cette exigence ne s’applique pas aux sauvegardes des clés de signature privées. Les clés privées de confidentialité qui sont sauvegardées par l’AC doivent recevoir une protection physique et cryptographique d’un niveau égal ou supérieur à celui offert par le système de l’AC.

4.6.3 Archivage des dossiers

Il faut archiver pendant au moins 1 an les renseignements de vérification des événements décrits à la section 4.5.

4.7 Renouvellement des clés Un propriétaire de composant technique tiers ne peut demander le renouvellement du bi-clé d’un composant technique tiers que dans les deux mois précédant l’expiration du certificat, pourvu que le certificat n’ait pas été révoqué. Le propriétaire du composant technique tiers, l’AC ou le contact PSA du tiers peuvent lancer le processus de renouvellement des clés. Le renouvellement automatique des clés est permis. L’AC doit s’assurer que les détails de ce processus figurent dans la DPC. L’AC ou l’ASA authentifient de nouveau les propriétaires des composants techniques tiers, sans clés valides, de la même façon que lors de l’enregistrement initial. Si le certificat d’un composant technique tiers a été révoqué pour cause de non-conformité, l’AC doit s’assurer que les motifs de non-conformité ont été réglés de manière satisfaisante, avant d’émettre un nouveau certificat.

POLITIQUE DE


Programs Partners


4.8 Compromission et plan anti-sinistre

4.8.1 Corruption des ressources informatiques, des logiciels et (ou) des données

L’AC doit établir des procédures visant à assurer le maintien des activités et décrire, dans ces procédures, les étapes prévues en cas de corruption ou perte de ressources informatiques, de logiciels et (ou) de données.

4.8.2 Révocation du certificat de signature de l’AC

S’il faut révoquer le certificat de signature de l’AC, celle-ci doit immédiatement en aviser :

• L’AC ‘AC PSA Peugeot Citroën Racine’ ;

• L’ASA ;

• Tous les propriétaires de composants techniques tiers ; En outre, l’AC doit :

• Publier le numéro de série du certificat dans la LCR appropriée ;

• Révoquer tous les certificats signés au moyen du certificat de signature révoqué. Après avoir corrigé les problèmes ayant motivé la révocation, l’AC peut :

• Produire un nouveau bi-clé de signature

• Emettre de nouveaux certificats à tous les composants techniques tiers et s’assurer que toutes les LCR sont signées au moyen de la nouvelle clé.

4.8.3 Compromission des clés privées de signature de l’AC

En cas de compromission de la clé privée de signature de l’AC, celle-ci doit, avant de renouveler le certificat au sein de l’ICP PSA :

• Demander la révocation des certificats émis en son nom

• Révoquer tous les certificats émis au moyen de cette clé ;

• Donner les avis appropriés (voir section 4.8.2) Après avoir résolu les problèmes ayant provoqué la compromission des clés, l’AC peut :

• Produire un nouveau bi-clé de signature ;

• Emettre de nouveaux certificats à tous les composants techniques tiers et s’assurer que toutes les LCR sont signées avec la nouvelle clé.

L’AC doit s’assurer que sa DPC et les ententes appropriées contiennent les dispositions décrivant les moyens qui seront utilisés pour aviser les parties intéressées de toute suspicion de compromission.

4.8.4 Sécurisation d’une installation après une catastrophe naturelle, un sinistre

L’AC doit définir dans un plan anti-sinistre les mesures à prendre pour rétablir une installation sécurisée en cas de catastrophe naturelle ou de tout autre type de sinistre.

POLITIQUE DE


Programs Partners


4.9 Fin des activités de l’AC Si l’AC interrompt ses activités, elle doit en aviser les propriétaires de composants techniques tiers et prendre des dispositions pour que les clés et l’information de l’AC continuent d’être archivées. En cas de changements dans la gestion des activités de l’AC, celle-ci doit en aviser tous les propriétaires de composants techniques tiers auxquels elle a émis des certificats. Les archives de l’AC doivent être conservées selon les indications et la période stipulées à la section 4.6.

POLITIQUE DE


Programs Partners


5 SÉCURITÉ PHYSIQUE ET SÉCURITÉ DES PROCÉDURES ET DU PERSONNEL

5.1 Mécanismes de contrôle de la sécurité physique des lieux

5.1.1 Emplacement, construction et accès physique

L’emplacement d’une AC doit :

• Satisfaire au minimum aux exigences d’une zone de sécurité ;

• Etre muni de dispositifs manuels ou électroniques permettant de contrôler en tout temps, les entrées autorisées ;

• S’assurer que l’accès au serveur de l’AC ne peut se faire qu’escorté par une des personnes identifiées sur une liste d’accès ;

• S’assurer que les membres escortés sont surveillés comme il se doit ;

• S’assurer qu’un journal des accès au site est tenu et vérifié périodiquement ;

• S’assurer que tous les supports amovibles et documents papier contenant de l’information sensible en clair sont entreposés dans les contenants sécurisés.

Si un poste de travail d’un ASA est utilisé pour l’attribution de certificats, le poste de travail doit être sécurisé par des modules matériels (hardware) ou logiciels (software). Un identifiant ou un mot de passe ne doivent jamais être consignés. Il faut assurer la sécurité physique de tout poste de travail des propriétaires de composants techniques tiers qui contient des clés privées sur disque dur ou le protéger au moyen d’un dispositif permettant d’en contrôler l’accès. Le propriétaire d’un cryptomodule matériel se doit d’en assurer la sécurité. Dans le cas où le porteur quitte son poste de travail, il se doit d’emporter son cryptomodule avec lui.

5.1.2 Système électrique et système de conditionnement d’air

L’AC doit s’assurer que les installations électriques et de conditionnement d’air sont suffisantes pour le bon fonctionnement du système de l’AC.

5.1.3 Dégâts causés par l’eau

L’AC doit s’assurer que son système est protégé contre les dégâts causés par l’eau.

5.1.4 Prévention et protection–incendie

L’AC doit s’assurer que son système est protégé contre les risques d’incendie.

POLITIQUE DE


Programs Partners


5.1.5 Stockage des supports

L’AC doit s’assurer que les supports de stockage utilisés par son système sont protégés contre un excès de température, d’humidité et de magnétisme et autres variables d’ambiance.

5.1.6 Mise au rebut du matériel

Tous les supports servant au stockage de l’information (par ex. clés, données d’activation aux fichiers de l’AC) doivent être nettoyés ou détruits avant leur mise au rebut.

5.1.7 Sauvegarde à l’extérieur

L’AC doit s’assurer que les installations de sauvegarde à l’extérieur de ses locaux offrent le même niveau de sécurité que ses locaux principaux.

5.2 Mécanismes de contrôle de la sécurité des procédures

5.2.1 Rôles de confiance

5.2.1.1 Rôles de confiance de l’AC

L’AC doit s’assurer que les tâches liées à ses fonctions essentielles sont réparties entre plusieurs personnes afin d’éviter qu’une personne utilise avec malveillance le système de l’AC sans se faire repérer. Chaque utilisateur a accès au système seulement pour les tâches qui lui incombe. L’AC doit prévoir au moins trois rôles distincts pour le personnel de l’ICP, en faisant la distinction entre les tâches suivantes :

• Exploitation quotidienne du système de l’AC ;

• Gestion et vérification des opérations ;

• Gestion des modifications importantes devant être apportées au système, notamment aux politiques, aux procédures et au personnel.

5.2.1.2 Rôles de confiance de l’ASA

L’AC doit s’assurer que les membres du personnel remplissant les fonctions d’AE comprennent les responsabilités qui leur incombent en ce qui touche à l’identification et l’authentification des propriétaires de composants techniques tiers éventuels et qu’ils remplissent les fonctions suivantes :

• Accepter les demandes de certificats, de renouvellement et de révocation des certificats ;

• Vérifier l’identité et les autorisations des requérants ; Les ASA assurent ces fonctions d’enregistrement auprès des propriétaires de composants techniques tiers. Ils sont seuls juges de la pertinence d’une demande de certificat et s’adressent si nécessaire à qui de droit.

POLITIQUE DE


Programs Partners


5.2.2 Nombre de personnes requises par tâche

L’AC doit s’assurer que personne n’a accès aux clés privées d’un composant technique tiers entreposées par l’AC. Au moins deux personnes doivent effectuer les opérations de récupération des clés, en utilisant de préférence des techniques de connaissance réparties (par ex. utilisation de mots de passe). Le contrôle par au moins deux utilisateurs est également requis pour la production de clés de l’AC. Toutes les autres tâches associées aux rôles de l’AC peuvent être effectuées par une même personne. L’AC doit s’assurer que tout processus de vérification qu’elle utilise permet de superviser toutes les activités des personnes qui, au sein de l’AC, détiennent des rôles privilégiés.

5.2.3 Identification et authentification pour chacun des rôles

Tous les membres du personnel de l’AC doivent faire vérifier leur identité et autorisations avant :

• Que leur nom soit ajouté à la liste d’accès à l’emplacement de l’AC

• Que leur nom soit ajouté à la liste d’accès des personnes autorisées à accéder physiquement au système de l’AC ;

• Qu’un certificat leur soit délivré pour accomplir le rôle qui leur est dévolu dans l’AC ; Chacun de ces certificats (à l’exception des certificats de signature de l’AC) :

• Doit-être attribué directement à une personne ;

• Ne doit pas être partagé ;

• Doit être utilisé seulement pour les tâches autorisées pour le rôle assigné, au moyen d’un mécanisme de contrôle.

Les opérations de l’AC doivent être protégées au moyen de divers mécanismes (par ex. Chiffrement et authentification forte par certificat sur carte à puce), lorsque l’accès se fait sur réseau partagé.

5.3 Procédures de contrôle de la sécurité du personnel

5.3.1 Antécédents, qualités, expérience et exigences d’attestation de sécurité

Le recrutement du personnel impliqué dans l’exploitation de l’AC doit faire l’objet d’une procédure de contrôle permettant de valider les compétences professionnelles et l’intégrité des candidats.

POLITIQUE DE


Programs Partners


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

Toutes les vérifications nécessaires des antécédents professionnels du personnel de l’AC doivent être accomplies.

5.3.3 Exigences en matière de formation

L’AC doit s’assurer que l’ASA reçoit une formation adéquate concernant l’utilisation de l’interface d’administration REUNIS-INDICE. L’AC doit s’assurer que tous les membres du personnel qui accomplissent des tâches touchant à l’exploitation de l’AC ou de l’AE ont reçu une formation dans ce qui suit :

• Les principes et mécanismes de sécurité de l’AC et de l’AE ;

• Toutes les versions des logiciels de l’ICP utilisés dans le système de l’AC ;

• Toutes les tâches qu’ils devront accomplir dans le cadre de l’ICP ;

• Le plan anti-sinistre et les procédures de maintien des activités.

5.3.4 Fréquence et exigences de formation

Les exigences décrites à la section 5.3.3 doivent être tenues à jour, afin de refléter les changements apportés au système de l’AC (organisation, outils, procédures). Des cours de formation professionnelle doivent être offerts en fonction des besoins.

5.3.5 Rotation des emplois

Aucune exigence n’est stipulée

5.3.6 Sanctions en cas d’actions non autorisées

Si une personne a réellement fait ou est soupçonnée d’avoir accompli une action non autorisée, dans l’exercice de ses fonctions en rapport avec l’exploitation de l’AC ou de l’AE machine, l’AC peut lui interdire l’accès à son système et faire prendre toutes les sanctions disciplinaires adéquates.

5.3.7 Contrôle des personnels des entreprises co-contractantes

L’AC doit s’assurer que les personnels des entreprises co-contractantes peuvent accéder à ses locaux conformément aux exigences de la section 5.1.1. Les exigences relatives au personnel des entreprises co-contractantes, sont identiques à celles des collaborateurs.

5.3.8 Documentation fournie au personnel

L’AC doit mettre à disposition des membres du personnel de l’AC et de l’AE machine, les Politiques de Certification qu’elle accepte, sa DPC ou des extraits de sa DPC, ainsi que toute loi, toute politique ou contrat qui s’applique au poste qu’ils occupent. Tout le personnel de l’AC doit avoir accès à des manuels complémentaires relatifs à leurs responsabilités. Ces manuels doivent porter sur l’ensemble des procédures en vigueur. On communiquera aux ASA, les extraits de la DPC correspondant à leurs besoins.

POLITIQUE DE


Programs Partners


6 MÉCANISMES TECHNIQUES DE SÉCURITÉ

Le présent chapitre a pour objet de définir les dispositions de gestion des bi-clés de l’AC, du personnel de l’AC, des AE déléguées, et des propriétaires de composants techniques tiers.

6.1 Production et installations des bi-clés

6.1.1 Production des bi-clés

Les bi-clés d’un composant technique tiers doivent être générés sur le composant technique tiers.

6.1.2 Remise des clés privées de confidentialité à l’AC

Les clés privées de confidentialité d’un composant technique tiers peuvent être remises à l’AC afin de permettre leur recouvrement. L’ensemble de la procédure de remise de la clé privée de confidentialité doit être protégé en confidentialité et accompli de façon sécurisée.

6.1.3 Remise de la clé publique d’un composant technique tiers à l’AC

La clé publique du composant technique tiers doit être remise à l’AC sous la forme d’une enveloppe attestant de la possession de la clé privée correspondante. La transmission doit assurer l’intégrité et la confidentialité de bout en bout.

6.1.4 Remise de la clé publique de l’AC aux utilisateurs

La délivrance de la clé publique de l’AC, qui permet aux parties utilisatrices de valider un certificat émis par l’AC, est effectuée par un moyen garantissant l’intégrité et l’authentification de cette clé publique.

6.1.5 Tailles des clés asymétriques

Les bi-clés utilisés sont des clés ayant les caractéristiques suivantes :

• Longueur : 2048 bits pour les clés de l’AC ; 1024 bits pour les clés des autres entités et des composants techniques tiers;

• Algorithme : RSA-MD5 ou SHA1-RSA

6.1.6 Production des paramètres des clés publiques

Le moyen de génération de bi-clé doit utiliser des paramètres respectant les normes internationales de sécurité propre à l’algorithme considéré.

POLITIQUE DE


Programs Partners


6.1.7 Vérification de la qualité des paramètres

Sans objet.

6.1.8 Production de clés par matériel et (ou) logiciel

Les bi-clés de l’AC doivent être produits par un module cryptographique matériel. Les bi-clés des composants techniques tiers peuvent être produits par un module cryptographique logiciel ou matériel.

6.1.8.1 Clé publique de vérification de signature

Les clés publiques de signature de l’AC doivent être les seules clés utilisables pour vérifier la signature des certificats et des LCR et ne servent à aucun autre usage. Le champ KeyUsage du certificat doit être utilisé conformément au profil des certificats et comporter l’une des valeurs suivantes :

• Pour les certificats des composants techniques tiers : digitalSignature et/ou key agrement

• Pour les certificats de l’AC : keyCertSign et/ou CRLSign : la signature de certificat d’autres AC est interdite

6.1.8.2 Clé publique de chiffrement

Une clé publique de chiffrement peut être utilisée pour échanger ou établir une clé de session de confidentialité des données ou pour chiffrer directement les données. Le champ KeyUsage du certificat doit être utilisé conformément au profil des certificats et comporter la valeur suivante :

• KeyEncipherment.

6.2 Protection des clés privées Le propriétaire du composant technique tiers doit protéger les clés privées afin qu’elles ne soient pas divulguées.

6.2.1 Normes relatives au cryptomodule de l’AC

Cf. section 6.8.

6.2.2 Contrôle par plusieurs personnes des clés privées de l’AC

Plusieurs personnes doivent contrôler les opérations de production des clés de l’AC. Les données utilisées pour leur création doivent être partagées par plusieurs personnes. Le partage du secret permettant la génération ou la re-génération de la clé de l’AC doit être fait entre trois personnes minimum.

POLITIQUE DE


Programs Partners


6.2.3 Clés privées en main tierce

Les clés privées de signature ne doivent jamais se retrouver en main tierce, leur recouvrement est donc impossible. En revanche, pour les clés de confidentialité, l’AC assure un service de recouvrement.

6.2.4 Sauvegarde des clés privées

6.2.4.1 Sauvegarde des clés privées de l’AC

La sauvegarde des clés privées de l’AC bénéficie de la même sécurité que la clé privée originale.

6.2.4.2 Sauvegarde des clés privées du composant technique tiers

Un propriétaire de composant technique tiers peut sauvegarder la clé de signature numérique ou de confidentialité. Le cas échéant, les clés sauvegardées doivent être enregistrées sous forme chiffrée et être protégées logiquement et physiquement contre tout accès illicite. Les mesures de protection prises pour la clé sauvegardée doivent être au moins de même niveau que celles prises pour la clé d’origine.

6.2.5 Archivage des clés privées

Voir section 4.6.2.

6.2.6 Entrée de la clé privée dans le module cryptographique

Les clés privées de l’AC sont générées dans un module cryptographique en utilisant des données fixes ou aléatoires. Elles sont conservées chiffrées, n’étant en clair que pour leur utilisation au sein même du module cryptographique. Les clés privées des composants techniques tiers sont générées par un moyen local logiciel ou matériel. S’il s’avère nécessaire pour le service de recouvrement, de transférer une clé privée de confidentialité depuis le poste client vers le module cryptographique de recouvrement, celle-ci sera transmise chiffrée et sera déchiffrée en local et au sein même de la ressource cryptographique de recouvrement. Les clés privées des composants techniques tiers sont autant que possible conservées chiffrées, n’étant en clair qu’au moment requis pour leur utilisation.

6.2.7 Méthode d’activation des clés privées

6.2.7.1 Méthode d’activation des clés privées de l’AC

Le document « Gestion des clés cryptographiques » décrit le cycle de vie des clés de l’AC.

6.2.7.2 Méthode d’activation des clés privées du composant technique tiers

Le composant technique tiers doit être identifié avant que la clé privée ne soit activée. Cette authentification se fait sous forme de données d’activation de type mot de passe.

POLITIQUE DE


Programs Partners


6.2.7.3 Méthode de désactivation des clés privées de l’AC

Le document « Gestion des clés cryptographiques » décrit le cycle de vie des clés de l’AC.

6.2.7.4 Méthode de désactivation des clés privées du composant technique tiers

Après un délai d’inactivité prolongé, la clé privée doit être désactivée.

6.2.8 Méthode de destruction des clés privées

Au moment où une clé privée cesse d’être utilisée, il faut écraser toutes les copies des clés privées dans la mémoire du composant technique tiers et dans l’espace disque partagé, afin de les détruire de manière sûre.

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

6.3.1 Archivage des clés publiques

L’AC émettrice doit archiver toutes les clés de vérification.

6.3.2 Périodes d’utilisation des clés publiques et privées

La période de validité de toutes les clés de 1024 bits est d’au plus deux ans La période de validité de toutes les clés de 2048 bits est d’au plus douze ans

6.4 Données d’activation

6.4.1 Production et installation des données d’activation

Les données d’activation sont aléatoires ou choisies par le propriétaire du composant technique tiers qui prendra soin de les rendre imprévisibles.

6.4.2 Protection des données d’activation

Les données d’activation doivent être protégées en intégrité et en confidentialité.

6.4.3 Autres aspects touchant les données d’activation

L’utilisation d’un mot de passe comme donnée d’activation d’un certificat requiert une longueur d’au moins huit caractères alphanumériques.

POLITIQUE DE


Programs Partners


6.5 Mécanismes de sécurité informatique

6.5.1 Sécurité informatique – Exigences techniques spécifiques

Les systèmes de l’AC doivent offrir les fonctions suivantes :

• Contrôle de l’accès aux services de l’AC ;

• Distinction rigoureuse des tâches ;

• Utilisation de la cryptographie pour assurer la sécurité des informations ;

• Audits assurant l’imputabilité et la connaissance de la nature des actions réalisées ;

• Archivage des historiques et des journaux de vérification de l’AC ;

• Vérification des événements relatifs à la sécurité. Ces fonctions peuvent être fournies par le système d’exploitation ou par une combinaison de fonctions offertes par le système d’exploitation, le système de l’AC et des mécanismes de protection physique.

6.5.2 Indice de sécurité informatique

Sans objet.

6.6 Mécanismes de contrôle technique du cycle de vie des systèmes de l’AC

6.6.1 Mécanismes de contrôle de mise au point des systèmes de l’AC

Le processus de mise au point des systèmes de l’AC doit offrir une documentation suffisante pour permettre à une tierce partie d’évaluer la sécurité des systèmes de l’AC ; ce processus doit reposer sur :

• La vérification de la conformité des processus ;

• Une évaluation suivie de la menace et des risques afin de modifier au besoin le mécanisme de sécurité et de réduire au minimum les risques résiduels.

6.6.2 Mécanismes de contrôle de la gestion et de la sécurité de l’AC

On doit appliquer une méthode formelle de gestion de la configuration pour installer le système de l’AC et en assurer la maintenance suivie.

6.7 Mécanismes de contrôle de la sécurité réseau Le serveur de l’AC doit être protégé contre les attaques provenant de tout réseau ouvert ou d’utilisation générale auquel il est connecté. Une telle protection doit être assurée par

POLITIQUE DE


Programs Partners


l’installation d’un dispositif configuré de façon à permettre la seule utilisation des protocoles et des commandes nécessaires à la bonne marche de l’AC.

6.8 Mécanismes de contrôle technique du module cryptographique Toutes les opérations de production de clés de signature numérique de l’AC, de stockage de ces clés et de signature des certificats doivent se faire dans un module cryptographique matériel validé au minimum au niveau 3 de la norme FIPS 140-1 ou équivalent.

POLITIQUE DE


Programs Partners


7 PROFILS DES CERTIFICATS ET DES LCR

7.1 Profil des certificats

7.1.1 Numéro de version

Les certificats émis par l’AC doivent-être conformes à la version 3 de la norme X.509.

7.1.2 Champs additionnels du certificat

Le logiciel de l’ICP doit traiter correctement les champs additionnels identifiés dans la sous section 4.2 de la norme PKIX X.509 Certificate and CRL. Les extensions permettent d’ajouter des informations sur le composant technique tiers, l’AC émettrice, l’usage du certificat et sur les LCR.

7.1.3 Identificateurs des objets algorithmes

Les identificateurs d’algorithmes doivent être inscrits auprès d’un registre (par exemple un registre international tel que celui de l’ISO).

7.1.4 Forme des noms

Tous les DN doivent être sous forme d’une chaîne imprimable X.501 (printableString)

7.1.5 Contraintes touchant les noms

Les DN inscrits dans les champs Subject et Issuer doivent être conformes aux normes PKIX et figurer dans tous les certificats.

7.1.6 Politique de certification – Identificateur d’objet (OID)

L’AC doit s’assurer que l’OID de la politique est contenu dans les certificats qu’elle délivre.

1.2.250.1.23.10000.1.1.7

7.1.7 Utilisation du champ additionnel policyConstraints

Sans objet.

7.1.8 Syntaxe et sémantique des qualificatifs des politiques


POLITIQUE DE


Programs Partners


7.1.9 Interprétation sémantique des champs critiques de la PC

Les champs additionnels critiques seront interprétés selon le document de l’IETF : PKIX X.509 Certificate and CRL.

7.2 Profil des LCR Les LCR doivent contenir les champs de base tels que spécifiés dans la version 2 de la recommandation X .509 CRL.

7.2.1 Champs additionnels des LCR et des entrées des LCR

Tous les logiciels de l’ICP doivent traiter adéquatement tous les champs additionnels des LCR indiqués dans le profil des LCR et des certificats PKIX.

POLITIQUE DE


Programs Partners


8 ADMINISTRATION DES SPÉCIFICATIONS

8.1 Procédures de modification des spécifications

8.1.1 Articles pouvant être modifiés sans avis

Aucun.

8.1.2 Changement avec avis

Avant de modifier cette PC, l’organisation en charge de la PC avisera l’AC Racine.

8.1.3 Liste des articles

Tous les articles de la présente PC sont assujettis à l’exigence concernant les avis.

8.1.4 Mécanisme de notification

L’organisation en charge de la PC avisera l’AC ‘AC PSA Peugeot Citroën Racine’ au sujet de toute modification proposée au sujet de cette PC. L’avis doit énoncer les modifications proposées, la date finale de réception des commentaires, ainsi que la date proposée d’entrée en vigueur des modifications.

8.1.5 Période de commentaires

La période pour présenter des commentaires sera de 15 jours, à moins d’avis contraire, et sera précisée dans l’avis.

8.1.6 Mécanisme de traitement des commentaires

Les commentaires portant sur les changements proposés doivent être signés et adressés à l’organisation en charge de la PC. Les décisions concernant les modifications proposées sont laissées à la discrétion de l’organisation en charge de la PC.

8.1.7 Période pour l’avis final de modification

L’organisation en charge de la PC déterminera la période d’avis définitif de modification.

8.1.8 Articles dont la modification nécessite la formulation d’une nouvelle politique

Si l’organisation en charge de la PC est d’avis qu’une modification justifie l’élaboration d’une nouvelle politique, elle peut assigner un nouvel identificateur d’objet (OID) à la nouvelle politique.

POLITIQUE DE


Programs Partners


8.2 Procédures de publication et de notification Ce document est disponible en version électronique, signé numériquement par un représentant autorisé de l’AC :

• Sur le site Réunis, à l’adresse URL :


• Sur demande en écrivant à l’adresse e-mail :


8.3 Procédures d’approbation de la DPC L’AC est garante de l’adéquation de la DPC avec la présente PC. Si la DPC contient des informations touchant à la sécurité de l’AC ou des informations qu’elle considère confidentielles, la publication de la DPC n’est pas requise. Il est possible de diffuser un résumé ou des extraits de la DPC sous forme électronique.





Autorit de Certification AC PSA Peugeot Citron...

Documents

Transcript of Autorit de Certification AC PSA Peugeot Citron...