Politique de Certification de l ... - · Responsabilités des acteurs de l’IGC .....11 2.2.2. Limites de responsabilités du CEA ... DOCUMENTS DE REFERENCES

Réf. du fichier : Politique Certification IGC Définitivie A6.doc

Modèle AQ : DCS/DIR/QUA/MOD/4.2/0001_A0

Page 1 sur 45

Copyright © 2003 CEA – Ce document est la propriété du CEA et ne peut être utilisé, reproduit ou communiqué en dehors du contexte de son IGC sans son autorisation.

Date : 06/01/2003

Direction Centrale de la

Sécurité

Réf. : DCS/ACI/DOC/SSI/4.2/0114 Politique de Certification de l’IGC CEA

Indice : A6

Etat : VALI

Politique de Certification de l’Infrastructure de Gestion de

Clés du CEA

Réf. du fichier : Politique Certification IGC Définitivie A6.doc

Modèle AQ : DCS/DIR/QUA/MOD/4.2/0001_A0

Page 2 sur 45

Copyright © 2003 CEA – Ce document est la propriété du CEA et ne peut être utilisé, reproduit ou communiqué en dehors du contexte de son IGC sans son autorisation.

Date : 06/01/2003

Direction Centrale de la

Sécurité

Réf. : DCS/ACI/DOC/SSI/4.2/0114 Politique de Certification de l’IGC CEA

Indice : A6

Etat : VALI

Etat de révision du document :

Date Indice Etat Rédacteur Observations 06/01/2003 A0 PROJ CV Création du document

14/01/2003 A1 PROJ CV Corrections typographiques et ajout schéma

15/01/2003 A2 PROJ CV Modification de la notion de validité des CRL

14/02/2003 A3 PROJ CV Modification des noms des AC

Mise à jour des URL contenues dans les certificats

Complément des procédures de séquestre et recouvrement

24/02/2003 A4 PROJ CV Evolutions liées à la rédaction de la DPC

13/03/2003 A5 PROJ CV Corrections typographiques

Modification des sujets des certificats utilisateurs

01/04/2003 A6 VALI CV Modifications de la mise en page

Réf. DCS/ACI/DOC/SSI/4.2/0114 Politique de Certification de l’IGC CEA Page 3 sur 45 Copyright © 2003 CEA – Ce document est la propriété du CEA et ne peut être utilisé, reproduit ou communiqué en dehors du contexte de son IGC sans son autorisation.

Date : 06/01/2003 Indice : A6 Etat : VALI

1. INTRODUCTION ................................................................................................................................. 6 1.1. PRESENTATION GENERALE............................................................................................................... 6

1.1.1. Contexte ................................................................................................................................. 6 1.1.2. Objectifs de la Politique de Certification................................................................................. 6

1.2. IDENTIFICATION ...............................................................................................................................6 1.3. APPLICATION DE LA POLITIQUE ET GROUPE D'UTILISATEURS CONCERNES............................................ 7

1.3.1. Autorités et Groupes d'utilisateurs concernés........................................................................ 7 1.3.2. Types d’applications concernés ............................................................................................. 9

1.4. CONTACTS ...................................................................................................................................... 9 1.4.1. Autorité compétente dans l’accréditation des composantes de l’IGC.................................... 9 1.4.2. Personnes à contacter concernant ce document ................................................................... 9

2. DISPOSITIONS D’ORDRE GENERAL............................................................................................. 10 2.1. OBLIGATIONS DES ACTEURS........................................................................................................... 10

2.1.1. Obligations communes à toutes les composantes............................................................... 10 2.1.2. Abonné ................................................................................................................................. 10 2.1.3. Autorité Administrative.......................................................................................................... 10 2.1.4. Autorité d’Enregistrement ..................................................................................................... 10 2.1.5. Opérateur d’Enregistrement ................................................................................................. 10 2.1.6. Autorité de Certification ........................................................................................................ 10 2.1.7. Autorité de Séquestre........................................................................................................... 11 2.1.8. Service de Publication .......................................................................................................... 11 2.1.9. Utilisateur de certificat .......................................................................................................... 11

2.2. RESPONSABILITES DES ACTEURS.................................................................................................... 11 2.2.1. Responsabilités des acteurs de l’IGC .................................................................................. 11 2.2.2. Limites de responsabilités du CEA....................................................................................... 11

2.3. RESPONSABILITES FINANCIERES..................................................................................................... 11 2.4. INTERPRETATIONS DE LA LOI .......................................................................................................... 11 2.5. BAREMES DE PRIX ......................................................................................................................... 11 2.6. PUBLICATIONS ET SERVICES ASSOCIES ........................................................................................... 12

2.6.1. Publication des informations relatives à l’IGC...................................................................... 12 2.6.2. Fréquence de publication ..................................................................................................... 12 2.6.3. Contrôles d’accès ................................................................................................................. 12 2.6.4. Service de Publication et Portail Web .................................................................................. 12

2.7. CONTROLE DE CONFORMITE........................................................................................................... 12 2.7.1. Fréquence du contrôle de conformité................................................................................... 12 2.7.2. Identification et qualifications du contrôleur ......................................................................... 12 2.7.3. Sujets couverts par le contrôle de conformité ...................................................................... 13 2.7.4. Mesures à prendre en cas de non-conformité...................................................................... 13 2.7.5. Communication des résultats ............................................................................................... 13

2.8. POLITIQUE DE CONFIDENTIALITE ..................................................................................................... 13 2.8.1. Type d’informations considérées comme confidentielles..................................................... 13 2.8.2. Type d’informations considérées comme non confidentielles.............................................. 13 2.8.3. Divulgation des causes de révocation et de suspension des certificats .............................. 13 2.8.4. Délivrance aux autorités légales .......................................................................................... 13 2.8.5. Délivrance à la demande du propriétaire ............................................................................. 13 2.8.6. Autres circonstances de délivrance possible ....................................................................... 13

2.9. DROITS DE PROPRIETE................................................................................................................... 14 3. IDENTIFICATION ET AUTHENTIFICATION .................................................................................... 15

3.1. ENREGISTREMENT INITIAL .............................................................................................................. 15 3.1.1. Conventions de noms........................................................................................................... 15 3.1.2. Nécessité d’utilisation de noms explicites ............................................................................ 15 3.1.3. Règles d’interprétation des différentes formes de noms...................................................... 15 3.1.4. Unicité des noms .................................................................................................................. 15 3.1.5. Procédures de résolution des litiges sur la revendication d’un nom .................................... 15 3.1.6. Reconnaissance, authentification et rôle concernant les noms de marques ....................... 15 3.1.7. Authentification de l’identité d’un organisme........................................................................ 15 3.1.8. Authentification de l’identité d’un individu............................................................................. 16



3.2. RE-GENERATION DE CERTIFICAT EN FIN DE VALIDITE ........................................................................ 16 3.3. RE-GENERATION DE CLES APRES REVOCATION................................................................................ 16 3.4. AUTHENTIFICATION D’UNE DEMANDE DE REVOCATION ...................................................................... 16

4. BESOINS OPERATIONNELS........................................................................................................... 17 4.1. DEMANDE DE CERTIFICAT............................................................................................................... 17

4.1.1. Demande de certificat pour l’AC Utilisateur.......................................................................... 17 4.1.2. Demande de certificat pour l’AC Badge ............................................................................... 17 4.1.3. Demande de certificat pour l’AC Technique......................................................................... 18 4.1.4. Demande de certificat pour l’AC Partenaire ......................................................................... 18

4.2. GENERATION DE CERTIFICAT .......................................................................................................... 18 4.3. ACCEPTATION D’UN CERTIFICAT...................................................................................................... 18 4.4. REVOCATION DES CERTIFICATS ...................................................................................................... 19

4.4.1. Causes possibles de révocation........................................................................................... 19 4.4.2. Origine des demandes de révocation................................................................................... 19 4.4.3. Procédure de demande de révocation ................................................................................. 19 4.4.4. Temps de traitement d’une révocation ................................................................................. 20 4.4.5. Fréquence de mise à jour de la liste des certificats révoqués (CRL)................................... 20 4.4.6. Exigences de contrôle des CRL ...........................................................................................20 4.4.7. Publication des causes de révocation .................................................................................. 20 4.4.8. Contrôle en ligne des CRL ................................................................................................... 20 4.4.9. Cas particulier de la révocation pour compromission de clé................................................ 20

4.5. JOURNALISATION ........................................................................................................................... 20 4.6. ARCHIVES ..................................................................................................................................... 20

4.6.1. Types de données archivées ............................................................................................... 20 4.6.2. Durée de rétention des archives .......................................................................................... 21 4.6.3. Protection des archives ........................................................................................................ 21 4.6.4. Procédures d’accès et de récupération des archives .......................................................... 21

4.7. CHANGEMENT DE CLE D’UNE COMPOSANTE..................................................................................... 21 4.8. COMPROMISSION ET PLAN ANTI-SINISTRE........................................................................................ 22

4.8.1. En cas de corruption des ressources informatiques (logiciels ou données) ........................ 22 4.8.2. En cas de révocation du certificat d’une composante de l’IGC............................................ 22 4.8.3. Mesures de sécurité en cas de sinistre ................................................................................ 22

4.9. FIN DE VIE D’UNE COMPOSANTE...................................................................................................... 22 5. CONTROLES DE SECURITE PHYSIQUE, DES PROCEDURES ET DU PERSONNEL................ 23

5.1. CONTROLES DE SECURITE PHYSIQUE.............................................................................................. 23 5.2. CONTROLES DES PROCEDURES...................................................................................................... 23

5.2.1. Rôles de confiance ............................................................................................................... 23 5.2.2. Nombre de personnes nécessaires à chaque tâche............................................................ 24 5.2.3. Identification et authentification des rôles ............................................................................ 24

5.3. CONTROLES DU PERSONNEL .......................................................................................................... 24 6. CONTROLES TECHNIQUES DE SECURITE .................................................................................. 25

6.1. GENERATION ET INSTALLATION DE BICLES....................................................................................... 25 6.1.1. Génération de biclés............................................................................................................. 25 6.1.2. Délivrance de clé privée à son propriétaire .......................................................................... 25 6.1.3. Transmission de clé publique à une AC............................................................................... 25 6.1.4. Délivrance de la clé publique des AC aux utilisateurs ......................................................... 25 6.1.5. Taille des clés ....................................................................................................................... 25 6.1.6. Génération des paramètres de clé publique ........................................................................ 25 6.1.7. Contrôle de la qualité des paramètres ................................................................................. 25 6.1.8. Mode de génération de clé (matériel ou logiciel).................................................................. 25 6.1.9. Usage de la clé..................................................................................................................... 25

6.2. PROTECTION DE CLE PRIVEE .......................................................................................................... 26 6.2.1. Module de cryptographie utilisant des normes..................................................................... 26 6.2.2. Contrôle des clés privées par plusieurs personnes ............................................................. 26 6.2.3. Séquestre de clé privée........................................................................................................ 26 6.2.4. Recouvrement de clé privée................................................................................................. 26 6.2.5. Archivage de clé privée ........................................................................................................ 26



6.2.6. Mise à la clé du module cryptographique............................................................................. 26 6.2.7. Méthode d’activation de clé privée ....................................................................................... 27 6.2.8. Méthode de désactivation de clé privée ............................................................................... 27 6.2.9. Méthode de destruction de clé privée .................................................................................. 27

6.3. AUTRES ASPECTS DE GESTION DES BICLES ..................................................................................... 27 6.3.1. Archivage des clés publiques............................................................................................... 27 6.3.2. Durée de vie des clés publiques et privées.......................................................................... 27

6.4. DONNEES D'ACTIVATION................................................................................................................. 27 6.5. SECURITE DES POSTES DE TRAVAIL ................................................................................................ 27 6.6. CONTROLES TECHNIQUES DU SYSTEME DURANT SON CYCLE DE VIE.................................................. 27 6.7. SECURITE DES RESEAUX................................................................................................................ 28 6.8. CONTROLES TECHNIQUES DES MODULES DE CRYPTOGRAPHIE ......................................................... 28

7. PROFILS DES CERTIFICATS ET DES LISTES DE CERTIFICATS REVOQUES.......................... 29 7.1. PROFILS DES CERTIFICATS ............................................................................................................. 29 7.2. PROFILS DES CRL......................................................................................................................... 29

8. ADMINISTRATION DES SPECIFICATIONS.................................................................................... 29 8.1. PROCEDURES DE MODIFICATION DE CES SPECIFICATIONS ................................................................ 29 8.2. POLITIQUES DE PUBLICATION ET DE NOTIFICATION ........................................................................... 29 8.3. PROCEDURES D’APPROBATION DES DPC........................................................................................ 29

ANNEXE A : DOCUMENTS DE REFERENCES .................................................................................. 30 ANNEXE B : GLOSSAIRE.................................................................................................................... 32

B.1 ACRONYMES.............................................................................................................................. 32 B.2 ACTIONS ................................................................................................................................... 32 B.3 ACTEURS .................................................................................................................................. 33 B.4 OBJETS..................................................................................................................................... 35

ANNEXE C : FORMAT DES CERTIFICATS ........................................................................................ 36 C.1 CERTIFICATS DE L’AC RACINE.................................................................................................... 36

C.1.1 Champs de base du certificat .......................................................................................... 36 C.1.2 Extensions du certificat .................................................................................................... 37

C.2 CERTIFICATS DES AC SUBORDONNEES....................................................................................... 38 C.2.1 Champs de base des certificats....................................................................................... 38 C.2.2 Extensions des certificats................................................................................................. 39

C.3 CERTIFICATS DES ABONNES....................................................................................................... 41 C.3.1 Champs de base des certificats des Abonnés................................................................. 41 C.3.2 Extensions des certificats des Abonnés des AC Utilisateur, Badge et Partenaire .......... 42 C.3.3 Extensions des certificats des Abonnés de l’AC Technique............................................ 43

ANNEXE D : FORMAT DES CRL......................................................................................................... 45



1. INTRODUCTION 1.1. PRESENTATION GENERALE 1.1.1. Contexte

L’évolution des réseaux et des traitements automatisés d’informations impose de renforcer la protection des données sur les systèmes d’information. La cryptographie est une solution qui, en complément des architectures de SI et procédures organisationnelles, permet de garantir l’intégrité et la confidentialité des données, ainsi que l’identité des personnes y accédant.

Cependant, pour être mise en œuvre de façon efficace, cette solution doit être en premier lieu guidée par les besoins de sécurité, tout en tenant compte de considérations relatives à sa mise en œuvre effective. Pour ces raisons, l’entreprise se doit de maîtriser son usage, par souci de préservation de la disponibilité du patrimoine, non-dispersion des conventions secrètes et respect des obligations légales.

C’est dans ce cadre que le Commissariat à l’Energie Atomique (CEA) a décidé de se doter d’une Infrastructure de Gestion de Clés, afin de fédérer et maîtriser l’utilisation des outils cryptographiques.

1.1.2. Objectifs de la Politique de Certification Ce document décrit la Politique de Certification (PC) de l’Infrastructure de Gestion de Clés (IGC)

gérée par le CEA. La PC est un ensemble de règles qui indique les conditions de gestion et d’utilisation des clés et des certificats dépendants de l’IGC. Son but est de fournir aux utilisateurs de l’IGC les informations relatives aux garanties offertes par les certificats qu’elle émet, ainsi que les conditions d’utilisation de ces certificats.

Les pratiques mises en oeuvre pour atteindre les garanties offertes sur ces certificats sont présentées dans un autre document, la Déclaration relative aux Pratiques de Certification (DPC).

La présente PC reprend la structuration du document « Procédures et Politiques de Certification de Clés » [PC2] émis par la Commission Interministérielle pour la Sécurité des Systèmes d’Information (CISSI), lui-même issu du document [RFC 2527].

1.2. IDENTIFICATION Chaque Politique de Certification doit être identifiée de façon unique. On lui donne pour cela un

nom de référence ainsi qu’un Identifiant d’Objet. La référence de la présente politique de certification est "PC_CEA_IGC". Un Identifiant d’Objet (OID) est une série de nombres organisée en arborescence et que l’on

associe à un « objet » (généralement informatique). Le CEA a obtenu auprès de l’IANA la branche « 1.3.6.1.4.1.12384 » sous laquelle la branche « 1 » désigne le projet IGC et la sous-branche « 2 » la présente Politique de Certification. L’OID de la politique est donc « 1.3.6.1.4.1.12384.1.2 » et il se décompose comme suit :

{ iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) cea(12384) igc(1) pc(2) } Tous les certificats émis selon la présente politique portent une référence à cet OID. La politique de certification est consultable à l’adresse : http://www-igc.cea.fr/pc/



1.3. APPLICATION DE LA POLITIQUE ET GROUPE D'UTILISATEURS CONCERNES

OpérateursAutorités

d’EnregistrementAbonnés

Autorité deSéquestre

Portail Web

AC Filles

AC Racine

Utilisateurs decertificats

Service dePublication

Composantes

Acteurs

Synopsis de l’IGC CEASynopsis de l’IGC CEA

AutoritéAdministrative

1.3.1. Autorités et Groupes d'utilisateurs concernés Abonnés

Un Abonné est une entité (personne physique, système informatique, …) disposant d'un certificat en cours de validité, émis par une Autorité de Certification de la présente Politique de Certification. L’Abonné peut également être désigné sous le nom de Porteur de certificat.

Autorité Administrative L'Autorité Administrative est garante de l'application de la Politique de Certification de l'IGC. Elle

valide et contrôle les pratiques de certification (DPC) des composantes de l’IGC.

Autorité d’Enregistrement Les Autorités d’Enregistrement (AE) sont les composantes de l’IGC qui relayent les demandes de

certification des utilisateurs auprès des Autorités de Certification. Elles ont en charge la vérification de l'identité des demandeurs lors de leur demande de certification.

Les AE sont reconnues par l’Autorité de Certification pour laquelle elles authentifient les utilisateurs. Elles sont au plus proche des utilisateurs et gèrent les Abonnés appartenant à un périmètre défini.

Autorité de Certification L’Autorité de Certification (AC) une composante de l’IGC qui a en charge l'émission, la révocation

et le renouvellement de certificats. Par ces actes, elle engage la responsabilité du CEA vis à vis des utilisateurs qui lui font confiance.

L’IGC est composée de plusieurs AC : � AC Racine

o seule AC possédant un certificat auto-signé, elle gère les certificats des autres AC de l’IGC (appelées AC filles) ;

� AC Utilisateur o gère les certificats des personnes physiques possédant un badge CEA ; o délivre un seul certificat par utilisateur, en utilisant des supports logiciels (fichiers)

pour le transport des biclés ;



� AC Badge o gère les certificats des personnes physiques possédant un badge CEA ; o délivre deux certificats par utilisateur (un certificat de signature/authentification et

un certificat de chiffrement), en utilisant des cartes à puce pour le transport des biclés ;

� AC Technique o gère les certificats d’authentification des entités techniques (serveurs Web,

routeurs, passerelles, …) appartenant au CEA ; o gère aussi les certificats attribués à des rôles d’exploitation ou d’administration

d’entités techniques ; o les biclés sont transportées par support logiciel ;

� AC Partenaire o gère les certificats des personnes physiques ou morales travaillant en

collaboration avec le CEA mais ne possédant pas de badge CEA. Les biclés sont transportées par support logiciel.

Autorité de Séquestre L’Autorité de Séquestre (AS) est la composante de l’IGC qui a la responsabilité de séquestrer les

biclés générées par une AC ou fournies par les utilisateurs. Elle permet le recouvrement de ces clés pour le compte des utilisateurs (perte de la biclé, départ d’un employé de l’entreprise, etc.) ou pour le compte d’autorités légales.

Opérateurs Les Opérateurs réalisent l’exploitation des services offerts par les différentes composantes de

l’IGC. Lorsqu’une action est validée par une autorité compétente, ils sont chargés de lancer l’exécution des fonctions cryptographiques correspondantes.

Portail Web Le Portail Web est la composante de l’IGC qui a le rôle d’interface entre les Acteurs et les autres

composantes de l’IGC. Il permet aux Opérateurs de mettre en œuvre les différentes fonctions auxquelles ils ont accès, aux utilisateurs d’effectuer leurs demandes de certificats, aux Abonnés de révoquer et renouveler leurs certificats, aux Utilisateurs de certificats d’accéder au Service de Publication.

Le Portail Web a aussi en charge la publication des ressources bibliographiques et documentaires de l’IGC.

Service de Publication Le Service de Publication distribue les certificats et les listes de révocation émis par l’IGC aux

Utilisateurs de ces certificats.

Utilisateur de certificat Un Utilisateur de certificat est une entité (personne physique, système informatique, …)

susceptible d'utiliser un certificat émis par l'IGC, sans forcément en détenir un en propre ; par exemple en vérifiant la signature d’un Abonné, ou en lui transmettant un message chiffré.



1.3.2. Types d’applications concernés Les certificats et clés émis par les AC de la présente Politique de Certification sont destinés à être

intégrés à toute application mettant en œuvre de la cryptographie et autorisée par la réglementation du CEA.

A titre d’exemple, les applications possibles pour chaque catégorie d’Abonné sont : Abonnés des AC Utilisateur et Badge : � authentification et le chiffrement des messages électroniques � authentification auprès de serveurs (Web, VPN, …) � chiffrement de fichiers � authentification de composants logiciels

Abonnés de l’AC Technique : � authentification de serveurs Web � authentification de passerelles de réseaux privés virtuels � authentification des administrateurs d’entités réseau

Abonnés de l’AC Partenaire : � authentification et chiffrement des communications entre le CEA et ses collaborateurs

extérieurs La mise en œuvre de ces applications est soumise à des configurations logicielles et matérielles

définies par la Direction des Technologies de l’Information du CEA et publiées sur le Portail Web de l’IGC.

Sont exclues de la présente politique les applications permettant la mise en œuvre de la signature électronique telle que définie par la loi, et les applications permettant de réaliser des transactions financières.

1.4. CONTACTS 1.4.1. Autorité compétente dans l’accréditation des composantes de l’IGC

L’IGC étant strictement réservée aux besoins interne du CEA, aucune accréditation par un organisme extérieur n’est demandée.

1.4.2. Personnes à contacter concernant ce document CEA DCS/SPACI/SSI Route du Panorama – B.P. 6 92265 Fontenay-aux-Roses Cedex tél. : 01 46 54 97 35 fax. : 01 46 54 97 37 mel : [email protected]



2. DISPOSITIONS D’ORDRE GENERAL 2.1. OBLIGATIONS DES ACTEURS

Tous les acteurs de l’IGC se doivent de respecter la [NIG469].

2.1.1. Obligations communes à toutes les composantes � protéger sa clé privée et ses données d’activation en intégrité et en confidentialité ; � 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 en accord avec la présente politique ; � respecter et appliquer la ou les DPC mises en oeuvre ; � respecter le résultat d’un contrôle de conformité et remédier aux non-conformités qu’il

révèle ; � respecter l’engagement qui lie l’entité à l’IGC ; � documenter ses procédures internes de fonctionnement ;

2.1.2. Abonné � protéger sa clé privée et ses données d’activation en intégrité et en confidentialité ; � respecter la PC selon laquelle ses certificats ont été émis ; � dès qu’il suspecte ou a connaissance d’une compromission ou d’une perte de sa clé

privée, en informer l’autorité chargée de la révocation ; � fournir à son AE des données personnelles d’identification sincères et authentiques lors

de son enregistrement ; � informer son AE de tout changement concernant les informations figurant dans ses

certificats ; � utiliser ses certificats et biclés aux fins pour lesquelles ils sont générés.

2.1.3. Autorité Administrative � valider la Politique de Certification ; � résoudre les litiges ; � contrôler la conformité des DPC avec la PC.

2.1.4. Autorité d’Enregistrement � s’assurer de l’identité du demandeur de certificat lorsqu’il lui présente son formulaire de

demande ; � authentifier les demandes de révocation qu’il reçoit et les traiter avec diligence.

2.1.5. Opérateur d’Enregistrement � n’accepter que les demandes pour lesquelles il a reçu un formulaire validé par une

Autorité d’Enregistrement qu’il reconnaît ; � authentifier les demandes de révocation qu’il reçoit de la part des Abonnés ; � traiter avec diligence les demandes de révocations authentifiées ; � conserver et protéger en confidentialité et en intégrité des données personnelles

d’identification transmises pour l’enregistrement.

2.1.6. Autorité de Certification � en cas de révocation du certificat d’une composante de l’IGC, en informer tous les

utilisateurs finaux, par tout moyen jugé pertinent ; � documenter et publier les schémas de certification qu’elle entretient avec d’autres AC ou

d’autres IGC ; � générer et renouveler les certificats quand les demandes ont été authentifiées ; � révoquer les certificats quand les demandes ont été authentifiées ; � transmettre des listes de certificats (valides et révoqués) au service de publication ; � garantir l'intégrité et la précision des dates utilisées dans la génération des certificats, des

listes de révocations, des journaux d’événements, des archives, etc. ; � générer les clés des Abonnés lorsque cela est demandé ; � pour les AC Utilisateur, Badge et Partenaire, transmettre les biclés de confidentialité à

l’Autorité de Séquestre ; � délivrer des clés aux Abonnés par un canal protégé (en confidentialité et en intégrité pour

les clés privées, en intégrité pour les clés publiques).



2.1.7. Autorité de Séquestre � protéger la confidentialité des clés secrètes qu’elle gère ; � permettre le recouvrement des clés privées qu’elle séquestre par les personnes

autorisées ; � s’assurer de la légitimité des demandes de recouvrement qu’elle traite ; � mettre en œuvre le recouvrement des biclés dans les délais prévus par la PC (cf. § 6.2.4).

2.1.8. Service de Publication � protéger en intégrité les listes qu’il publie ; � mettre à jour les listes de certificats et les CRL dans les délais fixés par la PC (cf.

§ 2.6.2) ; � protéger l’intégrité des données qui lui ont été transmises par l’AC ;

2.1.9. Utilisateur de certificat � consulter les listes de certificats publiées et vérifier la validité des certificats avant leur

utilisation.

2.2. RESPONSABILITES DES ACTEURS 2.2.1. Responsabilités des acteurs de l’IGC

Les acteurs, composantes et autorités de l’IGC sont responsables de la mise en œuvre des moyens techniques et humains nécessaires au respect de leurs obligations.

2.2.2. Limites de responsabilités du CEA Le CEA décline toute responsabilité vis à vis de l’utilisation, dans des conditions autres que celles

prévues par la présente PC, des certificats et clés émis par son IGC. Il décline notamment sa responsabilité pour tout dommage résultant d’un emploi de ces certificats pour des usages tels que : la réalisation de transactions financières, la réalisation d’actes délictueux, l’utilisation de moyens de cryptologie illégaux ou non approuvés par le CEA, le traitement d’informations n’appartenant pas au CEA.

Le CEA décline également sa responsabilité pour tout dommage résultant des erreurs ou inexactitudes entachant les informations contenues dans les certificats émis par son IGC, lorsque ces erreurs ou inexactitudes résultent directement du caractère erroné des informations qui lui ont été transmises.

2.3. RESPONSABILITES FINANCIERES Sans objet.

2.4. INTERPRETATIONS DE LA LOI Les composantes de l'IGC veillent à la protection des données à caractère personnel d’une

personne physique, suivant la loi [L78-17] et la directive [DE 96/95/CE] ; ainsi qu’au respect de la législation française et européenne définissant les conditions d’usage des moyens cryptographiques ([L90-1170], [D99-199], [D99-200], [D98-101], [A475], [A730], [A732]).

Les certificats fournis ne permettant pas de réaliser des opérations de signature électronique au sens des textes [L2000-230], [D2001-272] et [DE 93/CE], ils ne sont pas applicables au contexte de l’IGC CEA.

Les certificats fournis par l’IGC permettant d’assurer des fonctions de confidentialité, l’Autorité de Séquestre est en charge de l’application de l’article 11-1 de la loi [L91-646]. Néanmoins, l’IGC ne fournissant des certificats de confidentialité que pour les besoins internes du CEA, elle n’est pas considérée comme un organisme gérant pour le compte d’autrui des conventions secrètes. De ce fait, les textes [D98-102], [A731] et [A733] ne lui sont pas applicables.

2.5. BAREMES DE PRIX Sans objet dans le contexte d’une IGC d’entreprise à usage interne.



2.6. PUBLICATIONS ET SERVICES ASSOCIES 2.6.1. Publication des informations relatives à l’IGC

Les informations suivantes sont diffusées publiquement : � la politique de certification (PC) ; � les empreintes numériques des certificats des AC ; � les certificats des AC ; � les listes de révocation des certificats.

Les formulaires de gestion des certificats (création, révocation, etc.) de chaque AC ne sont diffusés qu’aux Abonnés et aux personnes autorisées à demander des certificats.

Le Service de Publication a en charge la diffusion de ces documents (cf. § 2.6.4).

2.6.2. Fréquence de publication La publication en ligne des informations est permanente. Le Service de Publication a en charge la

disponibilité et la continuité du service. Dans la mesure du possible, les interruptions pour maintenance sont annoncées une semaine à l’avance.

Les listes des certificats et CRL publiées sont mises à jour dans les 24 heures ouvrées qui suivent leur transmission par les AC.

2.6.3. Contrôles d’accès La population des utilisateurs est différente pour chaque AC. Le Service de Publication est

responsable de la mise en oeuvre du contrôle d'accès permettant de ne publier aux utilisateurs que les informations qui les concernent.

2.6.4. Service de Publication et Portail Web Les informations publiées sont reparties entre un annuaire LDAP, un portail Web et des points de

distribution. Le Portail Web est réparti sur deux sites : � https://www-igc.intra.cea.fr/ pour la consultation des certificats des Abonnés et les

formulaires de gestion des certificats des AC Utilisateur, Badge et Technique. Ce site n’est accessible que depuis l’Intranet CEA.

� http://www-igc.cea.fr/ pour la diffusion des informations publiques (cf. § 2.6.1), la consultation des certificats révoqués en ligne, et les formulaires de gestion des certificats des utilisateurs de l’AC Partenaire. Ce site est accessible depuis Internet.

L’annuaire LDAP distribue les certificats de l’IGC ainsi que les listes de révocation. L’arborescence de l’annuaire, les attributs utilisés et son adresse sont précisés sur le Portail Web.

Les points de distribution sont des URL utilisant le protocole HTTP. Ils sont inscrits dans les certificats émis par les AC. Ils permettent de récupérer les CRL, les certificats des AC et la Politique de Certification. Ils sont de la forme :

� http://www-igc.cea.fr/pc/ pour la Politique de Certification � http://crl-ac-nom.cea.fr/crl/ac-nom.crl pour les CRL � http://www-igc.cea.fr/ac/ac-nom.cer pour les certificats des AC

où ac-nom est : � ac-racine � ac-utilisateur � ac-badge � ac-technique � ac-partenaire

2.7. CONTROLE DE CONFORMITE 2.7.1. Fréquence du contrôle de conformité

Le premier contrôle de conformité d’une composante précède sa mise en service, puis des contrôles sont pratiqués annuellement.

2.7.2. Identification et qualifications du contrôleur L’Autorité Administrative désigne un contrôleur compétent en sécurité des systèmes d’information,

n’appartenant pas à la composante, et dûment autorisé à pratiquer ces contrôles.



2.7.3. Sujets couverts par le contrôle de conformité Le contrôle de conformité porte sur les procédures mises en œuvre par la composante et leur

correspondance avec les règles de la Politique de Certification et de la DPC de la composante.

2.7.4. Mesures à prendre en cas de non-conformité A l’issue du contrôle de conformité, le contrôleur rend un rapport à l’Autorité Administrative

indiquant les éventuels écarts relevés. Le cas échéant, il peut proposer des solutions correctives. L’Autorité Administrative évalue la gravité des écarts, en informe la composante, et étudie avec

elle les mesures à prendre afin de corriger dans les meilleurs délais les écarts relevés. En cas de grave disfonctionnement de la composante, une révocation de son certificat peut être décidée par l’Autorité Administrative.

2.7.5. Communication des résultats Les résultats sont communiqués aux composantes concernées. De plus, ils peuvent être

communiqués à toute personne ou entité ayant le besoin d’en connaître.

2.8. POLITIQUE DE CONFIDENTIALITE 2.8.1. Type d’informations considérées comme confidentielles

On définit au sein de l’IGC deux niveaux de confidentialité : « Diffusion Limitée IGC CEA » et « Confidentiel IGC CEA». La DPC détaille les conditions d’usage et de traitement de ces informations.

Les informations suivantes sont classées « Confidentiel IGC CEA » : � clés privées des composantes et des utilisateurs ; � conventions cryptographiques nécessaires au recouvrement des clés des AC ; � code porteur et mot de passe d’activation des clés privées ;

Dans le contexte de l’IGC, toute information qui n’est pas classée « Confidentiel IGC CEA », et qui n’est pas explicitement déclarée comme non confidentielle au § 2.8.2 est classée « Diffusion Limitée IGC CEA ». Ces informations regroupent en particulier :

� journaux d’événement des composantes ; � données d’identification d’un utilisateur (identifiant nominatif) ; � les certificats permettant d’identifier une personne ; � les causes de révocation des certificats ; � les DPC des composantes.

2.8.2. Type d’informations considérées comme non confidentielles Les informations suivantes ne sont pas confidentielles : � la Politique de Certification ; � les certificats des AC ; � les certificats des Abonnés de l’AC Technique ; � les listes des révocations ; � les formulaires de gestion des certificats des utilisateurs de l’AC Partenaire.

2.8.3. Divulgation des causes de révocation et de suspension des certificats La cause de révocation d’un certificat doit être communiquée à l’AC qui procède à la révocation.

Cette cause est conservée par l’AC mais elle n’apparaît pas dans la liste de révocation publiée.

2.8.4. Délivrance aux autorités légales Les autorités légales dûment mandatées peuvent demander à accéder aux informations

confidentielles. Elles doivent pour cela adresser leur demande à l’Autorité Administrative.

2.8.5. Délivrance à la demande du propriétaire Toute information, même confidentielle, est accessible par son propriétaire.

2.8.6. Autres circonstances de délivrance possible Les informations confidentielles peuvent être délivrées à tout tiers pouvant démontrer un besoin

d’en connaître, et dûment habilité par sa fonction à en prendre connaissance.



2.9. DROITS DE PROPRIETE Le CEA est titulaire de l’ensemble des droits de propriété intellectuelle et industrielle attachés aux

éléments de toute nature et notamment logiciel, bases de données, documentation, matériel, système, savoir-faire utilisés au titre du service proposé et fourni par l’IGC, ou a obtenu des titulaires desdits droits, les autorisations nécessaires aux fins d’exécution dudit service.

Les logiciels, bases de données, documentation, matériel, système, savoir-faire et tout autre produit, élément, document, utilisés au titre du service proposé et fourni pour l’IGC, ainsi que tous les droits de propriété intellectuelle et industrielle qui y sont attachés (droits d’auteur, brevet, marque, etc.), restent en toutes circonstances la propriété exclusive du CEA, quel s’en soit l’état d’achèvement et ce, au fur et à mesure de leur réalisation.

En conséquence, la fourniture du service par l’IGC ne saurait être interprétée comme entraînant la cessions d’un quelconque doit de propriété intellectuelle et industrielle appartenant au CEA.

Le porteur de certificat de l’IGC CEA s‘engage à maintenir sur tous les exemplaires et copies, mêmes partielles, des éléments précités, les mentions de propriété au profit du CEA, et à n’effectuer aucune adjonction ou modification, rendant notamment ces mentions de propriété illisibles, sans avoir obtenu d’accord préalable écrit du CEA.



3. IDENTIFICATION ET AUTHENTIFICATION 3.1. ENREGISTREMENT INITIAL 3.1.1. Conventions de noms

Le nom contenu dans un certificat (sujet du certificat) est sous la forme d'un DN. L’attribut Common Name (CN) du DN identifie de manière unique le possesseur du certificat. Les conventions de nommage utilisées dépendent de chaque AC :

� AC Utilisateur et AC Badge : CN="NOM Prénom PNxxxxxxC" avec le nom de famille en majuscule, la première lettre des prénoms en majuscule (cf. § 3.1.3). « PNxxxxxxC » se compose comme suit :

o P : première lettre du prénom en majuscule o N : première lettre du nom en majuscule o xxxxxx : numéro à 6 chiffres du badge CEA de la personne o C : première lettre, en majuscule, de la couleur du badge (Bleu, Jaune, Rouge,

Vert ou Autre) ; � AC Partenaire : CN="NOM Prenom ENTREPRISE"

avec le nom de famille en majuscule, la première lettre des prénoms en majuscule (cf. § 3.1.3). ENTREPRISE représente le nom de l’entreprise, en majuscule, à laquelle elle appartient. En l’absence d’entreprise de rattachement, le mot « NON-CEA » est utilisé ;

� AC Technique : CN="nom DNS ou adresse IP" pour un certificat de serveur, ou CN="pseudonyme" pour un certificat associé à un rôle sur une entité technique.

3.1.2. Nécessité d’utilisation de noms explicites Les certificats étant destinés à identifier des personnes ou des entités techniques, les noms qu’ils

contiennent doivent être explicites et respecter les conventions du § 3.1.1.

3.1.3. Règles d’interprétation des différentes formes de noms Les règles d’interprétation des caractères accentués et des noms composés sont détaillées dans

la DPC.

3.1.4. Unicité des noms L’unicité d’un certificat est basée sur l’unicité de son numéro de série pour une Autorité de

Certification donnée. Cependant, afin d’éviter les ambiguïtés sur la propriété d’un certificat, l’unicité du CN est respectée (cf. § 3.1.1).

Pour les Abonnés de l’AC Partenaire, une homonymie peut apparaître entre des personnes d’une même entreprise. Dans ce cas, un numéro de séquence est ajouté au nom de la personne.

Pour les autres AC, l'utilisation du numéro de badge, de l'adresse IP ou du nom DNS garantit l'unicité pour ces types d'entités.

3.1.5. Procédures de résolution des litiges sur la revendication d’un nom Pour le cas des pseudonymes, lorsque le nom à inclure dans un certificat provoque un litige avec

un autre Abonné, l’Autorité d’Enregistrement à qui la demande de certification a été formulée est responsable de la résolution de ce litige. A défaut, et sur demande du plaignant, l’Autorité Administrative peut intervenir sur la résolution du litige.

3.1.6. Reconnaissance, authentification et rôle concernant les noms de marques Aucun nom de marque ou autre nom déposé ne peut être utilisé comme sujet d'un certificat sans

un accord écrit de son propriétaire ; à l’exception des noms des Abonnés pouvant présenter une homonymie avec une marque déposée.

3.1.7. Authentification de l’identité d’un organisme Tout demandeur de certificat pour l’AC Partenaire doit fournir un courrier de son employeur

attestant de son lien avec son entreprise (durée et type de contrat), et précisant le nom, l’adresse, la raison sociale, et le numéro de SIRET de l’entreprise. Ce document doit être signé par un responsable hiérarchique et porter le cachet de l’entreprise.



3.1.8. Authentification de l’identité d’un individu Les Autorités d'Enregistrement authentifient des demandeurs de certificats lors d’un rapport facial. Les Abonnés des AC Utilisateur et Badge, ainsi que les responsables des Abonnés de l’AC

Technique sont identifiés par leur badge CEA. Les Abonnés de l’AC Partenaire doivent fournir à l’AE une photocopie d’une pièce d’identité, et leur présenter l’original lors de leur rencontre.

3.2. RE-GENERATION DE CERTIFICAT EN FIN DE VALIDITE Les Abonnés des AC Utilisateur et Badge peuvent demander le renouvellement de leur certificat

en fin de vie (mais non-expiré) en remplissant le formulaire disponible sur le Portail Web. La demande, authentifiée par le certificat en fin de vie, est automatiquement validée.

Le renouvellement des certificats expirés des AC Utilisateur et Badge, ainsi que le renouvellement des certificats des AC Techniques et Partenaire se fait en effectuant une nouvelle demande de certification (cf. § 4.1).

3.3. RE-GENERATION DE CLES APRES REVOCATION Après révocation de son certificat, il appartient à l'utilisateur de formuler une nouvelle demande de

génération de certificat (cf. § 4.1). Le processus de génération d’un certificat est alors mis en œuvre dans sa totalité. Il n'est pas permis de réutiliser la même biclé pour le nouveau certificat, sauf dérogation accordée par l'Autorité Administrative.

3.4. AUTHENTIFICATION D’UNE DEMANDE DE REVOCATION Les Abonnés des AC Utilisateur et Badge peuvent demander la révocation de leur certificat en

utilisant un formulaire du Portail Web. Le contrôle d'accès au formulaire de révocation met en œuvre la clé privée de l'Abonné pour son authentification. Un Abonné ne peut révoquer que son propre certificat.

Dans le cas d'une perte de la clé privée, rendant impossible l'utilisation du Portail Web, et pour les Abonnés des AC Technique et Partenaire, la demande de révocation se fait en contactant l’Autorité d’Enregistrement. En cas d’indisponibilité de l’AE, l’Opérateur d’Enregistrement peut être contacté directement.



4. BESOINS OPERATIONNELS 4.1. DEMANDE DE CERTIFICAT 4.1.1. Demande de certificat pour l’AC Utilisateur

Avant de demander un certificat, l’utilisateur doit s’assurer auprès de son correspond informatique que son poste de travail est compatible avec les exigences de l’IGC et les recommandations de la DTI. Il peut ensuite procéder à sa demande :

� l’utilisateur consulte le Portail Web de l’IGC (cf. § 2.6.4) et sélectionne l’AC Utilisateur ; � il se rend sous la rubrique « demande de certificat » ; � il sélectionne son centre CEA d’appartenance parmi ceux proposés ; � il fournit les informations demandées par le formulaire :

o nom, prénom, numéro de badge, couleur du badge ; o numéro de téléphone ; o ses adresses mel :

� une au format « carte de visite » : [email protected] � l’autre au format identifiant@nom_serveur.cea.fr

(la consultation de l’annuaire Exchange permet de connaître cette adresse)

� une éventuelle troisième adresse o un mot de passe qui protégera sa clé privée, et qu’il sera le seul à connaître

(aucun acteur de l’IGC ne pourra en prendre connaissance, ni le changer) ; � en validant le formulaire, l’utilisateur obtient un récapitulatif de sa demande qu’il doit

imprimer et signer ; � il transmet alors ce document à son AE lors d'une rencontre où il présente son badge afin

de lui permettre de valider son identité ; � l'AE vérifie les informations du formulaire, et si elles sont correctes, le signe et le transmet

à l’Opérateur d’Enregistrement ; o lorsque le demandeur est une AE, il doit faire valider son formulaire par son

responsable hiérarchique ; � les Opérateurs d’Enregistrement valident les demandes de certificat pour lesquelles ils

ont reçu un formulaire dûment signé par l’utilisateur et son AE ; � lorsque sa demande est validée par l’Opérateur, le demandeur reçoit un mel de

confirmation (adressé à la première adresse mel qu’il a saisie) ; ce mel contient l’URL de son fichier personnel (contenant sa biclé et son certificat) ;

� le demandeur télécharge le fichier et installe ses clés dans l’application voulue. Ce fichier est protégé par le mot de passe donné lors de sa demande. Le demandeur devient alors un Abonné ;

� Une fois l’installation terminée, l’Abonné transfert son fichier personnel sur disquette et la conserve dans un endroit sûr.

4.1.2. Demande de certificat pour l’AC Badge Avant de demander un certificat, l’utilisateur doit s’assurer auprès de son correspondant

informatique que son poste de travail est compatible avec les exigences de l’IGC et les recommandations de la DTI. Il doit aussi être équipé d’un lecteur de cartes à puce et des logiciels associés. L’utilisateur doit aussi renouveler son badge CEA si celui-ci ne possède pas de fonctions cryptographiques. Il peut ensuite procéder à sa demande :

� l’utilisateur consulte le Portail Web de l’IGC (cf. § 2.6.4) et sélectionne l’AC Badge ; � il se rend sous la rubrique « demande de certificats » ; � il sélectionne son centre CEA d’appartenance parmi ceux proposés ; � Il insère son badge dans le lecteur et fournit les informations demandées par le

formulaire : o nom, prénom, numéro de badge, couleur du badge ; o numéro de téléphone ; o ses adresses mel :

� une au format « carte de visite » : [email protected] � l’autre au format identifiant@nom_serveur.cea.fr

(la consultation de l’annuaire Exchange permet de connaître cette adresse)



� une éventuelle troisième adresse � en validant le formulaire, l’utilisateur obtient un récapitulatif de sa demande qu’il doit

imprimer et signer ; � il transmet alors ce document à son AE lors d'une rencontre où il présente son badge afin

de lui permettre de valider son identité ; � l’AE vérifie les informations du formulaire, et si elles sont correctes, le signe et le transmet

à l’Opérateur d’Enregistrement du centre ; o lorsque le demandeur est une AE, il doit faire valider son formulaire par son

responsable hiérarchique ; � les Opérateurs d’Enregistrement valident les demandes de certificat pour lesquelles ils

ont reçu un formulaire dûment signé par l’utilisateur et son AE ; � lorsque sa demande est validée par l’Opérateur, le demandeur reçoit un mel de

confirmation (adressé à la première adresse mel qu’il a saisie) ; ce mel contient les URL qui lui permettent d’obtenir son certificat de signature et sa clé de chiffrement ;

� l’utilisateur insère son badge dans le lecteur et consulte les URL contenues dans le mel de confirmation. Il suit les instructions afin de charger son certificat de signature, et d’incorporer sa clé de chiffrement et son certificat de chiffrement dans son badge.

4.1.3. Demande de certificat pour l’AC Technique Le demandeur doit contacter son AE en lui transmettant les informations sur l’entité à certifier (soit

une demande électronique contenant la clé publique à certifier, soit le nom IP ou DNS de l’entité) ainsi que le nom et l’adresse mel du responsable de l’entité. L’AE se charge de vérifier la légitimité de la demande.

L’AE retransmet ces informations, par mel signé, à l’Opérateur de l’AC Technique. Cet Opérateur est désigné sur le Portail Web de l’IGC.

L’Opérateur vérifie la signature électronique du mel. Si la signature est valide, il imprime et signe la demande pour archivage. Il peut ensuite valider la demande.

Lorsque le certificat est créé, il est transmis par messagerie au responsable de l’entité. Lorsque la clé privée est générée par l’AC, elle est transmise par messagerie sous la forme d’un fichier personnel protégé par mot de passe, au responsable de l’entité certifiée. Le mot de passe est transmis par mel signé et chiffré à l’AE du demandeur. Le responsable de l’entité certifiée doit se mettre en contact avec son AE pour obtenir son mot de passe.

4.1.4. Demande de certificat pour l’AC Partenaire Les collaborateurs CEA qui désirent faire certifier leurs partenaires extérieurs peuvent télécharger

sur le Portail Web de l’IGC un formulaire à imprimer et à faire remplir par les personnes à certifier. Ce formulaire doit être signé par le demandeur, le responsable CEA de la collaboration, et l’AE concernée. Ce formulaire doit être accompagné d’une photocopie d’un document justifiant de l’identité du demandeur. L’AE est en charge d’évaluer la pertinence du document justifiant l’identité du demandeur.

Cette demande est transmise par l’AE à l’Opérateur de l’AC Partenaire (désigné sur le Portail Web de l’IGC). L’Opérateur transmet par messagerie le fichier personnel (protégé en intégrité et confidentialité) contenant la biclé et le certificat au partenaire extérieur, et il lui transmet par téléphone ou courrier papier le mot de passe protégeant ce fichier.

4.2. GENERATION DE CERTIFICAT Les certificats sont générés par les AC après validation des demandes par les Opérateurs

d’Enregistrement. Lorsque le certificat est transmis à son titulaire par mel, ou lorsque celui-ci récupère son certificat par téléchargement, l’AC transmet le certificat au Service de Publication.

La période de validité des certificats générés est fixée par défaut à un an. Cette durée peut être écourtée à la demande de l’utilisateur ou de son autorité hiérarchique. Elle peut aussi être allongée en cas de demande motivée de l’utilisateur, et après acceptation par l’Autorité d’Enregistrement concernée. En aucun cas la durée d’un certificat ne peut dépasser les deux ans de validité (hors certificats d’AC).

4.3. ACCEPTATION D’UN CERTIFICAT La demande d’un certificat par un utilisateur implique son acceptation d’office. Si un utilisateur

désire refuser un certificat qui lui a été remis, il doit en demander la révocation.



4.4. REVOCATION DES CERTIFICATS Les Abonnés peuvent mettre fin à leurs engagements à tout moment. Ils doivent pour cela

demander la révocation de leur certificat. Les certificats de la présente Politique de Certification ne peuvent être révoqués que de façon

définitive. Il n’est pas prévu de révocation temporaire (suspension).

4.4.1. Causes possibles de révocation Le certificat de l’AC Racine peut être révoqué dans les cas suivants : � compromission, suspicion de compromission, perte ou vol de la clé privée

correspondante ; � cessation d’activité de l’AC ; � par anticipation : par exemple, en cas de risque de mise en péril de l’IGC suite à

l’apparition d’une faiblesse des clés ou algorithmes utilisés. Le certificat des AC Utilisateur, Badge, Technique et Partenaire peuvent être révoqués dans les

cas suivants : � compromission, suspicion de compromission, perte ou vol de la clé privée

correspondante ; � révocation du certificat de l’AC Racine ; � cessation d’activité de l’AC ; � par anticipation : par exemple, en cas de risque de mise en péril de l’IGC suite à

l’apparition d’une faiblesse des clés ou algorithmes utilisés ; � grave non-respect de la Politique de Certification ou de la Déclaration des Pratiques de

Certification. Les certificats des Abonnés peuvent être révoqués, dans les cas suivants : � compromission, suspicion de compromission, vol ou perte de la clé privée ; � révocation du certificat de l’AC émettrice du certificat ; � changement des informations contenues dans le certificat ; � non-respect des engagements liant l’utilisateur à l’IGC ; � départ de l'entreprise, changement d'activité, indisponibilité de longue durée ou décès du

porteur.

4.4.2. Origine des demandes de révocation Pour les certificats des AC Utilisateur et Badge, la demande de révocation peut être émise par

l’Abonné ou son supérieur hiérarchique. Pour les certificats de l’AC Technique, la demande de révocation peut être émise par le

responsable de l’entité certifiée (celui indiqué lors de la demande de certification). Pour les certificats de l’AC Partenaire, la demande de révocation peut être émise par l’Abonné,

son collaborateur CEA ou le supérieur hiérarchique du collaborateur CEA. Dans tous les cas, l'Autorité Administrative et l’AC qui a émis le certificat peuvent demander la

révocation d'un certificat.

4.4.3. Procédure de demande de révocation Les demandes de révocation se font par un formulaire du Portail Web, après authentification de

l'Abonné par sa clé privée. Dans les cas où cela n'est pas possible (perte de la clé privée, ou révocation demandée par une

autre personne que l’Abonné), la révocation se fait en contactant l'Autorité d'Enregistrement compétente, ou à défaut en contactant l’Opérateur d’Enregistrement. En charge pour l'AE ou pour l’OE de s'assurer de la légitimité de la demande.

La raison de la révocation doit être indiquée lors de la demande. Celle-ci est archivée mais elle n’est pas précisée dans la liste de révocation. Seuls le numéro de série et la date de révocation sont ajoutés à la CRL. La date de révocation utilisée est celle de la révocation effective du certificat par l’AC, soit quelques minutes après la validation par l’Opérateur.

Les certificats révoqués sont supprimés de l’annuaire.



4.4.4. Temps de traitement d’une révocation Les délais de traitement des demandes de révocation sont d’un jour ouvré, c’est à dire hors

samedi, dimanche, jour fériés et journées de récupération du temps de travail nationales et de centres.

4.4.5. Fréquence de mise à jour de la liste des certificats révoqués (CRL) Les Autorités de Certification de l’IGC ne garantissent le contenu des CRL qu’à la date de leur

signature. La date de prochaine mise à jour inscrite dans les CRL ne correspond pas à leur date de validité, elle indique uniquement la date « au plus tard » à laquelle l’AC émettra une nouvelle CRL.

La CRL de l’AC Racine est mise à jour tous les trois mois, sauf en cas de révocation d’une AC fille. Dans ce cas, la CRL est mise à jour dès que la révocation de l’AC a été traitée. La date de prochaine mise à jour indiquée dans la CRL est de 4 mois postérieure à celle de la signature de la CRL.

Les CRL des AC filles sont mises à jour quotidiennement. La date de prochaine mise à jour indiquée dans la CRL est de 7 jours postérieure à celle de la signature de la CRL.

4.4.6. Exigences de contrôle des CRL Il appartient aux Utilisateurs de certificats de vérifier le statut des certificats dans la CRL. De

même, il lui appartient de vérifier la validité de la CRL (signature, dates, et validité de l’émetteur). La signature d’un Abonné ne peut être validée qu’en utilisant une CRL émise postérieurement à

l’acte de signature.

4.4.7. Publication des causes de révocation Les causes de révocation n’apparaissent pas dans les CRL. Elles sont néanmoins connues et

archivées par les Autorités de Certification.

4.4.8. Contrôle en ligne des CRL Le service de contrôle en ligne des certificats révoqués est assuré par le Portail Web. Il permet,

par le biais d'un formulaire, de vérifier la présence d’un certificat parmi les certificats révoqués, sur la base du nom de l’utilisateur, de son adresse de messagerie, ou du numéro de série de son certificat.

Les CRL sont aussi librement disponibles en téléchargement sur l'annuaire LDAP et sur les points de distribution. Ces fichiers sont mis à jour dans les 24 heures qui suivent leur émission par une AC.

4.4.9. Cas particulier de la révocation pour compromission de clé En cas de révocation pour compromission ou suspicion de compromission de clé, la mise à jour

de la CRL est réalisée selon la politique exprimée au § 4.4.3. Cependant, des mesures particulières peuvent être prises. Ces mesures doivent être approuvées par l’Autorité Administrative. Ainsi, il peut être indiqué à l’autorité chargée de la révocation la date à laquelle l’on suppose que la compromission a eu lieu.

4.5. JOURNALISATION L’ensemble des opérations effectuées par et sur les composantes de l’IGC est journalisé. Le

détail des évènements enregistrés ainsi que le traitement qui leur est appliqué sont spécifiés dans la DPC.

4.6. ARCHIVES 4.6.1. Types de données archivées

Les données d’identification utilisées pour les demandes de certificats sont archivées : � pour les AC Utilisateur et Badge, le formulaire de demande signé ; � pour l’AC Technique, le mel de demande imprimé et signé par l’Opérateur ; � pour l’AC Partenaire, le formulaire de demande signé ainsi que le justificatif d’identité.

De plus, tous les certificats, clés privées séquestrées et les raisons des révocations sont archivés ; ainsi que toutes les données d’exploitation relatives à la sécurité des composantes, suivant les modalités précisées dans la DPC.



4.6.2. Durée de rétention des archives Les informations concernant les demandes de certificat sont conservées durant toute la durée de

validité des certificats concernés, ainsi que des éventuels certificats renouvelés à partir de ces certificats, prolongé d’une durée de 4 ans.

Les certificats sont conservés pendant une durée de 4 ans après leur expiration. Les clés privées séquestrées sont archivées pendant 4 ans après expiration du certificat qui leur est associé.

La durée de conservation des données d’exploitation relatives à la sécurité est précisée dans la DPC.

Passé le délai de conservation des archives, celles-ci sont détruites ou transmises au centre d’archives national du CEA, selon les modalités précisées dans la DPC.

4.6.3. Protection des archives Les archives sont protégées contre les risques d’accès illicite, de modification et de destruction,

selon les moyens précisés dans la DPC.

4.6.4. Procédures d’accès et de récupération des archives Les archives ne sont accessibles que par les entités et composantes concernées au sein de

l’IGC. Les Abonnés ou anciens Abonnés peuvent consulter les informations les concernant en

transmettant une demande à l’Autorité Administrative.

4.7. CHANGEMENT DE CLE D’UNE COMPOSANTE Le Service de Publication est considéré comme un Abonné de l’AC Technique, il suit donc les

même règles que les autres Abonnés. Une AC ne pouvant pas émettre un certificat dont la date d’expiration serait postérieure à sa

propre date d’expiration, ou à celle de son AC mère, il existe nécessairement des périodes où les AC possèdent deux certificats : le premier servant à vérifier la validité des certificats émis, l’autre servant à émettre de nouveaux certificats.

Les durées de validité des certificats des AC étant connues, il est possible d’établir à priori un calendrier des renouvellements de clé des AC.

Les certificats de l’AC Racine ont une durée de validité de 10 ans, et ceux des AC filles (AC Utilisateur, AC Badge, AC Technique, AC Partenaire) ont une durée de validité de 6 ans. Les premiers certificats d’AC étant créés en 2003, le planning des différentes générations de certificats est le suivant :

2003

2004

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

� 1ère génération d’AC Racine � 1ère génération d’AC filles � 2nde génération d’AC filles

2nde génération d’AC Racine � 3ème génération d’AC filles � 4ème génération d’AC filles �

3ème génération d’AC Racine � 5ème génération d’AC filles �

AC Racine pouvant émettre des certificats AC filles pouvant émettre des certificats AC en fin de vie : utilisée uniquement pour valider les certificats, révoquer et émettre des CRL 20.. Années où sont renouvelées des clés d’AC Les dates de début et de fin sont à moduler de quelques semaines afin de garantir qu’aucun

certificat n’est valide plus longtemps que son AC, tout en gardant une marge de temps pour réaliser les opérations de renouvellement.



4.8. COMPROMISSION ET PLAN ANTI-SINISTRE 4.8.1. En cas de corruption des ressources informatiques (logiciels ou données)

Les règles d’exploitation des moyens informatiques nationaux du CEA s’appliquent pour l’IGC. La DPC précise les mesures particulières prises pour garantir des délais de reprise, en cas de sinistre majeur, compatibles avec les exigences de sécurité spécifiques à l’IGC.

4.8.2. En cas de révocation du certificat d’une composante de l’IGC En cas de révocation d’une composante de l’IGC, la composante est mise hors service. Ses clés

doivent être renouvelées, et un contrôle de conformité doit être effectué avant sa remise en service. En cas de révocation du certificat d’une AC, l’ensemble des certificats qu’elle a émis au moins à

partir de sa date de révocation sont révoqués, préalablement à sa mise hors service.

4.8.3. Mesures de sécurité en cas de sinistre La DPC précise les mesures de sécurité en cas de sinistre spécifiques à l’IGC.

4.9. FIN DE VIE D’UNE COMPOSANTE En cas d’arrêt de l’activité d’une composante, celle-ci s’engage à : � en aviser ses partenaires (Abonnés, AE, autres AC, etc.) dès qu’elle en a connaissance,

ou au moins six mois avant sa cessation ; � faire révoquer son certificat par une AC supérieure ; � s’il s’agit d’une AE, confier ses archives ainsi que les données utilisateurs dont elle

dispose à l’AC dont elle dépend (c’est à cette dernière qu’incombent alors les obligations de l’AE vis-à-vis des utilisateurs) ;

� s’il s’agit d’une AC : o révoquer tous les certificats qu’elle a émis et qui sont encore valides à la date de

cessation d’activité ; o assurer la disponibilité de sa CRL au moins jusqu’à la date d’expiration de son

certificat ; o remettre ses archives, ainsi que la base de données de ses utilisateurs à l’AC de

niveau supérieur dont elle dépend ou à l’Autorité Administrative ; � s’il s’agit d’une Autorité de Séquestre, remettre ses archives, la base de données de ses

utilisateurs ainsi que les conventions secrètes qu’elle détient à l’Autorité Administrative.



5. CONTROLES DE SECURITE PHYSIQUE, DES PROCEDURES ET DU PERSONNEL 5.1. CONTROLES DE SECURITE PHYSIQUE

Les composantes de l’IGC sont implantées sur les centres CEA. La sécurité physique des composantes de l’IGC est assurée selon les règles en vigueur au CEA pour la protection de systèmes d’information sensibles. Le détail des procédures correspondantes est précisé dans la DPC, et mentionne notamment :

� le contrôle d’accès physique aux locaux renfermant les composantes ; � l’alimentation électrique et la climatisation ; � la vulnérabilité aux dégâts des eaux ; � la prévention et protection contre le feu ; � la conservation des médias ; � la destruction des données ; � la mise en place de site(s) de secours.

5.2. CONTROLES DES PROCEDURES 5.2.1. Rôles de confiance

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

� Opérateur o responsable des opérations ; o exploite les services délivrés ; o exécute les fonctions cryptographiques ; o remonte les incidents de sécurité à l’Administrateur.

� Ingénieur Système o met en route le système (initialisation système) ; o administre le système et le réseau ; o maintenance du système ; o remonte les incidents de sécurité à l’Administrateur.

� Administrateur o met en route (initialisation cryptographique) la composante ; o responsable des services délivrés ; o supervise les actions des opérateurs ; o met en œuvre la PC et les DPC ; o configure les journaux d’événements (de la composante) ; o remonte les incidents au responsable de sécurité.

� Responsable de Sécurité o contrôle la sécurité physique et fonctionnelle

(gestion des contrôles d’accès physique, etc.) ; o met en œuvre la politique de sécurité ; o analyse les journaux d’événements ; o remonte les incidents à l’autorité compétente.

Leurs attributions respectives au sein de l’organisation du CEA sont décrites dans la DPC. Le tableau qui suit en donne une vision synthétique :

AC Utilisateur et AC Badge Op IS Adm RS

enregistrement et recouvrement ULTI

révocation Abonné ou ULTI

renouvellement Abonné

infogérance DTI

publication infogérance DTI

DTI ASSI de DTI

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. Le document [ROLES_IGC] précise comment et sous quelles conditions ces rôles peuvent être cumulés par un même exploitant.



5.2.2. Nombre de personnes nécessaires à chaque tâche Selon le type d’opérations effectuées, le nombre et le rôle des personnes devant nécessairement

être présentes (en tant qu’acteurs ou témoins) peuvent être différents. Le nombre minimum d’exploitants nécessaires par type d’opération, ainsi que leur rôle, sont

précisés dans la DPC

5.2.3. Identification et authentification des rôles La connexion d'un exploitant au système d'information d'une composante de l'IGC nécessite son

identification, identification à laquelle est associée son ou ses rôles au sein de la composante. La gestion des droits d'accès au système est gérée par l'Ingénieur Système. La gestion des droits

d'accès aux fonctions liées à l'activité de la composante considérée est gérée par l'Administrateur de la composante. Ces droits sont contrôlés et maintenus dès qu'une modification survient (changement d'exploitant, changement d'activités, etc.)

5.3. CONTROLES DU PERSONNEL Les tâches et rôles des exploitants de l’IGC correspondent à leurs compétences professionnelles,

conformément aux règles en vigueur au CEA. Le personnel exécutant de l’IGC reçoit une formation initiale à l’utilisation des logiciels, matériels

et procédures mis à sa disposition dans le cadre de la composante pour laquelle il opère. Cette formation est complétée à chaque mise à jour significative de l’organisation, des outils ou des procédures.



6. CONTROLES TECHNIQUES DE SECURITE 6.1. GENERATION ET INSTALLATION DE BICLES 6.1.1. Génération de biclés

Les biclés des Abonnés sont soit générées par l'Autorité de Certification, soit générées directement sur la carte à puce de l’Abonné lorsqu’il s’agit de biclé de signature et/ou d’authentification.

Une copie des biclés de chiffrement générées par les AC Utilisateur, Badge et Partenaire est conservée par l’Autorité de Séquestre.

L'initialisation de l’AC, et en particulier la génération de ses clés, est effectuée selon une procédure de sécurité particulière, décrite dans la DPC, et nécessitant au moins la présence de plusieurs exploitants et éventuellement d'un ou plusieurs représentants de l'Autorité Administrative.

6.1.2. Délivrance de clé privée à son propriétaire Les propriétés des fichiers et des protocoles utilisés pour transmettre les clés privées garantissent

leur confidentialité et leur intégrité. Les clés privées de signature générées directement sur une carte à puce ne sont pas accessibles

en lecture, et seul l’utilisateur dispose du code porteur permettant de la mettre en œuvre.

6.1.3. Transmission de clé publique à une AC Les propriétés des fichiers et des protocoles utilisés pour transmettre les clés publiques à une AC

garantissent leur intégrité.

6.1.4. Délivrance de la clé publique des AC aux utilisateurs Le certificat de l’AC est disponible en ligne par l’intermédiaire de l’annuaire ou du Portail Web.

L’intégrité de ce certificat est assurée par l’utilisation du protocole SSL. De plus, les Utilisateurs de certificat peuvent obtenir l'empreinte numérique associée en consultant le Serveur de Publication ou en contactant leur AE.

6.1.5. Taille des clés Les biclés RSA des AC sont de 2048 bits. Les biclés RSA des Abonnés sont de 1024 bits, sauf pour les Abonnés de l’AC Technique,

lorsqu’ils génèrent eux-mêmes leur biclé. Dans ce cas, les tailles de clé acceptées vont de 512 à 4096 bits.

6.1.6. Génération des paramètres de clé publique Le générateur de la biclé génère aussi les paramètres de clé publique, conformément aux

standards établis dans le domaine des IGC.

6.1.7. Contrôle de la qualité des paramètres Le test de primalité utilisé par les AC pour le calcul des nombres premiers RSA est celui de Miller-

Rabin. Le test de primalité utilisé par les cartes à puce pour le calcul des nombres premiers RSA dépend

du constructeur de la carte.

6.1.8. Mode de génération de clé (matériel ou logiciel) Les générateurs aléatoires utilisés pour la génération des biclés sont logiciels.

6.1.9. Usage de la clé Les différents usages possibles des clés sont définis et contraints par l’utilisation des extensions

de certificat X509 v3 (cf. Annexe C : Format des Certificats).



6.2. PROTECTION DE CLE PRIVEE 6.2.1. Module de cryptographie utilisant des normes

Pas de spécification.

6.2.2. Contrôle des clés privées par plusieurs personnes La clé privée de l’AC Racine est protégée par un système de type n parmi m. Les personnes

habilitées à posséder une part du secret, ainsi que le nombre de personnes nécessaires à la reconstitution de la clé sont précisés dans la DPC.

Les Abonnés sont seuls à connaître le secret qui leur permet de mettre en œuvre leur clé privée.

6.2.3. Séquestre de clé privée Les clés privées associées aux certificats émis par l’AC Technique ne sont pas séquestrées. De

même, les clés privées de signature/authentification générées par les cartes à puces ne sont pas séquestrées.

Une copie de secours des clés privées des composantes de l’IGC est conservée selon des procédures décrites dans la DPC.

Toutes les clés privées émises par les AC Utilisateur, Badge et Partenaire, et associées à un certificat permettant d’effectuer du chiffrement, sont séquestrées. De plus, tout Abonné peut décider de sauvegarder sa clé privée. Cette copie doit être conservée avec autant de garanties d’intégrité et de confidentialité que la clé privée originale.

6.2.4. Recouvrement de clé privée Toute clé privée séquestrée peut être recouverte à la demande de l’Abonné, ou de son

responsable hiérarchique lorsque l’Abonné n’est pas disponible et que sa clé est nécessaire au bon fonctionnement de son unité.

De même les autorités légales peuvent demander le recouvrement de clé privée lorsqu’elles sont habilitées par le Premier Ministre, ou qu’elles interviennent suite aux réquisitions du procureur de la République.

Le demandeur d’un recouvrement utilise le formulaire disponible sur le Portail Web de l’IGC. Il renseigne son identité, la clé à recouvrir, le motif du recouvrement et l’identité de l’Autorité d’Enregistrement qui devra valider sa demande. Il donne aussi un mot de passe qui servira à protéger la clé privée recouverte.

Le demandeur imprime, puis signe et date le formulaire. Il le transmet à son Autorité d’Enregistrement qui valide la légitimité de la demande en signant à son tour le formulaire. L’Autorité d’Enregistrement précise sur le formulaire si le certificat associé doit être révoqué, puis elle le transmet à l’Opérateur d’Enregistrement. L’Autorité d’Enregistrement choisi systématiquement la révocation du certificat lorsque le recouvrement n’est pas demandé par l’Abonné.

L’Opérateur d’Enregistrement valide techniquement les demandes de révocation pour lesquelles il a reçu des formulaires signés. Il révoque les certificats lorsque cela est demandé.

La clé privée recouverte, protégée par le mot de passe donné lors de la demande, est transmise par message électronique chiffré à l’Autorité d’Enregistrement qui se charge de la remettre au demandeur. Un message électronique est envoyé à l’Abonné propriétaire de la clé pour l’informer de l’acte de recouvrement.

La clé recouverte est transmise à l’AE dans les deux jours ouvrés qui suivent la transmission du formulaire de demande signé à l’Opérateur d’Enregistrement.

6.2.5. Archivage de clé privée Les clés privées séquestrées sont archivées conformément au §4.6.

6.2.6. Mise à la clé du module cryptographique Les procédures d’initialisation des clés privées des composantes de l’IGC sont précisées dans la

DPC. Les Abonnés mettent à la clé leurs applications et de la clé de chiffrement des cartes à puces en

utilisant le fichier personnel qui leur a été remis, associé au mot de passe qu’ils ont choisi ou qui leur a été attribué.

La mise à la clé des cartes à puce, pour la clé de signature, se fait lors de la demande de certification, en utilisant les fonctions internes des cartes.



6.2.7. Méthode d’activation de clé privée Les clés privées des composantes sont activées par les actions des Opérateurs. Les clés privées des Abonnés sont activées par la saisie du code porteur lorsque les clés sont sur

carte à puce. Les clés privées qui ne sont pas stockées sur carte à puce sont activées par les applications qui les mettent en œuvre, selon des méthodes spécifiques à chaque application. Typiquement, l’ouverture de session de l’utilisateur active sa clé privée.

6.2.8. Méthode de désactivation de clé privée Les clés privées des composantes sont systématiquement désactivées lorsqu’elles ne sont pas

utilisées par un Opérateur. Les clés privées stockées sur carte à puce sont désactivées en retirant la carte de son lecteur. Les méthodes de désactivation des clés privées non stockées sur carte à puce dépendent des

logiciels qui les mettent en œuvre. Typiquement, la fermeture de session de l’utilisateur désactive sa clé privée.

6.2.9. Méthode de destruction de clé privée Hors carte à puce, les clés privées sont détruites en utilisant les fonctions de suppression

proposées par les logiciels qui les mettent en œuvre. Les clés privées stockées sur carte à puce sont détruites en réinitialisant la carte ou en la

déchiquetant.

6.3. AUTRES ASPECTS DE GESTION DES BICLES 6.3.1. Archivage des clés publiques

Les clés publiques sont archivées dans le cadre de l’archivage des certificats.

6.3.2. Durée de vie des clés publiques et privées Les biclés générées par les AC ont la même durée de vie que celle du certificat qui leur est

associé. Elles ne sont pas réutilisées pour émettre ou renouveler un certificat. Les biclés certifiées par l’AC Technique, lorsqu’elles sont générées par l’entité à certifier, peuvent

être réutilisées par l’entité pour un renouvellement de certificat. L’AC Technique ne vérifie pas l’unicité des clés publiques qui lui sont soumises.

Les biclés de signature générées par les cartes à puces sont renouvelées à chaque renouvellement de certificat.

6.4. DONNEES D'ACTIVATION Pour installer sa clé privée, l’Abonné doit saisir le mot de passe qu’il a choisi lors de sa demande

de certification (AC Utilisateur et AC Badge), ou qui lui a été fourni (AC Technique et AC Partenaire). Les cartes à puce sont protégées par un code porteur connu uniquement par l’Abonné. Ce code

porteur, constitué de 4 chiffres, est bloqué après 3 tentatives infructueuses de connexion. Les Opérateurs d’Enregistrement peuvent débloquer le code porteur en saisissant un code de déblocage. L’Abonné a la possibilité de modifier son code porteur à tout moment.

Le mot de passe et le code porteur sont des données d’activation qui doivent être protégées en confidentialité et en intégrité par l’Abonné.

6.5. SECURITE DES POSTES DE TRAVAIL La protection du poste de travail des Abonnés relève de la politique de sécurité des systèmes

d’information du CEA. Les mesures de protection particulières prises pour les postes de travail des composantes de

l’IGC sont décrites dans la DPC.

6.6. CONTROLES TECHNIQUES DU SYSTEME DURANT SON CYCLE DE VIE L’implémentation du système mettant en oeuvre l'IGC est documentée et respecte, dans la

mesure du possible, les normes de modélisation et d’implémentation. Toute évolution du système est documentée et fait l’objet, préalablement à sa mise en place,

d’une recette sur plate-forme indépendante garantissant la non-régression du système. L’évolution doit apparaître dans les procédures de fonctionnement interne à l’IGC et être conforme au schéma de maintenance des produits utilisés.



6.7. SECURITE DES RESEAUX Les composantes de l’IGC sont situées sur les réseaux internes du CEA et bénéficient des

protections mises en place sur ces réseaux. Les composantes qui le nécessitent sont interconnectées avec les réseaux publics, et protégées

par des passerelles de sécurité garantissant une surveillance et un filtrage du trafic.

6.8. CONTROLES TECHNIQUES DES MODULES DE CRYPTOGRAPHIE Les modules cryptographiques mis en oeuvre par les composantes de l’IGC et les Abonnés

respectent les réglementations nationales et européennes, et sont soumis aux règles d’usage de la cryptographie en vigueur au CEA.



7. PROFILS DES CERTIFICATS ET DES LISTES DE CERTIFICATS REVOQUES 7.1. PROFILS DES CERTIFICATS

Les certificats utilisés sont au format X.509 v3 tel que spécifié dans les normes [RFC 3280] et [9594-8]. Les valeurs des champs de base et des extensions sont décrites dans l'annexe « Certificats et CRL ».

7.2. PROFILS DES CRL Les CRL utilisées suivent les spécifications des normes [RFC 3280] et [9594-8]. La version 1 du

format est utilisée : seuls les champs de base sont renseignés, elles ne contiennent pas d’extensions. Les spécifications techniques des CRL sont décrites dans l’annexe « Certificats et CRL ».

8. ADMINISTRATION DES SPECIFICATIONS 8.1. PROCEDURES DE MODIFICATION DE CES SPECIFICATIONS

La présente Politique de Certification est revue régulièrement afin d’assurer sa conformité aux normes de sécurité, aux besoins du CEA et à l’évolution des technologies du marché.

Toute évolution doit être approuvée par l’Autorité Administrative, après avis du Comité de Sécurité des Systèmes d’Information du CEA.

8.2. POLITIQUES DE PUBLICATION ET DE NOTIFICATION La PC est disponible en version électronique sur le Portail Web de l’IGC. Les Abonnés sont notifiés par mel de toute modification de la PC entraînant un changement dans

leurs obligations ou dans l’utilisation de leurs certificats.

8.3. PROCEDURES D’APPROBATION DES DPC L’approbation d’une DPC est confiée à l’Autorité Administrative qui vérifie l’adéquation de la DPC

fournie par la composante avec la Politique de Certification.



ANNEXE A : DOCUMENTS DE REFERENCES [9594-1] 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-8] 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 ».

[A475] Arrêté du 17 mars 1999 définissant la forme et le contenu du dossier concernant les déclarations ou demandes d’autorisation relatives aux moyens et prestations de cryptologie. (PRMX9903475A, J.O n° 66 du 19 mars 1999 page 4052)

[A730] Arrêté du 13 mars 1998 définissant les dispositions particulières qui peuvent être prévues dans les autorisations de fourniture d'un moyen ou d'une prestation de cryptologie (PRMX9802730A, J.O n° 63 du 15 mars 1998 page 3888)

[A731] Arrêté du 13 mars 1998 fixant la forme et le contenu du dossier de demande d'agrément des organismes gérant pour le compte d'autrui des conventions secrètes (PRMX9802731A, J.O n° 63 du 15 mars 1998 page 3888)

[A732] Arrêté du 13 mars 1998 définissant le modèle de notification préalable par le fournisseur de l'identité des intermédiaires utilisés pour la fourniture de moyens ou prestations de cryptologie soumis à autorisation (PRMX9802732A, J.O n° 63 du 15 mars 1998 page 3888)

[A733] Arrêté du 13 mars 1998 fixant la liste des organismes agréés pouvant recevoir dépôt des conventions secrètes (PRMX9802733A, J.O n° 63 du 15 mars 1998 page 3891)

[D98-101] Décret n° 98-101 du 24 février 1998 définissant les conditions dans lesquelles sont souscrites les déclarations et accordées les autorisations concernant les moyens et prestations de cryptologie

[D98-102] Décret n° 98-102 du 24 février 1998 définissant les conditions dans lesquelles sont agréés les organismes gérant pour le compte d'autrui des conventions secrètes de cryptologie, en application de l'article 28 de la loi no 90-1170 du 29 décembre 1990 sur la réglementation des télécommunications

[D99-199] Décret n° 99-199 du 17 mars 1999 définissant les catégories de moyens et de prestations de cryptologie pour lesquelles la procédure de déclaration préalable est substituée à celle d’autorisation.

[D99-200] Décret n° 99-200 du 17 mars 1999 définissant les catégories de moyens et de prestations de cryptologie dispensées de toute formalité préalable.

[D2001-272] Décret n° 2001-272 du 30 mars 2001 pris pour l’application de l’article 1316-4 du code civil et relatif à la signature électronique (J.O. Numéro 77 du 31 mars 2001 page 5070).

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

[DE 96/95/CE] Directive du Parlement Européen et du Conseil du 24 Octobre 1995 96/95/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.

[L78-17] Loi n 78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés (Art. 323-1 à 323-3 du Code pénal).

[L90-1170] Loi n° 90-1170 du 29 décembre 1990 modifiée sur la réglementation des télécommunications (notamment son article 28).



[L91-646] Loi n° 91-646 du 10 juillet 1991 modifiée relative au secret des correspondances émises par la voie des télécommunications

[L2000-230] 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.

[NIG469] Note d’Instruction Générale n°469 du 10 juillet 2001 sur l’utilisation des moyens informatiques du CEA. – CEA/DCS

[PC2] Procédures et Politiques de Certification de Clés (PC²) version 2.2 – CISSI

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

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

[RFC 3280] « Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile » (avril 2002) - IETF - Network Working Group (remplace la RFC 2459).

[ROLES_IGC] 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.



ANNEXE B : GLOSSAIRE B.1 ACRONYMES

AA Autorité Administrative

AB Abonné

AC Autorité de Certification

AE Autorité d’Enregistrement

ASN.1 Abstract Syntax Notation 1 (Langage de Notation Abstraite 1)

CISSI Commission Interministérielle de la Sécurité des Systèmes d’Information

CSSI Comité de Sécurité des Système d’Information (CEA)

CRL Certificate Revocation List (Liste des Certificats Révoqués)

DCS Direction Centrale de la Sécurité (CEA)

DCSSI Direction Centrale de la Sécurité des Systèmes d’Information (SGDN)

DN Distinguished Name

DPC Déclaration des Pratiques de Certification

DTI Direction des Technologies de l’Information (CEA)

IETF Internet Engineering Task Force

IGC Infrastructure de Gestion de Clés

ISO International Organization for Standardization

ITU International Telecommunications Union

OE Opérateur d’Enregistrement

PC Politique de Certification

SGDN Secrétariat Général à la Défense Nationale

B.2 ACTIONS Accréditation

Action de garantir qu’une composante est reconnue par une autorité compétente et peut exercer son activité au sein d’une IGC dont elle respecte les modes de fonctionnement (PC et DPC).

Contrôle de conformité Action qui consiste à réaliser un examen le plus exhaustif possible afin de vérifier l’application stricte des procédures et de la réglementation au sein d’un organisme.

Émission d’un certificat Fait d’exporter un certificat à l’extérieur d’une AC (pour une délivrance à l’Abonné, une demande de publication, …).

Enregistrement Action qui consiste à éditer une demande de certification, en renseignement les informations nécessaires conformément à la Politique de Certification.

Génération d’un certificat Action réalisée par une AC et qui consiste à traiter une demande de certificat en signant la clé publique du demandeur.



Journalisation Fait d’enregistrer dans un espace dédié à cet effet certains types d’événements provenant de l’exploitation d’un système informatique. Les informations ainsi obtenues permettent la traçabilité et l’imputabilité des opérations effectuées.

Publication d’un certificat Fait de mettre un certificat à disposition d’utilisateurs susceptibles d’avoir à vérifier une signature ou à chiffrer des informations.

Rapport facial Action de se présenter en personne auprès d’une entité dans le but de prouver son identité ou son accord.

Renouvellement de certificat Action effectuée à la demande d’un Abonné en fin de période de validité de son certificat et qui consiste à lui générer un nouveau certificat sur la base des informations contenues dans le certificat encore valide. La re-génération de certificat après révocation n’est pas un renouvellement.

Révocation de certificat Action entraînant la suppression de la caution d’une AC sur un certificat donné, avant la fin de sa période de validité. Cette action peut être la conséquence de différents types d’événements tels que la compromission d’une clé, le changement d’informations contenues dans un certificat, etc. L’action de révocation peut consister soit à publier une liste des certificats révoqués, soit à mettre à la disposition des utilisateurs des moyens permettant d’indiquer l’état révoqué ou non d’un certificat.

Signature numérique Informations associées à des données par des fonctions cryptographiques et permettant de garantir la source et l’intégrité de ces données.

Validation de certificat Ensemble d’opérations qui consiste à s’assurer que les informations contenues dans un certificat ont été validées par une autorité de confiance. La validation d’un certificat inclut entre autres la vérification de sa période validité, de son état (révoqué ou non), et la vérification de la signature de l’AC émettrice. Elle inclut également la validation des certificats de l’AC émettrice et de ses AC supérieures, jusqu’au certificat de l’AC racine.

Vérification de signature La vérification d’une signature consiste à déchiffrer la signature d’un message, en mettant en œuvre la clé publique de l’émetteur. Si le clair obtenu est identique au haché calculé à partir du message reçu, alors il est garanti que le message est intègre et qu’il a été signé par le porteur de la clé privée correspondante à la clé publique utilisée pour la vérification.

B.3 ACTEURS Abonné

Un Abonné est un détenteur de certificat valide et de sa clé privée associée, dûment enregistré auprès d’une Autorité de Certification.

Administrateur Un administrateur met en oeuvre les politiques de certification et déclarations des pratiques de certification de l’IGC au sein de la composante qu’il administre. Il est responsable de l’ensemble des services rendus par cette composante.

Autorité Administrative Composante organisationnelle de l’IGC qui définit et fait appliquer la Politique de Certification, et valide et contrôle les Déclarations des Pratiques de Certification des composantes de l’IGC.

Autorité d’Enregistrement Composante de l’IGC qui vérifie les données propres au demandeur ou porteur de certificat ainsi que les contraintes liées à l’usage d’un certificat, conformément à la politique de



certification. L’AE est une composante optionnelle de l’IGC qui dépend d’au moins une autorité de certification.

Autorité de Certification Autorité chargée par un ou plusieurs utilisateurs de créer et d’attribuer les certificats. Cette autorité peut, facultativement, créer les clés d’utilisateur [9594-8].

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

Autorité de Séquestre Composante de l’IGC gérant les conventions secrètes de moyens de cryptologie permettant d’assurer des fonctions de confidentialité. Elle permet d’assurer le recouvrement des données chiffrées en cas de perte des conventions secrètes utilisées.

Composante de l’IGC Elément assurant un rôle organisationnel et/ou technique au sein de l’IGC. Les composantes organisationnelles appliquent les rôles et obligations qui leur sont confiés par la PC. Les composantes techniques sont des plate-formes constituées d’au moins un poste informatique, une application et d’un moyen de cryptographie.

Contrôleur 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 de la politique de certification, des déclarations des pratiques de certification et des services effectivement fournis par la composante de l’IGC.

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

Infrastructure de gestion de clés Ensemble organisé de composantes fournissant divers types de prestations dans le but de supporter des opérations effectuées au moyen de clés asymétriques au profit d’utilisateurs.

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.

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

Portail Web Composante assurant l’interface entre les acteurs de l’IGC et ses composantes. Il leur permet d’accéder aux fonctions auxquelles ils ont droit. Le Portail Web a aussi en charge la publication des ressources bibliographiques et documentaires de l’IGC.

Responsable de Sécurité Il 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 à la plate-forme de la composante, et est chargé de mettre en œuvre la politique de sécurité régissant la composante.

Service de Publication Le service de publication rend disponible les certificats é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, un serveur Web, une délivrance de la main à la main, une application de messagerie, etc.



Utilisateur de Certificat Toute entité (personne, organisme ou entité technique) utilisant un certificat de clé publique à des fins de vérification de signature numérique ou de chiffrement. Un Utilisateur de certificat ne détient pas forcément de certificat propre.

B.4 OBJETS Biclé

Une biclé est un couple composé d’une clé privée (devant être conservée secrète) et d’une clé publique, nécessaire à la mise en œuvre d’une prestation de cryptologie basée sur des algorithmes asymétriques. Une biclé peut être dédiée à un ou plusieurs usages cryptographiques (certification, signature, confidentialité, transport de clé, …).

Biclés d’échange ou de transport de clés Biclés par lesquelles le transport des clés secrètes (symétriques) est effectué (les clés secrètes étant celles mises en œuvre pour chiffrer ou déchiffrer un message protégé en confidentialité).

Biclés de certification Biclés dont la clé privée est utilisée par une AC à des fins de signature de certificats ou de signature d’informations de révocation de ces certificats et la clé publique à des fins de vérification de ces mêmes informations.

Biclés de confidentialité Biclés grâce auxquelles des messages de petite taille (par exemple, un numéro de carte de crédit) sont protégés en confidentialité.

Biclés de signature Biclés composées d’une privée utilisée à des fins de signature et/ou de non-répudiation, et d’une clé publique utilisée à des fins de vérification.

Certificat Association de la clé publique d’un utilisateur avec des informations permettant notamment d’identifier son porteur. Cette association est rendue infalsifiable par la signature de l’Autorité de Certification qui a délivré le certificat. Le format d’un certificat est normalisé dans les recommandations X509 v3 [9594-8] et [RFC 3280].

Déclaration des Pratiques de Certification (DPC) Enoncé des pratiques de certification effectivement mises en œuvre par une Autorité de Certification pour émettre et gérer des certificats.

Données d’activation Données privées associées à un Abonné permettant de mettre en œuvre sa clé privée.

Données d’identification personnelles Informations relatives à une personne et permettant de connaître sans ambiguïté son identité.

Haché Résultat d’une fonction de hachage, c’est-à-dire d’une fonction calculant le condensât d’un message de telle sorte qu’une modification même infime du message entraîne la modification du haché.

Paramètres de clés publiques Données publiques relatives à l’algorithme utilisé, pour la mise en œuvre de clés privées.

Politique de certification (PC) Ensemble de règles, identifié par un nom, qui indique les conditions de gestion et d’utilisation des clés et des certificats dépendants d’une IGC. Son but est de fournir aux utilisateurs de l’IGC les informations relatives aux garanties offertes par les certificats qu’elle émet, ainsi que les conditions d’utilisation de ces certificats.


Date : 06/01/2003

Indice : A6

ANNEXE C : FORMAT DES CERTIFICATS Tous les certificats émis dans le cadre de la présente politique sont au format x509 v3.

C.1 CERTIFICATS DE L’AC RACINE C.1.1 Champs de base du certificat Champs Format AC Racine version Integer 2 (pour version 3) serialNumber Integer numéro de série du certificat signature OID 1.2.840.113549.1.1.5 (sha1WithRSAEncryption) issuer RDNSequence type OID 2.5.4.6 (C) value PrintableString ”fr” type OID 2.5.4.10 (O) value PrintableString ”cea” type OID 2.5.4.11 (OU) value PrintableString ”AC” type OID 2.5.4.3 (CN) value PrintableString ”CEA AC Racine” validity Sequence notBefore UTCTime date de création (env. 2003) notAfter UTCTime date de fin (env. 2013) subject RDNSequence type OID 2.5.4.6 (C) value PrintableString ”fr” type OID 2.5.4.10 (O) value PrintableString ”cea” type OID 2.5.4.11 (OU) value PrintableString ”AC” type OID 2.5.4.3 (CN) value PrintableString ”CEA AC Racine” subjectPublicKeyInfo Sequence algorithmIdentifier OID 1.2.840.113549.1.1.1 (rsaEncryption) subjectPublicKey BitString clé publique de 2048 bits + exposant public (=65537) extensions Sequence voir tableau des extensions signatureAlgorithm OID 1.2.840.113549.1.1.5 (sha1WithRSAEncryption) signatureValue Sequence algorithmIdentifier OID 1.2.840.113549.1.1.1 (rsaEncryption) subjectPublicKey BitString signature du certificat calculée avec la clé publique du certificat (auto-signé)


Date : 06/01/2003

Indice : A6

C.1.2 Extensions du certificat Extensions Format AC Racine Key Usage 2.5.29.15

BitString critique

digitalSignature bit 0 non nonRepudiation bit 1 non keyEncipherment bit 2 non dataEncipherment bit 3 non keyAgreement bit 4 non keyCertSign bit 5 OUI cRLSign bit 6 OUI encipherOnly bit 7 non decipherOnly bit 8 non CRL Distribution Points 2.5.29.31

Sequence non-critique

distributionPoint fullName uniformResIdentifier IA5String http://crl-ac-racine.cea.fr/crl/ac-racine.crl Certificate Policies 2.5.29.32


policyIdentifier OID 1.3.6.1.4.1.12384.1.2 (PC_CEA_IGC) policyQualifiers OID 1.3.6.1.5.5.7.2.1 (CPS) CPS Pointer URI http://www-igc.cea.fr/pc/ policyQualifiers OID 1.3.6.1.5.5.7.2.2 (UNOTICE) noticeNumbers Seq. of Int 2,0 organization IA5String « CEA » displayText

(200c Max) IA5String « Ce certificat est soumis a une Politique de Certification qui en limite les garanties et responsabilites.

Vous devez accepter cette politique avant de l’utiliser. Consultez http://www-igc.cea.fr » Netscape Cert. Type 2.16.840.1.113730.1.1

BitString non-critique

SSL Client bit 0 non SSL Server bit 1 non S/MIME Client bit 2 non Object Signing bit 3 non SSL CA bit 5 OUI S/MIME CA bit 6 OUI Object Signing CA bit 7 OUI Netscape Comment 2.16.840.1.113730.1.13

IA5String non-critique

« Ce certificat est soumis a une Politique de Certification qui en limite les garanties et responsabilites. Vous devez accepter cette politique avant de l’utiliser. Consultez http://www-igc.cea.fr »

Basic Constraint 2.5.29.19

Sequence critique

cA Boolean vrai pathLenConstraint Integer non utilisé Subject Key Identifier 2.5.29.14


keyIdentifier OctetString 160 bits du hash Sha1 de la clé publique du certificat Authority Key Identifier 2.5.29.35


keyIdentifier OctetString 160 bits du hash Sha1 de la clé publique du certificat (= Subject Key ID)


Date : 06/01/2003

Indice : A6

C.2 CERTIFICATS DES AC SUBORDONNEES C.2.1 Champs de base des certificats Champs Format AC Utilisateur AC Badge AC Technique AC Partenaire version Integer 2 (pour version 3) 2 (pour version 3) 2 (pour version 3) 2 (pour version 3) serialNumber Integer numéro de série du certificat numéro de série du certificat numéro de série du certificat numéro de série du certificat signature OID 1.2.840.113549.1.1.5

(sha1WithRSAEncryption) 1.2.840.113549.1.1.5 (sha1WithRSAEncryption)

1.2.840.113549.1.1.5 (sha1WithRSAEncryption)


issuer RDNSequence type OID 2.5.4.6 (C) 2.5.4.6 (C) 2.5.4.6 (C) 2.5.4.6 (C) value PrintableString ”fr” ”fr” ”fr” ”fr” type OID 2.5.4.10 (O) 2.5.4.10 (O) 2.5.4.10 (O) 2.5.4.10 (O) value PrintableString ”cea” ”cea” ”cea” ”cea” type OID 2.5.4.11 (OU) 2.5.4.11 (OU) 2.5.4.11 (OU) 2.5.4.11 (OU) value PrintableString ”AC” ”AC” ”AC” ”AC” type OID 2.5.4.3 (CN) 2.5.4.3 (CN) 2.5.4.3 (CN) 2.5.4.3 (CN) value PrintableString ”CEA AC Racine” ”CEA AC Racine” ”CEA AC Racine” ”CEA AC Racine” validity Sequence notBefore UTCTime date de création (env. 2003) date de création (env. 2003) date de création (env. 2003) date de création (env. 2003) notAfter UTCTime date de fin (env. 2009) date de fin (env. 2009) date de fin (env. 2009) date de fin (env. 2009) subject RDNSequence type OID 2.5.4.6 (C) 2.5.4.6 (C) 2.5.4.6 (C) 2.5.4.6 (C) value PrintableString ”fr” ”fr” ”fr” ”fr” type OID 2.5.4.10 (O) 2.5.4.10 (O) 2.5.4.10 (O) 2.5.4.10 (O) value PrintableString ”cea” ”cea” ”cea” ”cea” type OID 2.5.4.11 (OU) 2.5.4.11 (OU) 2.5.4.11 (OU) 2.5.4.11 (OU) value PrintableString ”AC” ”AC” ”AC” ”AC” type OID 2.5.4.3 (CN) 2.5.4.3 (CN) 2.5.4.3 (CN) 2.5.4.3 (CN) value PrintableString ”CEA AC Utilisateur” ”CEA AC Badge” ”CEA AC Technique” ”CEA AC Partenaire” subjectPublicKeyInfo Sequence algorithmIdentifier OID 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) subjectPublicKey BitString clé publique de 2048 bits

+ exposant public (=65537) clé publique de 2048 bits + exposant public (=65537)

clé publique de 2048 bits + exposant public (=65537)


extensions Sequence voir tableau des extensions voir tableau des extensions voir tableau des extensions voir tableau des extensions signatureAlgorithm OID 1.2.840.113549.1.1.5




signatureValue Sequence algorithmIdentifier OID 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) subjectPublicKey BitString signature du certificat calculée par l’AC

Racine signature du certificat calculée par l’AC Racine

signature du certificat calculée par l’AC Racine

signature du certificat calculée par l’AC Racine


Date : 06/01/2003

Indice : A6

C.2.2 Extensions des certificats Extensions Format AC Utilisateur AC Badge AC Technique AC Partenaire

Key Usage 2.5.29.15

BitString critique critique critique critique

digitalSignature bit 0 non non non non nonRepudiation bit 1 non non non non keyEncipherment bit 2 non non non non dataEncipherment bit 3 non non non non keyAgreement bit 4 non non non non keyCertSign bit 5 OUI OUI OUI OUI cRLSign bit 6 OUI OUI OUI OUI encipherOnly bit 7 non non non non decipherOnly bit 8 non non non non CRL Distribution Points 2.5.29.31

Sequence non-critique non-critique non-critique non-critique

distributionPoint fullName uniformResIdentifier IA5String http://crl-ac-racine.cea.fr/crl/ac-racine.crl http://crl-ac-racine.cea.fr/crl/ac-racine.crl http://crl-ac-racine.cea.fr/crl/ac-racine.crl http://crl-ac-racine.cea.fr/crl/ac-racine.crl Autority Info. Access 1.3.6.1.5.5.7.1.1


accessMethod OID 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) accessLocation Gen.Name uniformResIdentifier IA5String http://www-igc.cea.fr/ac/ac-racine.cer http://www-igc.cea.fr/ac/ac-racine.cer http://www-igc.cea.fr/ac/ac-racine.cer http://www-igc.cea.fr/ac/ac-racine.cer Certificate Policies 2.5.29.32


policyIdentifier OID 1.3.6.1.4.1.12384.1.2 1.3.6.1.4.1.12384.1.2 1.3.6.1.4.1.12384.1.2 1.3.6.1.4.1.12384.1.2 policyQualifiers OID 1.3.6.1.5.5.7.2.1 (CPS) 1.3.6.1.5.5.7.2.1 (CPS) 1.3.6.1.5.5.7.2.1 (CPS) 1.3.6.1.5.5.7.2.1 (CPS) CPS Pointer URI http://www-igc.cea.fr/pc/ http://www-igc.cea.fr/pc/ http://www-igc.cea.fr/pc/ http://www-igc.cea.fr/pc/ policyQualifiers OID 1.3.6.1.5.5.7.2.2 (UNOTICE) 1.3.6.1.5.5.7.2.2 (UNOTICE) 1.3.6.1.5.5.7.2.2 (UNOTICE) 1.3.6.1.5.5.7.2.2 (UNOTICE) noticeNumbers Seq. of Int 2,0 2,0 2,0 2,0 organization IA5String « CEA » « CEA » « CEA » « CEA » displayText

(200c Max) IA5String « Ce certificat est soumis a une Politique

de Certification qui en limite les garanties et responsabilites. Vous devez accepter cette politique avant de l’utiliser. Consultez http://www-igc.cea.fr »




Netscape Cert. Type 2.16.840.1.113730.1.1

BitString non-critique non-critique non-critique non-critique

SSL Client bit 0 non non non non SSL Server bit 1 non non non non S/MIME Client bit 2 non non non non Object Signing bit 3 non non non non SSL CA bit 5 OUI OUI OUI OUI S/MIME CA bit 6 OUI OUI OUI OUI Object Signing CA bit 7 OUI OUI OUI OUI


Date : 06/01/2003

Indice : A6

Extensions Format AC Utilisateur AC Badge AC Technique AC Partenaire Netscape Comment 2.16.840.1.113730.1.13

IA5String non-critique non-critique non-critique non-critique





Basic Constraint 2.5.29.19

Sequence critique critique critique critique

cA Boolean vrai vrai vrai vrai pathLenConstraint Integer non utilisé non utilisé non utilisé non utilisé Subject Key Identifier 2.5.29.14


keyIdentifier OctetString 160 bits du hash Sha1 de la clé publique

du certificat 160 bits du hash Sha1 de la clé publique du certificat

160 bits du hash Sha1 de la clé publique du certificat


Authority Key Identifier 2.5.29.35


keyIdentifier OctetString 160 bits du hash Sha1 de la clé publique de l’AC Racine

160 bits du hash Sha1 de la clé publique de l’AC Racine




Date : 06/01/2003

Indice : A6

C.3 CERTIFICATS DES ABONNES C.3.1 Champs de base des certificats des Abonnés Champs Format AC Utilisateur AC Badge (sign et conf) AC Technique AC Partenaire version Integer 2 (pour version 3) 2 (pour version 3) 2 (pour version 3) 2 (pour version 3) serialNumber Integer numéro de série du certificat numéro de série du certificat numéro de série du certificat numéro de série du certificat signature OID 1.2.840.113549.1.1.5




issuer RDNSequence type OID 2.5.4.6 (C) 2.5.4.6 (C) 2.5.4.6 (C) 2.5.4.6 (C) value PrintableString ”fr” ”fr” ”fr” ”fr” type OID 2.5.4.10 (O) 2.5.4.10 (O) 2.5.4.10 (O) 2.5.4.10 (O) value PrintableString ”cea” ”cea” ”cea” ”cea” type OID 2.5.4.11 (OU) 2.5.4.11 (OU) 2.5.4.11 (OU) 2.5.4.11 (OU) value PrintableString ”AC” ”AC” ”AC” ”AC” type OID 2.5.4.3 (CN) 2.5.4.3 (CN) 2.5.4.3 (CN) 2.5.4.3 (CN) value PrintableString ”CEA AC Utilisateur” ”CEA AC Badge” ”CEA AC Technique” ”CEA AC Partenaire” validity Sequence notBefore UTCTime date de création du certificat date de création du certificat date de création du certificat date de création du certificat notAfter UTCTime date de création + 1 an (+/- 1 an) date de création + 1 an (+/- 1 an) date de création + 1 an (+/- 1 an) date de création + 1 an (+/- 1 an) subject RDNSequence type OID 2.5.4.6 (C) 2.5.4.6 (C) 2.5.4.6 (C) 2.5.4.6 (C) value PrintableString ”fr” ”fr” ”fr” ”fr” type OID 2.5.4.10 (O) 2.5.4.10 (O) 2.5.4.10 (O) 2.5.4.10 (O) value PrintableString ”cea” ”cea” ”cea” ”cea” type OID 2.5.4.11 (OU) 2.5.4.11 (OU) 2.5.4.11 (OU) 2.5.4.11 (OU) value PrintableString ”Utilisateur” ”Badge” ”Technique” ”Partenaire” type OID 2.5.4.3 (CN) 2.5.4.3 (CN) 2.5.4.3 (CN) 2.5.4.3 (CN) value PrintableString ”NOM Prenom PNxxxxxxC” ”NOM Prenom PNxxxxxxC” adresse IP ou nom DNS ”NOM Prenom ENTREPRISE” subjectPublicKeyInfo Sequence algorithmIdentifier OID 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) subjectPublicKey BitString clé publique de 1024 bits + exposant

public (=65537) clé publique de 1024 bits + exposant public (=65537)

clé publique de 512 à 4096 bits + exposant public (variable)


extensions Sequence voir tableau des extensions voir tableau des extensions voir tableau des extensions voir tableau des extensions signatureAlgorithm OID 1.2.840.113549.1.1.5




signatureValue Sequence algorithmIdentifier OID 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) 1.2.840.113549.1.1.1(rsaEncryption) subjectPublicKey BitString signature du certificat calculée par l’AC signature du certificat calculée par l’AC signature du certificat calculée par l’AC signature du certificat calculée par l’AC


Date : 06/01/2003

Indice : A6

C.3.2 Extensions des certificats des Abonnés des AC Utilisateur, Badge et Partenaire Extensions Format AC Utilisateur AC Badge signature AC Badge confidentialité AC Partenaire

Key Usage 2.5.29.15

BitString critique critique critique critique

digitalSignature bit 0 OUI OUI non OUI nonRepudiation bit 1 non OUI non non keyEncipherment bit 2 OUI non OUI OUI dataEncipherment bit 3 OUI non OUI OUI keyAgreement bit 4 non non non non keyCertSign bit 5 non non non non cRLSign bit 6 non non non non encipherOnly bit 7 non non non non decipherOnly bit 8 non non non non CRL Distribution Points 2.5.29.31


distributionPoint fullName uniformResIdentifier IA5String http://crl-ac-utilisateur.cea.fr/crl/ac-

utilisateur.crl http://crl-ac-badge.cea.fr/crl/ac-badge.crl http://crl-ac-badge.cea.fr/crl/ac-badge.crl http://crl-ac-partenaire.cea.fr/crl/ac-

partenaire.crl Autority Info. Access 1.3.6.1.5.5.7.1.1


accessMethod OID 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) accessLocation Gen.Name uniformResIdentifier IA5String http://www-igc.cea.fr/ac/ac-utilisateur.cer http://www-igc.cea.fr/ac/ac-badge.cer http://www-igc.cea.fr/ac/ac-badge.cer http://www-igc.cea.fr/ac/ac-partenaire.cer Certificate Policies 2.5.29.32


policyIdentifier OID 1.3.6.1.4.1.12384.1.2 1.3.6.1.4.1.12384.1.2 1.3.6.1.4.1.12384.1.2 1.3.6.1.4.1.12384.1.2 policyQualifiers OID 1.3.6.1.5.5.7.2.1 (CPS) 1.3.6.1.5.5.7.2.1 (CPS) 1.3.6.1.5.5.7.2.1 (CPS) 1.3.6.1.5.5.7.2.1 (CPS) CPS Pointer URI http://www-igc.cea.fr/pc/ http://www-igc.cea.fr/pc/ http://www-igc.cea.fr/pc/ http://www-igc.cea.fr/pc/ policyQualifiers OID 1.3.6.1.5.5.7.2.2 (UNOTICE) 1.3.6.1.5.5.7.2.2 (UNOTICE) 1.3.6.1.5.5.7.2.2 (UNOTICE) 1.3.6.1.5.5.7.2.2 (UNOTICE) noticeNumbers Seq. of Int 2,0 2,0 2,0 2,0 organization IA5String « CEA » « CEA » « CEA » « CEA » displayText

(200c Max) IA5String « Ce certificat est soumis a une Politique

de Certification qui en limite les garanties et responsabilites. Vous devez accepter cette politique avant de l’utiliser. Consultez http://www-igc.cea.fr »




Netscape Cert. Type 2.16.840.1.113730.1.1

BitString non-critique non-critique non-critique non-critique

SSL Client bit 0 OUI OUI OUI OUI SSL Server bit 1 non non non non S/MIME Client bit 2 OUI OUI OUI OUI Object Signing bit 3 non OUI non non SSL CA bit 5 non non non non S/MIME CA bit 6 non non non non Object Signing CA bit 7 non non non non


Date : 06/01/2003

Indice : A6

Extensions Format AC Utilisateur AC Badge signature AC Badge confidentialité AC Partenaire Netscape Comment 2.16.840.1.113730.1.13

IA5String non-critique non-critique non-critique non-critique





Subject Alternative Name 2.5.29.17


rfc822Name IA5String « [email protected] » « [email protected] » « [email protected] » « adresse mel 1 » rfc822Name IA5String « [email protected] » « [email protected] » (facultatif) « [email protected] » (facultatif) « adresse mel 2 » (facultatif) rfc822Name IA5String « [email protected] » (facultatif) « [email protected] » (facultatif) « [email protected] » (facultatif) « adresse mel 3 » (facultatif) otherName Sequence type-id OID 1.3.6.1.4.1.311.20.2.3 (PrincipalName) 1.3.6.1.4.1.311.20.2.3 (PrincipalName) non utilisé non utilisé value UTF8String « [email protected] »(1)

(nom de login dans l’AD Win2K) « [email protected] »(1) (nom de login dans l’AD Win2K)

non utilisé non utilisé

Subject Key Identifier 2.5.29.14


keyIdentifier OctetString 160 bits du hash Sha1 de la clé publique

du certificat 160 bits du hash Sha1 de la clé publique du certificat



Authority Key Identifier 2.5.29.35


keyIdentifier OctetString 160 bits du hash Sha1 de la clé publique de l’AC

160 bits du hash Sha1 de la clé publique de l’AC



Extended Key Usage 2.5.29.37 Sequence

non utilisé non-critique non utilisé non utilisé

Client Auth OID 1.3.6.1.5.5.7.3.2 Code Signing OID 1.3.6.1.5.5.7.3.3 Email Protection OID 1.3.6.1.5.5.7.3.4 Smart Card Logon OID 1.3.6.1.4.1.311.20.2.2 Ms Ind. Code Sign OID 1.3.6.1.4.1.311.2.1.21 any Ext. Key Usage OID 2.5.29.37.0

(1) login est constitué de la première lettre du prénom et de la première lettre du nom en majuscules, et suivies du numéro de badge CEA (idem « PNxxxxxx » dans le CN du DN du sujet).

C.3.3 Extensions des certificats des Abonnés de l’AC Technique Les extensions des certificats émis par l’AC Technique peuvent varier en fonction des besoins des entités à certifier. Par défaut, les extensions suivantes sont utilisées :

Extensions Format AC Technique Key Usage 2.5.29.15

BitString critique

digitalSignature bit 0 OUI nonRepudiation bit 1 non keyEncipherment bit 2 OUI dataEncipherment bit 3 OUI keyAgreement bit 4 non keyCertSign bit 5 non cRLSign bit 6 non encipherOnly bit 7 non decipherOnly bit 8 non


Date : 06/01/2003

Indice : A6

Extensions Format AC Technique CRL Distribution Points 2.5.29.31


distributionPoint fullName uniformResIdentifier IA5String http://crl-ac-technique.cea.fr/crl/ac-technique.crl Autority Information Access 1.3.6.1.5.5.7.1.1


accessMethod OID 1.3.6.1.5.5.7.48.2 (Cert Auth Issuer) accessLocation Gen.Name uniformResIdentifier IA5String http://www-igc.cea.fr/ac/ac-technique.cer Certificate Policies 2.5.29.32


policyIdentifier OID 1.3.6.1.4.1.12384.1.2 policyQualifiers OID 1.3.6.1.5.5.7.2.1 (CPS) CPS Pointer URI http://www-igc.cea.fr/pc/ policyQualifiers OID 1.3.6.1.5.5.7.2.2 (UNOTICE) noticeNumbers Seq. of Int 2,0 organization IA5String « CEA » displayText

(200c Max) IA5String « Ce certificat est soumis a une Politique de Certification qui en limite les garanties et responsabilites.

Vous devez accepter cette politique avant de l’utiliser. Consultez http://www-igc.cea.fr » Netscape Cert. Type 2.16.840.1.113730.1.1

BitString non-critique

SSL Client bit 0 non SSL Server bit 1 OUI S/MIME Client bit 2 non Object Signing bit 3 non SSL CA bit 5 non S/MIME CA bit 6 non Object Signing CA bit 7 non Netscape Comment 2.16.840.1.113730.1.13

IA5String non-critique


Subject Alternative Name 2.5.29.17


uniformResourceIdentifier IA5String autre adresse IP ou nom DNS (facultatif) Subject Key Identifier 2.5.29.14


keyIdentifier OctetString 160 bits du hash Sha1 de la clé publique du certificat Authority Key Identifier 2.5.29.35


keyIdentifier OctetString 160 bits du hash Sha1 de la clé publique de l’AC


Date : 06/01/2003

Indice : A6

ANNEXE D : FORMAT DES CRL Champs Format Valeurs version Integer 0 (pour version 1) signature OID 1.2.840.113549.1.1.5 (sha1WithRSAEncryption) issuer RDNSequence type OID 2.5.4.6 (C) value PrintableString ”fr” type OID 2.5.4.10 (O) value PrintableString ”cea” type OID 2.5.4.11 (OU) value PrintableString ”AC” type OID 2.5.4.3 (CN) value PrintableString nom de l’AC (1) thisUpdate Time UTCTime date d’émission de la CRL nextUpdate Time UTCTime date d’émission + délai maximum avant prochaine CRL(2) revokedCertificates Sequence userCertificate Integer numéro de série d’un certificat révoqué revocationDate UTCTime date de révocation du certificat userCertificate Integer … revocationDate UTCTime … … signatureAlgorithm OID 1.2.840.113549.1.1.5 (sha1WithRSAEncryption) signatureValue Sequence algorithmIdentifier OID 1.2.840.113549.1.1.1 (rsaEncryption) subjectPublicKey BitString signature du certificat calculée par l’AC émettrice

(1) Les noms d’AC sont : « CEA AC Racine », « CEA AC Utilisateur », « CEA AC Badge », « CEA AC Technique », « CEA AC Partenaire » (2) Le délai maximum avant la prochaine émission de CRL est indiqué au chapitre 4.4.5

Documents

Politique de Certification de l ... - · Responsabilités des acteurs de l’IGC .....11 2.2.2. Limites de responsabilités du CEA ... DOCUMENTS DE REFERENCES