igc de thales politique de certification ac...

58
Thales S.A 45, rue de Villiers 92526 Neuilly-sur-Seine Cedex FRANCE IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINE : THALES ROOT CA DATE DE PUBLICATION : 15/04/2005 DATE D’APPLICABILITE : 15/04/2005

Upload: lammien

Post on 17-May-2018

220 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

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

IGC DE THALES

POLITIQUE DE CERTIFICATION AC RACINE :

THALES ROOT CA

DATE DE PUBLICATION : 15/04/2005 DATE D’APPLICABILITE : 15/04/2005

Page 2: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique
Page 3: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

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

INDEXATION DU DOCUMENT

PROJECT:

TITRE: IGC de Thales - Politique de certification AC Racine : Thales Root CA

REFERENCE: A4284000-DOC-075-PCACR

MOTS CLES: IGC de Thales

RESUME D’AUTEUR La Politique de Certification AC Racine définit l’ensemble des règles techniques et organisationnelles qui déterminent l’applicabilité d’un certificat délivré par l’Autorité de Certification Racine de Thales S.A

ACTION NOM DATE SIGNATURE

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

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

SUIVI DU DOCUMENT

INDICE DATE MODIFICATIONS NOM V1.0 14/04/05 Création Christel Réman

V2.0 10/06/09 Modification Laurent Broussy

Page 4: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 4 © Thales S.A 2009 – Tous droits réservés

Sommaire

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

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

1.1.1 Aperçu général ................................................................................... 13 1.1.2 Aperçu de la politique......................................................................... 13

1.2 Définitions générales............................................................................ 14 1.2.1 Définitions........................................................................................... 14 1.2.2 Définitions de la Politique sur la Sécurité........................................... 16

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

1.5.1 Applications concernées .................................................................... 18 1.5.2 Groupes d’utilisateurs concernés....................................................... 18 1.5.3 Applicabilité de la Politique................................................................. 21

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

2.1.1 Obligations communes à plusieurs composantes.............................. 22 2.1.2 Obligations de l’ACR .......................................................................... 22 2.1.3 Obligations de l’AE ............................................................................. 23 2.1.4 Obligations de l’AC déléguée............................................................. 24

2.2 Responsabilité ..................................................................................... 25 2.2.1 Exigences de moyens ........................................................................ 25 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................................................................................... 26 2.3.2 Règlement des différends .................................................................. 26

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

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

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 .............................................. 29 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 ........................................................ 30 2.7.5 Délivrance à la demande du propriétaire ........................................... 30 2.7.6 Autres circonstances de délivrance possible ..................................... 30

Page 5: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 5 © Thales S.A 2009 – Tous droits réservés

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

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

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

fabrique, de commerce et de services ............................................... 32 3.1.7 Preuve de possession d’une clé privée.............................................. 32 3.1.8 Vérification de l’identité de l’Organistation ......................................... 32 3.1.9 Vérification de l’identité d’une ACR ou d’une composante ................ 32 3.1.10 Vérification de l’identité des AC déléguées........................................ 32

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

4 Exigences opérationnelles.......................... .................................................... 34 4.1 Demande de certificat .......................................................................... 34 4.2 Emission de certificat ........................................................................... 34 4.3 Acceptation de certificat ....................................................................... 35 4.4 Suspension, révocation et recouvrement de certificat .......................... 35

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

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

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

4.5 Journalisation des évènements............................................................ 38 4.5.1 Types d’évènements enregistrés ....................................................... 38 4.5.2 Fréquence des traitements de journalisation ..................................... 39 4.5.3 Durée de conservation des journaux d’évènements.......................... 40 4.5.4 Protection d’un journal d’évènements ................................................ 40 4.5.5 Copie de sauvegarde des journaux d’évènements............................ 40 4.5.6 Système de collecte des journaux (interne ou externe)..................... 40

Page 6: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 6 © Thales S.A 2009 – Tous droits réservés

4.5.7 Imputabilité des évènements ............................................................. 40 4.5.8 Analyse des vulnaribilités ................................................................... 40

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

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

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

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

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

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

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

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

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

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

6.1.1 Génération des clés ........................................................................... 49 6.1.2 Délivrance de clé privée à une composante ...................................... 49 6.1.3 Délivrance de clé privée à son propriétaire........................................ 49 6.1.4 Délivrance de clé publique à une ACR .............................................. 49 6.1.5 Fourniture de la clé publique de validation de l’ACR aux

composantes ...................................................................................... 49

Page 7: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 7 © Thales S.A 2009 – Tous droits réservés

6.1.6 Fourniture de la clé publique de validation d’ACR aux utilisateurs .... 49 6.1.7 Tailles des clés................................................................................... 49 6.1.8 Paramètres de génération des clés publiques................................... 50 6.1.9 Contrôle de qualité des paramètres de clés publiques ...................... 50 6.1.10 Mode de génération de clé (matérielle ou logicielle).......................... 50 6.1.11 Usage de la clé privée........................................................................ 50

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

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

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

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

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

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

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

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

de certification .................................................................................... 56 7.2 Profil de CRL........................................................................................ 56

7.2.1 Numéro de version ............................................................................. 56 7.2.2 Extensions des CRL........................................................................... 56

8 Administration des spécifications.................. ................................................ 57 8.1 Procédures de modification de la PC ................................................... 57

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

Page 8: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 8 © Thales S.A 2009 – Tous droits réservés

8.1.2 Changement avec avis....................................................................... 57 8.2 Procédures de publication et de notification ......................................... 58 8.3 Procédures d’approbation de la PC...................................................... 58

Page 9: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 9 © Thales S.A 2009 – Tous droits réservés

Documents de référence

Index local Titre Référence

Documentation IGC de Thales

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

Textes réglementaires

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

[10181-1]

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

[2382-8]

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

[7498-2]

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

[8825-1]

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

[9594-1]

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

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

[9594-8]

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

[CERTIFICAT_IGC]

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

[D98-102]

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

[DECOUPAGE_IGC]

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

[DSE]

Page 10: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

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

Index local Titre Référence

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

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

[DUE]

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

[GOC]

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

[IGI1300]

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

[IGI900]

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

[L00-230]

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

[L78-19]

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

[PP_AC]

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

[PP_AE]

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

[PP_IGC]

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

[PP_OSM]

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

[PP_RCIGC]

Page 11: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 11 © Thales S.A 2009 – Tous droits réservés

Index local Titre Référence

chapitre 1.5.

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

[R901]

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

[RFC 2459]

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

[RFC 2527]

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

[ROLES_IGC]

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

[DEC]

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

[LCEN]

Page 12: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 12 © Thales S.A 2009 – Tous droits réservés

Politique de Certification IGC de Thales

Sans préjudice des droits réservés et sauf autorisation, aucune partie de ce document ne peut être ni reproduite, ni enregistrée ou introduite dans un système de consultation, ni transmise sous quelque forme ou par quelque moyen que ce soit sans la permission écrite de Thales S.A.

Toute autre demande de permission de reproduire et d’exemplaires de la présente Politique de Certification doit être adressée à Thales S.A en utilisant les moyens de communication définis au paragraphe 8.2.

Page 13: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 13 © Thales S.A 2009 – Tous droits réservés

1 Domaine d’application

Une Politique de Certification (PC) est un ensemble de règles identifié par un nom, qui indique les conditions d'applicabilité d'un certificat pour une communauté donnée, ou pour des applications ayant des besoins de sécurité communs.

La PC est définie indépendamment des détails concernant l'environnement de mise en oeuvre de l'infrastructure à clé publique (ICP) à laquelle elle s'applique. La PC établit ce à quoi il faut se conformer lors de la gestion des certificats concernés.

La gestion d'un certificat comprend toutes les phases du cycle de vie d'un certificat, de la demande d'attribution d'un certificat à la fin de vie de ce certificat (péremption, révocation).

Thales S.A met en place une Infrastructure de Gestion de Clés (IGC ou PKI pour Public Key Infrastructure), dénommée IGC de Thales, permettant la délivrance de certificats numériques aux Abonnés du Système d’Information du groupe.

1.1 Présentation générale

1.1.1 Aperçu général

Ce document constitue la Politique de Certification (PC) de l’Autorité de Certification Racine de l’Infrastructure de Gestion de Clés de Thales.

La Politique énoncée dans ce document est utilisée dans le cadre de la certification des Autorités de Certification déléguées de l’IGC de Thales par l’Autorité de Certification Racine de l’IGC de Thales Thales Root CA.

L’ACR pour gérer les différentes AC déléguées qu’elle certifie est identifiée de la manière suivante :

• Thales Root CA

La Politique de Certification définie dans le présent document est destinée à être utilisée pour les services de certification par les exploitants et opérateurs de l’infrastructure de l’ACR de l’IGC de Thales ainsi que les AC déléguées. Elle couvre l’initialisation de l’ACR, l’administration de l’infrastructure de l’ACR de l’IGC de Thales, la gestion et l’utilisation des clés et des certificats délivrés.

1.1.2 Aperçu de la politique

La Politique de Certification s’applique à tous les certificats de l’IGC de Thales certifiés par l’ACR.

Cette politique a été conçue pour être utilisée dans certaines situations, et indique par conséquence les rôles et responsabilités spécifiques de l’ACR qui délivre ce type de certificat, et ceux de l’Autorité d’Enregistrement qui doit effectuer les tâches qui lui sont assignées par l’ACR. Les AC déléguées (ce terme est défini au §1.2.1) ont également des obligations spécifiques qui sont définies dans cette politique.

Les Utilisateurs de ce document doivent consulter l’AA de l’ACR afin d’obtenir plus de détails sur la mise en œuvre de cette politique si cela est nécessaire. L’applicabilité de ces certificats dépendra de leurs utilisations envisagées.

Cette PC met en œuvre des certificats tels que définis ci-après :

Page 14: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 14 © Thales S.A 2009 – Tous droits réservés

• Le support de stockage des paires de clés est sous forme physique et utilise un module cryptographique matériel de type carte chiffre. Les certificats associés peuvent être ou non stockés dans ce module.

1.2 Définitions générales

1.2.1 Définitions

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.

Authority Revocation List (ARL)

Liste des certificats d’AC déléguée ayant fait l’objet d’une révocation.

Une ARL est une CRL ne contenant que des certificats d’AC.

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.

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

Autorité, subordonnée à l’Autorité de Certification Racine, chargée de créer et d’attribuer les certificats.

Dans ce document, l’AC déléguée est un demandeur de certificats auprès de l’ACR.

Autorité de Certification Racine (ACR)

AC prise comme référence par une communauté d’utilisateurs finaux (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 (AE)

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

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 cette PC, la chaîne se compose du certificat de l’AC déléguée et du certificat de l’ACR, AC à 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).

Page 15: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 15 © Thales S.A 2009 – Tous droits réservés

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 ACR, un serveur AE, …

Certificate Revocation List (CRL)

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

Distinguished Name (DN)

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

Données d’activation

Données privées associées à un détenteur de paire de clés 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 ACR pour la gestion des certificats.

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 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’Utilisateurs a confiance.

Politique de Certification (PC)

Ensemble de règles, définissant les exigences auxquelles l’ACR 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’ACR.

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 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.

Page 16: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 16 © Thales S.A 2009 – Tous droits réservés

Révocation (d’un certificat)

Opération demandée par l’AC déléguée, une composante de l’infrastructure de l’ACR de l’IGC de Thales ou une personne habilitée à cet effet, dont le résultat est la suppression de la caution de l’ACR 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 de publication

Le service de publication rend disponible les certificats de clés publiques émis par une AC, à l’ensemble des Utilisateurs 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.2.2 Définitions de la Politique sur la Sécurité

La politique de sécurité est l’ensemble des règles de sécurité applicables. On définit notamment :

Dossier de sécurité : définit les contraintes de sécurité appliquées à l’infrastructure ; ce dossier est validé par le GTSSI.

Procédure d’exploitation : Procédure des sites d’hébergement qui fixe les règles générales en matière de protection industrielle et définit la conduite à tenir dans les principaux cas d’espèces. Cette procédure s’applique à l’ensemble de la zone réservée hébergeant les AC et ses composantes localisées sur les sites d’hébergement, ainsi que l’infrastructure associée.

Zone d’enregistrement : zone utilisée pour les opérations d’enregistrement en mode face à face dont l’accès est contrôlé par le personnel habilité du groupe Thales.

Zone réservée : zone dont l’accès est restreint aux personnes qui y ont leur emploi, titulaires d’un code d’accès délivré par l’Agent de sécurité du site.

Zone à haute sécurité : zone dont l’accès est restreint aux personnes habilitées à effectuer des opérations très sensibles liés à la sécurité de l’IGC de Thales et de ses infrastructures chez l’OSC (Gestion de l’AC, Opération de recouvrement, Audit, …). La Zone à haute sécurité est incluse dans la zone réservée.

1.3 Liste des acronymes

Acronyme français

Définition française Acronyme anglais

Définition anglaise

Page 17: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 17 © Thales S.A 2009 – Tous droits réservés

AA Autorité d’Administration AA Administration Authority

AC Autorité de Certification CA Certification Authority

ACR Autorité de Certification Racine CA root Root Certification Authority

AE Autorité d’Enregistrement RA Registration Authority

CN Nom usuel CN Common Name

LAR Liste des Autorités Révoqués ARL Authority Revocation List

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

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

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

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

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

Page 18: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 18 © Thales S.A 2009 – Tous droits réservés

RFC Document de spécifications de technologies

RFC Request For Comments

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

URL Adresse Internet URL Unique Resource Locator

1.4 Identification (OID)

La présente Politique de Certification est enregistrée conformément à la norme d’enregistrement ISO par un identificateur numérique unique. Cet OID se rattache à l’identificateur unique de la société auteur du document.

Tout lecteur a donc les moyens de vérifier l’appartenance du document à Thales S.A.

La désignation de l’identification objet (OID) pour la présente politique est : 1.2.250.1.108.1.2

Cet OID est présent dans les certificats émis par l’Autorité de Certification Racine de l’IGC de Thales.

1.5 Applications et groupes 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 Racine et ses propres composantes ou services.

• L’Autorité d’Administration.

• L’Autorité d’Enregistrement.

• Les AC déléguées.

• Les Utilisateurs de Certificats.

1.5.1 Applications concernées

L’application concernée est la certification d’AC déléguée de l’IGC de Thales.

1.5.2 Groupes d’utilisateurs concernés

1.5.2.1 Autorité de Certification Racine (ACR) L'Autorité de Certification Racine est responsable vis-à-vis de ses AC déléguées, mais aussi de toute personne se fiant à un certificat qu'elle a émis, de l'ensemble du processus de certification, et donc de la validité des certificats qu'elle émet, conformément à la Politique de Certification définie par l’AA de l’ACR et la Déclaration des Pratiques de Certification validée par l’AA de l’ACR.

Page 19: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 19 © Thales S.A 2009 – Tous droits réservés

La garantie apportée par l’Autorité de Certification Racine vient de la qualité de la technologie mise en oeuvre, mais aussi du cadre réglementaire et contractuel qu’elle définit et s’engage à faire respecter.

En vertu de cette politique, l’ACR est chargée :

• De créer et de signer les certificats des AC déléguées et de gérer le cycle de vie de ces certificats.

• De faire connaître l’état des certificats par l’intermédiaire des ARL (CRL).

Les fonctions de l’ACR doivent être exécutées par des personnels autorisés par l’AA de l’ACR, ayant connaissance et respectant les règles, principes et procédures énoncés dans la PC et la DPC liés au fonctionnement de l’ACR.

Le certificat de l’ACR est auto-certifié, c’est-à-dire que l’ACR signe elle-même son propre certificat, ce qui permet de disposer d’un chemin de confiance pour l’interopérabilité des certificats de clés publiques des AC déléguées du groupe Thales.

La fonction d’enregistrement des certificats fait partie des fonctions indispensables d’une IGC.

La fonction d’enregistrement est remplie par une composante de l’ACR avec laquelle elle collabore ou qui lui est rattachée.

L’ACR traite et valide les demandes d’enregistrement et de révocation des certificats de l’Autorité d’Enregistrement (AE).

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 qui doit identifier les obligations de toutes les entités externes participant aux services de l’IGC 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. En vertu de cette politique, l’AA est chargée :

• D’éditer et faire respecter la PC par les différentes composantes de l’IGC et les détenteurs de certificats.

• De valider et faire respecter la DPC par les différentes composantes de l’IGC et les détenteurs de certificats.

• De contrôler et d’auditer l’IGC et l’OSC.

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 applique des procédures d’identification des personnes physiques, conformément aux règles définies par l’Autorité d’Administration. Son but est :

• De coordonner les demandes de certificats des AC déléguées.

• D'établir que le demandeur est représenté par l’AA de l’AC déléguée ou une personne mandatée par l’AA de l’AC déléguée.

Page 20: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 20 © Thales S.A 2009 – Tous droits réservés

• De distribuer le certificat à l’AA de l’AC déléguée ou la personne mandatée par l’AA l’AC déléguée sur un support physique (disquette, CD-R, …).

• De gérer et protéger les données personnelles et de sécurité des AC déléguées.

• De maintenir, administrer, exploiter et protéger les machines et logiciels utilisés pour remplir ces fonctions.

L’AE a également pour tâche de réceptionner les demandes de révocation de certificats et doit les traiter.

L'Autorité d'Enregistrement est un lien dans la chaîne de confiance entre l'Autorité de Certification Racine et l’AC déléguée. En vertu de cette Politique de Certification, une AE est responsable de toutes les tâches qui lui sont assignées par l’AA de l’ACR.

Les fonctions de l’AE doivent être exécutées par des personnels ayant connaissance et respectant les règles, principes et procédures énoncées dans la PC et la DPC.

1.5.2.4 Autorité de Certification déléguée (AC délé guée) En vertu de cette Politique de Certification, une AC déléguée est une AC subordonnée à l’ACR de qui elle obtient un certificat. Une AC déléguée est elle-même capable de générer et gérer le cycle de vie de certificats après l’obtention d’un certificat de l’ACR.

L’AA de l’AC déléguée est responsable de l’authenticité, de l'exactitude, et de la complétude des données d’identification fournies à l’AE lors de l’enregistrement.

L’AC déléguée est responsable :

• De la protection, de l’intégrité et de la confidentialité de sa clé privée, et des éventuelles données d’activation liées aux certificats.

• De la sécurité de ses équipements matériels, logiciels et de ses réseaux impliqués dans l’utilisation de ses certificats.

• De l’utilisation de sa clé privée et de son certificat, qui doit être conforme à la présente Politique de Certification.

L’AC déléguée doit communiquer à l’ACR, par les canaux qu’elle aura désignés, définis dans la DPC, toute information ayant pour conséquence la révocation de son certificat.

1.5.2.5 Opérateur de Service de Certification (OSC) Dans le cadre de l’IGC de Thales, l’OSC de l’ACR est défini dans la Déclaration des Pratiques de Certification.

L’OSC assure les prestations techniques, en particulier cryptographiques, nécessaires au processus de certification. Il est en charge du bon fonctionnement et de la sécurité des moyens informatiques et techniques. Il est en charge de la sécurité des personnels, des locaux et plus généralement du bon respect des procédures.

Il est techniquement dépositaire de la clé privée de l'Autorité de Certification Racine utilisée pour la signature des certificats. Une de ses premières missions est de la protéger contre toute compromission.

L'OSC connaît et applique les procédures de la PC et DPC.

Sa responsabilité ne peut être engagée que par l’Autorité d’Administration de l’ACR et se limite au respect des procédures établies dans la Déclaration des Pratiques de Certification, validée par

Page 21: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 21 © Thales S.A 2009 – Tous droits réservés

l'Autorité d’Administration de l’ACR. L'Autorité d’Administration de l’ACR a un devoir de contrôle et d'audit de l'OSC.

1.5.2.6 Annuaires Le dépôt de la CRL se présente sous la forme d’une entrée d’annuaire conforme à la norme LDAP.

1.5.2.7 Parties utilisatrices En vertu de cette Politique de Certification, les Utilisateurs des certificats émis par l’ACR sont les AC déléguées.

1.5.3 Applicabilité de la Politique

Cette Politique de Certification est applicable à l’ACR, à l’Autorité d’Enregistrement ainsi qu’aux exploitants de l’ACR et aux AC déléguées.

Page 22: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 22 © Thales S.A 2009 – Tous droits réservés

2 Dispositions de portée générale

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

2.1 Obligations

Certaines des obligations sont communes à toutes les composantes qui concourent à l’accomplissement des fonctions de l’infrastructure de l’ACR, d’autres leurs sont spécifiques.

2.1.1 Obligations communes à plusieurs composantes

Les obligations communes à l’ACR, l’AE et aux AC déléguées sont les suivantes :

• Protéger et garantir l’intégrité et la confidentialité de leurs clés privées.

• N’utiliser leurs clés publiques et privées qu’aux seules fins pour lesquelles elles ont été émises et avec les moyens informatiques autorisés.

• Accepter le résultat et les conséquences d’un contrôle de conformité et en particulier remédier aux non-conformités qui pourraient être révélées.

Les obligations communes à l’ACR, l’AE et l’OSC sont les suivantes :

• Respecter et appliquer les obligations décrites dans la présente PC et la DPC associée.

• Documenter leurs procédures internes de fonctionnement.

• Mettre en œuvre les moyens techniques et employer les ressources humaines nécessaires à la réalisation des prestations auxquelles elles s’engagent dans des conditions garantissant qualité et sécurité.

2.1.2 Obligations de l’ACR

2.1.2.1 Fonctions de gestion des certificats L’ACR doit :

• Publier sur un serveur Web accessible aux AC déléguées le certificat de l’ACR.

• Publier sur un site Web accessible aux AC déléguées la PC, et fournir aux AC déléguées l’adresse de ce site afin de garantir que les AC déléguées connaissent leurs droits et leurs obligations en ce qui concerne l’utilisation et la gestion des clés.

• Publier systématiquement dans l’annuaire les certificats d’AC déléguées émis.

• Publier systématiquement dans la CRL de l’annuaire les certificats d’AC déléguées révoqués.

Page 23: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 23 © Thales S.A 2009 – Tous droits réservés

2.1.2.2 Exactitude des informations Lorsque l’ACR publie un certificat, l’ACR garantit qu’elle a délivré le certificat à une AC déléguée et que les informations contenues dans le certificat en question ont été vérifiées conformément à cette PC.

L’ACR contrôle à chaque demande de certificat ou de révocation que la demande émane d’un opérateur autorisé.

L'ACR doit veiller à ce que l’AE se conforme à toutes les modalités pertinentes de la présente PC, concernant le fonctionnement de l’AE.

2.1.2.3 Délai entre la demande et l’émission du cer tificat Il n’y a pas d’exigence sur le délai entre la demande d’un certificat et sa fabrication. L’émission d’un certificat est subordonnée au respect de la procédure de traitement des demandes.

2.1.2.4 Révocation et renouvellement des certificat s Dans le cas d’une demande de révocation du certificat d’une AC déléguée, l’AE qui reçoit la demande doit effectuer des vérifications avant d’accepter la révocation et d’introduire le certificat en cause dans la CRL protégée en intégrité et authenticité.

L’ACR doit s’assurer que toutes les procédures relatives à l’expiration, à la révocation et au renouvellement d’un certificat sont conformes aux dispositions de cette PC et qu’elles ont été mentionnées à l’AC déléguée, ou consignées dans tout autre document applicable décrivant les modalités d’utilisation du certificat.

2.1.2.5 Protection des clés privées L’ACR garantit la protection de sa clé privée par le stockage et l’exploitation de sa clé privée au travers d’une ressource matérielle tel que décrit aux §4 et 6.

La clé privée de l’ACR doit faire l’objet d’une sauvegarde sécurisée qui est précisée dans la DPC.

2.1.2.6 Restriction quant à l’utilisation des clés privées de l’AC émettrice L'ACR s'engage à n'utiliser ses clés publiques et privées qu'aux fins pour lesquelles elles ont été émises et avec les outils spécifiés, soit la signature de certificats et de CRL.

2.1.2.7 Fonctions de séquestre Sans Objet.

2.1.3 Obligations de l’AE

2.1.3.1 Fonctions de gestion des certificats L’AE doit :

• Traiter les demandes de certificat et de révocation.

• Transmettre les certificats générés par l’ACR aux AC déléguées.

• Protéger en confidentialité et en intégrité toutes les données à caractère personnel et d’identification collectées lors des procédures d’enregistrement.

Page 24: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 24 © Thales S.A 2009 – Tous droits réservés

2.1.3.2 Exactitude des informations L’AE doit vérifier et garantir l’authenticité des informations d’identité du demandeur de certificat d’AC déléguée.

L’AE doit vérifier que le demandeur de certificat d’AC déléguée est représenté par l’AA de l’AC déléguée ou une personne mandatée par l’AA de l’AC déléguée.

2.1.3.3 Protection des clés privées L’AE s'engage à protéger et garantir l’intégrité et la confidentialité de sa clé privée et des données d’activation.

2.1.3.4 Restriction quant à l’utilisation des clés privées de l’AE L'AE s'engage à n'utiliser ses clés publiques et privées qu'aux fins pour lesquelles elles ont été émises et avec les outils spécifiés, soit l’authentification aux applications de l’AE et la signature de demandes de certificat ou de révocation.

2.1.4 Obligations de l’AC déléguée

2.1.4.1 Fonctions de gestion des certificats L’AC déléguée s’engage à prévenir l’AE de toutes compromissions de clés privées dans les plus brefs délais.

En cas de révocation pour changement d’identité, cessation d’activité, l’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée s’engage à prévenir l’AE des modifications dans le changement du statut du certificat de l’AC déléguée dans des délais compatibles avec la modification.

2.1.4.2 Exactitude des informations L’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée, garantit l’exactitude des informations fournies à l’AE dans la demande de certificat.

L’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée, garantit l’exactitude des informations fournies à l’AE dans la demande de révocation d’un certificat.

2.1.4.3 Protection des clés privées de l’AC délégué e Les AC déléguées garantissent la protection de leur clé privée par le stockage et l’exploitation de leur clé privée au travers d’un module cryptographique matériel de type carte chiffre.

Les AC déléguées sont responsables des clés privées qu’elles génèrent en respect du §6 de la présente PC.

Les AC déléguées doivent prendre les précautions d’usage pour éviter la perte, la divulgation, la compromission, la modification ou l’utilisation non autorisée des clés privées qu’elles génèrent.

2.1.4.4 Restriction quant à l’utilisation des clés privées de l’AC déléguée L’AC déléguée s'engage à n'utiliser les certificats délivrés par l’ACR et les clés privées associées qu'aux fins pour lesquelles ils ont été émis et avec les outils spécifiés, soit la signature de certificats et de CRL.

L’AC déléguée de l’IGC de Thales s'engage à ne pas accepter d’autres certificats que ceux émis par l’ACR de l’IGC de Thales.

Page 25: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 25 © Thales S.A 2009 – Tous droits réservés

2.1.4.5 Responsabilité en matière de vérification L’AC déléguée s’engage à utiliser la clé publique extraite du certificat de l’émetteur pour vérifier une signature électronique.

2.1.4.6 Responsabilité de la vérification de la rév ocation L’AC déléguée s’engage à ne plus utiliser les certificats et clés associées émis par l’ACR si l’AA de l’ACR publie un avis de compromission.

2.2 Responsabilité

2.2.1 Exigences de moyens

Au titre de la présente PC, l’ACR a une obligation de moyens. En conséquence, il revient à toute partie plaignante de prouver que l’ACR a commis une faute dans l’exercice de ses fonctions pour mettre en cause la responsabilité de l’ACR.

2.2.2 Limites de la responsabilité

La responsabilité de l’ACR ne saurait être mise en cause en cas de dommages résultant :

• s’agissant des certificats qu’elle a émis, d’une utilisation de ces derniers à des fins et/ou dans des conditions autres que celles mentionnées dans la présente PC ;

• d’une utilisation d’un certificat révoqué ;

• d’une utilisation d’un certificat au delà de sa limite de validité ;

• d’une faute ou négligence d’un tiers ;

• du non-respect par les AC déléguées des obligations définies dans la PC ;

• d’un cas de force majeure tels que visés à la clause 2.2.3.1 ci-dessous.

2.2.3 Autres modalités

L’ACR n’assume aucune responsabilité quant aux dommages liés aux retards, erreurs ou pertes que pourraient subir dans leur transmission tous messages électroniques, lettres, documents.

L’ACR ne garantit pas l’exactitude, l’authenticité et la non-falsification des documents remis lors de l’enregistrement et n’assume donc aucune responsabilité quant aux dommages liés.

2.2.3.1 Force majeure Une partie ne saurait être tenue responsable pour tout retard ou interruption dans l’exécution de ses obligations ou pour toute inexécution d’obligations résultant de la présente PC lorsque les circonstances y donnant lieu relèvent de la force majeure au sens de l’article 1148 du Code civil.

2.3 Interprétation et application

Il est expressément entendu qu’en l’état de la pratique et des textes législatifs et réglementaires en vigueur, les certificats émis en vertu de la présente PC sont des certificats dits « simples » (non qualifiés) dont les conditions d’utilisation sont définies par la présente PC.

Page 26: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 26 © Thales S.A 2009 – Tous droits réservés

Si une disposition de la PC de référence s’avérait inapplicable ou incompatible avec une loi ou un règlement en vigueur, elle serait considérée comme nulle, mais cette nullité n’affecterait en aucune manière la validité des autres dispositions de la PC de référence.

Le caractère inapplicable dans un contexte donné d’une disposition des Pratiques de Certification n’affecte en rien la validité des autres dispositions, ni de cette disposition hors du-dit contexte. La DPC continue à s’appliquer en l’absence de la disposition inapplicable et ce, tout en respectant l’intention des parties.

2.3.1 Droit applicable

La présente PC est soumise au droit français.

2.3.2 Règlement des différends

A défaut de stipulations contractuelles contraires ou de dispositions d’ordre public qui seraient applicables, tout litige relatif à la validité, l’interprétation, l’exécution de la présente PC sera soumis aux tribunaux compétents français.

2.4 Barêmes de prix

Sans objet.

2.5 Publication et services associés

2.5.1 Informations publiées

La PC, certains éléments de la DPC et autres documentations liées au fonctionnement de l’ACR sont disponibles sur le site http://www.thalesgroup.com/certification_policy

Les éléments suivants doivent être inclus dans les informations publiées, notamment via la présente PC :

• L’obligation d’utiliser pour support de stockage des clés certifiées un module cryptographique matériel de type carte chiffre.

• Les limites d’usage du certificat.

• Les limites de responsabilité.

• Les durées d’archivage.

• La procédure de règlement de litige.

• Les lois applicables.

• Les informations sur les moyens disponibles pour vérifier les certificats.

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’ACR, 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.

Page 27: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 27 © Thales S.A 2009 – Tous droits réservés

Toutefois l’AA de l’ACR doit fournir, en cas de besoin, la version complète de sa DPC, 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 présente politique, ainsi que dans le cadre du respect de la loi.

Le service de publication fournit au minimum les informations suivantes :

• Le certificat de l’ACR.

• La liste des certificats des AC déléguées.

• La liste des certificats révoquées (CRL) la plus récente.

La DPC doit préciser les modes d’accès à ces informations.

2.5.2 Fréquence de publication

L’écriture d’un événement donnant lieu à la mise à jour et publication de certificats doit se faire à chaque opération de certification.

L’écriture d’un événement donnant lieu à la mise à jour et publication de la CRL doit se faire à chaque opération de révocation, dans un délai inférieur à un jour ouvré, s’il n’est pas possible de le faire en temps réel. La nouvelle CRL publiée est complète et n’est pas définie comme un delta de la CRL précédente. Le délai de validité de la CRL est précisé dans la DPC.

Les éléments déclencheurs pour la mise à jour et la publication de la CRL dépendent de l’opération à effectuer :

• Dans le cas d’une demande de révocation du certificat d’une AC déléguée, l’événement déclencheur est l’acceptation, après vérification, de la demande de révocation.

• Dans le cas d’un incident majeur tel que la perte, la suspicion de compromission, la compromission, le vol de la clé privée de l’ACR, l’événement déclencheur est la constatation de cet incident par l’ACR.

L’AA de l’ACR doit également s’assurer de la publication d’informations (notamment la PC) ayant fait l’objet d’une révision suite à modification, dans un délai précisé dans la DPC.

2.5.3 Contrôle de l’accès

L’accès aux informations publiées, pour création ou modification, ne sera autorisé qu’au seul personnel habilité par l’ACR, et ce à travers des contrôles d’accès appropriés.

Les conditions de mises en oeuvre de mesures de sécurité aux fins de contrôler l’accès aux informations publiées sont du ressort du service de publication.

2.5.4 Service de publication

L’ACR est tenue de diffuser les certificats émis à destination des AC déléguées et les CRL au travers du service de publication.

L'accès aux CRL doit être disponible 24 heures sur 24 et 7 jours sur 7 dans la limite de la disponibilité du système dont la durée maximale d’indisponibilité est définie dans la DPC.

Page 28: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 28 © Thales S.A 2009 – Tous droits réservés

2.6 Contrôle de conformité

L’ACR a la responsabilité du bon fonctionnement de ses composantes, conformément aux dispositions énoncées dans le présent document. L'AA de l’ACR effectuera ou fera effectuer en ce sens des contrôles réguliers de conformité et de bon fonctionnement des composantes de l’infrastructure de l’ACR.

L’audit de conformité est fait sur demande de l’AA de l’ACR.

L’audit comprend entre autres:

• L'examen de la validité du processus de vérification que l'ACR a mis en place pour valider la qualité de ses services.

• Une comparaison entre les pratiques de l’ACR et de ses composantes, décrites dans la DPC et la conformité à ces déclarations.

• Une comparaison entre les pratiques de l’ACR et de ses composantes, et les exigences des différentes Politiques de Certification a priori supportées.

Le contrôle de conformité à la PC a pour but de vérifier la recevabilité de catégories de certificats délivrés par une AC. Les contrôles sur le fonctionnement des composantes de l’ACR se feront dans ce seul but. Il ne s’agit en aucun cas de la reconnaissance de qualification de l'ACR par un organisme accrédité au sens du décret n°2001-272 du 30 mars 2001 [DEC] et de l'arrêté du 26 juillet 2004.

2.6.1 Fréquence d’audit de conformité

L’auditeur peut également être amené à procéder à l’audit d’une composante de l’ACR dans le cadre du fonctionnement régulier de l’ACR. Cet audit s’effectuera sur préavis, à une fréquence à définir dans la DPC, ou de façon exceptionnelle.

2.6.2 Identité / qualité de l’auditeur

L’AA de l’ACR doit approuver la personne ou entité chargée de mener l’audit de conformité. Cet auditeur doit pouvoir apporter la preuve de son expérience dans les IGC et technologies de cryptographie.

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

L’auditeur ne doit être lié en aucune façon aux parties auditées (ACR, OSC, ..) et au commanditaire en dehors du contrat d'audit.

2.6.4 Objet de l’audit

Le contrôle de conformité portera parmi les points suivants :

• Dispositions générales (cf. §2.2 et suivants)

• Identification et authentification (cf. §3)

• Besoins opérationnels (cf. §4)

• Contrôle de sécurité physique, contrôle des procédures, contrôle du personnel (cf. §5)

• Contrôles techniques de sécurité (cf. §6)

Page 29: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 29 © Thales S.A 2009 – Tous droits réservés

• Profil des certificats et CRL (cf. §7)

• Spécifications d'administration (cf. §8)

2.6.5 Mesures à prendre à la suite de l’audit

La réception par Thales S.A des rapports d'audit ainsi établis par des tiers ne constitue ni l'entérinement ni l'approbation par Thales S.A du contenu, des conclusions ou des recommandations de ces rapports. Thales S.A n'est pas l'auteur des rapports d'audit et n'est donc pas responsable de leur contenu.

A l’issue d’un contrôle de conformité, le contrôleur rend au commanditaire de l’audit un avis parmi les suivants :

« Réussite », « Échec », « A confirmer ».

2.6.6 Communication des résultats

Les résultats des contrôles de conformité ne sont communiqués qu’à l’AA de l’ACR contrôlée.

Il appartient à l’AA de l’ACR de transmettre aux opérateurs et administrateurs des composantes de l’ACR les résultats les concernant ou concernant les AC déléguées et de définir si les AC déléguées ont besoin d’être informés de l’action menée.

Dans le cas d’une révocation des certificats émis par l’ACR à destination de composantes ou d’AC déléguées, l’AA de l’ACR avise toutes les AC déléguées les informant de l’action. Cet avis peut être émis par messagerie électronique.

2.7 Politique de confidentialité

Il est rappelé que l’ACR, en tant que gestionnaire de données à caractère personnel, est soumise à la loi n°78-17 du 6 Janvier 1978 « Informatique et Libertés » modifiée par la loi n°2004-801 du 6 Août 2004. Conformément à cette loi, toute personne concernée – en l’occurrence tout représentant d’AC déléguée ou Utilisateur- a le droit notamment d’accéder aux informations qui se rapportent à elle et, le cas échéant, à les faire rectifier.

L’ACR prendra toutes les mesures nécessaires pour que les obligations résultant de cette loi soient scrupuleusement respectées. Ce droit peut s’exercer par l’intermédiaire du service agent, en particulier l’AE ayant recueilli ces informations, à l’adresse électronique figurant sur le site Web de l’ACR.

L’ACR doit respecter rigoureusement toutes les prescriptions légales applicables et expliquer sur son site Web, les modalités concrètes d’application de la loi. Notamment, aucun renseignement personnel recueilli par une ACR ne peut être divulgué sans le consentement de la personne concernée, à moins que la loi ne le prescrive.

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

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

• Les clés privées de l’ACR et de ses composantes.

• Les clés privées de signature des AC déléguées.

Page 30: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 30 © Thales S.A 2009 – Tous droits réservés

• Les données d'activation de la clé privée de l’ACR et de ses composantes.

• Les journaux d'événements de l’ACR et de ses composantes.

La clé privée de signature numérique de chaque AC déléguée, ainsi que les données d’activation correspondantes, doivent demeurer confidentielles. La divulgation de ces informations secrètes par l’AC déléguée s'effectuera à ses risques et périls, l'ACR se dégageant alors de tout préjudice pouvant en résulter.

Les résultats des contrôles de conformité sont considérés comme confidentiels et ne peuvent être diffusés, sauf si leur publication a été demandée sur décision judiciaire ou administrative.

La DPC doit apporter des précisions concernant les types d’informations considérées comme confidentielles.

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

Ne sont pas considérées comme confidentielles, les informations suivantes :

• Les certificats ;

• Les CRL qui ne contiennent que les numéros d’enregistrement des certificats et leur date de révocation.

2.7.3 Divulgation des causes de révocation de certi ficat

Les causes de révocation de certificat ne peuvent être communiquées qu’à l’AE par l’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée.

Les causes de révocation sont considérées comme confidentielles et protégées en conséquence.

2.7.4 Délivrance aux autorités légales

La divulgation des informations confidentielles ne sera effectuée qu’aux autorités légales habilitées à accéder à ces informations conformément à la présente PC ou aux textes législatifs et réglementaires en vigueur.

2.7.5 Délivrance à la demande du propriétaire

La divulgation des informations confidentielles pourra être effectuée au propriétaire de ces informations ou à un tiers habilité au niveau adéquat, sur demande du propriétaire.

2.7.6 Autres circonstances de délivrance possible

Les informations relatives aux AC déléguées et définies comme confidentielles pourront être divulguées à l’AA de l’ACR ou à un tiers autorisé par l'AA de l’ACR.

2.8 Droits relatifs à la propriété intellectuelle

Tous les droits de propriété intellectuelle détenus par l’ACR sont protégés par la réglementation applicable. Leur non-respect est susceptible d’entraîner des poursuites civiles et/ou pénales.

Page 31: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 31 © Thales S.A 2009 – Tous droits réservés

3 Identification et authentification

3.1 Enregistrement initial

3.1.1 Conventions de noms

Les noms utilisés dans un certificat émis dans le cadre de la présente Politique de Certification seront décrits selon la norme IS0/IEC 9594 (Distinguished Names).

Un certificat émis par l’ACR doit contenir dans le champ Subject : un Distinguished Name, nom distinctif facile à distinguer et obligatoire pour l’AC déléguée.

Ces noms doivent être sous la forme d'une chaîne imprimable (printableString) X.501 et doivent être conformes à la partie 1 de la norme PKIX. Le nom distinctif (DN) X.501, porté dans le champ Subject du certificat ne doit pas être vide.

3.1.2 Nécessité d’utilisation de noms explicites

Le nom distinctif (DN) X.501, porté dans le champ Subject du certificat, doit être, non seulement facile à distinguer des autres noms, mais aussi unique pour l’ACR.

Le contenu des champs de nom Subject et Issuer doit avoir un lien explicite avec l'entité authentifiée.

Un nom distinctif (DN) doit se composer au moins des éléments :

• Nom d’organisation (O)

• Nom usuel (CN = CommonName)

Le nom distinctif doit contenir le terme « Thales » et une fonction ou un rôle organisationnel.

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

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

Aucune exigence n’est stipulée.

3.1.4 Unicité des noms

L'unicité d'un certificat est basée sur l'unicité de son numéro de série à l'intérieur du domaine de l'ACR. Cependant, les noms distinctifs doivent être uniques au sein de l'IGC.

L’unicité des noms est obtenue suivant les règles décrites au §3.1.2.

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

Une partie qui demande un certificat AC déléguée doit avoir le droit d'utiliser le nom qu'elle souhaite y voir figurer. Elle doit également être en mesure de prouver qu'elle a le droit d'utiliser ce nom en particulier.

Page 32: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 32 © Thales S.A 2009 – Tous droits réservés

L'ACR s'engage quant à l'unicité des noms de ses porteurs définie dans sa politique de nommage, conformément aux §3.1.1 et §3.1.2. Elle proposera des procédures de résolution amiable des litiges au cas par cas.

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

Le droit d’utiliser un nom qui est une marque de fabrique, de commerce ou de services ou un autre signe distinctif (nom commercial, enseigne, dénomination sociale) au sens des articles L.711-1 et suivants du Code de la Propriété intellectuelle (codifié par la loi n°92-957 du 1 er juillet 1992 et ses modifications ultérieures) appartient au titulaire légitime de cette marque de fabrique, de commerce ou de services, ou de ce signe distinctif ou encore à ses licenciés ou cessionnaires.

L’ACR dégage toute responsabilité en cas d’utilisation illicite par les AC déléguées des marques déposées, des marques notoires et des signes distinctifs, ainsi que les noms de domaine.

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

L’ACR doit vérifier que l’AC déléguée est véritablement en possession de la clé privée associée à la clé publique de vérification de signature de certificat qui a été inscrite dans son certificat.

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

Sans Objet.

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

L’identité de l’ACR ou d’une de ses composantes est vérifiée au travers de l’authentification du responsable de composante nommé par l’AA de l’ACR.

Le certificat de l’ACR ou d’une de ses composantes doit toujours contenir dans son nom un élément identifiant sa fonction au sein de l’IGC de façon unique et non ambiguë.

3.1.10 Vérification de l’identité des AC déléguées

Le certificat ne doit être délivré que sur enregistrement en personne de l’AA de l’AC déléguée ou d’une personne mandatée par l’AA de l’AC déléguée, dans une procédure en face à face avec une Autorité d’Enregistrement, ou plus généralement, par un représentant de l’ACR. L’identité du demandeur de certificat est vérifiée lors de cette procédure. L’ACR garantit alors le lien entre le détenteur du certificat et une paire de clés.

L’AE ne doit accepter que les demandes de certificats contenant la liste exhaustive des données requises.

Toute demande de certificat d’AC déléguée doit être adressée à l’AE.

L’AE doit examiner les pièces et documents remis avec un soin raisonnable et vérifier s’ils présentent ou non l’apparence de conformité et de validité.

Le distribution des certificats par l’AE peut se faire directement à l’AA de l’AC déléguée ou à une personne mandatée par l’AA de l’AC déléguée.

Page 33: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 33 © Thales S.A 2009 – Tous droits réservés

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

Les bi-clés des composantes de l’infrastructure de l’ACR et des AC déléguées doivent être périodiquement renouvelés afin de minimiser les attaques cryptographiques.

Pour faciliter l'exploitation, un nouveau certificat peut être obtenu alors que le certificat courant est encore valide.

L’ACR doit renouveler ses bi-clés au moins tous les dix (10) ans. A cette occasion, il faut vérifier que la demande de renouvellement provient effectivement de l’AA de l’ACR.

Les AC déléguées doivent renouveler leurs bi-clés de signature au moins tous les dix (10) ans. A cette occasion, il faut vérifier que la demande de renouvellement provient effectivement de l’AA de l’AC déléguée ou d’une personne mandatée par l’AA de l’AC déléguée.

Etant donnée l’obligation de l’ACR de garantir la conformité des informations remises lors de l’enregistrement, il ne doit pas y avoir de renouvellement purement technique pour les AC déléguées. La vérification lors d’un renouvellement ou lors de la modification d’informations faisant partie du dossier, doit être la même que lors d’un enregistrement initial, avec la présentation de toutes les pièces demandées pour ce dernier.

Il n’y a pas de renouvellement de clés sans re-génération des clés.

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

Si un certificat a été révoqué, il ne peut être réactivé. Il ne peut également jamais faire l’objet d’un renouvellement. Il faut procéder à la certification de nouvelles clés de la même façon que pour un enregistrement initial.

Après une révocation, l’attribution et la certification de nouvelles clés suivent la procédure d’enregistrement initial (cf. §3.1). Selon le type de révocation (compromission de la clé, compromission de l’autorité signataire du certificat) il appartient à l’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée de formuler une nouvelle demande de génération de certificat.

3.4 Demande de révocation

L'AA de l’ACR doit établir et rendre public le mécanisme qu'elle utilise pour traiter les demandes de révocation et en établir la validité.

L'ACR doit s'assurer du bon droit de la personne qui fait une demande de révocation. Elle vérifie la validité de la demande soit en vérifiant un ensemble d’informations déposées lors de l’enregistrement initial, soit au moyen d'une signature numérique valide reconnue par l'ACR, soit de toute autre façon non équivoque.

Par nature une demande de révocation doit être traitée en urgence.

Une demande de révocation ne peut être présentée que par une entité habilitée (cf. §4.4.2) et doit être authentifiée par l’AE.

Page 34: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 34 © Thales S.A 2009 – Tous droits réservés

4 Exigences opérationnelles

Un seul type de certificats est proposé :

• Les certificats pour les AC déléguées avec enregistrement en face à face avec l’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée.

4.1 Demande de certificat

L’AE doit s’assurer que les demandeurs de certificats d’AC déléguée suivent et respectent les procédures et exigences publiées par l’AA de l’ACR.

Les informations suivantes doivent au moins figurer dans la demande de certificat d’AC déléguée :

• Le nom de l’AC déléguée à utiliser dans le certificat.

• La clé publique de l’AC déléguée, générée par cette AC.

• Le nom 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.

• L’adresse de courrier électronique ou l’adresse postale 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.

• La preuve de possession de la clé privée associée à la clé publique à certifier.

• La preuve que le demandeur a les pouvoirs d’effectuer la demande dans le cas où ce n’est pas l’AA de l’AC déléguée qui effectue la demande.

Lors d’une demande de certificat, l’AE doit contrôler les pièces de la demande présentée par 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.

4.2 Emission de certificat

Une demande de certificat n'oblige en aucune façon l'ACR à émettre un certificat.

L'émission d'un certificat par l’ACR indique que celle-ci a définitivement et complètement approuvé la demande de certificat selon les procédures décrites dans la DPC. Le certificat est considéré comme valable dès le moment où il est accepté par l’AA de l’AC déléguée ou la personne mandatée par l’AA de l’AC déléguée.

A la réception d’une demande de certificat :

• L’ACR doit s'assurer que la demande a bien été émise par l’AE et que l'AE a traité la demande, et fournit une trace imputable de son avis.

• L’ACR doit générer et signer le certificat.

• L’AE doit notifier à l’AA de l’AC déléguée ou à la personne mandatée par l’AA de l’AC déléguée la mise à disposition de son certificat et l’ensemble des procédures à suivre pour être en mesure de l’obtenir et de l’utiliser en cas d’acceptation.

• L’AE doit mettre le certificat à disposition 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, c’est-à-dire rendre accessible par des moyens physiques ou logiques les informations permettant l'obtention du certificat.

Page 35: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 35 © Thales S.A 2009 – Tous droits réservés

4.3 Acceptation de certificat

Le face à face 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 avec l’AE vaut acceptation de sa part du certificat et des obligations qui les lient à l’ACR.

4.4 Suspension, révocation et recouvrement de certi ficat

4.4.1 Causes possibles de révocation

Lorsque la confiance dans un certificat (certificat d’AC déléguée ou d’une composante de l’infrastructure de l’ACR) est remise en cause, le certificat concerné doit d’être révoqué et placé dans une liste des certificats révoqués (CRL).

Les circonstances suivantes peuvent être à l’origine de la révocation d’un certificat :

• Cessation d’activité de l’AC déléguée.

• Suspicion de compromission, compromission, perte ou vol de la clé privée ou des données d’activation de l’AC déléguée.

• Modification d'une information contenue dans le certificat.

• Suspicion de compromission, compromission, perte ou vol de la clé privée de l’ACR, ou plus généralement, révocation du certificat de l'ACR.

• Décision de changement de composante de l'ACR ou de composante d’enregistrement de l’ACR suite à non-conformité des procédures de la DPC.

Outre les cas de révocation de certificats mentionnés plus haut, l’ACR et l’AE peuvent révoquer un certificat dès lors qu’elle est en possession d’informations de nature à indiquer une perte de confiance dans un certificat.

Plus généralement, il est rappelé que l’AA de l’ACR pourra, à sa discrétion, demander la révocation du certificat d’une AC déléguée ou d’une composante de l’infrastructure de l’ACR lorsqu’elle ne respecte pas les obligations énoncées dans la présente Politique de Certification ainsi que dans toute loi et règlement applicable.

4.4.2 Personnes pouvant demander une révocation

Seuls peuvent demander la révocation d’un certificat (certificat d’AC déléguée ou d’une composante de l’ACR) :

• L’AA de l’AC déléguée.

• L’AA de l’ACR.

4.4.3 Procédure de demande de révocation

Les différentes composantes de l’ACR doivent s’assurer que lors de la demande de révocation, toutes les procédures et exigences publiées par l’AA de l’ACR sont respectées.

Dans le cas où le certificat d’AC déléguée se doit d’être révoqué (voir causes §4.4.1), l’AA de l’AC déléguée doit informer au plus vite l’AE. L’AC déléguée ne pouvant plus s’authentifier par signature, l’AE authentifiera la demande de révocation :

Page 36: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 36 © Thales S.A 2009 – Tous droits réservés

• Soit au moyen d'une signature numérique valide reconnue par l'ACR.

• Soit selon la même procédure que pour l’enregistrement initial (cf. §3.1), c’est-à-dire par une procédure en face à face avec l’AA de l’AC déléguée ou une personne mandatée par l’AA de l’AC déléguée et l’AE.

• Soit par une autre procédure manuelle prévue à cet effet (par exemple en vérifiant un ensemble d’informations déposées lors de l’enregistrement initial).

La demande de révocation doit contenir explicitement les informations d'identification du certificat et de son propriétaire. La demande doit également contenir quand c’est possible la cause de révocation et le cas échéant, les éléments justificatifs de cette cause.

Les causes de révocation mentionnées dans les certificats révoqués ne doivent en aucun cas contenir d’informations privées sur les personnes et ce conformément aux lois nationales.

Si la procédure de demande de révocation d’un certificat est justifiée et acceptée, la révocation est déclenchée.

Dans tous les cas de révocation d’un certificat, l’AA de l’AC déléguée doit être informée de la révocation du certificat. Cette notification doit indiquer la date à laquelle la révocation du certificat a pris effet et peut être effectuée par messagerie électronique.

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

A la réception d’une demande de révocation en provenance de l’AA de l’AC déléguée ou d’une personne mandatée par l’AA de l’AC déléguée, l’AE analyse cette demande en vérifiant l’authenticité du demandeur, puis la transmet à la composante de l’ACR chargée d’analyser les causes et justificatifs éventuels de révocation. Si la demande est justifiée, l’ACR révoque le certificat en faisant introduire le numéro de série du certificat et éventuellement d’autres informations dans une liste de révocation.

Les demandes de révocation doivent être traitées immédiatement à réception de la demande.

L’AA de l’ACR sera immédiatement informée en cas de compromission avérée ou soupçonnée de la clé d’une des composantes de l’ACR.

Pour tous les autres cas de révocation, la prise en compte des demandes de révocation par le service de révocation de l’ACR doit pouvoir être effective au moins pendant les heures d’ouverture des jours ouvrés du service de révocation de l’ACR. Un temps minimal garanti de traitement devra figurer dans la DPC qui ne devra pas dépasser un jour ouvré. Un temps minimal garanti de publication devra figurer dans la DPC qui ne devra pas dépasser quatre jours ouvrés.

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.

Page 37: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 37 © Thales S.A 2009 – Tous droits réservés

4.4.8 Limites de la période de suspension

Sans Objet.

4.4.9 Fréquence de publication des CRL

L’ACR doit garantir aux Utilisateurs de Certificats, la mise à disposition d'une CRL à jour. Un délai minimum de mise à jour des listes de certificats révoqués sera fixé dans la DPC en fonction des objectifs opérationnels (cf. §2.5.2) et du délai de traitement d’une révocation (cf. §4.4.4).

4.4.10 Exigences de vérification des CRL

Avant toute utilisation de certificats, tout Utilisateur de Certificat doit, outre la vérification de la validité intrinsèque du certificat auquel il entend se fier, en particulier sa signature, impérativement vérifier auprès de l’ACR le statut de révocation de ce certificat, en consultant la Liste des Certificats Révoqués (CRL) la plus récente.

Il appartient aussi à l’utilisateur de certificat de vérifier la validité des CRL. La validité d'une CRL est contrôlée par vérification de sa signature et vérification de la validité du certificat de l’ACR l’ayant publiée.

En cas d’indisponibilité temporaire de la CRL nécessaire à la vérification d’un certificat, l’utilisateur du certificat doit considérer le certificat comme potentiellement non valide. Il doit, si possible, différer l’utilisation de services usant des certificats, en cas d’impossibilité d’attente, l’AA de l’ACR se décharge de toute responsabilité d’utilisation du certificat (cf. §2.1.4.5).

4.4.11 Publication des causes de révocation

Les motifs de la révocation d'un certificat donné ne sont jamais enregistrés et par conséquent ils ne sont jamais divulgués à des tiers.

4.4.12 Vérification en ligne de la révocation

La validité des certificats est vérifiée en consultant la Liste des Certificats Révoqués valide la plus récente. Cette liste est publiée en ligne sur l’annuaire.

Les CRL sont des listes des certificats révoquées conformes à la version 2 de la norme X.509 sur les CRL.

L’annuaire de publication des CRL est conforme au protocole LDAP V2.

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

Aucune autre forme de publication des avis de révocation que la CRL n’est proposée aux Utilisateurs de Certificats.

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

Aucune autre forme de publication des avis de révocation que la CRL n’est proposée aux Utilisateurs de Certificats.

Page 38: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 38 © Thales S.A 2009 – Tous droits réservés

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

En cas de compromission avérée ou soupçonnée de la clé de signature de l’ACR, l’OSC doit sans tarder en aviser :

• L’AA de l’ACR.

• L’AE.

• Toutes les AC déléguées.

En cas de compromission avérée ou soupçonnée de la clé de signature de l’AE, l’AE doit sans tarder en aviser l’OSC.

Dans le cas où une AC déléguée ou une composante de l’ACR a connaissance d’une perte de confiance dans un certificat (cf. §4.4.1), réelle ou soupçonnée, il a l’obligation de procéder sans délais à la vérification de la révocation du certificat associé ou de la demander dans les plus brefs délais si celle-ci n'a pas été faite.

4.4.16 Causes possibles de recouvrement

Sans Objet.

4.4.17 Personnes pouvant demander un recouvrement

Sans Objet.

4.4.18 Procédure de demande de recouvrement

Sans Objet.

4.4.19 Temps de traitement d’une demande de recouvr ement

Sans Objet.

4.5 Journalisation des évènements

4.5.1 Types d’évènements enregistrés

Le personnel de l’infrastructure de l’ACR doit pouvoir justifier les opérations effectuées et l’imputabilité des opérations, en particulier par la tenue d’un journal d’événements.

Les événements seront enregistrés sous forme manuelle ou sous forme électronique par saisie ou par génération automatique. Les différentes composantes liées à la gestion des certificats doivent tenir à jour une liste d'événements qui les concernent. La liste des événements et données à conserver doit être documentée.

L'ACR doit consigner au moins les événements suivants :

• Tous les événements ayant trait à la sécurité des systèmes informatiques.

• Démarrage et arrêt des systèmes informatiques.

Page 39: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 39 © Thales S.A 2009 – Tous droits réservés

• Démarrage et arrêt des applications.

• Opérations échouées ou réussies pour créer, extraire, établir des mots de passe ou modifier les privilèges système d’Utilisateurs privilégiés (opérateurs de l’infrastructure de l’ACR, du responsable de sécurité ou du gestionnaire),

• Génération des clés de ses composantes.

• La génération et la révocation de certificat.

• Changements des caractéristiques et / ou de ses composantes.

• Opérations pour initialiser, extraire, valider et invalider des AC déléguées.

• Opérations d'écriture dans les CRL.

Ces enregistrements d'événements devront contenir au minimum les champs suivants :

• Type d'opération.

• Destinataire de l'opération.

• Nom du demandeur de l'opération.

• Nom de l'exécutant.

• Nom des personnes présentes (s'il s'agit d'une opération nécessitant plusieurs personnes).

• Date et heure de l'opération.

• Cause de l'événement.

• Résultat de l'événement (échec ou réussite).

L'ACR devra recueillir, par des moyens électroniques ou manuels, d’autres événements. Ce sont ceux concernant la sécurité et qui ne sont pas produits par les systèmes informatiques, notamment :

• Les accès physiques.

• Les actions de maintenance et de changements de la configuration du système.

• Les changements apportés au personnel.

• Les actions de destruction : des supports contenant des clés, des données d'activation.

4.5.2 Fréquence des traitements de journalisation

Le processus de journalisation doit être effectué en tâche de fond et permettre un enregistrement en temps réel des opérations effectuées. Le processus de journalisation doit être conçu de façon à être incontournable.

En cas de saisie manuelle l’écriture doit se faire dans le même jour ouvré que l'événement.

Page 40: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 40 © Thales S.A 2009 – Tous droits réservés

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

Les journaux doivent être conservés par la composante sur le site pour une période minimale de un mois calendaire. Ces journaux doivent ensuite être archivés conformément aux instructions indiquées au §4.6.2.

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

L'écriture dans les journaux d'événements doit être conditionnée par des contrôles de droits d'accès. Les enregistrements et l’horloge des composantes de l’infrastructure de l’ACR doivent être protégés contre les tentatives non autorisées de modification et de destruction.

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

Les journaux d'événements seront sauvegardés. L’ensemble des copies de sauvegarde des journaux d’événements devront être protégées au même niveau que les originaux (voir §4.5.4).

Les précisions sont fournies dans la DPC.

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

L’enregistrement des événements doit commencer au démarrage des systèmes concernés par les événements à enregistrer et se terminer à l'arrêt de ces systèmes.

4.5.7 Imputabilité des évènements

L'imputabilité d'une action revient à la personne, l'organisme ou le système l'ayant exécutée. Le nom ou l'identifiant de l'exécutant doit figurer dans l'un des champs du journal d'événements.

4.5.8 Analyse des vulnaribilités

Les composantes de l’ACR responsables de la fonction de journalisation doivent être en mesure de détecter toute tentative de violation de l’intégrité du système de gestion des certificats, y compris les équipements physiques, l’environnement d’exploitation et le personnel.

Les journaux d’événements journaliers doivent être contrôlés pour identifier des anomalies liées à des tentatives en échec.

Les journaux doivent être revus avec une fréquence hebdomadaire. Cette révision donnera lieu à un résumé dans lequel les éléments importants sont analysés et expliqués. Le résumé doit faire apparaître les anomalies et les falsifications constatées.

Il est souhaitable qu’un rapprochement mensuel soit fait entre les différents journaux de l’AE et ceux des composantes de l'ACR et éventuellement les registres manuels pour vérifier la concordance entre événements dépendants et contribuer ainsi à révéler toute anomalie.

La DPC doit documenter les mesures à prendre à la suite de ces analyses.

4.6 Archives des dossiers

4.6.1 Types de données à archiver

Les données à archiver sont au moins les suivantes :

Page 41: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 41 © Thales S.A 2009 – Tous droits réservés

• Les logiciels et les fichiers de configuration des équipements informatiques de l'IGC.

• La PC.

• La DPC.

• Les journaux d'événements.

• Les certificats tels qu'émis ou publiés.

• Les CRL telles qu'émises ou publiées.

Concernant les données relatives aux enregistrements/renouvellements et demande de révocation, pour des mesures d’allègement des procédures au niveau de l’AE, il n’est pas demandé de conservation des éléments suivants :

• Les demandes d’enregistrement / renouvellement :

• Les demandes de révocation.

Ces éléments pourront être au besoin récupérés au travers de la base de journaux sur l’ACR.

4.6.2 Période de rétention des archives

Les certificats, ainsi que les CRL produites par l'ACR doivent être archivés pendant au moins dix (10) ans après l'expiration des clés.

Les journaux d’évènements doivent être archivés pendant la durée d’opposabilité des documents, c’est-à-dire dix (10) ans après l'expiration des clés.

4.6.3 Protection des archives

Pendant tout le temps de leur conservation, les archives doivent :

• Etre protégées en intégrité.

• Etre disponibles.

• Pouvoir être relues et exploitées.

4.6.4 Procédures de copie des archives

Les archives sont réalisées en deux (2) exemplaires dont chaque version est protégée en intégrité par des moyens organisationnels sur site et hors site.

4.6.5 Besoins d’horodatage des enregistrements

Les enregistrements des certificats et des CRL sont horodatés.

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

Aucune exigence n'est stipulée. Les précisions seront fournies dans la DPC.

Page 42: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 42 © Thales S.A 2009 – Tous droits réservés

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

Une composante de l’ACR ne peut récupérer et consulter que ses propres archives.

Les autres personnes habilitées à récupérer et consulter les archives reçoivent au préalable l’accord de l’AA de l’ACR.

Toutefois, les archives d’une composante de l’ACR étant dupliquées pour des raisons de sécurité, les documents archivés peuvent être récupérés et consultés également sur le lieu de duplication de l’archive tel que défini dans la DPC.

Le processus de récupération doit faire l’objet d’une procédure et figurer dans la DPC de la composante.

Une archive doit être récupérée sous un délai inférieur à dix (10) jours ouvrés.

4.7 Changement de clé d’une composante

L'ACR possède une clé privée de signature unique avec laquelle sont effectuées toutes les opérations de certification. Le certificat portant la clé publique associée à la clé privée unique de l’ACR est le certificat « courant » de l’ACR.

L'ACR ne peut pas générer de certificat dont la date de fin serait postérieure à la date d'expiration du certificat courant de l'ACR. Pour cela la date de fin de validité du certificat courant de l'ACR doit être postérieure à la date de fin de validité des certificats d’AC déléguées émis sous ce certificat d’ACR.

Par conséquent, pour garantir une durée de validité identique pour tous les certificats d’AC déléguée, le certificat courant de l’ACR doit être renouvelé avant que sa durée de validité restant à courir ne devienne inférieure à la durée de validité des certificats d’AC déléguée. L’ACR doit demander le renouvellement de son bi-clé dans un délai permettant une continuité de service.

Lorsqu'un nouveau bi-clé d'ACR est généré, seule la nouvelle clé privée correspondante doit être utilisée pour générer des certificats. Le certificat portant la clé publique précédente peut toujours être utilisé pour valider les certificats émis sous ce certificat et ce jusqu'à ce que ces certificats d’AC déléguée aient expiré.

Lorsqu’une composante renouvelle ses clés, le nouveau certificat est mis à disposition des AC déléguées dans les délais indiqués au §2.5.2.

L’AE doit demander le renouvellement de son bi-clé à chaque renouvellement du bi-clé de l’ACR.

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.

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

L’OSC dispose d’un plan de reprise d’activités en cas de sinistre (comprenant notamment la compromission ou la suspicion de compromission de la clé de l’ACR) qui prend en compte les paramètres suivants :

• Services principaux à remettre en service en priorité.

• Délai minimum de recouvrement de ces services.

• Procédures de secours ( détection de sinistre, contact des équipes de secours, ….)

Page 43: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 43 © Thales S.A 2009 – Tous droits réservés

• Politique de sécurité et de protection des secrets.

• Tests pratiques, formation et entraînement des personnels.

Ce plan est testé à une fréquence qui sera définie dans la DPC.

D’ores et déjà, il est à noter qu’en cas de sinistre, l’OSC peut procéder à la reconstruction de l’infrastructure de l’ACR par la réinstallation du système d’exploitation et des applications et la restauration des données sauvegardées en appliquant les procédures de récupération des archives tel que décrit au §4.6.7.

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

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

Cette rubrique doit être renseignée et apparaître dans la DPC .

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

En cas de révocation de la clé de l’ACR, touts les certificats émis par cette AC doivent être révoqués et publiés dans la CRL.

Après avoir corrigé les problèmes ayant motivé la révocation, et avoir publié le numéro de série du certificat et la date de révocation dans la CRL appropriée, l’ACR peut :

• Produire un nouveau bi-clé de signature de l’ACR.

• Emettre de nouveaux certificats aux AC déléguées et s’assurer que toutes les CRL sont signées au moyen de la nouvelle clé.

L’AA de l’ACR proposera un contrôle préalable à la remise en service de toute ACR.

Pour les autres composantes, selon la nature de la révocation, après avoir corrigé les problèmes ayant motivé la révocation, la composante peut renouveler ses clés.

4.8.3 Compromission des clés de la composante

En cas de compromission de la clé de signature numérique d’une ACR, celle-ci doit, avant de redéfinir un certificat au sein de l’IGC révoquer sa clé publique suivant les procédures décrites au §4.4 et au §4.8.2.

4.8.4 Mesure de sécurité an cas de sinistre

L'ACR doit établir des procédures visant à assurer le maintien des activités et décrire, dans ces procédures, les étapes prévues après une catastrophe naturelle ou un autre sinistre.

4.9 Cessation d’activité d’une composante

Si l’ACR interrompt ses activités :

• L’AA de l’ACR doit immédiatement en aviser les AC déléguées et prendre des dispositions pour que les clés et les informations en possession de l'ACR continuent d'être archivées.

Page 44: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 44 © Thales S.A 2009 – Tous droits réservés

• Sa clé doit être détruite, ou le module cryptographique qui la supporte.

De même, en cas de changements dans la gestion des activités de l'ACR, l’AA de l’ACR doit en aviser toutes les composantes de l’ACR et les AC déléguées.

Les archives de l'ACR doivent être conservées selon les indications et la période stipulées au §4.6.

En conséquence, l’AA de l'ACR en fin de vie s'engage à :

• Communiquer avec un préavis de 3 mois son intention de cesser l’activité de l’ACR.

• Mettre en œuvre tous les moyens dont elle dispose pour informer les AC déléguées de ses intentions.

Et l'ACR en fin de vie s'engage à :

• Révoquer son certificat.

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

• Remettre ses archives ainsi que l'ensemble des données dont elle dispose à l'AA de l’ACR.

Dans le cas où une composante de l’ACR autre que l’ACR interrompt ses activités, l’ACR doit reprendre à sa charge ou faire porter sur une autre entité les obligations de cette composante.

Page 45: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 45 © Thales S.A 2009 – Tous droits réservés

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

5.1 Contrôles physiques

5.1.1 Situation géographique et construction de sit es

Le site d’hébergement de l'ACR se trouve sur le territoire national et dispose de locaux à accès contrôlé.

La DPC précise les conditions de sécurité physique et les règles appliquées aux et dans les locaux, en particulier sur les sujets suivants :

• Emplacement, construction et accès physique.

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

• Dégâts causés par l’eau.

• Prévention et protection-incendie.

• Stockage et archivage des supports.

• Retrait du matériel, destruction.

• Duplication des supports de sauvegarde à l’extérieur des locaux.

5.1.2 Accès physique

L'accès physique à une composante de l’infrastructure de l’ACR doit être protégé contre tout accès non autorisé.

Les zones à accès contrôlé doivent être physiquement protégées contre un accès extérieur non autorisé. La liste des personnels autorisés à y accéder doit exister et être limitée au strict besoin du bon fonctionnement du service. L'accès des personnels autorisés doit être contrôlé par un moyen physique et enregistré.

En dehors des heures ouvrables, la sécurité doit être renforcée par la mise en oeuvre de moyens de détection d'intrusion physique et logique.

5.1.3 Energie et air conditionné

Les administrateurs des composantes de l’infrastructure de l’ACR doivent s'assurer que les installations électriques et de conditionnement d'air sont suffisantes pour le bon fonctionnement de leur système.

5.1.4 Exposition aux liquides

Les administrateurs des composantes de l’infrastructure de l’ACR doivent s'assurer que leur système n’est pas situé en zone inondable.

Page 46: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 46 © Thales S.A 2009 – Tous droits réservés

5.1.5 Prévention et protection incendie

Les administrateurs des composantes de l’infrastructure de l’ACR doivent s'assurer que leur système est protégé contre les incendies grâce à un système de protection incendie.

5.1.6 Conservation des médias

Les administrateurs des composantes de l’infrastructure de l’ACR doivent s'assurer que les supports de stockage utilisés par leur système sont protégés contre un excès de température, d'humidité et de magnétisme et autres variables ambiantes.

5.1.7 Destruction des déchêts

Tous les supports servant au stockage de l'information sensible doivent être effacés ou détruits avant leur mise au rebut.

5.1.8 Site de recouvrement

Les administrateurs des composantes de l’infrastructure de l’ACR doivent s'assurer que les installations de sauvegarde à l'extérieur de leurs locaux offrent le même niveau de sécurité que leurs locaux principaux.

Toute sortie d’équipement, d’informations ou de médias relatif à l’infrastructure de l’ACR fait l’objet d’une autorisation par l’AA de l’ACR ou toute personne mandatée par l’AA de l’ACR.

5.2 Contrôle des procédures

5.2.1 Rôles de confiance

Afin de veiller à la séparation des tâches critiques, on distingue les rôles suivants au sein des composantes de l’IGC :

• Autorité d’Administration (AA).

• Responsables de sécurité (OSSI).

• Ingénieurs systèmes.

• Opérateurs.

L’Autorité d’Administration est 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.

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

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

L’opérateur d’une composante réalise l’exploitation des services offerts par la composante, dans le cadre de ses attributions. Il est chargé de lancer l’exécution des fonctions cryptographiques.

Page 47: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 47 © Thales S.A 2009 – Tous droits réservés

Les attributions associées à chaque rôle doivent être décrites dans la DPC. Plusieurs rôles peuvent être attribués à une même personne, dans la mesure où cela ne dégrade pas la sécurité des services offerts.

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

Toute opération relative à la clé privée ou au certificat de l’ACR requiert l’autorisation ou la présence d’au moins 1 représentant de l’AA de l’ACR et d’un représentant de l’OSC.

Toute opération relative aux certificats requiert l’autorisation ou la présence d’au moins un membre du personnel de l’infrastructure de l’ACR.

Le nombre de personnes dont la présence ou l’autorisation sont nécessaires à chaque tâche doivent être précisé dans la DPC.

5.2.3 Identification et authentification des rôles

Tous les membres du personnel de l’OSC doivent être nommés formellement par le responsable de sécurité (OSSI). Ils doivent faire vérifier leur identité et leurs autorisations avant :

• Que leur nom soit ajouté à la liste d’accès aux locaux de l’OSC.

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

Tous les intervenants sur le système de l'ACR, ou d'une autre composante de l’infrastructure de l’ACR, doivent faire vérifier leur identité et leur autorisation avant :

• Qu’un certificat leur soit délivré pour accomplir le rôle qui leur est dévolu.

• Qu’un compte soit ouvert en leur nom dans le système.

L’OSC ne doit donner l’accès au rôle de l’intervenant qu’après contrôle positif de l’identification/authentification.

5.3 Contrôle du personnel

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

Le responsable de l’OSC doit s’assurer que tous les membres du personnel qui accomplissent des tâches relatives à l’exploitation de l’ACR :

• Sont nommés à leur poste par écrit.

• Sont tenus par contrat ou par la loi de respecter les obligations, notamment de confidentialité, du poste qu’ils occupent.

• Possèdent les qualifications pertinentes et ont reçu toute la formation nécessaire pour accomplir leurs tâches.

• N’ont pas de tâches ou d’intérêts susceptibles d’entrer en conflit avec les obligations qui leur incombent à l’égard de l’ACR.

Page 48: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 48 © Thales S.A 2009 – Tous droits réservés

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

L’appréciation du passé professionnel doit être fait conformément à la politique de l'ACR en matière de sécurité, afin de déterminer dans la mesure du raisonnable le caractère digne de confiance et la compétence des postulants à un emploi auprès de l’OSC.

5.3.3 Exigences de formation

L’OSC doit s’assurer que tous les membres du personnel qui accomplissent des tâches touchant l’exploitation de l’ACR ont reçu une formation adaptée concernant les principes de fonctionnement et des mécanismes de sécurité de l’ACR et sont familiarisés aux règles de sécurité en vigueur.

5.3.4 Fréquence des formations

Le contenu des formations décrites au §5.3.3 doit être mis à jour en fonction des changements apportés à l’infrastructure de l’ACR, et les personnels de l’ACR doivent bénéficier de la formation professionnelle en fonction des besoins.

En outre, le personnel de l’OSC doit participer à des séances de formation sur la sécurité au moins une (1) fois par année.

5.3.5 Gestion des métiers

Aucune exigence n'est stipulée concernant la gestion des métiers.

5.3.6 Sanctions pour des actions non autorisées

Chaque membre de l’OSC s’engage à remplir les tâches qui lui sont attribuées dans le cadre de l’exploitation de l’infrastructure de l’ACR.

5.3.7 Contrôle des personnels des entreprises contr actantes

Sans Objet.

5.3.8 Documentation fournie au personnel

L’ACR doit mettre à la disposition des membres de l’infrastructure de l’ACR la présente Politique de Certification, et s’assurer qu’ils disposent de l’accès à toute loi, ou tout contrat qui s’applique au poste qu’ils occupent.

Les documents dont doit également disposer les membres de l’infrastructure de l’ACR sont notamment les suivants :

• La DPC appliquée à la présente PC dans son intégralité .

• Les procédures internes de fonctionnement de l’OSC.

• Les documents constructeurs des matériels et logiciels utilisés.

Page 49: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 49 © Thales S.A 2009 – Tous droits réservés

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

L’ACR doit produire son propre bi-clé de signature numérique à partir d’un boîtier matériel cryptographique et au moyen d’un algorithme de cryptographie, selon une procédure impliquant plusieurs personnes conformément aux dispositions du §5.2.2.

La clé privée de l’ACR est dédiée uniquement à la signature des certificats et CRL.

Le boîtier matériel cryptographique de l’ACR est un boîtier à usage dédié à l’ACR de l’IGC de Thales.

Le bi-clé de signature numérique de l’AC déléguée est produit par le module cryptographique matérielle de type carte chiffre de l’AC déléguée avant la procédure d’enregistrement en face à face avec l’AE.

6.1.2 Délivrance de clé privée à une composante

Si le bi-clé n’est pas généré par un module cryptographique matériel (de type carte à puce, carte chiffre), la clé privée doit être remise à son propriétaire sous la forme d’un paquet protégé en intégrité et en confidentialité de bout en bout.

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

Sans Objet.

6.1.4 Délivrance de clé publique à une ACR

La clé publique d'une composante ou d’une AC déléguée doit être remise à l’ACR sous la forme d’un paquet attestant de la possession de la clé privée correspondante. La transmission doit assurer l'intégrité de bout en bout.

6.1.5 Fourniture de la clé publique de validation d e l’ACR aux composantes

La clé publique de validation de l’ACR est diffusée sous la forme d’un certificat numérique X.509 V3 protégé en intégrité avec authentification d’origine (certificat auto-signé par l’ACR). Ce certificat doit être fourni aux composantes en même temps que leurs certificats.

6.1.6 Fourniture de la clé publique de validation d ’ACR aux utilisateurs

La clé publique de validation de l’ACR est diffusée sous la forme d’un certificat numérique X.509 V3 protégé en intégrité avec authentification d’origine (certificat auto-signé par l’ACR). Ce certificat doit être rendu disponible aux AC déléguées. La DPC doit préciser les moyens mis à disposition pour assurer la disponibilité du certificat d’ACR.

6.1.7 Tailles des clés

Les tailles de clés sont définies de la façon suivante :

Page 50: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 50 © Thales S.A 2009 – Tous droits réservés

• Le bi-clé de l’ACR est d’une complexité au moins équivalente à 2048 bits pour l’algorithme RSA.

• Le bi-clé de l’AC déléguée est d’une complexité au moins équivalente à 2048 bits pour l’algorithme RSA.

• Le bi-clé de l’AE est d’une complexité au moins équivalente à 2048 bits pour l’algorithme RSA.

• Le bi-clé des autres composantes de l’infrastructure de l’ACR, y compris les opérateurs, est d’une complexité au moins équivalente à 2048 bits pour l’algorithme RSA.

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

L'équipement de génération de bi-clé utilise des paramètres respectant les normes internationales de sécurité propre à l'algorithme considéré (RSA).

Les recommandations décrites dans le document suivant doivent être appliquées pour la génération des bi-clés RSA :

IEEE P1363 / D9 (Draft Version 9). Standard Specifications for Public Key Cryptography - Annex A (Informative) - Number-Theoretic Background. (Copyright 0 1997, 1998, 1999 by the Institute of Electrical and Etectronics Engineers, Inc., 345 East 47th Street New York, NY 10017, USA, All rights reserved.)

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

Les modules cryptographiques vérifient la qualité des bi-clés qu’ils génèrent.

6.1.10 Mode de génération de clé (matérielle ou log icielle)

Le bi-clé de l’ACR est produit par un module cryptographique matériel.

Les bi-clés de l’AE et des opérateurs de l’IGC sont produits par un module cryptographique matériel.

Le bi-clé de l’AC déléguée est produit par un module cryptographique matériel de type carte chiffre.

6.1.11 Usage de la clé privée

Les différents usages possibles des clés publiques sont définis et contraints par l'utilisation d'une extension de certificat X.509 v3 (champ « keyUsage »).

Le champ « keyUsage » des certificats est défini dans la DPC.

6.2 Protection de la clé privée

La clé privée de l’ACR est stockée et exploitée par le boîtier cryptographique.

La clé privée de l’AC déléguée est stockée et exploitée par le boîtier cryptographique.

Le boîtier est protégé contre les accès frauduleux logiques et physiques. En cas de détection d’attaque le boîtier efface physiquement les clés privées stockées.

Page 51: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 51 © Thales S.A 2009 – Tous droits réservés

6.2.1 Normes pour les modules cryptographiques

Concernant le module cryptographique de l’ACR, celui-ci doit être en conformité avec les recommandations de la norme FIPS140-1 niveau 3 au moins.

L’AC déléguée doit protéger ses clés privées afin qu’elles ne soient pas divulguées.

L’utilisation d’un module cryptographique en conformité avec les recommandations de la norme FIPS140-1 niveau 3 au moins est imposé à l’AC déléguée.

6.2.2 Contrôle de clé privée par plusieurs personne s

Plusieurs personnes différentes de l’AA de l’ACR contrôlent les opérations de production des clés de l’ACR. Les données utilisées pour leur création doivent être partagées par plusieurs personnes. Le partage du secret permettant la génération, la regénération ou la restitution de la clé de l’ACR est décrite dans la DPC.

6.2.3 Récupération de clé privée

Les clés privées de signature numérique des AC déléguées ne doivent jamais se trouver en main d’une tierce personne. Il ne doit pas y avoir de recouvrement possible.

6.2.4 Sauvegarde de clé privée

Une entité identifiée peut sauvegarder ses propres clés de signature numérique . Le cas échéant, les clés sauvegardées doivent être enregistrées sous forme chiffrée et être protégées logiquement ou physiquement contre tout accès illicite. Les mesures de protection prises sur la clé sauvegardée doivent être au moins du même niveau que celles prises pour la clé d’origine.

La clé privée de l’ACR est sauvegardée dans le module cryptographique. Ce module cryptographique dispose :

• D’une détection d’intrusion lorsque la clé privée est active.

• D’un autotest.

6.2.5 Archive de clé privée

Les mesures et les contraintes relatives à l’archivage des clés privées sont identiques à celles qui sont prises en matière de sauvegarde (cf. §6.2.4).

6.2.6 Initialisation de clé privée dans le module c ryprographique

La procédure de mise à la clé et la procédure de mise sous contrôle des secrets sont spécifiés comme suit :

Les clés privées de l’ACR doivent être générées dans le module cryptographique; elles doivent être conservées chiffrées, n’étant en clair qu’au moment requis pour leur utilisation.

6.2.7 Méthode d’activation de clé privée

La clé privée d’ACR est activée selon les méthodes internes du module cryptographique sur lequel ces clés sont générées. Une fois désactivées, les clés du module cryptographique peuvent être conservées sous une forme chiffrée dans un coffre.

Page 52: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 52 © Thales S.A 2009 – Tous droits réservés

La méthode d‘activation de clé privée d’une AC déléguée est du ressort de l’AA de l’AC déléguée. L’AC déléguée doit assurer que son personnel habilité à activer sa clé privée, soit identifié par le système. Une fois désactivées, les clés privées doivent être conservées tant que possible sous une forme chiffrée dans un coffre.

6.2.8 Méthode de désactivation de clé privée

La clé privée d’ACR est désactivée par effacement des clés du module cryptographique ou réinitialisation de ce module.

L’AA de l’AC déléguée s’engage à ne jamais laisser dans un état l’AC déléguée qui permet d'utiliser la clé privée sans utiliser un secret approprié.

6.2.9 Méthode de destruction de clé privée

Lorsque le certificat de signature numérique arrive à expiration ou s’il est révoqué, la clé privée ne doit plus servir à aucune opération et doit être détruite.

Lorsque l’ACR doit détruire sa clé privée, elle doit réinitialiser le module cryptographique ce qui implique la réécriture complète de toute forme de mémoire dans le module cryptographique. Elle doit aussi détruire tous les secrets de génération qui ont été partagés.

Pour détruire une clé privée, il faut écraser toutes les copies des clés privées quel qu’en soit le support. Les procédures de destruction des clés privées sont décrites dans la DPC.

6.3 Autres aspects de la gestion des paires de clés

6.3.1 Archive des clés publiques

L’ACR doit archiver toutes les clés publiques de validation conformément au §4.6.

6.3.2 Durée de vie des clé publiques et privées

La durée de validité du bi-clé de l’ACR et de ses composantes est de 10 ans.

La durée de validité du bi-clé de l’AC déléguée est de 10 ans.

L’utilisation d’une longueur particulière de clé doit être déterminée conformément à l’évaluation de la menace et des risques prenant en compte l’évolution des technologies d’attaque.

Les durées de validité des autres certificats sont définies dans la DPC.

6.4 Données d’activation

6.4.1 Génération et installation des données d’acti vation

La génération et l’installation des données d’activation des clés des AC déléguées sont du ressort de l’AC déléguée. Les mécanismes cryptographiques et de contrôle de l’accès utilisant ces données doivent être suffisamment robustes pour protéger les clés et les données elles-mêmes.

Page 53: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 53 © Thales S.A 2009 – Tous droits réservés

6.4.2 Protection des données d’activation

Les données d’activation doivent être protégées en confidentialité par les AC déléguées et les composantes de l’ACR. Celles-ci doivent être mémorisées et en aucun cas ne doivent être transcrites sur un support.

6.4.3 Autres aspects des données d’activation

L'utilisation de code PIN requiert une longueur d’au moins quatre (4) caractères alphanumériques.

L'utilisation d'un mot de passe requiert une longueur d’au moins huit (8) caractères alphanumériques dont la présence de chiffres, de lettres et de caractères spéciaux.

6.5 Contrôles de sécurité des postes de travail

6.5.1 Exigences de sécurité spécifiques sur les pos tes de travail

Les besoins de sécurité suivants doivent permettre d'évaluer le niveau de sécurité des postes de travail des composantes de l’ACR :

• Identification et authentification des Utilisateurs du poste de travail.

• Gestion de sessions d'utilisation (déconnexion après un temps d'inactivité, accès aux fichiers contrôlé par rôle et nom d'Utilisateur).

• Protection contre les virus informatiques.

• Fonctions d'audits (imputabilité et nature des actions effectuées).

• Eventuellement, gestion des reprises sur erreur.

• Le poste de travail de l’ACR, associé au module cryptographique contenant la clé privée de l’ACR doit être hors ligne.

Le niveau minimal d'assurance recherché doit au moins répondre à ces objectifs de sécurité. Les applications utilisant les services des composantes peuvent requérir des besoins de sécurité complémentaires, à prendre en compte dans la recherche du niveau minimal d'assurance offert par les postes de travail.

Le niveau d’assurance recherché pour les AC déléguées doit répondre aux même objectifs de sécurité suivants :

• Identification et authentification des Utilisateurs du poste de travail.

• Gestion de sessions d'utilisation (déconnexion après un temps d'inactivité, accès aux fichiers contrôlé par rôle et nom d'Utilisateur).

• Protection contre les virus informatiques.

• Fonctions d'audits (imputabilité et nature des actions effectuées).

• Eventuellement, gestion des reprises sur erreur.

Page 54: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 54 © Thales S.A 2009 – Tous droits réservés

6.5.2 Niveau de sécurité postes de travail

Un niveau minimal d'assurance dans le niveau de sécurité offert doit être défini dans la DPC pour tous les systèmes de l’infrastructure de l’ACR. Le niveau de sécurité des postes de travail doit être défini en terme :

• d’identification ;

• d’authentification ;

• de génération, initialisation et protection des données d’activation ;

• de lutte anti-virus ;

• d’accès réseau.

Si on utilise un système de mots de passe réutilisables, un mécanisme permettant de bloquer temporairement le compte après un nombre limité et fixé au préalable de tentatives est souhaitable. Cette mesure de protection est obligatoire pour les systèmes de l’ACR.

6.6 Contrôles techniques du système durant son cycl e de vie

6.6.1 Contrôles des développements des systèmes

L'implémentation d'un système permettant de mettre en oeuvre les composantes de l’infrastructure de l’ACR doit être documentée et respecter dans la mesure du possible des normes de modélisation et d'implémentation.

Les composantes de l’ACR doivent faire l’objet d’un suivi d’activité afin d’anticiper les modifications nécessaires notamment en termes de capacité de traitement et de stockage.

La configuration du système, des composantes, doivent être documentées et contrôlées. De même, toute modification et mise à niveau de composantes du système doivent être documentées et contrôlées et suivre la procédure pour la gestion des évolutions du système (changement de version, « patch », …).

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

Toute évolution du système doit être documentée et doit apparaître dans les procédures de fonctionnement interne de la composante concernée et être conforme au schéma de maintenance de l'assurance de conformité, dans le cas de produits évalués, et avec accord écrit de l’AA de l’ACR.

6.7 Contrôles de la sécurité réseau

L’ACR doit être isolée physiquement de tout réseau de communication.

6.8 Contrôles de la gestion du module cryptographiq ue

Les modules cryptographiques utilisés par l'ACR doivent présenter un label d'évaluation correspondant à une évaluation faite selon une méthode internationale d'assurance du niveau de sécurité.

Page 55: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 55 © Thales S.A 2009 – Tous droits réservés

7 Profils de certificats et de CRL

7.1 Profil des certificats

Le profil des certificats de l’ACR et des composantes d’ACR est défini dans la DPC.

Le profil des certificats AC déléguées est défini dans la DPC.

7.1.1 Numéro de version

Les certificats sont conformes à la norme X.509 v3 et au document RFC 2459.

7.1.2 Extensions du certificat

La version 3 de certificat X.509 permet de rajouter des informations additionnelles sur la clé publique de l’AC déléguée, la clé publique de l'émetteur, et sur les CRL.

Les extensions du certificat sont définis dans la DPC.

7.1.3 Identificateurs des objets algorithmes

Les identificateurs d’algorithmes sont inscrits auprès du registre international ISO.

Les algorithmes suivants doivent être utilisés par l'ACR et être pris en charge par les composantes et les AC déléguées, aux fins de signature et de vérification :

Algorithme Type Identificateur d’objet

RSA Asymétrique 1.2.840.113549.1.1.1

SHA-1 Hachage 1.3.14.3.2.26

7.1.4 Format des noms

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

Le format des noms est défini dans la DPC.

7.1.5 Contraintes relatives aux noms

Les dispositions relatives aux contraintes de noms sont celles édictées au §7.1.4.

7.1.6 Identificateur d’objet de la politique de cer tification

L'ACR doit s'assurer que l'OID de la politique est contenu dans les certificats des AC déléguées qu'elle délivre.

L’identificateur d’objet de la PC est référencé au §1.4.

7.1.7 Usage d’extension de contraintes de politique

L’usage d’extension de contraintes de politique est défini dans la DPC.

Page 56: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 56 © Thales S.A 2009 – Tous droits réservés

7.1.8 Syntaxe et sémantique des qualificatifs de po litique

La syntaxe et sémantique des qualificatifs de politique sont définies dans la DPC.

7.1.9 Sémantique de traitement pour l’extension cri tique de la politique de certification

Conformément à la norme X.509v3, le caractère critique doit être traité de la façon suivante selon que l'extension est critique ou non :

• Si l'extension est non - critique, alors :

- Si l'application ne sait pas la traiter, l'extension est abandonnée mais le certificat est accepté.

- Si l'application sait la traiter, alors :

• Si l'extension est conforme avec l'usage que l'application veut en faire, l'extension est traitée.

• Si l'extension n'est pas conforme avec l'usage que l'application veut en faire, l'extension est abandonnée, mais le certificat est accepté.

• Si l'extension est critique, alors :

- Si l'application ne sait pas la traiter, le certificat est rejeté.

- Si l'application sait la traiter, alors :

• Si l'extension est conforme avec l'usage que l'application veut en faire, l'extension est traitée.

• Si l'extension n'est pas conforme avec l'usage que l'application veut en faire, le certificat est rejeté.

7.2 Profil de CRL

Le profil des CRL de l’ACR et des composantes d’ACR est décrit dans la DPC.

Le profil des CRL des AC déléguées est décrit dans la DPC.

7.2.1 Numéro de version

Les CRL sont conformes à la norme X.509 v2 et au document RFC 2459.

7.2.2 Extensions des CRL

La version 2 de CRL X.509 permet de rajouter des informations additionnelles.

Les extensions des CRL sont définies dans la DPC.

7.2.2.1 Extensions prises en charge Les extensions prises en charge sont définies dans la DPC.

7.2.2.2 Extensions non prises en charge Les extensions non prises en charge sont définies dans la DPC.

Page 57: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 57 © Thales S.A 2009 – Tous droits réservés

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 Politique de Certification.

8.1 Procédures de modification de la PC

En cas d’évolution de document une référence ne peut pas être supprimée, à défaut elle est annotée comme sans objet.

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 PC doit être publiée dans une nouvelle version et approuvée par l’AA de l’ACR.

Le processus de revue pour la modification et l’approbation de la PC et de la DPC doit être documenté et mis en œuvre.

8.1.2.1 Liste des articles Tous les articles de la présente PC 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 ne soient apportées à la présente PC, un avis concernant les prochaines modifications sera transmis de manière sécurisée à l’OSC par l’AA de l’ACR.

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 de l’ACR pourra demander à l’ACR d’aviser les AC déléguées à qui elle a émis des certificats 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 de l’ACR qui jugera de la pertinence des commentaires et acceptera ou non l’intégration de ces commentaires aux modifications.

Page 58: IGC DE THALES POLITIQUE DE CERTIFICATION AC RACINEcrl.thalesgroup.com/certification_policy/A4284000-DOC-075-PCACR-V2... · Documents de référence ... IGC de Thales – Politique

IGC de Thales – Politique de Certification AC racine : Thales Root CA

A4284000-DOC-075-PCACR-V2.0.doc 10/06/2009 Page 58 © Thales S.A 2009 – Tous droits réservés

8.1.2.5 Période de l’avis définitif de modification L’AA de l’ACR doit donner un préavis de trente (30) jours calendaires aux AC déléguées 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 de l’ACR doit donner un préavis de quinze (15) jours calendaires aux AC déléguées 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 de l’ACR doit donner un préavis aux AC déléguées 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 de l’ACR ou de sa composante d’enregistrement, l’AA de l’ACR 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 de l’ACR 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 PC est disponible 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 :

• par messagerie à l’adresse suivante : [email protected]

8.3 Procédures d’approbation de la PC

L'approbation de la présente PC est réalisée par l’AA de l’ACR, représentée par le Directeur Systèmes d’Information de Thales S.A.

La décision de l’AA de l’AC déléguée de ne pas demander la révocation de son certificat suite à la notification d'un changement proposé constitue l'acceptation du changement.