IGC DE THALES DECLARATION DES PRATIQUES DE …crl.thalesgroup.com/certification_policy/A4284000-DOC-068-DPC-V2.0.… · Documents de référence ... IGC de Thales – Déclaration

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

IGC DE THALES

DECLARATION DES PRATIQUES DE CERTIFICATION DES AC

DELEGUEES : THALES CLASS 3 CA V2

THALES CLASS 3 EXTERNAL CA V2

DATE DE PUBLICATION : Août 05

DATE D’APPLICABILITE : Août 05

IGC de Thales – Déclaration des Pratiques de Certification des AC déléguées : Thales Class 3 CA V2 et Thales Class 3 External CA V2

A4284000-DOC-068-DPC-V2.0.doc 10/06/2009 Page 3 © Thales S.A – Tous droits réservés

INDEXATION DU DOCUMENT

PROJECT:

TITRE: IGC de Thales - Déclaration des Pratiques de Certification des AC déléguées : Thales Class 3 CA V2 et Thales Class 3 External CA V2

REFERENCE: A4284000-DOC-068-DPC

MOTS CLES: IGC de Thales

RESUME D’AUTEUR La Déclaration des Pratiques de Certification AC déléguées est une description détaillée de l’implantation effective des services offerts et des procédures qui sont associées à la gestion du cycle de vie des certificats émis par les Autorités de Certification déléguées de Thales S.A : Thales Class 3 CA V2 et Thales Class 3 External CA V2.

ACTION NOM DATE SIGNATURE

REDIGE PAR Christel Réman APPROUVE PAR Claude-Luce Imbaud / Paul Dias / Sandrine

Paulic / Christel Réman / Patrick Anglard

SUIVI DU DOCUMENT

INDICE DATE MODIFICATIONS NOM V0.1 03/02/05 Création Christel Réman

V0.2 18/02/05 Mise à jour mineure Claude-Luce Imbaud V0.3 28/02/05 Version draft livrée Christel Réman V0.4 11/03/05 Mise à jour pour tenir

compte des remarques : - Internes (CLI et MSS) - Issues du GT du 15/03/2005

Claude-Luce Imbaud Christel Réman

V0.5 07/04/05 Modifications pour mise en conformité avec la PC v0.5

Christel Réman

V0.6 02/05/05 Modifications pour mise en conformité avec la PC v1.0

Christel Réman

V0.7 05/06/05 Modifications à l’issue de la relecture par les équipes MSS

Claude-Luce Imbaud

V1.0 22/07/05 Version majeure Claude-Luce Imbaud V2.0 10/06/09 Modification Laurent Broussy



Sommaire

Documents de référence............................. .................................................................... 9

1 Domaine d’application.............................. ....................................................... 12 1.1 Présentation générale .......................................................................... 12

1.1.1 Aperçu général ................................................................................... 12 1.1.2 Aperçu de la Déclaration des Pratiques de Certification.................... 12

1.2 Définitions générales............................................................................ 14 1.2.1 Définitions........................................................................................... 14

1.3 Liste des acronymes ............................................................................ 18 1.4 Identification (OID) ............................................................................... 20 1.5 Applications et groupe d’utilisateurs concernés.................................... 20

1.5.1 Applications concernées .................................................................... 21 1.5.2 Groupes d’utilisateurs concernés....................................................... 21 1.5.3 Applicabilité de la Déclaration des Pratiques de Certification............ 23

2 Dispositions de portée générale.................... ................................................. 24 2.1 Obligations........................................................................................... 24

2.1.1 Obligations communes à plusieurs composantes.............................. 24 2.1.2 Obligations de l’AC............................................................................. 24 2.1.3 Obligations de l’AE, l’AEL, l’AEO et l’AD............................................ 24 2.1.4 Obligations de l’Abonné ..................................................................... 24 2.1.5 Obligations des Utilisateurs de Certificats.......................................... 24

2.2 Responsabilité ..................................................................................... 24 2.2.1 Exigences de moyens ........................................................................ 24 2.2.2 Limites de la responsabilité ................................................................ 25 2.2.3 Autres modalités................................................................................. 25

2.3 Interprétation et application .................................................................. 25 2.3.1 Droit applicable................................................................................... 25 2.3.2 Règlement des différends .................................................................. 25

2.4 Barêmes de prix................................................................................... 25 2.5 Publication et services associés........................................................... 25

2.5.1 Informations publiées ......................................................................... 25 2.5.2 Fréquence de publication ................................................................... 27 2.5.3 Contrôle de l’accès............................................................................. 28 2.5.4 Service de publication ........................................................................ 28

2.6 Contrôle de conformité......................................................................... 28 2.6.1 Fréquence d’audit de conformité........................................................ 28 2.6.2 Identité / qualité de l’auditeur ............................................................. 28 2.6.3 Lien entre l’auditeur et la fonction vérifiée.......................................... 28 2.6.4 Objet de l’audit ................................................................................... 28 2.6.5 Mesures à prendre à la suite de l’audit .............................................. 28 2.6.6 Communication des résultats............................................................. 29

2.7 Politique de confidentialité.................................................................... 29 2.7.1 Types d’informations considérées comme confidentielles................. 29 2.7.2 Types d’informations considérées comme non confidentielles.......... 30 2.7.3 Divulgation des causes de révocation de certificat ............................ 30 2.7.4 Délivrance aux autorités légales ........................................................ 31



2.7.5 Délivrance à la demande du propriétaire ........................................... 31 2.7.6 Autres circonstances de délivrance possible ..................................... 31

2.8 Droits relatifs à la propriété intellectuelle .............................................. 32

3 Identification et authentification................. .................................................... 33 3.1 Enregistrement initial............................................................................ 33

3.1.1 Conventions de noms......................................................................... 33 3.1.2 Nécessité d’utilisation de noms explicites .......................................... 33 3.1.3 Règles d’interprétation des différentes formes de noms.................... 33 3.1.4 Unicité des noms................................................................................ 34 3.1.5 Procédure de résolution de litige sur la déclaration de nom.............. 34 3.1.6 Reconnaissance, authentification et rôle des noms de marques de

fabrique, de commerce et de services ............................................... 34 3.1.7 Preuve de possession d’une clé privée.............................................. 34 3.1.8 Vérification de l’identité de l’Organistation ......................................... 34 3.1.9 Vérification de l’identité d’une AC ou d’une composante................... 34 3.1.10 Vérification de l’identité des Abonnés ................................................ 35

3.2 Re-génération de certificat en fin de validité......................................... 36 3.3 Re-génération de clés après révocation ............................................... 37 3.4 Demande de révocation ....................................................................... 37

4 Exigences opérationnelles.......................... .................................................... 39 4.1 Demande de certificat .......................................................................... 39 4.2 Emission de certificat ........................................................................... 41 4.3 Acceptation de certificat ....................................................................... 43 4.4 Suspension, révocation et recouvrement de certificat .......................... 44

4.4.1 Causes possibles de révocation ........................................................ 44 4.4.2 Personnes pouvant demander une révocation .................................. 44 4.4.3 Procédure de demande de révocation ............................................... 45 4.4.4 Temps de traitement d’une demande de révocation.......................... 47 4.4.5 Causes possibles de suspension....................................................... 47 4.4.6 Personnes pouvant demander une suspension................................. 47 4.4.7 Procédure de demande de suspension ............................................. 47 4.4.8 Limites de la période de suspension.................................................. 47 4.4.9 Fréquence de publication des CRL.................................................... 47 4.4.10 Exigences de vérification des CRL .................................................... 48 4.4.11 Publication des causes de révocation................................................ 48 4.4.12 Vérification en ligne de la révocation ................................................. 48 4.4.13 Autres formes de publication des avis de révocation......................... 49 4.4.14 Autres formes de publication des avis de révocation – exigences

de vérification ..................................................................................... 49 4.4.15 Exigences spéciales en cas de révocation pour compromission des

clés ..................................................................................................... 49 4.4.16 Causes possibles de recouvrement ................................................... 49 4.4.17 Personnes pouvant demander un recouvrement............................... 49 4.4.18 Procédure de demande de recouvrement.......................................... 49 4.4.19 Temps de traitement d’une demande de recouvrement .................... 50

4.5 Journalisation des évènements............................................................ 50 4.5.1 Types d’évènements enregistrés ....................................................... 50 4.5.2 Fréquence des traitements de journalisation ..................................... 51 4.5.3 Durée de conservation des journaux d’évènements.......................... 51



4.5.4 Protection d’un journal d’évènements ................................................ 51 4.5.5 Copie de sauvegarde des journaux d’évènements............................ 51 4.5.6 Système de collecte des journaux (interne ou externe)..................... 52 4.5.7 Imputabilité des évènements ............................................................. 52 4.5.8 Analyse des vulnaribilités ................................................................... 52

4.6 Archives des dossiers .......................................................................... 52 4.6.1 Types de données à archiver............................................................. 52 4.6.2 Période de rétention des archives...................................................... 53 4.6.3 Protection des archives ...................................................................... 55 4.6.4 Procédures de copie des archives ..................................................... 55 4.6.5 Besoins d’horodatage des enregistrements....................................... 55 4.6.6 Système de collecte des archives (interne ou externe) ..................... 56 4.6.7 Procédures de récupération des archives.......................................... 56

4.7 Changement de clé d’une composante ................................................ 56 4.8 Récupération en cas de désastre ou de compromission ...................... 57

4.8.1 Corruption des ressources informatiques, des logiciels et / ou des données.............................................................................................. 57

4.8.2 Révocation de la clé publique d’une composante.............................. 57 4.8.3 Compromission des clés de la composante....................................... 57 4.8.4 Mesure de sécurité an cas de sinistre................................................ 58

4.9 Cessation d’activité d’une composante ................................................ 58

5 Contrôle de sécurité physique, contrôle des procédu res, contrôle du personnel.......................................................................................................................... 59 5.1 Contrôles physiques............................................................................. 59

5.1.1 Situation géographique et construction de sites ................................ 59 5.1.2 Accès physique .................................................................................. 59 5.1.3 Energie et air conditionné................................................................... 59 5.1.4 Exposition aux liquides....................................................................... 59 5.1.5 Prévention et protection incendie....................................................... 59 5.1.6 Conservation des médias................................................................... 59 5.1.7 Destruction des déchêts..................................................................... 59 5.1.8 Site de recouvrement ......................................................................... 60

5.2 Contrôle des procédures...................................................................... 60 5.2.1 Rôles de confiance............................................................................. 60 5.2.2 Nombre de personnes nécessaires à chaque tâche.......................... 60 5.2.3 Identification et authentification des rôles .......................................... 61

5.3 Contrôle du personnel.......................................................................... 61 5.3.1 Passé professionnel, qualifications, exigences d’habilitations........... 61 5.3.2 Procédures de contrôle du passé professionel .................................. 61 5.3.3 Exigences de formation...................................................................... 61 5.3.4 Fréquence des formations.................................................................. 61 5.3.5 Gestion des métiers ........................................................................... 61 5.3.6 Sanctions pour des actions non autorisées ....................................... 61 5.3.7 Contrôle des personnels des entité possédant un BE ....................... 62 5.3.8 Contrôle des personnels des entreprises contractantes.................... 62 5.3.9 Documentation fournie au personnel ................................................. 62

6 Contrôles techniques de sécurité ................... ............................................... 63 6.1 Génération et installation des clés........................................................ 63

6.1.1 Génération des clés ........................................................................... 63



6.1.2 Délivrance de clé privée à son propriétaire........................................ 63 6.1.3 Délivrance de clé publique à une AC ................................................. 64 6.1.4 Tailles des clés................................................................................... 64 6.1.5 Paramètres de génération des clés publiques................................... 65 6.1.6 Contrôle de qualité des paramètres de clés publiques ...................... 65 6.1.7 Mode de génération de clé (matérielle ou logicielle).......................... 65 6.1.8 Usage de la clé privée........................................................................ 65

6.2 Protection de la clé privée.................................................................... 66 6.2.1 Normes pour les modules cryptographiques...................................... 66 6.2.2 Contrôle de clé privée par plusieurs personnes................................. 67 6.2.3 Récupération de clé privée................................................................. 67 6.2.4 Sauvegarde de clé privée................................................................... 67 6.2.5 Initialisation de clé privée dans le module cryprographique .............. 68 6.2.6 Méthode d’activation de clé privée..................................................... 68 6.2.7 Méthode de désactivation de clé privée............................................. 68 6.2.8 Méthode de destruction de clé privée ................................................ 69

6.3 Autres aspects de la gestion des paires de clés................................... 69 6.3.1 Archive des clés publiques................................................................. 69 6.3.2 Durée de vie des clé publiques et privées ......................................... 69

6.4 Données d’activation............................................................................ 70 6.4.1 Génération et installation des données d’activation........................... 70 6.4.2 Protection des données d’activation .................................................. 70 6.4.3 Autres aspects des données d’activation........................................... 71

6.5 Contrôles de sécurité des postes de travail .......................................... 72 6.5.1 Exigences de sécurité spécifiques sur les postes de travail .............. 72 6.5.2 Niveau de sécurité postes de travail .................................................. 72

6.6 Contrôles techniques du système durant son cycle de vie ................... 73 6.6.1 Contrôles des développements des systèmes................................... 73 6.6.2 Contrôles de la gestion de la sécurité ................................................ 73

6.7 Contrôles de la sécurité réseau............................................................ 73 6.8 Contrôles de la gestion du module cryptographique............................. 73

7 Profils de certificats et de CRL................... .................................................... 74 7.1 Profil des certificats .............................................................................. 74

7.1.1 Numéro de version ............................................................................. 75 7.1.2 Extensions du certificat ...................................................................... 75 7.1.3 Identificateurs des objets algorithmes................................................ 78 7.1.4 Format des noms ............................................................................... 78 7.1.5 Contraintes relatives aux noms.......................................................... 79 7.1.6 Identificateur d’objet de la politique de certification ........................... 79 7.1.7 Usage d’extension de contraintes de politique .................................. 79 7.1.8 Syntaxe et sémantique des qualificatifs de politique ......................... 79 7.1.9 Sémantique de traitement pour l’extension critique de la politique

de certification .................................................................................... 79 7.2 Profil de CRL........................................................................................ 79

7.2.1 Numéro de version ............................................................................. 80 7.2.2 Extension des CRL............................................................................. 80

8 Administration des spécifications.................. ................................................ 82 8.1 Procédures de modification de la DPC................................................. 82

8.1.1 Articles pouvant être modifiés sans avis ............................................ 82



8.1.2 Changement avec avis....................................................................... 82 8.2 Procédures de publication et de notification ......................................... 83 8.3 Procédures d’approbation de la DPC ................................................... 83



Documents de référence

Index local Titre Référence

Documentation CASIC V2

[1] IGC de Thales - Politique de Certification AC Racine : Thales Root CA

[PCACR_CASIC]

[2] IGC de Thales - Politique de Certification des AC déléguées : Thales Class 3 CA V2 et Thales Class 3 External CA V2

[PCAC_CASIC]

[3] IGC de Thales - Déclaration des Pratiques de Certification AC Racine : Thales Root CA

[DPCACR_CASIC]

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

Textes réglementaires

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

[10181-1]

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

[2382-8]

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

[7498-2]

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

[8825-1]

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

[9594-1]

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

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

[9594-8]

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

[CERTIFICAT_IGC]

[12] Décret 98-102 du 24 Février 1998 précisant l’article [L90-1170] relatif aux conditions dans lesquelles sont agréés les organismes gérant pour le compte d’autrui les conventions

[D98-102]




secrètes de cryptologie.

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

[DECOUPAGE_IGC]

[14] Directive 1993/93/CE du Parlement européen et du Conseil du 13 décembre 1999 sur un cadre communautaire pour les signatures électroniques – (JOCE du 19 janvier 2000).

[DSE]

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

[DUE]

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

[GOC]

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

[IGI1300]

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

[IGI900]

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

[L00-230]

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

[L78-19]

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

[PP_AC]

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

[PP_AE]

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

[PP_IGC]

[24] Profil de protection sur les outils de sécurisation de message version 1.5 du 24 juin 1998 (PP/9804) – Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de la

[PP_OSM]




CISSI. Disponible sur demande à l’adresse donnée au chapitre 1.5.

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

[PP_RCIGC]

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

[R901]

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

[RFC 2459]

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

[RFC 2527]

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

[ROLES_IGC]

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

[DEC]

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

[LCEN]



1 Domaine d’application

Une Déclaration des Pratiques de Certification (DPC) a pour objet de décrire les moyens, les méthodes et les procédures mis en oeuvre afin de garantir que les objectifs de sécurité spécifiés dans la Politique de Certification de référence seront effectivement atteints. C’est principalement un énoncé des procédures d’exploitation de l’Autorité de Certification.

Il est important de s’assurer que les mesures de sécurité retenues dans la DPC couvrent l’ensemble des objectifs de sécurité formulés dans la Politique de Certification de référence.

1.1 Présentation générale

1.1.1 Aperçu général

La Déclaration des Pratiques de Certification (DPC) définie dans le présent document définit les procédures et moyens à mettre en place pour répondre aux objectifs de sécurité décrits dans la Politique de Certification (PC) référencée « IGC de Thales - Politique de Certification des AC déléguées : Thales Class 3 CA V2 et Thales Class 3 External CA V2 » et identifiée dans la suite du document [PCAC_CASIC].

La Politique de Certification [PCAC_CASIC] a été mise place par Thales S.A pour garantir aux Abonnés un niveau d’assurance et de confiance sur la qualité de ses services de certification.

1.1.2 Aperçu de la Déclaration des Pratiques de Cer tification

Cette Déclaration relative aux Pratiques de Certification décrit les moyens organisationnels et techniques mis en place pour :

• La création, la gestion et l'utilisation de certificats de clés publiques destinés aux Autorités de Certification déléguées de Thales S.A ;

• La sécurité de l’infrastructure des Autorités de Certification déléguées ;

• La création, la gestion et l'utilisation de certificats de clés publiques destinés aux Abonnés du groupe Thales;

Cette Déclaration de Pratiques de Certification (DPC) s’applique aux deux Autorités de Certification déléguées de Thales S.A :

• Thales CLASS 3 CA V2 ayant pour but de délivrer des certificats aux Abonnés A, B et D ;

• Thales CLASS 3 External CA V2 ayant pour but de délivrer des certificats aux Abonnés C.

Le terme Abonné désigne toute personne physique ou entité technologique, détenant un certificat de clé d’authentification, de signature ou de chiffrement délivré par une composante de l’IGC. L’Abonné est appelé demandeur de certificat lorsqu’il effectue une demande de certificat auprès d’une autorité d’enregistrement (AE). Il est appelé porteur de certificat dès l’instant où il dispose d’un certificat émis par l’IGC. Un Abonné ne peut émettre de certificats pour le compte d’autres entités (composantes ou Abonnés). Les types d’Abonnés sont les suivants :

• Abonné A : Abonné ayant la qualité de salarié de l’une des entités du groupe Thales.

• Abonné B : Abonné non salarié de l’une des entités du groupe Thales mais ayant accès au SI : prestataires ; représentants des clients, des partenaires et des fournisseurs qui sont connectés sur le réseau local de l'entreprise.



• Abonné C : abonné non salarié de l’une des entités du groupe Thales et n’ayant pas accès au SI du groupe Thales; c’est le cas par exemple de sociétés de service externe, d’Abonnés, de sociétés co-traitants intervenant dans des projets, de clients, de fournisseurs.

• Abonné D : Abonné technologique, de type serveur, équipements réseaux (proxy, contrôleurs domaine) et application.

L’Infrastructure de Gestion de Clés (IGC) de Thales S.A met en œuvre des composantes organisationnelles et des composantes techniques. Afin de différencier les composantes techniques des composantes organisationnelles qui pour certaines composantes portent des noms identiques, la convention de nom suivante a été mise en œuvre : les composantes techniques utiliseront un nom générique..

L’Autorité de Certification en tant qu’instance technique regroupant l’Autorité de Certification et ses composantes sera définie par le terme AC dans le reste du document. Le terme AC déléguée est utilisé pour définir l’Autorité de Certification Thales Class 3 CA V2 ou Thales Class 3 External CA V2. En cas de nécessité, le nom complet de l’AC sera utilisé pour différentier les deux AC.

La DPC n’est mise en application que sur approbation de l’Autorité Administrative (AA) des AC déléguées. Le rôle de l'Autorité Administrative de l’AC déléguée est définie dans la Politique de Certification de référence.

Le présent document de la Déclaration relative aux Pratiques de Certification est organisé selon le standard RFC 2527 et ce, conformément aux recommandations faites par l’IETF PKIX (Internet Engineering Task Force Public Key Infrastructure X.509).

Les utilisateurs de ce document doivent consulter la Politique de Certification de référence pour obtenir toutes les informations nécessaires sur les droits et obligations de chacune des parties.

L’Autorité d’Administration AA de l’AC déléguée est le responsable de l’ensemble des services rendus par l’AC déléguée.

Sauf indication contraire, les pratiques énoncées dans ce document correspondent à un niveau d’assurance moyen.



1.2 Définitions générales

1.2.1 Définitions

Abonné Personne physique ou entité technologique qui obtient des services des différentes composantes de l’IGC.

L’Abonné peut être désigné sous le nom de demandeur de certificat dans la phase amont de certification, ou sujet dans le contexte du certificat X.509.

L’Abonné peut également être désigné sous le nom de porteur de certificat dès l’instant où il dispose d’un certificat émis par l’IGC.

Dans le cadre des AC déléguées, l’Abonné désigne tout possesseur de certificat de l’IGC, que ce possesseur soit un Abonné du Système d’Information du groupe Thales, c’est-à-dire un individu identifié qui doit accéder aux applications du Système d’Information, ou une entité technologique, telle qu’un serveur ou une application.

Un Abonné ne peut émettre de certificats pour le compte d’autres entités (composantes ou Abonnés).

L’Abonné appartient à une des catégories suivantes et à une seule :

Abonné A : Abonné ayant la qualité de salarié de l’une des entités du groupe Thales.

Abonné B : Abonné non salarié de l’une des entités du groupe Thales mais ayant accès au SI : prestataires ; représentants des clients, des partenaires et des fournisseurs qui sont connectés sur le réseau local de l'entreprise.

Abonné C : Abonné non salarié de l’une des entités du groupe Thales et n’ayant pas accès au SI du groupe Thales; c’est le cas par exemple de sociétés de service externe, d’Abonnés, de sociétés co-traitants intervenant dans des projets, de clients, de fournisseurs.

Abonné D : Abonné technologique, de type serveur, équipement réseau (proxy serveur, serveur domaine) et application.

Dans la suite du document un Abonné pourra être affecté à une des catégories identifiées ci-dessus.

Auditeur Personne désignée par une autorité compétente et dont le rôle est de procéder de manière régulière à des contrôles de conformité de la mise en œuvre des politiques de certification, des déclarations des pratiques de certification et des services effectivement fournis par la composante de l’IGC.

Autorité d’Administration (AA)

Responsable de l’IGC possédant un pouvoir décisionnaire au sein de l’IGC. Elle définit et fait appliquer les Politiques de Certification et les Déclarations des Pratiques de Certification par l’IGC, ainsi que la politique de sécurité générale de l’IGC.



Autorité de Certification (AC)

Autorité chargée de créer et d’attribuer les certificats. Cette entité est responsable des certificats signés en son nom. Cette autorité peut, facultativement, créer les clés des utilisateurs finaux.

Dans ce document, l’AC est considérée en tant qu’instance technique regroupant l’autorité de certification en tant que telle et ses composantes participant dans les processus de certification.

Autorité de Certification déléguée (AC déléguée)

Autorité chargée de créer et d’attribuer les certificats aux Abonnés. Cette entité est responsable des certificats signés en son nom. Cette autorité peut, facultativement, créer les clés des Abonnés.

Autorité de Certification Interne (AC Interne)

L’AC Interne désigne l’AC déléguée de Thales S.A délivrant des certificats pour les Abonnés A, B ou D.

Autorité de Certification Externe (AC Externe)

L’AC Externe désigne l’AC déléguée de Thales S.A délivrant des certificats pour les Abonnés C.

Autorité de Certification Racine (ACR)

AC prise comme référence par une communauté d’Abonnés (incluant d’autres AC). Elle est un élément essentiel de la confiance qui peut lui être accordée dans un contexte donné.

Autorité d’Enregistrement Centrale (AEC)

Composante de l’infrastructure de l’AC qui vérifie les données propres à l’AC ainsi que les contraintes liées à l'usage d'un certificat, conformément à la Politique de Certification. L’AEC doit être reconnue par l’AC pour laquelle elle édite des demandes de certificats et des demandes de révocation.

L’AEC est l’AE intégrée à l’AC.

Autorité de Délivrance (AD)

Personne physique représentant une entreprise (hors du groupe Thales) ayant adhéré à l’IGC de Thales. Elle assure l’authentification des demandes auprès d’entités du groupe Thales pour le compte de ses employés travaillant pour ou avec des entités du groupe Thales.

Autorité d’Enregistrement (AE)

Dans ce document, il ne s’agit pas de la composante de l'IGC qui vérifie les données propres au demandeur ou porteur de certificat ainsi que les contraintes liées à l'usage d'un certificat, conformément à la politique de certification. Les tâches de cette composante ayant été regroupé dans le terme d’AC.

Dans le cadre de l’infrastructure de l’AC déléguée de l’IGC de Thales, ce rôle est sous la responsabilité d’une personne du groupe Thales. Il a en charge toutes les Autorités d’Enregistrement Locales. Il assure l’authentification des demandes d’AEO auprès de l’IGC.

Autorité d’Enregistrement Locale (AEL)

Ce rôle est affecté à une personne du groupe Thales sous la responsabilité de l’AE. Il a en charge un ou plusieurs BE et les Opérateurs d’Autorité d’Enregistrement qui lui sont associés. Il assure l’authentification physique des AEO.

Bureau d’Enregistrement (BE)

Poste informatique équipé pour se connecter à l’infrastructure des AC déléguées de l’IGC afin d’émettre des certificats pour les Abonnés. Un BE est opéré par plusieurs Opérateurs d’Autorité d’Enregistrement (AEO).



Bureau de Sécurité (BS)

L’acronyme BS regroupe le Bureau de Sécurité et tous les organismes qui sont sous sa responsabilité. Le BS est notamment chargé de produire la personnalisation graphique des cartes à puce et la personnalisation des droits d'accès aux sites.

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 oeuvre d’une prestation de cryptographie basée sur des algorithmes asymétriques.

Chaîne de confiance Ensemble des certificats nécessaires pour valider la généalogie d’un certificat porteur. Dans le cadre de l’IGC de Thales, la chaîne se compose du certificat du porteur, du certificat de l’AC déléguée et du certificat de l’ACR, à laquelle l’AC déléguée est subordonnée.

Common Name (CN) Identité réelle ou pseudonyme du titulaire du certificat (exemple CN = Jean Dupont).

Certificate Revocation List (CRL)

Liste de certificats ayant fait l’objet d’une révocation.

Composante de l’IGC

Plate-forme constituée d'au moins un poste informatique, une application, un moyen de cryptologie, un support réseau et jouant un rôle déterminé au sein de l'IGC. Une composante peut être le serveur AC, un serveur AE, …

Distinguished Name (DN)

Nom distinctif de l’Abonné (au format X.500) pour lequel le certificat est émis.

Données d’activation

Données privées associées à un Abonné permettant de mettre en oeuvre sa clé privée.

Déclaration des Procédures de Certification (DPC)

Déclaration des procédures et pratiques de certification effectivement respectées par une AC pour la gestion des certificats.

Entité Entreprise du groupe Thales ou projet du groupe Thales adhérent à l’IGC de Thales.

Exploitant Personne travaillant pour le compte de l’IGC et disposant de droits d’accès à une autorité associés aux rôles qui lui sont attribués.

Identificateur d’objet (OID)

Identificateur alphanumérique unique enregistré conformément à la norme d’enregistrement ISO pour désigner un objet ou une classe d’objets spécifiques.

Infrastructure de Gestion de Clés (IGC)

Ensemble de composants, fonctions et procédures dédiés à la gestion de clés et de certificats utilisés par des services de sécurité basés sur la cryptographie à clé publique.

Ingénieur Système Il est chargé de la mise en route, de la configuration et de la maintenance technique de la plate-forme informatique de la composante. Il assure l’administration du système et du réseau de cette plate-forme.

Module cryptographique

Un module cryptographique est un dispositif matériel, du type carte à mémoire, carte PCMCIA, carte chiffre ou autre, 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 oeuvre ces éléments.



Opérateur de Certification (OC)

Voir Exploitant.

Opérateur de Service de Certification (OSC)

Entité exploitant pour le compte de Thales S.A, les services de certification sur la plate-forme en central. Il génère et émet des certificats en lesquels une communauté d'Abonnés a confiance.

Opérateur d’Autorité d’Enregistrement (AEO)

L’Opérateur d’Autorité d’Enregistrement réalise l’authentification physique des Abonnés et le traitement des requêtes des Abonnés. Il opère la délivrance de cartes à puce aux Abonnés depuis un BE.

Politique de Certification (PC)

Ensemble de règles, définissant les exigences auxquelles l’AC se conforme dans la mise en place de prestations adaptées à certains types d’applications. La Politique de Certification doit être identifiée par un OID défini par l'AA de l’AC.

Porteurs de (certificats)

Voir Abonné.

Représentant d’Abonné

Personne dûment déléguée par l’Abonné A ou D pour effectuer à sa place l’enregistrement face à face. Les obligations relatives aux Abonnés s’appliquent au Représentant, lorsqu’il existe. Le Représentant doit lui-même appartenir à la catégorie d’Abonné A.

Responsable de sécurité (OSSI)

Le responsable de sécurité est responsable de l’application de la politique de sécurité physique et fonctionnelle d’une composante de l’IGC et de son environnement. Il gère les contrôles d’accès physiques à la plate-forme de la composante, et est chargé de mettre en œuvre la politique de sécurité régissant la composante.

Renouvellement (d’un certificat)

Opération effectuée à la demande d’un Abonné ou en fin de période de validité d’un certificat et qui consiste à générer un nouveau certificat pour un porteur. La re-génération de certificat après révocation n’est pas un renouvellement.

Révocation (d’un certificat)

Opération demandée par l’Abonné, une composante de l’IGC ou une personne habilitée à cet effet, dont le résultat est la suppression de la caution de l’AC sur un certificat donné, avant la fin de sa 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, … L’opération de révocation est considérée terminée quand le certificat mis en cause est publié dans la liste des certificats révoqués.

Service d’archivage de clés

Le service d’archivage de clés est une composante de l’IGC qui permet le stockage sécurisé de bi-clés de confidentialité pour lesquels l’IGC a généré des certificats. Il permet également le recouvrement de ces bi-clés.

Service de publication

Le service de publication rend disponible les certificats de clés publiques émis par une AC, à l’ensemble des Abonnés potentiels de ces certificats. Il publie une liste de certificats reconnus comme valides et une liste de certificats révoqués (CRL). Ce service peut être rendu par un annuaire (par exemple, de type X.500), un serveur d’information (Web), une délivrance de la main à la main, une application de messagerie, …

Utilisateur de Certificat (UC)

Toute entité (Utilisateur humain, organisme ou entité technologique) ayant à utiliser des certificats de clé publique à des fins de vérification de signature. Un Utilisateur de Certificat ne détient pas forcément de certificat propre.



Validation (de certificat)

Opération de contrôle du statut d’un certificat ou d’une chaîne de certification.

Vérification (de signature)

Opération de contrôle d’une signature numérique.

1.3 Liste des acronymes

Acronyme français

Définition française Acronyme anglais

Définition anglaise

AA Autorité d’Administration AA Administration Authority

AC Autorité de Certification CA Certification Authority

ACR Autorité de Certification Racine CA root Root Certification Authority

AD Autorité de Délivrance DA Delivery Authority

AE Autorité d’Enregistrement RA Registration Authority

AEC Autorité d’enregistrement centrale CAO Certification Authority Operator

AEL Autorité d’Enregistrement Locale RAL Local Registration Authority

AEO Opérateur d’Autorité d’Enregistrement

RAO Registration Authority Operator

AGCA Autorité de Gestion des Codes Administrateur

PUKMAO Personal Unblock Key Management Authority Operator

ARL Liste de révocation d’autorités de certification

ARL Authority Revocation List

BE Bureau d’Enregistrement RO Registration Office

BS Bureau de Sécurité SO Security Office

CGCA Centre de Gestion des Codes Administrateur

PUKMA Personal Unblock Key Management Authority

CN Nom usuel CN Common Name

CSS Service de délivrance de statut de certificats

CSS Certificate Status Server

DN Nom distinctif DN Distinguish Name

DPC Déclaration relative aux Procédures de Certification

CPS Certificate Policy Statement

DSG Direction Sécurité Groupe Thales DSG Thales Group Security Service

EBI Expression de Besoin Informatiques

CRR Computer Requirement Request



EH Service de notification par messagerie électronique

EH Email Handler

FIPS Standard de traitement de données fédéral. Standard gouvernemental américain publié par le NIST.

FIPS Federal Information Processing Standard

GTSSI Groupe de Travail Sécurité Système d’Information de Thales

GTSSI Security Information System Workgroup (from Thales)

ICP Infrastructure à Clé Publique PKI Public Key Infrastructure

IETF Organisme visant à l’amélioration d’Internet

IETF Internet Engineering Task Force

IGC Infrastructure de Gestion de Clés PKI Public Key Infrastructure

KAS Service d’archivage de clés KAS Key Archive Server

LCR Liste des Certificats Révoqués CRL Certificate Revocation List

LMK Clé Locale Maître LMK Local Master Key

OC Opérateur de Certification CO Certification Operator

OID Identificateur d’objet OID Object IDentifier

OSC Opérateur de Service de Certification

CSP Certification Service Provider

OSSI Officier Sécurité Système d’Information / Responsable sécurité

ISSO Information Security System Officer

PC Politique de Certification CP Certificate Policy

PC2 Procédures et Politique de Certification

PCP Practices and Certificate Policy

PIN Numéro d’identification personnel PIN Personal Identification Number

PKCS Standards de cryptographie à clé publique développés par les Laboratoires RSA

PKCS Public Key Cryptographic Standard

PKIX Infrastructure à clé publique (conforme à la norme X.509)

PKIX Public Key Infrastructure eXchange X.509

RFC Document de spécifications de technologies

RFC Request For Comments

RA Autorité d’Enregistrement (composante technique)

RA Registration Authority

RSA Algorithme asymétrique RSA Rivest Shamir Adelman

SHA-1 Algorithme de hachage sécurisé SHA-1 Secure Hash Algorithm



SI Système d’Information IS Information System

S/MIME Standard pour la protection de messages électroniques

S/MIME Secure / Multipurpose Internet Mail Extensions

SSL Protocole de sécurisation des échanges sur Internet

SSL Secure Sockets Layer

TGI Identifiant au sein du groupe Thales

TGI Thales Group Identifier

UC Utilisateur de Certificat CU Certificate User

URL Adresse Internet URL Unique Resource Locator

1.4 Identification (OID)

La PC de référence à la présente DPC est identifiée par l'OID : 1.2.250.1.108.1.3

La présente DPC ne fait pas l’objet d’un enregistrement spécifique et n’est pas référencée par un OID.

1.5 Applications et groupe d’utilisateurs concernés

Le processus de certification et la gestion du cycle de vie du certificat font appel à une grande diversité d’intervenants dans la chaîne de la confiance :

• L’Autorité de Certification déléguée et ses propres composantes ou services.

• L’Autorité d’Administration.

• L’Autorité d’Enregistrement.

• L’Autorité d’Enregistrement Locale.

• L’Autorité de Délivrance.

• L’Opérateur d’Autorité d’Enregistrement.

• Les Abonnés.

• Les Utilisateurs de Certificats.

• L’Autorité d’Enregistrement Centrale.

• L’Autorité de Gestion des Codes Administrateur.

• L’OSC.

Ces intervenants sont détaillés dans les paragraphes suivants.



1.5.1 Applications concernées

Les applications concernées sont les applications du groupe Thales qui ont fait l’objet d’une autorisation du GTSSI et qui acceptent l’usage de certificats X509 v3. Ce sont notamment des applications de :

• De messagerie ;

• D’accès contrôlé au Système d’Information;

• De protection de données sur les postes

1.5.2 Groupes d’utilisateurs concernés

1.5.2.1 Autorité de Certification déléguée (AC délé guée) L'Autorité de Certification déléguée dispose d’une plate-forme matérielle et logicielle.

Elle est responsable de la génération, de l’émission, de la publication, de la révocation, du renouvellement des certificats, conformément à la PC définie et validée par son AA et la DPC validée par son AA, au profit d’Abonnés et en lesquelles une communauté d’Utilisateurs de Certificats a confiance.

Elle est également responsable de la génération, de l’émission, de la publication des CRL.

L’AC déléguée délègue à l’AEC l’enregistrement des AEO.

L’AC déléguée délègue aux AEO l’enregistrement des Abonnés.

1.5.2.2 Autorité d’Administration (AA) L’Autorité d’Administration est responsable de l’IGC et possède un pouvoir décisionnaire au sein de l’IGC. A ce titre, elle édicte et valide la Politique de Certification et valide la Déclaration des Pratiques de Certification.

Elle est garante de l’application de la politique de sécurité qui régit l’IGC.

L’AA de l’ACR est incarnée par l’autorité qualifiée de Thales S.A, soit le Directeur Systèmes d’Information de Thales S.A.

1.5.2.3 Autorité d’Enregistrement (AE) L’AE a en charge toutes les AEL de sa Division. Elle assure l’authentification de demandes pour les AEL et AEO auprès de l’AC déléguée, conformément à la Politique de Certification définie par l’AA de l’AC déléguée et la Déclaration des Pratiques de Certification validée par l’AA de l’AC déléguée.

L’AE est représentée par le RSSI Division.

Les certificats délivrés aux AE sont de type Abonné et non pas Opérateur de Certification.

1.5.2.4 Autorité d’Enregistrement Locale (AEL) L’AE a en charge un ou plusieurs BE et les AEO qui lui sont associés. Elle assure l’authentification physique des AEO, conformément à la Politique de Certification définie par l’AA de l’AC déléguée et la Déclaration des Pratiques de Certification validée par l’AA de l’AC déléguée.

L’AEL est représentée par le RSSI de chaque entreprise/site de la Division.

Les certificats délivrés aux AEL sont de type Abonné et non pas Opérateur de Certification.



1.5.2.5 Autorité de Délivrance (AD) L’AD assure l’authentification de demandes auprès d’entité du groupe Thales, conformément à la Politique de Certification définie par l’AA de l’AC déléguée et la Déclaration des Pratiques de Certification validée par l’AA de l’AC déléguée.

L’AD est représentée par une entreprise (hors groupe Thales) ayant adhéré à l’IGC de Thales.

Les certificats délivrés aux AD sont de type Abonné et non pas Opérateur de Certification.

1.5.2.6 Opérateur d’Autorité d’Enregistrement (AEO) L’AEO a en charge l’authentification physique des Abonnés et le traitement des requêtes des Abonnés, conformément à la Politique de Certification définie par l’AA de l’AC déléguée et la Déclaration des Pratiques de Certification validée par l’AA de l’AC déléguée.

1.5.2.7 Abonnés Toute personne physique ou machine qui détient un certificat délivré par l’AC déléguée et un dispositif de création de signature. Il agit soit pour son propre compte ou pour celui de la personne physique ou morale qu’il représente dans le cadre de l’application concernée.

Il appartient au domaine d’application ou est en relation avec ce domaine dans le cadre de l’application concernée et utilise les services de l’IGC de ce domaine.

1.5.2.8 Parties utilisatrices En vertu de la Politique de Certification de référence, les Utilisateurs de Certificats émis par l’AC déléguée sont :

• Les Abonnés.

• Toute entité (Utilisateur humain, organisme ou entité des technologies de l’information) ayant à utiliser des certificats de clé publique à des fins de vérification de signature.

Un Utilisateur de certificat ne détient pas forcément de certificat propre.

1.5.2.9 Autorité d’Enregistrement Centrale (AEC) L’AEC est la composante d’Autorité d’Enregistrement de l’AC déléguée intégrée à l’AC déléguée.

Elle vérifie les données propres aux AEO et exploitants de l’infrastructure de l’AC déléguée ainsi que des contraintes liées à l’usage du certificat qui leur est délivré, conformément à la PC définie et validée par l’AA de l’AC déléguée et la DPC validée par l’AA de l’AC déléguée, pour laquelle elle édite des demandes de certificats et les demandes de révocation. La demande de certificat contient les informations (enregistrement de l’AEO ou de l’exploitant et profil associé) qui lui sont fournies par les personnes habilitées.

L’AEC a également à charge de réceptionner les demandes de révocation, de traiter les demandes de certificats ou de révocation et de distribuer les certificats délivrés par l’AC pour les AEO et exploitants. Elle est opérée par un opérateur de certification dit « Opérateur AEC ».

1.5.2.10 Opérateur de Service de Certification (OSC ) L’OSC est l’opérateur de l’IGC qui dispose d’une plate-forme matérielle et logicielle lui permettant de générer et émettre des certificats, conformément à la PC définie par l’AA de l’AC déléguée et la DPC validée par l’AA de l’AC déléguée, auxquels une communauté d’Utilisateurs fait confiance.

Il est en charge du bon fonctionnement de l’infrastructure de l’AC déléguée et de la sécurité des moyens informatiques et techniques, de la sécurité des personnels et des locaux.



Dans le cadre de l’IGC de Thales, l’OSC de l’infrastructure de l’AC deéléguée est Thales Services dont les locaux sont situés Elancourt (Yvelines).

1.5.2.11 Opérateur de Certification L’Opérateur de Certification (OC) assure les prestations techniques, en particulier cryptographiques, nécessaire au processus de certification, conformément à la PC définie par l’AA de l’AC déléguée et la DPC validée par l’AA de l’AC déléguée.

Sa responsabilité ne peut être engagée que par l’AA de l’AC déléguée et se limite au respect des procédures établies dans la présente DPC.

1.5.3 Applicabilité de la Déclaration des Pratiques de Certification

Cette DPC est applicable aux AC déléguées et leurs composantes, aux Autorité d’Enregistrement Centrale, aux AE, aux AEL, aux AEO, aux AD, à l’OSC ainsi qu’aux Opérateurs de Certification des AC déléguées, aux Abonnés et aux UC.



2 Dispositions de portée générale

Ce chapitre contient des dispositions relatives aux obligations respectives de l’AC déléguée, des personnels, des diverses entités composant l’infrastructure de l’AC déléguée et des Abonnés. Elle contient aussi des dispositions juridiques relatives notamment à la loi applicable et à la résolution des litiges.

2.1 Obligations

2.1.1 Obligations communes à plusieurs composantes

Les dispositions relatives aux obligations communes à plusieurs composantes sont celles édictées dans la PC de référence.

2.1.2 Obligations de l’AC

Les dispositions relatives aux obligations de l’AC déléguée sont celles édictées dans la PC de référence.

2.1.3 Obligations de l’AE, l’AEL, l’AEO et l’AD

Les dispositions relatives aux obligations de l’AE, l’AEL, l’AEO et l’AD sont celles édictées dans la PC de référence.

2.1.4 Obligations de l’Abonné

Les dispositions relatives aux obligations de l’Abonné sont celles édictées dans la PC de référence.

2.1.5 Obligations des Utilisateurs de Certificats

Les dispositions relatives aux obligations des Utilisateurs de Certificats sont celles édictées dans la PC de référence.

2.2 Responsabilité

Les dispositions relatives aux responsabilités sont celles édictées dans la PC de référence.

2.2.1 Exigences de moyens

Les dispositions relatives aux exigences de moyens sont celles édictées dans la PC de référence.

La présente DPC apporte les précisions suivantes :

Engagement des AC déléguée vis à vis de l’ACR

Les engagements des AC déléguées sur l’usage du certificat de l’ACR et de leur propre certificat délivré par l’ACR, doivent être portés à leur connaissance avant souscription du contrat qui les lie à l’ACR.

La relation entre une AC déléguée et l’ACR est formalisée par un engagement de l’AC déléguée visant à certifier l’exactitude des renseignements et des documents fournis et l’engageant à respecter le contrat qui le lie l’ACR.



Engagement des composantes des AC déléguée vis-à-vis de leur AC

Les composantes de l’AC déléguée rattachées à une AC déléguée doivent se conformer à toutes les exigences de la présente DPC et de la PC associée.

Les engagements des composantes de l’AC déléguée sur l’usage de certificats et de clés cryptographiques doivent être portés à la connaissance de leurs exploitants avant souscription du contrat qui les lie à l’AC déléguée à laquelle elles sont affiliées.

Engagement des utilisateurs vis-à-vis de leur AC déléguée

Les utilisateurs de certificats de l’AC déléguée doivent se conformer à toutes les exigences de la présente DPC et de la PC associée.

Les engagements des Abonnés de l’AC déléguée sur l’usage de certificats et de clés cryptographiques doivent être portés à leur connaissance avant souscription du contrat qui les lient à l’AC déléguée.

2.2.2 Limites de la responsabilité

Les dispositions relatives aux limites de la responsabilité sont celles édictées dans la PC de référence.

2.2.3 Autres modalités

Les dispositions relatives aux autres modalités sont celles édictées dans la PC de référence.

2.2.3.1 Force majeure Les dispositions relatives à la force majeure sont celles édictées dans la PC de référence.

2.3 Interprétation et application

2.3.1 Droit applicable

Les dispositions relatives au droit applicable sont celles édictées dans la PC de référence.

2.3.2 Règlement des différends

Les dispositions relatives au règlement des différends sont celles édictées dans la PC de référence.

2.4 Barêmes de prix

Sans objet.

2.5 Publication et services associés

2.5.1 Informations publiées

Les informations publiées sont mentionnées dans la PC de référence.




Elles concernent :

• La DPC

• Les CRL

• Les certificats d’AC déléguées

• Les certificats des Abonnés

• Le formulaire de déploiement d’un BE/AEO

La DPC, qui donne, entre autres, le détail des procédures et des moyens mis en oeuvre pour assurer la protection des installations de l’AC déléguée, n’est pas publiée dans son intégralité pour des raisons de sécurité évidentes. Les éléments publiés de la DPC doivent permettre de vérifier la conformité des pratiques de certification avec la PC. Les éléments non publiés de la DPC sont décrits dans un document Annexe à la DPC classifié « Confidentiel Groupe ».

Toutefois, l’AA de l’AC déléguée doit fournir, en cas de besoin, la DPC dans son intégralité, lors d'une demande d'un organisme habilité à en connaître à des fins de vérification, d'audit ou de contrôle, prévu à cet effet dans la PC de référence, ainsi que dans le cadre du respect de la loi.

Les CRL des AC déléguées sont publiées aux URL suivantes :

• Pour l’AC Interne (délivrant des certificats pour les Abonnés de type A, B ou D) :

http://crl.thalesgroup.com/crlThalesClass3CAV2.crl

• Pour l’AC Externe (délivrant des certificats pour les Abonnés de type C) :

http://crl.thalesgroup.com/crlThalesClass3ExternalCAV2.crl

Les CRL sont également disponibles dans l’annuaire du groupe Thales dont les points de distribution sont définis comme suit :

• Pour l’AC Interne (délivrant des certificats pour les Abonnés de type A, B ou D) :

cn=crlThalesClass3CAV2, ou=Thales, ou=Certification Authority, o=group

• Pour l’AC Externe (délivrant des certificats pour les Abonnés de type C) :

cn=crlThalesClass3ExternalCAV2, ou=Thales, ou=Certification Authority, o=group

Cette publication dans l’annuaire l’est uniquement à des fins techniques, cette publication permettant ensuite d’être récupérée pour un stockage aux URL nommées ci-dessus, qui sont l’unique point de distribution connu par les Abonnés.

Un outil d’administration est mis en oeuvre par l’entité en charge de l’administration des réseaux et des serveurs Web du groupe Thales pour récupérer ces CRL dans l’annuaire à des fréquences similaires à celle de la publication par l’AC déléguée et les publier aux URL citées plus haut.

Les certificats d’AC déléguées sont publiés à l’URL suivante :

• Pour l’AC Interne :



http://crl.thalesgroup.com/ThalesClass3CAV2.crt

• Pour l’AC Externe :

http://crl.thalesgroup.com/ThalesClass3ExternalCAV2.crt

Les certificats d’AC déléguées sont publiés dans l’annuaire du groupe à l’entrée suivante :

Root O = Group OU = Certification Authority OU = Thales Group

CN = Thales Class 3 CA V2 pour l’IGC interne et Thales Class 3 External CA V2 pour l’IGC destinée à la délivrance de certificats pour les clients partenaires du groupe Thales Cependant, la publication dans cet espace est réservé à un usage technique, ces informations étant disponibles aux Abonnés aux URL nommées ci-dessus

Les certificats des Opérateurs de Certification (y compris les AEO) ne sont pas non plus publiés dans l’annuaire.

Les certificats des Abonnés sont publiés dans l’annuaire du groupe Thales.

Le formulaire de déploiement d’un BE/AEO est publié dans la QuickPlace Thales Pass, accessible à l’adresse : http://quicksiege.corp.thales/is-prj001

2.5.2 Fréquence de publication

Les dispositions relatives à la fréquence de publication des informations sont celles édictées dans la PC de référence.

La publication des nouvelles versions de la PC de référence ou de la présente DPC doit être effectuée dans un délai de sept (7) jours ouvrables suivant l’approbation des modifications apportées sur la PC et / ou la DPC.

Délai de publication de l’AC déléguée :

• La liste de certificats est publiée dans un délai de 1 heure maximum après délivrance.

• La fréquence de publication est de 24 heures, à moins qu’une révocation ait eu lieu entre temps, auquel cas une CRL est produite à l’occurrence de l’événement.

• Le délai de publication de la CRL ne peut excéder 24 heures après la production d’une nouvelle CRL.

Cependant en termes de disponibilité de la CRL aux Abonnés et Utilisateurs de Certificats, le service de réplication de la CRL sur les points d’accès opère à une fréquence de 24 heures. En conséquence, les réplications sur les serveurs Web ne prennent pas en compte les publications opérées sur événements par l’AC déléguée.

L’AC déléguée met tous les moyens en œuvre pour assurer que l’indisponibilité des certificats et CRL ne dépassent pas 24 heures maximum d’interruption consécutives. Ces engagements s’appliquent aux publications dans l’annuaire tampon qu’elle met en œuvre. L’ AC déléguée ne pourra être tenue pour responsable des problèmes de publication dans l’annuaire du groupe Thales, ni des problèmes de réplication des CRL sur les serveurs Web.



2.5.3 Contrôle de l’accès

Les dispositions relatives au contrôle d’accès des informations publiées sont celles édictées dans la PC de référence.


L’accès en écriture au niveau de l’AC déléguée n’est accessible qu’à la composante Unicert CA. Les accès en modification, suppression au niveau de l’annuaire sont réalisées par l’administrateur de l’annuaire avec l’accord de l’AA de l’AC déléguée.

2.5.4 Service de publication

Les dispositions relatives au service de publication des informations publiées sont celles édictées dans la PC de référence.

2.6 Contrôle de conformité

Les dispositions relatives au contrôle de conformité sont celles édictées dans la PC de référence.

2.6.1 Fréquence d’audit de conformité

Les dispositions relatives à la fréquence d’audit de conformité sont celles édictées dans la PC de référence.


Un contrôle de conformité peut avoir lieu préablement à des événements dans le cycle de vie de l’AC déléguée soit lors de sa première mise en œuvre ou du changement de la présente DPC.

Un contrôle de conformité n’est pas réalisé lors de la mise en œuvre de chaque certificat d’une AC déléguée de l’IGC, mais de manière sporadique sur demande de l’AA de l’AC déléguée.

Un contrôle de conformité peut également avoir lieu sur les composantes techniques tous les trois (3) ans.

2.6.2 Identité / qualité de l’auditeur

Les dispositions relatives à l’identité / qualité de l’auditeur sont celles édictées dans la PC de référence.

2.6.3 Lien entre l’auditeur et la fonction vérifiée

Les dispositions relatives au lien entre l’auditeur et la fonction vérifiée sont celles édictées dans la PC de référence.

2.6.4 Objet de l’audit

Les dispositions relatives à l’objet de l’audit sont celles édictées dans la PC de référence.


Les sujets d’un audit de conformité portent sur les pratiques techniques, les procédures ou les personnels impliqués dans l’exploitation des AC déléguées telles que décrites dans la présente DPC.

2.6.5 Mesures à prendre à la suite de l’audit

Les dispositions relatives aux mesures prises à la suite à l’audit sont celles édictées dans la PC de référence.



2.6.6 Communication des résultats

Les dispositions relatives à la communication des résultats sont celles édictées dans la PC de référence.

2.7 Politique de confidentialité

Les dispositions relatives à la politique de confidentialité sont celles édictées dans la PC de référence.

2.7.1 Types d’informations considérées comme confid entielles

Les dispositions relatives aux types d’informations considérées comme confidentielles sont celles édictées dans la PC de référence.


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

Informations Diffusion

Archives de journaux d’événements Diffusion restreinte

Journaux d’audit Diffusion restreinte

Annexe de la DPC Confidentiel groupe

Bandes de sauvegardes Diffusion restreinte

Clés privées des composantes techniques Diffusion restreinte

Clés privées de confidentialité des Abonnés Clés noircies

Données d’identification anonyme (pseudonyme, identification, user ID, certificate S/N) d’une composante

Confidentiel à caractère privatif

Données d’activation de la clé privée des composantes

Diffusion restreinte

Données d’identification anonyme (pseudonyme, identification, user ID, certificate S/N) d’un opérateur de composante

Confidentielles à caractère privatif

Clés privées des opérateurs des composantes Non protégées :

- protégées par la protection apportée par la carte à puce.

- protégées dans un coffre pour des clés logicielles

Données d’activation des clés privées (code PIN, passe-phrase) des opérateurs des composantes

Confidentielles à caractère privatif (*)

Les codes Administrateurs des cartes à puce permettant de débloquer les codes PIN

Diffusion restreinte



Clés privées des Abonnés Non protégées :

- pour les clés matérielles : protégées par la protection apportée par la carte à puce.

- pour les clés logicielles : protégées par l’application qui en assure le stockage au travers de la mise en place d’une passe-phrase.

Données d’activation des clés privées (code PIN, passe-phrase) des Abonnés

Confidentielles à caractère privatif (*).Si l’Abonné souhaite consigner ses données d’activation sur papier, ce dernier doit être conservé dans un coffre.

Données d’identification anonyme (pseudonyme, identification, user ID, certificat S/N) d’un Abonné

Confidentielles à caractère privatif (*).

L’ensemble de ces informations à l’exclusion des données d’identification, des données d’activation et clés privées restant sous la responsabilité de leur titulaire, sont conservées sous la responsabilité de l’hébergeur avec le niveau de sécurité adéquat.

Il appartient à l’AA de l’AC déléguée de définir pour chaque type d’information, sur exception tel qu’un audit, l’ensemble des personnes objet des diffusions.

(*) Dans le cas d’utilisation d’un pseudonyme pour être identifié, celui-ci peut être divulgué par l’AA aux autorités légales dans les conditions suivantes :

• Renseigner son identité (identification, user ID, certificat S/N),

• Définir le nom du pseudonyme à divulguer par l’AA,

• Exposer la(les) raison(s) de demande de divulgation par l’AA,

2.7.2 Types d’informations considérées comme non co nfidentielles

Les dispositions relatives aux types d'informations considérées comme non confidentielles sont celles édictées dans la PC de référence.

2.7.3 Divulgation des causes de révocation de certi ficat

Les dispositions relatives à la divulgation des causes de révocation de certificat sont celles édictées dans la PC de référence.


Composantes d’AC déléguées

Les causes de révocation des composantes d’AC déléguée ne sont pas publiées, le champ « CRLreason » sera renseigné avec la valeur suivante : « unspecified ».

Dans le cas d’un renouvellement de certificat de composante d’AC déléguée, la cause sera renseignée avec la mention suivante « superseded ».

Abonnés

Les causes de révocation des certificats d’Abonnés ne sont pas publiées, le champ « CRLreason » sera renseigné avec la valeur suivante : « unspecified ».



2.7.4 Délivrance aux autorités légales

Les dispositions relatives à la délivrance aux autorités légales sont celles édictées dans la PC de référence.


Les clés d’authentification et de signature stockés sur carte à puce ne peuvent, en aucun cas, être divulgués, puisqu’elles ne peuvent pas être extraits de leur support de stockage.

Seules les clés de confidentialité des Abonnés ayant fait l’objet d’un archivage peuvent être divulgués aux autorités légales habilitées à accéder à ces informations conformément à la présente DPC et PC associée.

Toute divulgation d’informations considérées comme confidentielles nécessite une autorisation de l’AA de l’AC déléguée concernée.

2.7.5 Délivrance à la demande du propriétaire


Les informations relatives aux composantes d’AC déléguée et définies comme confidentielles au §2.7.1 ne peuvent être divulguées qu’à leur propriétaire ou à un tiers ayant un niveau d’habilitation au moins égal au niveau de confidentialité des informations à délivrer, et validé par l’AA de l’AC déléguée, sur demande du propriétaire.

Abonnés

Les renseignements relatifs aux Abonnés concernant l’identification ou d’autres données à caractère personnel ne peuvent être divulgués qu’à son propriétaire ou à un tiers ayant un niveau d’habilitation au moins égal au niveau de confidentialité des informations, sauf :

• Si l’Abonné a donné son consentement formel et préalable à toute diffusion,

• Si leur publication a été demandée sur décision judiciaire ou administrative (Ex : fourniture de preuve d’authenticité et validité du certificat - lien entre le certificat et l’Abonné - à un tiers).

La délivrance des clés privées d’Abonnés (personne physique ou machine) suit la règle suivante :

• Pour les clés d’authentification et de signature Abonné, aucune clé ou donnée d’activation ne peut être remise à un tiers.

• Pour les clés de confidentialité Abonné, ayant fait l’objet d’un archivage, les clés peuvent être divulguées à la demande du propriétaire ou d’un tiers ayant un niveau d’habilitation au moins égal au niveau de confidentialité des informations.

2.7.6 Autres circonstances de délivrance possible

Les dispositions relatives aux autres circonstances de délivrance possible sont celles édictées dans la PC de référence.



Les informations relatives aux composantes d’AC déléguée considérées comme confidentielle (au sens du §2.7.1) pourront être délivrées à des tiers sous réserve d’avoir un niveau d’habilitation au moins égal au niveau de confidentialité des informations à délivrer et validé par l’AA de l’AC déléguée.



Un consentement doit être donné par l'AA de l’AC déléguée pour que les informations utilisées pour l’enregistrement des composantes de l’AC déléguée soient conservées et communiquées à une tierce partie dans le cas d’une AC déléguée en fin de vie (dans les conditions définies par cette politique).

Abonnés

Les informations relatives aux Abonnés considérées comme confidentielle (au sens du §2.7.1) pourront être délivrées à des tiers sous réserve d’avoir un niveau d’habilitation au moins égal au niveau de confidentialité des informations à délivrer et validé par l’AA de l’AC déléguée.

2.8 Droits relatifs à la propriété intellectuelle

Les dispositions relatives à la propriété intellectuelle sont celles édictées dans la PC de référence.



3 Identification et authentification

3.1 Enregistrement initial

3.1.1 Conventions de noms

Les dispositions relatives aux conventions de noms sont celles édictées dans la PC de référence.

3.1.2 Nécessité d’utilisation de noms explicites

Les dispositions relatives à la nécessité d’utilisation de noms explicites sont celles édictées dans la PC de référence.


La politique de DN retenue dans le cadre du certificat d’AC déléguée est la suivante :

• Pour l’AC Interne émettant des certificats pour les Abonnés de type A, B ou D :

cn=Thales Class 3 CA V2, o=Thales

• Pour l’AC Externe émettant des certificats pour les Abonnés de type C :

cn=Thales Class 3 External CA V2, o=Thales

D’autres politiques de DN sont mises en œuvre dans le cadre d’une AC déléguée. Ces politiques sont les suivantes :

• Des politiques de DN des Opérateurs accédant aux composantes (précisées dans la DPC – ANNEXE au §2.9.2.2.)

Abonnés

Par ailleurs, l’AC déléguée met en place les politiques auxquels les BE doivent se conformer pour produire les certificats d’Abonnés, soit :

uid= LCCCCCCC, e=ppp.nnn@detdom, cn=nnn ppp, o=Thales

Où :

• LCCCCCCC représente le TGI de l’Abonné, où L étant une lettre et C un chiffre.

• ppp.nnn@detdom représente l’adresse de messagerie de l’Abonné, où ppp est le prénom de l’Abonné, nnn le nom de l’Abonné et detdom est le nom de domaine de l’entité Thales dont fait partie l’Abonné.

• nnn ppp représente le nom et prénom de l’Abonné.

3.1.3 Règles d’interprétation des différentes forme s de noms

Les dispositions relatives aux règles d'interprétation des différentes formes de noms sont celles édictées dans la PC de référence et au §3.1.2 du présent document.



3.1.4 Unicité des noms

Les dispositions relatives à l’unicité des noms sont celles édictées dans la PC de référence.

La présente DPC précise les règles de déclaration des DN au §3.1.2 du présent document.

3.1.5 Procédure de résolution de litige sur la décl aration de nom

Les dispositions relatives à la procédure de résolution de litige sur la déclaration de nom sont celles édictées dans la PC de référence.

3.1.6 Reconnaissance, authentification et rôle des noms de marques de fabrique, de commerce et de services

Les dispositions relatives à la reconnaissance, l’authentification et le rôle des noms de marques de fabrique, de commerce et de services sont celles édictées dans la PC de référence.

3.1.7 Preuve de possession d’une clé privée

Les dispositions relatives à la preuve de possession d’une clé privée sont celles édictées dans la PC de référence.

La vérification par l’ACR de la possession de la clé privée associée à la clé publique de vérification de signature de l’AC déléguée est réalisée à partir de la demande de certificat au standard PKCS#10.

L’AC déléguée s’assure que les composantes techniques possèdent la clé privée correspondant à la clé publique à certifier par le biais du format de données utilisé par celles-ci pour transmettre leur clé publique à certifier (PKCS#10).

Abonnés :

La preuve de possession de clé privée de chaque Abonné est implicitement reconnue lors de la génération de son certificat.

L’AC déléguée s’assure que les Abonnés possèdent la clé privée correspondant à la clé publique à certifier par le biais du format de données utilisé par ceux-ci pour transmettre leur clé publique à certifier (PKCS#10).

3.1.8 Vérification de l’identité de l’Organistation

Sans Objet.

3.1.9 Vérification de l’identité d’une AC ou d’une composante

Les dispositions relatives à la vérification de l'identité d’une AC ou d’une composante sont celles édictées dans la PC de référence.


Pour l’enregistrement initial de l’AC déléguée, l’AC déléguée doit être identifiée de façon unique et non ambiguë. L’identification est réalisée en face à face par contrôle des informations ainsi que leur complétude avec l’AA de l’AC déléguée ou le représentant mandaté par l’AA de l’AC déléguée au cours de la cérémonie d’initialisation.

Par la suite, l’identité de l’AC déléguée est vérifiée au travers de l’authentification en face à face d’un opérateur responsable CA nommé par l’OSC.

Pour l’enregistrement initial, l’authentification d’une composante technique doit l’identifier de façon unique et non ambiguë. L’authentification est réalisée par l’Opérateur d’AEC de l’AC déléguée.



Composantes AEO

Pour l’enregistrement initial, l’authentification d’une AEO doit l’identifier de façon unique et non ambiguë et requiert les informations décrites ci dessous. L’authentification est réalisée par envoi d’un courrier électronique signé de l’AE à l’Opérateur d’AEC de l’AC déléguée. L’Opérateur d’AEC contrôle les informations ainsi que leur complétude.

Les informations requises sont les suivantes :

• Nom et prénom ;

• Une adresse électronique / téléphonique permettant de contacter l’AEO ;

• Identification de l’entité du groupe Thales et du site de l’AEO ;

• Nom du BE auquel il est rattaché ;

• L’AEL dont il dépend ;

• Une adresse de livraison pour l’émission de ses cartes à puce.

3.1.10 Vérification de l’identité des Abonnés

Les dispositions relatives à la vérification de l’identité des Abonnés sont celles édictées dans la PC de référence.


L’authentification d’un Abonné ou de son représentant doit l’identifier de façon unique et non ambiguë et requiert les informations décrites ci-dessous. L’authentification est réalisée par rapport facial de l’Abonné ou de son Représentant auprès d’une autorité habilitée.

Cette autorité habilitée à authentifier l’Abonné est :

• Une AEO pour les Abonnés de type A, B et D

• Une AD pour les Abonnés de type B et C

Cette autorité vérifie l'identité et les attributs spécifiques à l’Abonné à l’aide des informations qu’elle possède sur lui (confère liste ci-dessous).

Compléments sur l'authentification d'un Abonné de type A :

• Nom et prénom ;

• Un attribut reconnu par l’AA de l’AC déléguée permettant de distinguer les Abonnés ayant le même nom (ex : TGI) ;

• Badge nominatif du groupe Thales ou pièce d’identité légale de l’Abonné ou de son Représentant ;

• Attestation de représentation dûment signée par l’Abonné, si l’Abonné délègue la charge d’enregistrement à un tiers ; et dans ce cas une copie d’une pièce d’identité de l’Abonné ;

• Une adresse électronique / téléphonique permettant de contacter l’Abonné ;

• Identification de l’entité du groupe Thales et du site de l’Abonné.



Compléments sur l’authentification d’un Abonné de type B ou C :

• Référence du contrat d’adhésion à l’IGC de Thales ;

• Informations sur l’autorité de délivrance (AD) :

- Nom et prénom ;

- Nom de la société ;

- Une adresse postale / électronique / téléphonique, ou un autre attribut permettant de contacter le représentant de l’Autorité de Délivrance ;

• Nom et prénom de l’Abonné ;

• Un attribut reconnu par l’AA de l’AC déléguée permettant de distinguer les Abonnés ayant le même nom (ex : TGI) ;

• Badge nominatif du groupe Thales ou pièce d’identité légale de l’Abonné ;

• Une adresse électronique / téléphonique permettant de contacter l’Abonné.

Compléments sur l'authentification d'un Abonné de type D :

• Nom ;

• Un attribut, reconnu par l’AA de l’AC déléguée permettant de distinguer les équipements ayant le même nom (ex : numéro de série, TGI de l’administrateur de l’entité technologique ) ;

• Identité de l’administrateur de l’entité technologique ;

• Une adresse électronique / téléphonique, ou un autre attribut permettant de contacter l’administrateur de l’entité technologique ;

• Identification de l’entité du groupe Thales et du site de l’équipement ;

• Sur demande du BE, un contrôle physique pourra être effectué au niveau de l’équipement candidat à l’obtention du certificat.

3.2 Re-génération de certificat en fin de validité

Les dispositions relatives à la re-génération de certificat en fin de validité sont celles édictées dans la PC de référence.

La re-génération de certificat après expiration requiert une authentification de la composante concernée ainsi que de son Opérateur si la composante n’est pas un Opérateur (cf §3.1.9). Cette authentification est réalisée par la même procédure que lors de la première demande de certificat. Cette re-génération induit une re-génération de bi-clés.

Préalablement à la production d’un nouveau bi-clés et certificat, si le certificat est encore en cours de validité, il est opéré une révocation de ce certificat, la cause étant renseignée avec la mention suivante « superseded ».



Pour la composante CA, si une opération de révocation est effectuée, l’ancien certificat d’AC déléguée est publié dans la CRL de l’ACR et y reste jusqu’à la fin prévue de sa validité. Au-delà, il est automatiquement purgé.

Abonnés :

Il est notifié à l’Abonné par courrier électronique, l’expiration prochaine du certificat de l’Abonné. Cette notification s’effectue soixante (30) jours avant la fin de validité du certificat.

La re-génération de certificat après expiration requiert une authentification de l’Abonné (cf §3.1.10).. Cette re-génération induit une re-génération de bi-clés.

Le renouvellement doit être opéré quelques jours avant la péremption pour garantir une continuité de service. Ceci implique que les anciens certificats sont révoqués pour limiter leur usage. Ces informations sont purgées automatiquement de la CRL dès lors que la date de péremption est atteinte, évitant ainsi une taille entropique de la CRL.

Lors d’un renouvellement de clés, les clés privées en fin de validité de la carte à puce sont détruites en présence d’un AEO. Pour les Abonnés D, l’Abonné s’engage à opérer la destruction de ses précédentes clés logicielles.

3.3 Re-génération de clés après révocation

Les dispositions relatives à la re-génération de clés après révocation sont celles édictées dans la PC de référence.


Il n’y a pas de renouvellement de certificat sans renouvellement des bi-clés, même pour un changement d'informations dans le certificat durant la validité de celui-ci.

Lors d’une re-génération de clés après révocation, si le support utilisé est une carte à puce, les bi-clés doivent être effacées du support ou le support doit être détruit par découpage de la puce.

Abonnés :

Lors d’une re-génération de clés après révocation, la carte à puce détenant le certificat révoqué peut être réutilisée après suppression des clés précédentes de la puce

3.4 Demande de révocation

Les dispositions relatives à la demande de révocation sont celles édictées dans la PC de référence.


Quelque soit l’objet de la révocation ( compromission ou suspicion de compromission de clé, perte ou vol, ou modification d’informations contenue dans le certificat), l'authentification doit être réalisée par un rapport facial de l’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée auprès de l’AEC de l’ACR.

Si la demande de révocation est due à une compromission ou suspicion de compromission de clé, perte ou vol, l’authentification de la demande de révocation ne peut être effectuée avec la clé compromise. L'authentification doit être réalisée obligatoirement par un rapport facial des Opérateurs habilités de la composante avec l’AEC de l’AC déléguée.

Composantes AEO



Quelque soit l’objet de la révocation ( compromission ou suspicion de compromission de clé, perte ou vol, ou modification d’informations contenue dans le certificat), l'authentification doit être réalisée par un rapport facial de l’AEO auprès de l’AE ou de l’AEL qui transmet la demande à l’AEC de l’AC déléguée par courrier électronique signé.

Abonnés :

Si la demande de révocation est due à une compromission ou suspicion de compromission de clé, perte ou vol, l’authentification de la demande de révocation ne peut être effectuée avec la clé compromise.

Il est du ressort de l’AEO de s’assurer de l’authentification de la personne distante demandant la révocation avant de procéder à la révocation effective du certificat.



4 Exigences opérationnelles

Les exigences opérationnelles définies ci-après s’appliquent aux AC déléguées, à leurs composantes et à leurs exploitants, ainsi qu’aux Abonnés.

4.1 Demande de certificat

Les dispositions relatives à la demande de certificat sont celles édictées dans la PC de référence.


Pour la délivrance du certificat de signature de l’AC déléguée, l’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée doit s’authentifier par rapport facial auprès de l’Opérateur AEC de l’ACR. Il fournit l’ensemble des informations nécessaires à l’émission du certificat à l’Opérateur AEC de l’ACR. L’Opérateur AEC de l’ACR contrôle et valide les informations et accepte ou refuse la demande de certificat.

Les pièces constituant le dossier sont :

• Nom de l’AC déléguée tel qu’il apparaîtra dans le certificat.

• Courrier de demande de certificat d’AC déléguée signé par l’AA de l’AC déléguée.

• La preuve de possession de la clé privée associée à la clé publique à certifier sous la forme d’un fichier au format PKCS#10.

• La clé publique à certifier sous la forme d’un fichier au format PKCS#10.

En cas d’acceptation de la demande, la procédure se poursuit par l’émission du certificat tel que décrit au §4.2.

Cette opération s’effectue auprès de l’AC déléguée dont dépend la composante.

Pour la délivrance de certificats de composante technique, la procédure à suivre est la suivante :

• L’AA de l’AC déléguée ou le représentant mandaté par l’AA de l’AC déléguée fournit l’ensemble des informations nécessaires à l’émission du certificat à l’Opérateur AEC de l’AC déléguée.

• L’Opérateur AEC de l’AC déléguée contrôle et valide le dossier d’enregistrement fourni par l’AA de l’AC déléguée ou le représentant mandaté par l’AA de l’AC déléguée.

• L’Opérateur AEC de l’AC déléguée accepte ou refuse la demande de certificat.

• L’Opérateur AEC de l’AC déléguée s’authentifie auprès de l’AC déléguée.

• L’Opérateur AEC de l’AC déléguée transmet les informations de la demande à l’AC déléguée.

La délivrance de certificats Opérateurs (cf. §6.5.2.2) s’effectue de manière identique à la procédure mise en œuvre pour les composantes d’AC déléguées décrite ci-dessus à l’exception des AEO et AGCA.

Note : le service d’enregistrement de l’AC déléguée est disponible les jours ouvrables de 9h00 à 18h00.



Composantes AEO

Pour la délivrance de certificats d’AEO, la procédure suivante doit être suivie :

• L’AEL remplit le formulaire de demande de déploiement d’un AEO et/ ou d’un BE qui précise notamment les informations nécessaires à l’enregistrement d’un AEO et du BE si aucun bureau d’enregistrement n’a encore été déployé.

• L’AEL transmet la demande à l’AE dans le respect des processus internes à l’entité.

• L’AE valide les formulaires de demande et les transmet à l’Opérateur AEC de l’AC déléguée. Il est préconisé l’usage de formulaire de demande signé ou de courrier électronique signé.

• L’Opérateur AEC de l’AC déléguée contrôle et valide les informations.

• L’Opérateur AEC de l’AC déléguée accepte ou refuse la demande certificat.

• L’Opérateur AEC de l’AC déléguée transmet les informations de la demande à l’AC déléguée.

Abonnés

La procédure d’enregistrement complète nécessite un face à face avec l’Abonné ou de son Représentant. A l’issue du face à face, les certificats demandés par l’Abonné lui sont remis sur le support requis : carte à puce ou autre support (disquette, clé USB) à la convenance du représentant de l’ dans le cadre d’une demande de certificats logiciels pour les Abonnés D. Une procédure exceptionnelle peut être mise en œuvre si l’Abonné ne peut se déplacer auprès de son AEO, pour raison de déplacement, par exemple. Il est du ressort de l’AEO de s’assurer de la délivrance dans des conditions de confiance des supports et données d’activation.

Pour la délivrance de certificats à l’Abonné de type A ou D, la procédure suivante doit être suivie :

• L’Abonné ou la DRH remplit un formulaire EBI en suivant la procédure mise en place dans son entité.

• Si l’Abonné ne délègue pas l’enregistrement à un Représentant :

- L’AEO convoque l’Abonné et l’authentifie.

- L’Abonné fournit à l’AEO les pièces justificatives attestant de son identité (cf §3.1.10).

• Si l’Abonné délègue l’enregistrement à un Représentant :

- L’AEO convoque le Représentant et l’authentifie.

- Le Représentant fournit à l’AEO les pièces justificatives attestant de son identité et de sa représentativité de l’Abonné (cf §3.1.10).

• L’AEO contrôle et valide les informations.

• L’AEO accepte ou refuse la demande de certificat.

• L’AEO s’authentifie auprès de l’AC.

• L’AEO enregistre l’ensemble des pièces du dossier d’enregistrement et envoie les demandes de certificats validées à l’AC déléguées .



Pour la délivrance de certificats à l’Abonné de type B ou C, la procédure suivante doit être suivie :

• L’AD de l’entreprise hors groupe Thales remplit le formulaire de demande de certificat et l’envoie au demandeur entité du groupe Thales par courrier électronique signé.

• Si l’Abonné est présent dans les locaux du groupe Thales :

- L’AEO convoque l’Abonné et l’authentifie.

- L’Abonné fournit à l’AEO les pièces justificatives attestant de son identité (cf §3.1.10).

• Si l’Abonné n’est pas présent dans les locaux du groupe Thales :

- L’AEO effectue les étapes restantes du processus sans la présence de l’Abonné.

• L’AEO contrôle et valide les informations.

• L’AEO accepte ou refuse la demande de certificat.

• L’AEO s’authentifie auprès de l’AC déléguée.

• L’AEO transmet les informations de la demande validée et la requête de certification à l’AC déléguée.

En cas d’acceptation de la demande, la procédure se poursuit par l’émission du certificat tel que décrit au §4.2.

Note : le service d’enregistrement des Abonnés est disponible les jours ouvrables de 9h00 à 18h00.

4.2 Emission de certificat

Les dispositions relatives à l’émission de certificat sont celles édictées dans la PC de référence.

Pour l’émission du certificat de signature de l’AC déléguée, se référer à [DPCACR_CASIC].

Pour l’émission des certificats des composantes techniques, la procédure ci-dessous doit être suivie :

• Le CA s’assure que la demande a été émise par l’Opérateur AEC et que celui-ci a été dûment authentifié par l’AC déléguée..

• Le CA génère le certificat.

• La génération de certificat s’effectue avec une ressource matérielle cryptographique et le processus de génération de certificat doit être lié de manière sécurisée au processus de génération de clés si les clés ne sont pas générées par la composante.

• L’Opérateur AEC de l’AC déléguée remet la carte à puce contenant le bi-clé et le certificat ainsi que le code PIN associé à la carte à puce ou le fichier contenant le bi-clé et le certificat protégé par passe-phrase.

• L’authentification pour la remise est identique à celle décrite au §3.1.9.

L’ensemble des communications entre les différentes composantes est protégé en confidentialité et en intégrité (PKIX, protocole interne).



Composantes AEO

Pour l’émission des certificats des composantes AEO, la procédure ci-dessous doit être suivie :

• Le CA au travers de son interface d’enregistrement auquel l’Opérateur AEC de l’AC déléguée s’est authentifié, reçoit une demande de certificat de la part de l’AE conformément au §4.1 de la présente DPC.



• L’Opérateur AEC de l’AC déléguée transmet par courrier la carte à puce cryptographique contenant le certificat à l’AEO.

• L’Opérateur AEC de l’AC déléguée transmet par courrier avec accusé de réception les codes PIN des cartes à puce AEO à l’AEL.

• L’Opérateur AEC de l’AC déléguée émet un compte-rendu de réalisation de l’opération, contenant la référence du BE pour lequel des certificats AEO ont été émis, par courrier électronique signé à l’AE, l’AEL et au RCSSI.

• L’AEL remet les courriers de code PIN aux AEO après authentification de l’AEO sur présentation de son badge nominatif du groupe Thales ou de sa pièce d’identité légale et de sa carte à puce AEO.


Abonnés :

Pour l’émission des certificats d’Abonnés, la procédure ci-dessous doit être suivie :

• Le CA reçoit une demande de certificat de la part de l’AEO conformément au §4.1 de la présente DPC. Cette demande de certificat a été authentifiée et contrôlée par les différentes composantes d’AC déléguée ;

• Gestion des clés privées :

- Pour les clés d’authentification et de signature matérielles d’Abonnés (type A, B, C, D si l’entité technologique supporte des carte à puce) : ces clés sont générées préalablement à la demande de certificat à l’AC déléguée par la carte à puce destinée à l’Abonné.

- Pour les clés de confidentialité d’Abonnés (type A, B, C) : ces clés sont générées logiciellement par le BE puis stockées sur la carte à puce destinée à l’Abonné.

- Pour les clés d’authentification et de signature logicielles d’Abonnés (type D) : ces clés sont soit :

• pré-générées par l’entité technologique lui-même et l’attestation de clé privée est assurée par le fichier PKCS#10 remis par l’équipement pour l’obtention de son certificat ;

• générées logiciellement par le BE si l’entité technologique ne sait pas produire un bi-clé d’un bon niveau de confiance ;





• Le CA transmet le certificat à Unicert RA qui le transmet à l’AEO.

• Le CA publie le certificat dans l’annuaire.

• Dans le cas particulier des opérations consécutives à la génération de certificat de confidentialité, le CA au travers de la composante RA met sous séquestre la clé privée de confidentialité associée .

• La délivrance de la clé privée est réalisée conformément à la PC de référence.

• L’AEO remet à l’Abonné la carte à puce contenant le bi-clé et le certificat et lui demande d’en modifier le code PIN ou le fichier contenant le bi-clé et le certificat protégé par passe-phrase.

• L’authentification pour la remise est identique à celle décrite au §3.1.10.


4.3 Acceptation de certificat

Les dispositions relatives à à l’acceptation de certificat sont celles édictées dans la PC de référence.


CA

L’acceptation du certificat est effective par le biais de la signature de l’AA de l’AC déléguée ou de la personne mandatée par l’AA de l’AC déléguée du document de cérémonie des clés de l’AC déléguée (ou PV d’initialisation / renouvellement des clés).

Composantes techniques

L’acceptation d’un certificat par une composante s’effectue par le biais d’une signature du document de cérémonie des clés (ou PV d’initialisation / renouvellement des clés).

L’acceptation du certificat d’Autorité Administrative est effective par le biais de la signature de l’AA de l’AC déléguée du document de cérémonie des clés (ou PV d’initialisation / renouvellement des clés).

L’acceptation de certificat par les autres Opérateurs des composantes (hors AEO) s’effectue au travers l’acceptation de la fonction d’exploitation vis-à-vis de l’AC déléguée qui lui a été attribuée par l’OSC.

Composantes AEO

L’AEO accepte implicitement le certificat et déclare avoir pris connaissance des obligations qui le lient à l’IGC et des pratiques mises en œuvre au niveau de l’AC déléguée auquel il est rattaché, par le biais de l’acceptation de la charte informatique du groupe Thales annexée au règlement interne de l’entreprise et de l’acceptation de la fonction d’exploitation vis-à-vis de l’AC déléguée qui lui a été attribuée par l’entité de Thales à laquelle elle appartient.

Abonnés :



L’Abonné accepte implicitement le certificat et déclare avoir pris connaissance des obligations qui le lient à l’IGC et des pratiques mises en œuvre au niveau de l’AC auquel il est rattaché, par le biais de l’acceptation de la charte informatique du groupe Thales annexée au règlement interne de l’entreprise pour les Abonnés de type A ou D et par le biais de la signature du contrat d’adhésion à l’IGC de Thales pour les Abonnés de type B et C. Ces obligations sont celles définies ci-dessous :

• Les obligations et responsabilités de chacun des acteurs, édictées dans la PC de référence.

• Les termes et conditions régissant l’AC déléguée et ses composantes (PC de référence et la présente DPC).

• La publication du certificat de l’Abonné (et sous quelles conditions), édictées dans la présente DPC (§2.5).

• Les chapitres liés à la procédure d’enregistrement, édictée dans la présente DPC (§3.1 et 4.1).

• Les chapitres liés à la procédure de révocation, édictée dans la présente DPC (§3.4).

• Les chapitres liés à la procédure de résolution de litiges, édictée dans la présente DPC (§2.3.2).

4.4 Suspension, révocation et recouvrement de certi ficat

4.4.1 Causes possibles de révocation

Les causes possibles de révocation sont celles édictées dans la PC de référence.

4.4.2 Personnes pouvant demander une révocation

Les dispositions relatives aux personnes pouvant demander une révocation sont celles édictées dans la PC de référence.


Les personnes pouvant demander une révocation sont identifiées ci-dessous :

• Pour les composantes techniques :

- L’AA de l’AC déléguée dont dépend la composante.

• Pour les AEO :

- L’AA de l’AC déléguée dont ils dépendent.

- L’AE.

- L’AEL.

- L’AEO lui-même.

• Pour les Abonnés :

- L’AE.

- L’AA de l’AC déléguée dont ils dépendent.

- L’Abonné lui-même.



- La DRH pour les Abonnés A.

- L’AD pour les Abonnés B et C.

4.4.3 Procédure de demande de révocation

Les dispositions relatives à la procédure de demande de révocation sont celles édictées dans la PC de référence.


Une fois que le certificat est révoqué, il ne peut être réutilisé.

Remarque : Il ne peut y avoir de re-certification de la même clé publique d’AC déléguée, de la composante ou de l’Abonné même pour une révocation suite à un changement de nom ; la re-génération du certificat entraîne automatiquement la re-génération du bi-clés.

Après une révocation, les clés associées au certificat révoqué doivent être détruites.

CA

La procédure de révocation du certificat de signature d’une AC déléguée est la suivante :

• L’AA de l’AC déléguée se présente en face à face auprès de l’Opérateur AEC de l’ACR pour demander la révocation de son certificat.

• L’Opérateur AEC de l’ACR authentifie l’AA de l’AC déléguée (cf. §3.1.9).

• L’Opérateur AEC de l’ACR procède à la révocation à travers son interface d’enregistrement auquel l’Opérateur AEC s’est authentifié.

• L’ACR produit, signe et publie l’ARL.

• L’Opérateur AEC de l’ACR informe l’AA de l’AC déléguée du nouveau statut de son certificat.

Composantes techniques

• L’Opérateur AEC de l’AC déléguée authentifie en face à face le responsable sécurité dénommé par la suite Officier Sécurité Système Information (OSSI) de la composante à révoquer (cf. §3.1.9).

• L’Opérateur AEC de l’AC déléguée s’authentifie auprès du CA.

• L’Opérateur AEC de l’AC déléguée procède à la révocation du certificat à travers son interface d’enregistrement.

• L’Opérateur AEC de l’AC déléguée informe l’OSSI de la composante de la réalisation de l’opération de révocation.

Opérateurs (hors AEO)



La révocation nécessite une authentification en face à face de l’Opérateur auprès de l’AEC de l’AC déléguée sauf si la cause de révocation est due à la fin de contrat de travail de l’Opérateur chez l’OSC.

La procédure de révocation d’un Opérateur est la suivante :

• L’Opérateur AEC de l’AC déléguée authentifie l’Opérateur détenteur du certificat à révoquer dans le cas d’une révocation nécessitant un face à face.


• L’Opérateur AEC de l’AC déléguée révoque le certificat de l’Opérateur concerné à travers son interface d’enregistrement.

• L’Opérateur AEC de l’AC déléguée informe l’Opérateur concerné ou l’OSC de la réalisation de l’opération de révocation.

Préalablement à la requête de demande de révocation de certificat du premier Opérateur AEC d’AC déléguée , l’AA de l’AC déléguée doit fournir :

• Un courrier de demande de révocation du premier Opérateur d’AC déléguée signé par l’AA de l’AC déléguée.

La révocation ne nécessite pas une authentification en face à face de l’AA de l’AC déléguée auprès de l’AEC de l’AC déléguée.

La révocation de ce certificat ne peut s’opérer que si au moins un autre Opérateur AEC de niveau équivalent (ayant des droits similaires à ceux du premier opérateur) est déclaré et est valide auprès de l’AC déléguée. Si ce n’est pas le cas, la génération d’un tel exploitant doit précéder la révocation du certificat du premier Opérateur AEC d’AC déléguée.

Composantes AEO

• L’AEO ou l’AEL (en cas de compromission) ou l’AE transmet par courrier électronique signé la demande de révocation d’un certificat AEO à l’Opérateur AEC de l’AC déléguée.

• L’Opérateur AEC de l’AC déléguée authentifie l’AEO ou l’AEL ou l’AE (cf. §3.1.9).


• L’Opérateur AEC de l’AC déléguée procède à la révocation à travers son interface d’enregistrement.

• L’Opérateur AEC de l’AC déléguée émet un compte-rendu de réalisation de l’opération par courrier électronique signé à l’AE, l’AEL et à l’AEO dont le certificat est révoqué.

Abonnés :

Le demandeur de la révocation doit :

• Appeler un opérateur du help desk.

• Décliner son identité

• L’opérateur fait jouer le jeu de qustions réponses.

• L’opérateur révoque les certificats associés à la carte



Les demandes de révocation doivent être traitées dès réception.

Si l’authentification de demande est effectuée a posteriori, il est possible de retarder la révocation du certificat. Le délai de révocation est équivalent au temps nécessaire pour pouvoir authentifier la demande. Si l’authentification de la demande est réussie, il est possible de confirmer par la suite qu’il y a bien révocation.

Il est à noter qu’en cas de révocation de clés sur carte à puce, les clés doivent être effacées de la carte ou celle-ci doit être détruite (par découpe de la puce) par l’Abonné ou l’AEO.

En cas de révocation de clés logicielles, l’Abonné s’engage à détruire les clés (par suppression du fichiers de stockage des clés).

La révocation d’un certificat d’une carte à puce entraîne la révocation de l’ensemble des certificats de la carte à puce. Il ne peut pas y avoir de révocation partielle du contenu d’une carte à puce.

4.4.4 Temps de traitement d’une demande de révocati on

Les dispositions relatives au temps de traitement d’une demande de révocation sont celles édictées dans la PC de référence.


Le délai de traitement d’une demande de révocation est de 24 heures en jour ouvrable et ne peut pas dépasser quatre jour ouvrés.

Composantes d’AC déléguée

Le service de révocation auprès de l’AC déléguée n’est disponible que durant les jours ouvrables de 9h00 à 18h00.

Abonnés :

Le service de révocation auprès des AEO est disponible durant les jours ouvrables de 9h00 à 18h00.

4.4.5 Causes possibles de suspension

Sans Objet.

4.4.6 Personnes pouvant demander une suspension

Sans Objet.

4.4.7 Procédure de demande de suspension

Sans Objet.

4.4.8 Limites de la période de suspension

Sans Objet.

4.4.9 Fréquence de publication des CRL

Les dispositions relatives à la fréquence de publication des CRL sont celles édictées dans la PC de référence.


Cf. §2.5.2.



La CRL inclut la date de publication de la prochaine CRL. Cette date couvre une période de validité de 4 jours afin de s’assurer que la CRL ne puisse être obsolète à l’occasion d’une fin de validité hors des jours ouvrables et en cas de défaillance de l’AC déléguée ou du service de publication durant ces jours.

4.4.10 Exigences de vérification des CRL

Les dispositions relatives aux exigences de vérification des CRL sont celles édictées dans la PC de référence.



Il appartient à chaque composante de l’AC déléguée de vérifier le statut de son certificat ainsi que des certificats participants de la chaîne de certification. Ce contrôle doit être réalisé au moins à chaque démarrage d’une composante et quotidiennement si possible.

Abonnés :

Il appartient aux Abonnés de vérifier le statut de leur certificat ainsi que des certificats participants à la chaîne de certification. Ce contrôle doit être réalisé au moins quotidiennement.

Un certificat se trouvant dans la CRL ne peut plus être utilisé sauf pour, postérieurement à l’apparition du certificat dans la CRL, authentifier ou contrôler la signature d’un document signé par la clé privée associée utilisée durant sa validité et préalablement à sa révocation quelque soit la raison de la révocation.

Par contre, il ne peut être possible, de déchiffrer postérieurement à l’apparition du certificat dans la CRL, un message chiffré avec le certificat de confidentialité durant sa période de validité et préalablement à sa révocation, du fait que l’Abonné a l’obligation de détruire sa clé privée à l’issue de son renouvellement ou de sa révocation. Il sera donc de son ressort préalablement à une demande de renouvellement ou de révocation de procéder au déchiffrement de tous ses documents chiffrés par le certificat en fin de validité.

Exceptionnellement, un déchiffrement peut être réalisé à l’issue d’une opération de recouvrement.

De la même manière, les UC doivent vérifier au moins quotidiennement la CRL pour les certificats de signature et d’authentification. Il est préconisé que les certificats de confidentialité soient contrôlés par rapport à une CRL à jour à chaque usage de ceux-ci.

En cas d’indisponibilité temporaire des CRL nécessaires à la vérification d’un certificat, l’utilisateur du certificat (Abonné ou UC), doit considérer le certificat comme potentiellement non valide. Il doit, si possible, différer le traitement du document signé par le certificat, ou en cas d’impossibilité d’attente, considérer la signature comme invalide.

4.4.11 Publication des causes de révocation

Les dispositions relatives à la publication des causes de révocation en ligne sont celles édictées dans la PC de référence.

4.4.12 Vérification en ligne de la révocation

Les dispositions relatives à la vérification en ligne de la révocation sont celles édictées dans la PC de référence.




La capacité de contrôle en ligne dépend de la disponibilité de l’annuaire et du service Web pour lequel le taux d’indisponibilité de l’annuaire et du service Web ne peut dépasser 24 heures maximum consécutives.

Abonnés :

Les CRL intègrent les dates présumées de compromission qui peuvent être antérieures à la date de révocation effective et donc antérieure à la date de publication de la nouvelle CRL. Il appartient donc aux Abonnés, dans la mesure du possible, de contrôler cette date dans les CRL publiées.

4.4.13 Autres formes de publication des avis de rév ocation

Sans Objet.

4.4.14 Autres formes de publication des avis de rév ocation – exigences de vérification

Sans Objet.

4.4.15 Exigences spéciales en cas de révocation pou r compromission des clés

Les dispositions relatives aux exigences spéciales en cas de révocation pour compromission des clés sont celles édictées dans la PC de référence.

4.4.16 Causes possibles de recouvrement

Les dispositions relatives aux causes possibles de recouvrement sont celles édictées dans la PC de référence.


Le recouvrement concerne exclusivement les clés de confidentialité des Abonnés.

4.4.17 Personnes pouvant demander un recouvrement

Les dispositions relatives aux personnes pouvant demander un recouvrement sont celles édictées dans la PC de référence.

4.4.18 Procédure de demande de recouvrement

Les dispositions relatives à la procédure de demande de recouvrement sont celles édictées dans la PC de référence.


Préalablement à la demande de recouvrement, le demandeur du recouvrement doit :

• Se procurer le formulaire de demande de recouvrement.

• Remplir l’ensemble des informations demandées.

La demande doit être formulée au niveau du BE ayant délivré le certificat de confidentialité.

Les demandes formulées au niveau du BE doivent être transmises à une AEL ou une AE qui valide la demande et la transmet à l’Opérateur de recouvrement par courrier électronique signé.

Les demandes remises à l’AEL, à l’AE ou à l’Opérateur de recouvrement sont contrôlées et validées par celui-ci. Un contrôle consiste à vérifier que le document à déchiffrer est un document produit préalablement à une révocation potentielle du certificat. Dans le cas contraire, une confirmation doit être demandée à l’AA de l’AC déléguée ou toute personne mandatée par l’AA de l’AC déléguée.



Procédure du recouvrement de clés de confidentialité :

• L’AE ou l’AEL authentifie la demande de recouvrement au moyen d'une signature numérique valide reconnue par les Opérateurs de l’AC déléguée et la transfert à l’Opérateur de recouvrement.

• L’Opérateur de recouvrement s’authentifie et réalise une requête de recouvrement.

• Une clé recouvrée ainsi que le certificat associé sont exportés sous la forme d’un fichier PKCS#12 protégé par une passe-phrase ou sur une carte à puce dont le code PIN est modifié par l’Opérateur de recouvrement (le code PIN doit différent du code PIN par défaut).

• Le fichier PKCS#12 ou la carte à puce est transmise par courrier au demandeur du recouvrement.

• La passe-phrase ou le code PIN protégeant les clés recouvrées est transmis par courrier avec accusé de réception à l’AEO du BE dont dépend le demandeur.

4.4.19 Temps de traitement d’une demande de recouvr ement

Les dispositions relatives au temps de traitement d’une demande de recouvrement sont celles édictées dans la PC de référence.


Les demandes de recouvrement doivent être traitées dès réception.

Le service de recouvrement est disponible durant les jours ouvrables de 9h00 à 18h00 au niveau de l’AC déléguée.

Le délai de traitement d’une demande de recouvrement est d’au maximum 5 jours ouvrés.

4.5 Journalisation des évènements

La journalisation d’évènements est réalisée par les composantes des AC déléguées gérant des données des Abonnés .

Les AEO n’ont pas d’obligations spécifiques de journalisation d’événements à respecter.

Les Abonnés n’ont pas non plus d’obligations spécifiques de journalisation d’événement à respecter relativement à l’usage de leur certificat.

4.5.1 Types d’évènements enregistrés

Les dispositions relatives aux types d’évènements enregistrés sont celles édictées dans la PC de référence.


A la liste des données enregistrées décrites dans la PC de référence, s’ajoutent l’enregistrement sur la main courante ou registre, les opérations de maintenance physique et autres opérations physiques exceptionnelles portées sur la composante et pour lesquelles les données suivantes sont consignées :

• Date de l’événement

• Nom du demandeur de l’opération.

• Nom des personnes présentes.



• Nom de l’événement tel que : installation/désinstallation, cérémonie, destruction physique de secrets, …

Ces opérations doivent être consignées dans la mesure où le système d’information n’est pas disponible pour opérer lui-même la tracabilité des opérations (journaux du système d’exploitation Windows ou journaux de l’IGC).

Les anomalies détectées dans le déroulement des procédures (par exemple, impossibilité de révoquer un certificat parce que l’AC n’est pas joignable) sont consignées manuellement dans un journal selon les procédures décrites dans la DPC – ANNEXE au §2.1.1.

4.5.2 Fréquence des traitements de journalisation

Les dispositions relatives à la fréquence des traitements de journalisation sont celles édictées dans la PC de référence.


La journalisation des événements doit être enregistrée dès que les opérations auxquelles ils se rapportent sont réalisées.

Les fréquences de contrôle des journaux sont traitées dans la DPC – ANNEXE au §2.1.1..

Les réactions sur incidents sont décrites dans la DPC – ANNEXE au §2.1.1.

4.5.3 Durée de conservation des journaux d’évènemen ts

Les dispositions relatives à la durée de conservation des journaux sont celles édictées dans la PC de référence.


Les journaux sont archivés pendant un (1) mois calendaire sur le poste informatique, puis dix (10) ans sur le site de rétention des archives.

4.5.4 Protection d’un journal d’évènements

Les dispositions relatives à la protection d’un journal d’évènements sont celles édictées dans la PC de référence.


Les événements générés par les composantes sont protégés en intégrité par les moyens techniques inhérents à la solution IGC, durant leur stockage sur le poste informatique. Pour la période, hors poste informatique, les documents papier et supports informatiques sont conservés sous clefs dans des zones à accès contrôlé. La protection applicable est présentée au §4.6.3 pour les Abonnés et dans la DPC – ANNEXE au §2.2.3 pour les AC déléguées et leurs composantes .

4.5.5 Copie de sauvegarde des journaux d’évènements

Les dispositions relatives à la copie de sauvegarde des journaux d’évènements sont celles édictées dans la PC de référence.


Une sauvegarde des journaux d’événements est effectuée tous les jours automatiquement sur chaque AC déléguée et ses composantes disposant de journaux. Les sauvegardes différentielles s’effectuent à chaud (c’est à dire les applicatifs IGC étant en fonctionnement) 4 jours sur 5 et une sauvegarde complète s’effectue à froid (c’est à dire applicatifs IGC arrêtés) une fois par semaine.



Une copie de la sauvegarde complète doit être réalisée de manière organisationnelle. Cela peut s’effectuer au travers d’une 2ème opération de sauvegarde complète à l’issue de la première, ou par copie de supports par des moyens externes.

Après analyse du contenu des journaux d’événements, ceux-ci sont archivés conformément à la procédure indiquée au §4.5.4 pour les Abonnés et dans la DPC – ANNEXE au §2.2.3 pour les AC déléguées et les composantes d’AC, pour une durée indiquée au §4.6.2 pour les Abonnés et dans la DPC – ANNEXE au §2.2.2 pour les AC déléguées et leurs composantes .

4.5.6 Système de collecte des journaux (interne ou externe)

Les dispositions relatives au système de collecte des journaux (interne ou externe) sont celles édictées dans la PC de référence .

4.5.7 Imputabilité des évènements

Les dispositions relatives à l’imputabilité des événements sont celles édictées dans la PC de référence.


Pour chaque journalisation enregistrée devront figurer :

• Le nom de la personne ayant effectué l’opération.

• Le rôle de la personne ayant effectué l’opération.

• La date de l’opération.

• Le niveau de gravité.

• Le type d’événement.

• Le numéro de séquence de l’événement.

4.5.8 Analyse des vulnaribilités

Les dispositions relatives à l’analyse des vulnérabilités sont celles édictées dans la PC de référence.


L’analyse des vulnérabilités est décrite dans la DPC – ANNEXE au §2.1.1.

4.6 Archives des dossiers

4.6.1 Types de données à archiver

Les dispositions relatives aux types de données à archiver sont celles édictées dans la PC de référence.


AC déléguées et composantes d’AC de Thales S.A :

Les données archivées par les AC déléguées sont les suivantes :

• La PC de référence (papier)



• La présente DPC (papier).

• Les agréments contractuels ou les conventions avec l’AC Racine

• Les logiciels et les fichiers de configuration des équipements informatiques des AC déléguées et de ses composantes.

• Les journaux d'événements de l’AC déléguée et de ses composantes (supports informatiques ou éventuellement papier).

• Les certificats tels qu'émis ou publiés (dans la limite ou le demandeur a donné son consentement).

• La CRL telle qu'émise ou publiée.

• Les notifications de révocation.

Les données archivées par la composante RA sont les suivantes :

• Les logiciels et les fichiers de configuration des équipements informatiques la constituant.

• Les demandes de révocation de certificats.

• Les notifications de révocation.

Les données archivées par le BE sont les suivantes :

Aucune donnée spécifique à archiver

Les autres types de données à archiver des AC déléguées et des composantes d’AC déléguées de Thales S.A sont décrits dans la DPC – ANNEXE au §2.2.1.

Abonnés :

Les données à archiver par l’Abonné sont les suivantes :

• Accords contractuels (dans le cadre des Abonnés B et C), conventions ou charte informatique.

• Certificats d’utilisateurs et de composantes.

• Données d’identifications personnelles.

• Ensemble des éléments utiles à l’enregistrement.

Les contenus et formats des demandes Abonnés sont ceux applicables dans l’entité hébergeant le BE.

4.6.2 Période de rétention des archives

Les dispositions relatives à la période de rétention des archives sont celles édictées dans la PC de référence.





Les données archivées par l’AC déléguée :

La PC de référence 10 ans

La présente DPC 10 ans

Les agréments contractuels ou les conventions avec l’AC Racine

10 ans

Les logiciels et les fichiers de configuration des équipements informatiques de l’AC déléguée et de ses composantes

10 ans

Les journaux d'événements de l’AC déléguée et de ses composantes

10 ans

Les certificats tels qu'émis ou publiés (dans la limite ou le demandeur a donné son consentement) y compris les certificats d’AEO

10 ans

La CRL telle qu'émise ou publiée 10 ans

Les notifications de révocation de ses composantes, des opérateurs des composantes en central, et des AEO.

10 ans

Les données archivées par la composante Unicert RA sont les suivantes :

Les logiciels et les fichiers de configuration des équipements informatiques constituant les composantes techniques

durée de validité de la version des logiciels

Les demandes de révocation de certificats 10 ans

Les notifications de révocation 10 ans

Les données archivées par la composante Unicert KAS sont les suivantes :

Les logiciels et les fichiers de la composante technique durée de validité de la version des logiciels

Les journaux d'événements de la composante technique 10 ans

Les bi-clés et les certificats de confidentialité des Abonnés chiffrés (logiciel)

10 ans

Les demandes de recouvrement 10 ans

Les autres périodes de rétention des archives des AC déléguées et des composantes d’AC de Thales S.A sont décrits dans la DPC – ANNEXE au §2.2.2.



Les données archivées par le BE sont les suivantes :

Aucune donnée spécifique à archiver

Abonnés :

Accords contractuels (pour Abonnés B et C), conventions ou charte informatique

Fin de vie des certificats en possession de l’Abonné

Certificats d’utilisateurs et de composantes Fin de vie des certificats en possession de l’Abonné

Données d’identifications personnelles Fin de vie des certificats en possession de l’Abonné

Ensemble des éléments utiles à l’enregistrement Fin de vie des certificats en possession de l’Abonné

4.6.3 Protection des archives

Les dispositions relatives à la protection des archives sont celles édictées dans la PC de référence.


AC déléguées et composantes d’ AC de Thales S.A :

La protection des archives des AC déléguées et des composantes d’AC de Thales S.A est décrite dans la DPC – ANNEXE au §2.2.3.

Abonnés :

Les documents papier et supports informatiques sont conservés sans application de protection particulière.

Les données archivées sur support informatique doivent pouvoir être exploitées soit directement dans le cas d’un support papier soit au travers de l’utilisation d’un éditeur de texte (format ASCII).

Les archives sont récupérables sous un délai de 10 jours.

4.6.4 Procédures de copie des archives

Les dispositions relatives aux procédures de copie des archives sont celles édictées dans la PC de référence.

4.6.5 Besoins d’horodatage des enregistrements

Les dispositions relatives aux besoins d’horodatage des enregistrements sont celles édictées dans la PC de référence.



Les besoins d’horodatage des enregistrement des AC déléguées et des composantes d’AC de Thales S.A sont décrites dans la DPC – ANNEXE au §2.2.4.

BE et Abonnés :



Aucune exigence d’horodatage spécifique n’est applicable aux BE et Abonnés.

4.6.6 Système de collecte des archives (interne ou externe)


Le système de collecte des archives des AC déléguées et des composantes d’AC de Thales S.A est décrit dans la DPC – ANNEXE au §2.2.5.

BE et Abonnés :

Aucune exigence sur le système de collecte des archives n’est applicable aux BE et Abonnés.

4.6.7 Procédures de récupération des archives

Les dispositions relatives aux procédures de récupération des archives sont celles édictées dans la PC de référence.


AC déléguées et composantes d’AC de Thales S.A. :

Les procédures de récupération des archives des AC déléguées et des composantes d’AC de Thales S.A sont décrites dans la DPC – ANNEXE au §2.2.6.

BE et Abonnés :

Aucune exigence de récupération d’archives n’est applicable aux BE et Abonnés.

4.7 Changement de clé d’une composante

Les dispositions relatives au changement de clé d’une composante sont celles édictées dans la PC de référence.



Pour garantir une durée de validité suffisante pour tous les certificats d’Abonnés (1, B et C : 5 ans et D : 2 ans ) durant le cycle de vie du certificat de l’AC déléguée (10 ans), le certificat courant de l’AC déléguée doit être renouvelé avant que sa durée de validité restant à courir ne devienne inférieure à la durée de validité des certificats d’Abonnés, soit au bout de 10 ans. L’AC doit demander le renouvellement de son bi-clé dans les trois mois précédant cette date.

Une composante possède une clé privée de signature unique avec laquelle sont effectuées toutes les opérations d’échange de données ou de certification. Le certificat portant la clé publique associée à la clé privée unique de chaque composante est le certificat « courant » de la composante.

Chaque certificat de composantes est régénéré à la même fréquence que les certificats d’AC déléguée de Thales S.A dont elles dépendent.

Selon la nature du changement (fin de période de validité de clés, renouvellement de clé suite à une révocation, …), les mesures prises doivent respecter les procédures de traitement énoncées dans les chapitres correspondants.

Abonnés :



Le changement de clé d’une composante hormis en cas de révocation d’une composante, n’affecte pas les Abonnés. En effet les mécanismes de tuilage mis en œuvre au sein des AC déléguées assurent, qu’aucun changement de clé de composante n’induira une révocation de certificat d’Abonné signé par la clé en fin de vie.

En cas de changement de clé de la composante pour cause de compromission, l’Abonné doit suspendre l’utilisation de ses certificats dès notification de la compromission par e-mail par l’AA de l’AC déléguée concernée. De nouveaux certificats lui seront délivrés dès que l’IGC sera remise en fonctionnement et de nouveaux certificats de composantes générés.

4.8 Récupération en cas de désastre ou de compromis sion

Les dispositions relatives à la récupération en cas de désastre ou de compromission sont celles édictées dans la PC de référence .



Les précisions concernant la récupération en cas de désastre ou de compromission des AC déléguées et des composantes d’AC de Thales S.A sont décrites dans la DPC – ANNEXE au §2.3.

Abonnés :

Il n’y a pas de plan anti-sinistre applicable aux Abonnés.

En cas de désastre sur l’IGC dont dépend l’Abonné, ce sinistre n’affecte pas directement l’Abonné. Il peut continuer à utiliser ces certificats dans la limite de validité de la CRL. Dès que la CRL n’est plus valide, il est de la responsabilité des Abonnés de choisir s’ils veulent utiliser leurs certificats. L’AA ne prendra aucune responsabilité en cas d’utilisation frauduleuse de certificats.

En cas de compromission de l’IGC, il n’y a pas de récupération possible applicable aux Abonnés. Ils doivent cesser toute utilisation de leurs certificats dès notification du problème par l’AA de l’ AC déléguée.

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

Les dispositions relatives à la corruption des ressources informatiques, des logiciels et / ou des données sont celles édictées dans la PC de référence.



La corruption des ressources informatiques, des logiciels et / ou des données des AC déléguées et des composantes d’AC de Thales S.A est traitée dans la DPC – ANNEXE au §2.3.1.

Aucune contrainte n’est appliquée au niveau des BE.

4.8.2 Révocation de la clé publique d’une composant e

Les dispositions relatives à la révocation de la clé publique d’une composante sont celles édictées dans la PC de référence .

4.8.3 Compromission des clés de la composante

Les dispositions relatives à la compromission de la clé publique d’une composante sont celles édictées au §4.8.2.



4.8.4 Mesure de sécurité an cas de sinistre


La mesure de sécurité en cas de sinistre des AC déléguées et des composantes d’AC de Thales S.A est décrite dans la DPC – ANNEXE au §2.3.2.

4.9 Cessation d’activité d’une composante

Les dispositions relatives à la cessation d’une composante sont celles édictées dans la PC de référence.


AC déléguée et composantes d’AC de Thales S.A :

Avant de cesser son activité, l’AC déléguée ou la composante concernée doit communiquer son intention 3 mois avant la cessation effective.

Les composantes affiliées à cette AC déléguée ainsi que les Utilisateurs de Certificats (UC) sont avertis par l’autorité dont ils dépendent directement. En cas de fin de vie de l’AC déléguée, l’AC doit procéder à la révocation des composantes qui lui sont affiliées.

Si les opérations d’une AC déléguée sont transférées à une autre AC, l’AA de l’AC déléguée devra préalablement s’assurer que celle-ci permet d’avoir le même niveau d'assurance.

Cette dernière devra s’engager à conserver les archives de la composante en fin de vie selon les indications et la période stipulées dans la DPC – ANNEXE au §2.2.

Les Abonnés sont avertis par l’Autorité d’Administration (AA) de l’AC déléguée dont ils dépendent directement.

Abonnés :

A réception d’un message de cessation d’activité de l’AC déléguée, les Abonnés doivent cesser l’utilisation de tous certificats émis sous la responsabilité de cette AC déléguée en cessation d’activité.



5 Contrôle de sécurité physique, contrôle des procé dures, contrôle du personnel

Le contrôle de sécurité physique, le contrôle des procédures et le contrôle du personnel sont réalisés par les responsables de la sécurité de l’OSC de chaque AC déléguée de Thales S.A.

Les Abonnés n’ont pas d’obligations spécifiques de contrôle de sécurité physique, de contrôle des procédures et de contrôle du personnel à respecter.

5.1 Contrôles physiques

5.1.1 Situation géographique et construction de sit es

Les dispositions relatives à la situation géographique et construction des sites sont celles édictées dans la PC de référence.

Des précisions concernant la situation géographique et construction des sites sont traitées dans la DPC – ANNEXE au §2.4.1.

5.1.2 Accès physique

Les dispositions relatives à l’accès physique sont celles édictées dans la PC de référence.

Des précisions concernant l’accès physique sont traitées dans la DPC – ANNEXE au §2.4.2.

5.1.3 Energie et air conditionné

Les dispositions relatives à l’énergie et l’air conditionné sont celles édictées dans la PC de référence.

Des précisions concernant l’énergie et air conditionné sont traitées dans la DPC – ANNEXE au §2.4.3.

5.1.4 Exposition aux liquides

Les dispositions relatives à l’exposition aux liquides sont celles édictées dans la PC de référence.

5.1.5 Prévention et protection incendie

Les dispositions relatives à la prévention et protection incendie sont celles édictées dans la PC de référence.

Des précisions concernant la prévention et protection incendie sont traitées dans la DPC – ANNEXE au §2.4.4.

5.1.6 Conservation des médias

Les dispositions relatives à la conservation des médias sont celles édictées dans la PC de référence, au §5.1.3 et dans la DPC – ANNEXE au §2.4.3.

Des précisions concernant la conservation des médias sont traitées dans la DPC – ANNEXE au §2.4.5.

5.1.7 Destruction des déchêts

Les dispositions relatives à la destruction des déchets sont celles édictées dans la PC de référence.



5.1.8 Site de recouvrement

Les dispositions relatives au site de recouvrement sont celles édictées dans la PC de référence.

5.2 Contrôle des procédures

5.2.1 Rôles de confiance

Les dispositions relatives aux rôles de confiance sont celles édictées dans la PC de référence.

Les précisions concernant les rôles de confiance sont traitées dans la DPC – ANNEXE au §2.5.1.

5.2.2 Nombre de personnes nécessaires à chaque tâch e

Les dispositions relatives au nombre de personnes nécessaires à chaque tâche sont celles édictées dans la PC de référence.

Les précisions concernant le nombre de personnes nécessaires à chaque tâche sont traitées dans la DPC – ANNEXE au §2.5.2.

Note : les tableaux ci-après utilisent les termes suivants :

• (1) : Administrateur (ADMIN)

• (2) : Opérateur (OP)

• (3) : Responsable sécurité (OSSI)

• (6) : Ingénieur Système (IS)

Les procédures d’exploitation des BE seront définies dans le manuel d’installation et configuration d’une part pour ce qui relève de l’installation et le manuel d’utilisation d’autre part. Il est à noter que ce dernier document identifie un certain nombre de problèmes (notamment réseau) qui peuvent être rencontrés par les opérateurs ainsi que les opérations à réaliser pour rétablir le fonctionnement.

Les procédures sont mises en œuvre conformément au tableau suivant :

Opérations Autorisations requises

Nb ADMIN(1) Nb OP(2) Nb OSSI(3) Nb IS (6)

Installation de la plate-forme du BE - 1 1 1

Intégration des bi-clés et des certificats générés par l’AC déléguée

- 1 - -

Authentification des Abonnés - 1 - -

Enregistrement des demandes de certificats des Abonnés

- 1 - -

Distribution de cartes à puce (avec bi-clés et - 1 - -



certificats associés) ou fichiers PKCS#12

Enregistrement des demandes de révocation - 1 - -

Notification de révocation de certificat - 1 - -

5.2.3 Identification et authentification des rôles

Les dispositions relatives à l’identification et l’authentification des rôles sont celles édictées dans la PC de référence.


Une fois ces personnels autorisés par l’AA de l’AC déléguée de Thales S.A, un certificat et une carte à puce leur sont délivrés, permettant ainsi de les identifier et les authentifier dans l’infrastructure déléguée.

5.3 Contrôle du personnel

5.3.1 Passé professionnel, qualifications, exigence s d’habilitations

Les dispositions relatives au passé professionnel, qualifications, exigences d'habilitations sont celles édictées dans la PC de référence.

Des précisions concernant le passé professionnel, qualifications, exigences d’habilitations sont traitées dans la DPC – ANNEXE au §2.6.1.

5.3.2 Procédures de contrôle du passé professionel

Les dispositions relatives au contrôle du passé professionnel sont celles édictées dans la PC de référence.

5.3.3 Exigences de formation

Les dispositions relatives aux exigences de formation sont celles édictées dans la PC de référence.

5.3.4 Fréquence des formations

Les dispositions relatives à la fréquence des formations sont celles édictées dans la PC de référence.

5.3.5 Gestion des métiers

Les dispositions relatives à la gestion des métiers sont celles édictées dans la PC de référence.

5.3.6 Sanctions pour des actions non autorisées

Les dispositions relatives aux sanctions pour des actions non autorisées sont celles édictées dans la PC de référence.


Sur faute avérée ou soupçonnée d’un membre gérant une composante dans l’accomplissement de ses tâches en rapport avec l’exploitation d’autres composantes, le Responsable Sécurité en concertation avec les autorités compétentes doit lui interdire l’accès au système et, le cas échéant, prendre toutes sanctions disciplinaires adéquates.



5.3.7 Contrôle des personnels des entité possédant un BE

Les dispositions relatives au contrôle des personnels des BE sont celles édictées dans la PC de référence.

5.3.8 Contrôle des personnels des entreprises contr actantes

Sans Objet.

5.3.9 Documentation fournie au personnel

Les dispositions relatives à la documentation fournie au personnel sont celles édictées dans la PC de référence.



6 Contrôles techniques de sécurité

6.1 Génération et installation des clés

6.1.1 Génération des clés

6.1.1.1 Génération de paires de clés Les dispositions relatives à la génération des clés sont celles édictées dans la PC de référence.



Le bi-clé de signature d’AC déléguée est un bi-clé RSA. Dans le cadre de la présente IGC, un deuxième bi-clé d’AC déléguée est généré à des fins d’usage interne de signature des journaux.

Les bi-clés de signature sont des bi-clés RSA.

Les bi-clés des Opérateurs d’AC déléguée sont des bi-clés RSA générées par la carte à puce cryptographique.

Abonnés :

La génération des clés des Abonnés dépend de leur nature :

• Pour les clés d’authentification et de signature carte à puce d’Abonnés (type A, B, C, D) : les bi-clés de signature et d’authentification de l’Abonné sont produits par la carte à puce qui lui est attribuée lors de la procédure d’enregistrement en face à face avec l’AEO.

• Pour les clés d’authentification et de signature logicielles d’Abonnés (type D) : les bi-clés de signature et d’authentification de l’Abonné sont pré-générés par l’équipement lui-même et l’attestation de clé privée est assurée par le fichier PKCS#10 remis par l’équipement pour l’obtention de son certificat.

• Pour les clés d’authentification et de signature logicielles d’Abonnés (type D) ne pouvant produire de bi-clé d’un bon niveau de confiance : les bi-clés de signature et d’authentification de l’Abonné sont générés logiciellement par le BE.

• Pour les clés de confidentialité d’Abonnés (type A, B, C) : les bi-clés de confidentialité de l’Abonné sont produits logiciellement par le BE puis stockés sur la carte à puce qui lui est attribuée lors de la procédure d’enregistrement en face à face avec l’AEO.

6.1.2 Délivrance de clé privée à son propriétaire

Les dispositions relatives à la délivrance de clé privée à son propriétaire sont celles édictées dans la PC de référence.


AEO :

Il ne s’agit pas de délivrance de clés privées proprement dites, celles-ci étant directement générées par la carte à puce, mais de délivrance des données d’activation (code PIN) qui sont choisies par l’OSC et transmises à l’AEL.



Abonnés :

La délivrance de clé privée est applicable dans les cas suivants :

• Pour les clés de confidentialité d’Abonnés (type A, B, C) : ces clés générées par le BE sont remis aux Abonnés sous forme d’un fichier PKCS#12 introduit dans la même opération sur carte à puce

• Pour les clés d’authentification et de signature logicielles d’Abonnés (type D) ne pouvant produire de bi-clé d’un bon niveau de confiance : ces clés générées le BE sont remises aux Abonnés D sous forme d’un fichier PKCS#12 protégé par une passe-phrase choisie par l’Abonné.

Pour tous les autres cas, les clés sont générées par les cartes à puce elle-même et le code d’activation de ses cartes choisi par l’Abonné lui-même.

6.1.3 Délivrance de clé publique à une AC

Les dispositions relatives à la délivrance de clé publique à une AC sont celles édictées dans la PC de référence.


AC déléguées de Thales S.A :

La délivrance de la clé publique, requête de certification signée à l’aide de la clé privée correspondant à la clé publique (PKCS#10), s’effectue par disquette au travers de l’interface d’enregistrement (cf. §4.1).

Composantes d’AC de Thales S.A :

La délivrance de la clé publique des composantes d’AC déléguée est effectuée au travers d’une requête de certification signée à l’aide de la clé privée correspondant à la clé publique (PKCS#10). Cette opération s’effectue par disquette lors de l’enregistrement auprès de l’AC déléguée concernée (cf. §4.1).

Abonnés :

La délivrance de la clé publique des Abonnés à l’AC déléguée est effectuée au travers d’une requête de certification signée à l’aide de la clé privée correspondant à la clé publique (PKCS#10). Cette opération s’effectue lors de l’enregistrement auprès du BE concerné (cf. §4.1), soit par extraction du PKCS#10 de la carte à puce, s’il s’agit de clé de certification sur ressource matérielle, soit par génération du PKCS#10 par l’AEO dans le cas de clé de certification logicielle, soit par fourniture du PKCS#10 dans le cas d’équipement générant ses propres clés privées, ce PKCS#10 étant ensuite transmis signé par l’AEO émettrice par réseau.

6.1.4 Tailles des clés

Les dispositions relatives à la taille des clés sont celles édictées dans la PC de référence.


Les empreintes SHA-1 sont codées sur 20 octets.

6.1.4.1 Génération de paires de clés Les dispositions relatives à la génération de paires de clés sont celles édictées dans la PC de référence.



6.1.5 Paramètres de génération des clés publiques

Les dispositions relatives aux paramètres de génération des clés publiques sont celles édictées dans la PC de référence.


L’entité qui génère un bi-clé génère également les paramètres de clé publique. Aucune trace des paramètres de génération n’est conservée.

6.1.6 Contrôle de qualité des paramètres de clés pu bliques

Les dispositions relatives au contrôle de la qualité des paramètres des clés publiques sont celles édictées dans la PC de référence.

6.1.7 Mode de génération de clé (matérielle ou logi cielle)

Les dispositions relatives au mode de génération de clé (matérielle ou logicielle) sont celles édictées dans la PC de référence.



La ressource cryptographique utilisée par l’AC déléguée est une carte THALES e-Security WebSentry qui répond aux recommandations de la norme FIPS140-1 niveau 4.

Abonnés :

Les cartes à puce des Abonnés sont des cartes à puce Cosmo Dual emulation Mifare 1Ko d’OberthurCS évalués EAL 4+.

6.1.8 Usage de la clé privée

Les dispositions relatives à l’usage de la clé privée sont celles édictées dans la PC de référence.



Le champ « keyUsage » du certificat doit être utilisé conformément au profil des certificats :

Objet Valeur du champ keyUsage

Clé de signature AC déléguée Certificate Signing

CRL Signing

Clé d’ AC déléguée d’usage interne Digital Signature

Non Repudiation

Composantes techniques Digital Signature

Non Repudiation



AEO et autres opérateurs de l’AC déléguée Digital Signature

Non Repudiation

Abonnés :

Le champ « keyUsage » du certificat doit être utilisé conformément au profil des certificats :

Objet Valeur du champ keyUsage

Abonné Authentification (type A, B, C) Non Repudiation

Key Agreement

Digital signature

Abonné Signature (type A, B, C) Digital Signature

Non Repudiation

Abonné Confidentialité (type A, B, C) Key Encipherment

Data Encipherment

Abonné (type D) Digital Signature

Non Repudiation

Key Encipherment

Data Encipherment

6.2 Protection de la clé privée

Les dispositions relatives à la protection de la clé privée sont celles édictées dans la PC de référence.

6.2.1 Normes pour les modules cryptographiques

Les dispositions relatives à les normes pour les modules cryptographiques sont celles édictées dans la PC de référence.



Les modules cryptographiques Thales e-Security WebSentry et cartes à puce utilisées par les composantes utilisent les algorithmes RSA et SHA-1 conformément sa normalisation :

• RSA : norme ANSI X 9-31 et PKCS#1 v2.1

• SHA-1 : norme FIPS PUB 180-1 et ANSI X9.30 (partie 2)

Abonnés :



Les cartes à puce utilisées par les composantes utilisent les algorithmes RSA et SHA-1 conformément sa normalisation :

• RSA : norme ANSI X 9-31 et PKCS#1 v2.1

• SHA-1 : norme FIPS PUB 180-1 et ANSI X9.30 (partie 2)

6.2.2 Contrôle de clé privée par plusieurs personne s

Les dispositions relatives au contrôle de clé privée par plusieurs personnes sont celles édictées dans la PC de référence.


Des précisions concernant le contrôle de clé privée par plusieurs personnes des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.7.1.

6.2.3 Récupération de clé privée

Les dispositions relatives à la récupération de clé privée sont celles édictées dans la PC de référence.


Des précisions concernant récupération de clé privée des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.7.2.

Abonnés :

Seule la récupération des clés de confidentialité est possible. Les §4.4.16 à 4.4.19 détaillent les exigences opérationnelles liées aux recouvrement.

6.2.4 Sauvegarde de clé privée

Les dispositions relatives à la sauvegarde de clé privée sont celles édictées dans la PC de référence.


Des précisions concernant la sauvegarde de clé privée des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.7.3.

Abonnés :

La clé privée de confidentialité des Abonnés est archivée par le service d’archivage de clés

Les dispositions relatives à l’archive de clé privée sont celles édictées dans la PC de référence.


L’archive de clé privée des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.7.4.

Abonnés :

La clé privée de confidentialité d’un Abonné de type A, B et C est archivée et conservée pendant la durée de vie et la période de rétention des archives de l’AC déléguée et de ses composantes.



6.2.5 Initialisation de clé privée dans le module c ryprographique

Les dispositions relatives à l’initialisation de clé privée dans le module cryptographique sont celles édictées dans la PC de référence.


L’initialisation de clé privée dans le module cryptographique des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.7.5.

Abonnés :

Cette opération ne s’applique qu’aux clés de confidentialité matérielles des Abonnés. Cette opération a lieu lors de l’introduction par le BE, d’une clé privée de confidentialité dans une carte à puce, dans la phase d’enregistrement d’un Abonné, et lors d’un recouvrement d’une clé privée d’un Abonné. L’opération de transfert est protégée par des moyens organisationnels et techniques :

• En confidentialité : par le fait que le BE ou le service d’archivage de clés sont des postes à utilisation restreinte, qu’ils sont exploités dans le respect des conditions de sécurité et d’accès et que leurs opérateurs en charge de l’initialisation de la carte à puce se sont préalablement authentifiés auprès de l’IGC.

• En intégrité : par un contrôle avant initialisation dans le module cryptographique de la correspondance clé privée / clé publique.

6.2.6 Méthode d’activation de clé privée

Les dispositions relatives à la méthode d'activation de la clé privée sont celles édictées dans la PC de référence.



Des précisions concernant la méthode d’activation de clé privée des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.7.6.

Abonnés :

L’activation de la clé privée de l’Abonné stockée sur carte à puce s’effectue à l’aide d’un code d’activation (code PIN).

Les clés privées logicielles détenues par les Abonnés doivent être activées après saisie d’une passe-phrase.

6.2.7 Méthode de désactivation de clé privée

Les dispositions relatives à la désactivation de clé privée sont celles édictées dans la PC de référence.



Des précisions concernant la méthode de désactivation de clé privée des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.7.7.

Abonnés :



L’Abonné s’engage à ne jamais quitter son poste de travail en le laissant dans un état qui permette d'utiliser sa clé privée sans utiliser un secret approprié.

Pour les cartes à puce, la désactivation est opérationnelle après 5 saisies erronées du code d’activation voir aussi au §6.4.3.

6.2.8 Méthode de destruction de clé privée

Les dispositions relatives à la méthode de destruction de clé privée sont celles édictées dans la PC de référence.


Des précisions concernant la méthode de destruction de clé privée des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.7.8.

Abonnés :

La destruction de la clé privée sur carte à puce est réalisée :

• Pour les cartes à puce : découpe de carte à puce incluant une découpe de la puce ou suppression des clés dans la puce dans le cas où la carte avec ses informations graphiques restent attribuées à l’Abonné.

• Pour des clés logicielles, moyens d’effacement sécurisé nettoyage des disques durs par les moyens mis en place au sein de l’entreprise.

6.3 Autres aspects de la gestion des paires de clés

6.3.1 Archive des clés publiques

Les dispositions relatives à l’archive des clés publiques sont celles édictées dans la PC de référence.


L’archivage des clés publiques revient à archiver les certificats correspondants générés par l’AC déléguée.

6.3.2 Durée de vie des clé publiques et privées

Les dispositions relatives à la durée de vie des clés publiques et privées sont celles édictées dans la PC de référence.



La durée de vie des clés privées des AC déléguées est de 10 ans.

La durée de vie des clés publiques des AC déléguées est de 10 ans.

La durée de vie des clés privées des composantes d’AC est de 10 ans.

La durée de vie des clés publiques des composantes d’AC est de 10 ans.

La durée de vie des clés privées des composantes AEO est de 2 ans.



La durée de vie des clés publiques des composantes AEO est de 2 ans.

Abonnés :

La durée de vie des clés privées de l’Abonné est de 2 ans (D) et 5 ans (A, B et C).

La durée de vie des clés publiques de l’Abonné est de 2 ans (D) et 5 ans (A, B et C).

6.4 Données d’activation

6.4.1 Génération et installation des données d’acti vation

Les dispositions relatives à la génération et installation des données d’activation sont celles édictées dans la PC de référence.



La génération et installation des données d’activation des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.8.1.

Abonnés :

La délivrance de la carte à puce de l’Abonné s’effectuant en face à face, la remise de la carte est conditionnée par le changement immédiat du code PIN initial par un nouveau code choisi exclusivement par l’Abonné.

Si l’Abonné ne peut se déplacer et que son représentant effectue l’enregistrement en face à face, la carte est remise au représentant après modification du code PIN par l’AEO qui communique ce code par courrier avec accusé de réception directement à l’Abonné.

De la même manière, lors d’un recouvrement de clé de confidentialité, l’opérateur du recouvrement communique, par courrier avec accusé de réception, au demandeur du recouvrement le code PIN ou la passe-phrase permettant le déblocage de la clé privée stockée respectivement dans la carte à puce ou dans le fichier PKCS#12.

La délivrance du fichier PKCS#12 à l’Abonné de type D s’effectuant en face à face, l’AEO convie l’abonné à choisr la passe-phrase de protection du fichier avant la remise du à l’Abonné.

6.4.2 Protection des données d’activation

Les dispositions relatives à la protection des données d’activation sont celles édictées dans la PC de référence.



La protection des données d’activation des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.8.2.

Abonnés :

La protection des codes d’activation est du ressort de l’Abonné.



6.4.3 Autres aspects des données d’activation

Les dispositions relatives aux autres aspects des données d’activation sont celles édictées dans la PC de référence.



Les autres aspects des données d’activation des AC déléguées et des composantes d’AC sont décrites dans la DPC – ANNEXE au §2.8.3.

Abonnés :

Le code PIN de la carte à puce d’Abonné requiert une longueur d’au moins quatre (4) caractères alphanumériques.

La passe-phrase pour l’activation de clés logicielles requiert une longueur d’au moins huit (8) caractères dont des chiffres, des lettres et des caractères spéciaux.

Le blocage du module (carte à puce) doit s’effectuer de manière définitive après 5 tentatives infructueuses. Il est cependant possible, de débloquer une carte à puce par renseignement du code Administrateur. La procédure à suivre est la suivante :

Déblocage en ligne

Le processus concerne uniquement le possesseur de carte

1. Le possesseur de carte appelle le help desk

2. L’opérateur du helpdesk fait jouer le jeu de questions réponse concernant l’utilisateur concerné

3. Le code de déblocage est affiché à l’opérateur qui le communiqué à l’utilisateur

4. Le possesseur de carte entre le code

5. A l’authentification le possesseur de carte doit changer son code PIN

6. La carte est débloquée et le code PIN changé

Déblocage hors ligne

Le processus concerne uniquement le possesseur de carte et un opérateur via téléphone

1. Le possesseur de carte génère sur son poste un code de pré déblocage.

2. Le possesseur de carte appelle le support et communiqué les choses suivantes :

information:

3. son identité;

4. le numéro de série de la carte;

5. son code de pré déblocage;

6. L’opérateur se connecte au système et à partir des informations retrouve l’utilisateur.



7. L’opérateur fait jouer le jeu de questions réponses

8. L’utilisateur répond aux questions.

9. L’opérateur entre le code de pré déblocage.

10. Le code de déblocage est affiché à l’opérateur qui le communiqué à l’utilisateur

11. Le possesseur de carte entre le code

12. La carte est débloquée.

6.5 Contrôles de sécurité des postes de travail

Les dispositions relatives aux exigences de sécurité des postes de travail sont celles édictées dans la PC de référence.

Abonnés :

Aucune exigence n'est stipulée pour le poste de travail de l'Utilisateur d'un certificat. Cependant, les Abonnés et les UC devront prendre toutes les mesures leur permettant de satisfaire à leurs obligations (cf. §2.1).

Par conséquent, le présent chapitre n’est applicable qu’aux AC déléguées et leurs composantes.

6.5.1 Exigences de sécurité spécifiques sur les pos tes de travail

Les dispositions relatives aux exigences de sécurité spécifiques sur les postes de travail sont celles édictées dans la PC de référence.

Des précisions concernant les exigences de sécurité spécifiques que les postes de travail des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.9.1.

6.5.2 Niveau de sécurité postes de travail

Les dispositions relatives à l’identification et l’authentification des rôles sont celles édictées dans la PC de référence.

6.5.2.1 Identification L’identification sur les postes de travail des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.9.2.1.

6.5.2.2 Authentification L’authentification sur les postes de travail des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.9.2.2.

6.5.2.2.1 Génération et initialisation des données d’activation La génération et initialisation des données d’activation des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.9.2.2.1.

6.5.2.2.2 Protection des données d’activation La protection des données d’activation des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.9.2.2.2.

6.5.2.2.3 Autres aspects des données d’activation Les autres aspects des données d’activation des AC déléguées et des composantes d’AC sont décrites dans la DPC – ANNEXE au §2.9.2.2.3.



6.5.2.3 Lutte anti-virus La lutte anti-virus des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.9.2.3.

6.5.2.4 Accès réseau L’accès réseau des AC déléguées et des composantes d’AC est décrite dans la DPC – ANNEXE au §2.9.2.2.4.

6.6 Contrôles techniques du système durant son cycl e de vie

Abonnés :

Aucune exigence n'est stipulée pour le poste de travail de l'Utilisateur d'un certificat. Cependant, les Abonnés et les UC devront prendre toutes les mesures leur permettant de satisfaire à leurs obligations décrites dans la PC de référence.

Par conséquent, le présent chapitre n’est applicable qu’aux AC déléguées et leurs composantes.

6.6.1 Contrôles des développements des systèmes

Les dispositions relatives aux contrôles des développements des systèmes sont celles édictées dans la PC de référence.

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

Les dispositions relatives aux contrôles de la gestion de la sécurité sont celles édictées dans la PC de référence.


Des précisions concernant les contrôles de la gestion de la sécurité des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.10.1.

6.7 Contrôles de la sécurité réseau

Les dispositions relatives aux contrôles de la sécurité réseau sont celles édictées dans la PC de référence.



Des contrôles de la sécurité des AC déléguées et des composantes d’AC sont traitées dans la DPC – ANNEXE au §2.11.

6.8 Contrôles de la gestion du module cryptographiq ue

Les dispositions relatives aux contrôles de la gestion du module cryptographique sont celles édictées dans la PC de référence.



Les modules cryptographiques utilisés par les composantes sont conformes aux normes définies au §6.1.7.



7 Profils de certificats et de CRL

7.1 Profil des certificats

Les dispositions relatives au profil des certificats émis sont celles édictées dans la PC de référence.


Abonnés :

Champ Util. Crit. Contenu

Certificate Fields

tbsCertificate Oui Ensemble des champs décrits au §7.1 et §7.1.2 et signés par l’AC avec sa clé privée.

signature Algorithm Oui Identifiant de l’algorithme utilisé pour produire la signature du certificat.

signatureValue Oui Résultat de la signature sur l’ensemble des champs de tbsCertificate.

TBSCertificate

version Oui “2” (pour X.509 version 3).

serialNumber Oui Le numéro de série pourra être obtenu par l’utilisation d’une fonction « one-way ». Dans ce cas, l’unicité du numéro de série sera vérifiée.

signature Oui Ce champ est une structure composée du champ algorithmIdentifier, elle-même composée du champ algorithm, complété avec l'identifiant (OID) de l'algorithme utilisée par l’AC pour signer le certificat. L'algorithme utilisé est le RSA avec l'OID 1.2.840.113549.1.1.5 (sha-1WithRSAEncryption, Identifier for SHA-1checksum with RSA encryption for use with Public Key Cryptosystem One defined by RSA Inc.). Le champ parameters n’est pas utilisé pour le RSA.

issuer Oui Le nom distinctif de l’autorité de certification signataire du certificat.

validity Oui Dates d’activation et d’expiration du certificat.

notBefore Oui Date d’activation du certificat.

UTCTime Oui Le format UTCTime est utilisé. Ne pas générer de certificat dont les secondes sont 00.

GeneralizedTime Non

NotAfter Oui Date d’expiration du certificat.



UTCTime Oui Le format UTCTime est utilisé. Ne pas générer de certificat dont les secondes sont 00.

GeneralizedTime Non

subject Oui Le nom distinctif du porteur de certificat.

subjectPublicKeyInfo Oui Ce champ est une structure composée du champ algorithmIdentifier, elle-même composée du champ algorithm, qui définit l’identifiant (OID) de l’algorithme pour lequel le certificat est émis, complété avec l’OID 1.2.840.113549.1.1.1 (OID description: rsaEncryption, Identifier for RSA encryption for use with Public Key Cryptosystem One defined by RSA Inc.). Le champ parameters n’est pas utilisé pour le RSA. Le champ subjectPublicKey contient la clé du porteur de certificat.

issuerUniqueID Non

subjectUniqueID Non

7.1.1 Numéro de version

Les dispositions relatives au numéro de version des certificats émis sont celles édictées dans la PC de référence.

7.1.2 Extensions du certificat

Les dispositions relatives aux extensions des certificats émis sont celles édictées dans la PC de référence.


Abonnés :


Standard Extensions

AuthorityKeyIdentifier Oui Non Identifie la clé publique utilisée pour vérifier la signature sur un certificat. Il permet de différencier les clés utilisées par une même AC.

keyIdentifier Oui

authorityCertIssuer Non

AuthorityCertSerialNumber Non

SubjectKeyIdentifier Non Non

KeyUsage Oui Oui Voir à la suite du tableau

digitalSignature Oui Valeur 0 ou 1.



nonRepudiation Oui Valeur 0 ou 1.

keyEncipherment Oui Valeur 0 ou 1.

dataEncipherment Oui Valeur 0 ou 1

keyAgreement Non Valeur 0 ou 1

keyCertSign Non Valeur 0

CRLSign Non Valeur 0

encipherOnly Non Valeur 0 ou 1

decipherOnly Non Valeur 0 ou 1.

PrivateKeyUsagePeriod Non Non

NotBefore Non

GeneralizedTime Non

NotAfter Non

GeneralizedTime Non

certificatePolicies Oui Oui Définit les politiques de certification que le certificat reconnaît supporter.

policyIdentifier Oui Identifiant (OID) de la politique de certification tel que défini au §1.4.

CPSuri Oui URL où se trouve une version écrite de la politique de certification tel que défini dans la PC.

userNotice Oui Brève description de la politique de certification.

PolicyMappings Non Non

issuerDomainPolicy Non Utilisé dans les certificats d’AC lorsque l’extension est utilisée.

subjectDomainPolicy Non Utilisé dans les certificats d’AC lorsque l’extension est utilisée.

SubjectAltName Oui Non Contirnt le courriel de l’utilisateur

otherName Oui

rfc822Name Oui

dNSName Non

x400Address Non

directoryName Non

ediPartyName Non



uniformResourceIdentifier Non

iPAddress Non

registeredID Non

IssuerAltName Non Non

otherName Oui

rfc822Name Oui

dNSName Non

x400Address Non

directoryName Non

ediPartyName Non

uniformResourceIdentifier Non

iPAddress Non

registeredID Non

SubjectDirectoryAttributes Non Non

BasicConstraints Non Non

cA Non Non 0

pathLenConstraint Non Non

NameConstraints Non Non

permittedSubtrees Non Non

base Non Non

minimum Non Non Valeur comprise entre 0 et max. Si rien n’est précisé, la valeur de 0 est mise par défaut.

maximum Non Non

excludedSubtrees Non Non

base Non Non

minimum Non Non Valeur comprise entre 0 et max. Si rien n’est précisé, la valeur de 0 est mise par défaut.

maximum Non Non

PolicyConstraints Non Non

requireExplicitPolicy Non Non



inhibitPolicyMapping Non Non

extendedKeyUsage Oui Non

serverAuth Oui

clientAuth Oui

codeSigning Oui

emailProtection Oui

timeStamping Oui

ipsecEndSystem Oui

ipsecTunnel Oui

ipsecUser Oui

cRLDistributionPoints Oui Non

distributionPoint Oui

reasons Oui

cRLIssuer Oui

Private Internet Extensions

authorityInfoAccess Oui Non

accessMethod Oui

accessLocation Oui

Un champ additionnel non critique(propriétaire Microsoft) est rajouté « SmartCard Logon » excepté pour les usagers de type C.

7.1.3 Identificateurs des objets algorithmes

Les dispositions relatives aux identificateurs des objets d’algorithmes sont celles édictées dans la PC de référence.

7.1.4 Format des noms

Les dispositions relatives au format des noms sont celles édictées dans la PC de référence.



La politique de DN retenue dans le cadre des certificats d’AC et de leurs composantes est celle définie au §3.1.2.

Abonnés :



La politique de DN retenue dans le cadre du certificat Abonné est la suivante :

UID=TGI Abonné, E=Email Abonné, CN=Nom Prénom, O=Thales

Où :

• UID : < LCCCCCCC>, où L est une lettre et C un chiffre

• Email (E) : Ppp.NNNàDETCOM> où Ppp représente le prénom de l’Abonné, NNN représente le nom de l’Abonné et DETCOM représente le nom de domaine de l’entité du groupe Thales dont fait partie l’Abonné

• Common Name (CN) : <NNN Ppp> où Ppp représente le prénom de l’Abonné tel qu’il est renseigné dans le premier champ de son adresse de messagerie et NNN représente le nom de l’Abonné tel qu’il est renseigné dans le deuxième champ de son adresse de messagerie

• Organisation (O) : <Thales>

7.1.5 Contraintes relatives aux noms

Les dispositions relatives aux contraintes de noms sont celles édictées au §7.1.2.

7.1.6 Identificateur d’objet de la politique de cer tification

L’identificateur de la PC est celui référencé au §1.4.

7.1.7 Usage d’extension de contraintes de politique

Les certificats émis dans le cadre de l’AC déléguée n’utilise pas d’extension de contraintes de politique.

7.1.8 Syntaxe et sémantique des qualificatifs de po litique

Un qualificateur de politique est défini pour la Politique de Certification (PC) indiquée dans l'extension certificatePolicies.

Ce qualificateur est une URL vers la version complète de la PC telle que définie dans la PC.

7.1.9 Sémantique de traitement pour l’extension cri tique de la politique de certification

Les dispositions relatives à la sémantique de traitement pour l’extension critique de la Politique de Certification sont celles édictées dans la PC de référence.

7.2 Profil de CRL


CRL Fields

tbsCertList Oui Ensemble des champs décrits au §7.2 et §7.2.2. L’AC doit apposer avec sa clé privée un sceau sur le certificat. Ce sceau est le résultat d’une fonction mathématique appliquée sur ce champ.

signature Algorithm Oui Identifiant de l’algorithme utilisé pour produire le sceau d’intégrité de la liste.



signatureValue Oui Résultat de cet algorithme sur l’ensemble des champs de tbsCertList.

TBSCertList

version Oui “1” (pour X.509 version 2).

signature Oui Signature de l’AC pour authentifier la CRL, complétée avec l’identifiant (OID) de l’algorithme utilisé pour signer le certificat.

issuer Oui Le nom distinctif de l’autorité de certification signataire du certificat.

thisUpdate Oui Date de génération de la CRL.

nextUpdate Oui Date de la génération de la prochaine mise à jour de la CRL.

revokedCertificates Oui Liste des certificats révoqués. Chaque certificat révoqué est identifié avec les champs userCertificate complété avec le numéro de série de certificat révoqué et revocationDate complété avec la date de révocation du certificat.

7.2.1 Numéro de version

Les dispositions relatives au numéro de version de CRL sont celles édictées dans la PC de référence.

7.2.2 Extension des CRL

7.2.2.1 Extension prises en charge Les dispositions relatives aux extensions prises en charge sont celles édictées dans la PC de référence.


AC déléguées


Standard Extensions

AuthorityKeyIdentifier Oui Identifie la clé publique utilisée pour vérifier la signature sur un certificat et complété des champs authorityCertIssuer, authorityCertSerialNumber et keyIdentifier. Il permet de différencier les clés utilisées par une même AC.

CRLNumber Oui Incrémenté chaque fois qu’une CRL est modifiée.



7.2.2.2 Extension non prises en charge Sans Objet.



8 Administration des spécifications

Le présent chapitre définit les exigences en matière d’administration et de gestion de la présente Déclaration relative aux Pratiques de Certification.

8.1 Procédures de modification de la DPC

La DPC devra être revue en raison de projets de modifications suivants :

• Les modifications de PC.

• Les mises à jour ou suggestions de modifications sur la DPC.

• Les modifications du plan de sécurité ayant des impacts sur les procédures édictées par la présente DPC.

8.1.1 Articles pouvant être modifiés sans avis

Sans Objet.

8.1.2 Changement avec avis

Toutes modifications d’articles de la présente DPC doit être publiée dans une nouvelle version et approuvée par l’AA des AC déléguées.

Le processus de revue pour la modification et l’approbation de la DPC doit être documenté et mis en œuvre.

8.1.2.1 Liste des articles Tous les articles de la présente DPC peuvent être soumis aux exigences en matière d’avis énoncées au §8.1.1 et §8.1.2.

8.1.2.2 Mécanisme de notification Trente (30) jours calendaires avant que des modifications majeures ne soient apportées à la présente DPC, un avis concernant les prochaines modifications sera transmis de manière sécurisée à l’OSC par l’AA des AC déléguées.

L’avis devra énoncer :

• Les modifications proposées.

• La date finale de réception des commentaires.

• La date proposée d’entrée en vigueur des modifications.

L’AA des AC déléguées pourra demander aux AC déléguées d’aviser ses abonnés des modifications proposées.

8.1.2.3 Période de commentaire La période de commentaire sera de trente (30) jours calendaires, sauf indication contraire. La période de commentaires sera précisée dans l’avis.

8.1.2.4 Mécanisme de traitement des commentaires Les commentaires portant sur des changements proposés doivent être adressés à l’AA des AC déléguées. Ces communications doivent comporter une description et une justification du



changement, ainsi que les coordonnées, signature et fonction de la personne demandant le changement.

L’AA des AC déléguées acceptera en l’état, avec modifications ou rejettera le changement proposé une fois la période de commentaires terminée.

8.1.2.5 Période de l’avis définitif de modification L’AA des AC déléguées doit donner un préavis de trente (30) jours calendaires à l’OSC et aux Abonnés avant de procéder à tout changement de la présente politique qui, selon l’évaluation du responsable de la politique, ont un impact majeur sur eux.

L’AA des AC déléguées doit donner un préavis de quinze (15) jours calendaires à l’OSC et aux Abonnés avant de procéder à tout changement de la présente politique qui, selon l’évaluation du responsable de la politique, ont un impact mineur sur eux.

L’AA des AC déléguées doit donner un préavis à l’OSC et aux Abonnés dans les sept (7) jours calendaires d’un changement de la présente politique qui résulte d’une situation hors du contrôle du responsable de la politique, à condition que ce changement ait un impact sur eux.

En cas de changement intervenant dans la composition des AC déléguées ou de sa composante d’enregistrement, l’AA des AC déléguées doit prévenir l’OSC :

Au plus tard un (1) mois calendaire avant le début de l’opération si elle a un impact sur le niveau de qualité et de sécurité des fonctions des AC déléguées et d’une composante d’enregistrement vis à vis des certificats référencés.

Au plus tard un (1) mois calendaire après la fin de l’opération s’il n’ y a pas d’ impact.

8.2 Procédures de publication et de notification

La présente DPC est disponible dans les limites exposées au §2.5 depuis les sources suivantes :

• par téléchargement, à l’URL suivante : http://www.thalesgroup.com/certification_policy

Toute remarque sur la présente PC ou DPC associée est à adresser :

• soit par messagerie à l’adresse suivante : [email protected]

8.3 Procédures d’approbation de la DPC

L’AA des AC déléguées de Thales S.A nomme les personnes habilitées à déterminer la conformité de la DPC avec la PC de référence.

La décision de l’AA des AC déléguées de ne pas demander la révocation de ses certificats suite à la notification d'un changement proposé constitue l'acceptation du changement.