Gestion des certificats par LDAP
Nadia RASAMOELY
Septembre 2002
I. Présentation des PKI
La signature électronique repose sur un système ou une infrastructure
"Public Key Infrastructure" (PKI). La PKI est une norme permettant d'échanger
de façon fiable des données électroniques, reposant sur
des techniques de cryptage utilisant une paire de clés numériques
(une clé privée et une clé publique). Elle offre un cadre
global permettant d'installer des éléments de sécurité
tels que la confidentialité, l'authentification, l'intégrité
et la non-répudiation tant au sein de l'entreprise que lors d'échanges
d'information avec l'extérieur.
Une infrastructure PKI fournit donc quatre services principaux:
- Fabrication de bi-clés.
- Certification de clé publique et publication de certificats.
- Révocation de certificats.
- Gestion la fonction de certification
L'objectif est de garantir que la communication provient d'une source identifiable
et n'est pas modifiée par rapport au moment de l'envoi par cette source
(authentification).
Ces paires de clés sont liées de manière univoque à
un ou plusieurs certificats, où figurent l'identité (signature)
et/ou une ou plusieurs qualités ou attributs de cette personne.
I.1. La signature électronique
Le chiffrement permet de rendre les services de confidentialité.
La signature électronique va permettre de garantir l’authentification
de l’origine d’un document ou d’un message électronique et son intégrité.
Ceci implique un certain nombre de propriétés :
· une signature ne peut être falsifiée,
· une signature donnée n’est pas réutilisable par un
autre document
· la modification d’un document signé altère la signature
de ce document
· une signature ne peut être reniée
Pour générer une signature électronique il faut dans
un premier temps utiliser une fonction de hachage. C’est une fonction mathématique
qui, à partir d’un texte, génère un nombre caractéristique
de ce texte. Ce nombre est appelé empreinte (fingerprint) parce que
toute modification du texte entraîne la modification de son empreinte.
L’empreinte n’est pas une compression puisqu’on en peut retrouver le fichier
d’origine à partir de son empreinte beaucoup plus petite.
MD5 (MD pour Message Digest, rfc1321) est une fonction de hachage très
répandue, elle crée une empreinte de 128 bits. SHA (Secure Hash
Algorithm), autre fonction, crée des empreintes de 160 bits. Ce sont
les deux algorithmes les plus répandus actuellement.
Le principe utilisé pour la signature d’un document est de chiffrer
une empreinte de celui-ci avec la clé privée de son auteur.
Tout un chacun peut déchiffrer cette empreinte avec la clef publique
de l’auteur et recalculer l’empreinte sur le document lui même. La bonne
correspondance entre ces deux empreintes constitue la preuve que :
1. le document n’a pas été modifié (puisque l’empreinte
d’origine est conforme à l’empreinte du document reçu
2. l’empreinte d’origine a bien été apposée par le
titulaire de la clef privée associée à la clef publique
utilisée pour vérifier la signature.
I.2. Problématique de la gestion des clés
Dans un système utilisant un chiffrement à clés symétriques,
il y aura beaucoup de clés à gérer suivant le nombre
d’entités concernées (en fonction du carré du nombre
de liaisons à établir : n(n-1)/2). Si on veut ajouter une nouvelle
liaison (un nouvel utilisateur, un nouveau service …), il faudra générer
n clés et les distribuer. Cette gestion des clés est inadaptée
sur une échelle importante : les problèmes d’administration
deviennent rapidement insurmontables.
Dans un système utilisant un chiffrement à clés asymétriques,
un utilisateur a un couple de clés. La clé privée reste
toujours avec l’utilisateur et la clé publique est publiée dans
un annuaire public. Un nouvel utilisateur aura uniquement besoin de son couple
de clés et de publier sa clé publique dans l’annuaire pour
pouvoir communiquer avec l’ensemble des autres entités.
Ce type de système introduit un nouveau problème : l’utilisation
d’un couple de clés entraîne la nécessité de publication,
en toute confiance, de la clé publique. Cette publication doit offrir
l’assurance que :
· la clé est bien celle appartenant à la personne avec
qui les échanges sont envisagés ;
· le possesseur de cette clé est « digne de confiance
» ;
· la clé est toujours valide.
Cette notion de confiance est résolue avec les certificats et les
autorités de certification.
I.3. Certificats et Autorité de Certification
I.3.1. DEFINITION D’UN CERTIFICAT
Un certificat est un document électronique, résultat d’un
traitement fixant les relations qui existent entre une clef publique, son
propriétaire (une personne, une application, un site) et l’application
pour laquelle il est émis :
· pour une personne il prouve l’identité de la personne au
même titre qu’une carte d’identité, dans le cadre fixé
par l’autorité de certification qui l’a validé ;
· pour une application il assure que celle-ci n’a pas été
détournée de ses fonctions ;
· pour un site il offre la garantie lors d’un accès vers celui-ci
que l’on est bien sur le site auquel on veut accéder.
On ne parlera dans ce document que des certificats qui s’appuient sur un
protocole normalisé X509 (ITU-T X.509 international standard V3 - 1996)
(RFC2459). Il existe des applications ou des systèmes de cryptologie
qui ne s’appuie pas sur les certificats X509 (PGP par exemple).
Le certificat est signé (au sens signature électronique) :
on effectue une empreinte du certificat à l’aide d’algorithme (MD5
par exemple), et on chiffre l’empreinte obtenue.
Le chiffrement s’effectue avec la clé privée de l’autorité
de certification qui possède elle-même son propre certificat.
I.3.1.1. Contenu d'un certificat
Le certificat contient un certain nombre de champs obligatoires et des extensions
dont certaines sont facultatives :
Version : indique à quelle version de X509 correspond ce certificat
Numéro de série : Numéro de série du certificat
Algorithme de signature: identifiant du type de signature utilisée
Emetteur : Distinguished Name (DN) de l'autorité de certification
qui a émis ce certificat
Valide à partir de: la date de début de validité
de certificat
Valide jusqu'à : la date de fin de validité de certificat
Objet: Distinguished Name (DN) de détenteur de la clef publique
Clé publique : infos sur la clef publique de ce certificat
Extensions X509v3 : Extensions génériques optionnelles,
introduites avec la version 3 de X509
Signature : Signature numérique de l'AC sur l'ensemble des champs
précédents
Le certificat associe à la clé publique des informations spécifiques
à l’entité (physique ou morale) à laquelle elle se rapporte
(informations s’ajoutant aux informations de bases que sont : numéro
de version, numéro de série, algorithme de signature, période
de validité… contenues dans un certificat X509).
Les extensions introduites dans la norme X509v3 permettent de spécifier
un certain nombre d'informations en fonction de l'usage prévu d'un
certificat. Les extensions ci-dessous ne sont pas exhaustives :
· X509v3 Basic Constraint : indique s'il s'agit du certificat d'une
Autorité de Certification ou non, c'est à dire permettant d'émettre
des certificats
· X509v3 Key Usage : Donne une ou plusieurs fonctions de sécurité
auxquelles la clé publique est destinée. Ce champ permet de
spécifier plusieurs services de sécurité
· X509v3 subjectAltName: Ce champ contient un ou plusieurs noms alternatifs
pour le porteur de certificat, exprimé sous diverses formes possibles.
· X509v3 issuerAltName: Ce champ contient un ou plusieurs noms alternatifs
pour l'AC qui a généré ce certificat, exprimé
sous diverses formes possibles.
· X509v3 CRL Distribution Points : adresse de la CRL permettant de
connaître le statut de ce certificat
Une extension dans un certificat peut être qualifiée de critique
ou non. Le fait qu'une extension soit critique rend obligatoire la conformité
du certificat aux informations contenues dans l’extension. Si une application
traitant un certificat ne reconnaît pas une extension contenue dans
ce certificat et marquée comme critique, ce certificat doit être
déclaré invalide par l'application. En particulier les extensions
key Usage et Basic Constraint doivent être marquée critique.
Avant que la norme X509v3 n'ai été créée, Netscape
a introduit plusieurs extensions propriétaires permettant de
limiter l'usage d'un certificat.
Ces extensions propriétaires sont toujours utilisables, et parfois
mêmes nécessaires avec Netscape. Elles apparaissent dans la partie
X509v3 Extensions du certificat.
I.3.1.2. Vérification d’un certificat
La vérification s’effectue avec la clé publique de l’autorité
de certification. Toute personne voulant vérifier un certificat délivré
par une autorité de certification doit connaître la clé
publique de cette autorité de certification.
I.3.2. L’ AUTORITE DE CERTIFICATION
Une Autorité de Certification est une organisation qui délivre
des certificats électroniques à une population. Une AC possède
elle-même un certificat (autosigné ou délivré par
une autre AC) et utilise sa clé privée pour créer les
certificats qu'elle délivre.
N'importe qui peut se déclarer Autorité de Certification.
Une AC peut être organisationnelle, pécifique à
un corps de métiers (exemple : notaires) ou encore institutionnelle.
Selon le crédit accordé à l'AC, les certificats délivrés
auront un champ d'applications plus ou moins importants :
· limité à l'intérieur d'un organisme
· échanges inter-organismes
· …
En délivrant un certificat, l'AC se porte garant de l'identité
de l'entité qui se présentera avec ce certificat. Par rapport
aux entités (personnes ou applications) qui utilisent ses certificats,
une AC joue le rôle de tiers de confiance.
Le niveau de garantie offert par une AC dépendra du mécanisme
de signature : moyens mis en œuvre pour s'assurer de l'identité des
demandeurs, sécurité mise en œuvre pour la protection de la
clé privée de l'AC, etc.
I.3.3. CERTIFICATION CROISEE ET CERTIFICATION HIERARCHIQUE
Une AC peut cautionner une autre AC en créant un certificat en signant
sa clé publique. On peut ainsi mettre en place des relations de confiance
hiérarchiques ou croisées entre ACs.
Dans le cas d'une relation hiérarchique(fig.1), une AC dite racine
délivre un certificat à une ou plusieurs autres ACs, qui elles-mêmes
peuvent délivrer un certificat à d'autres ACs et ainsi de suite.
Au sommet de ces arborescences, on trouve les ACs racines dont le certificat
est signé avec leur propre clé privée (certificat auto-signé).
Dans le cas de la figure ci-dessus, pour valider un certificat issu de l'AC
AC4, il faut les certificats des ACs AC0, AC1 et AC4. On appelle cela une
chaîne de certification.
Une chaîne de certification est l'ensemble des Certificats nécessaires
pour valider la généalogie d'un certificat d'un porteur de certificat.
Dans une architecture horizontale simple, la chaîne se compose du
Certificat de l'Autorité de Certification qui a émis le certificat
et de celui du Porteur de Certificat.
Dans une architecture arborescente comme ci-dessus, c'est l'ensemble des
certificats formant le chemin entre le certificat à vérifier
et celui de l'AC racine.
En général dans ce type de schéma, seuls les ACs "feuilles"
délivrent des certificats à des personnes ou à des services.
La confiance accordée à une AC est héritée par
toutes ses ACs "filles". Ainsi si l'on décide de faire confiance à
une AC racine, cette confiance sera également accordée à
l'ensemble des Acs appartenant à la même hiérarchie.
Les relations de confiance croisées sont utiles lorsqu'un organisme
O1 et O2 ayant chacun leur propre AC, AC1 et AC2, n'appartenant pas à
une même arborescence, veulent se faire confiance. Dans ce cas, AC1
et AC2 peuvent chacun créer un certificat en signant la clé
publique de l'autre. Ainsi un utilisateur de O1 pourra vérifier le
certificat d'une personne de O2.
I.4. Infrastructure à Clés Publiques (ICP) ou PKI
On parle aussi d'"Infrastructure de gestion de Clés" (IGP) ou de
"Private Key Infrastructure" (PKI).
Un certificat électronique peut être comparé à
une carte d'identité.
Dans le cas d'une carte d'identité, la personne fera sa demande à
la mairie de sa commune, qui procédera à la vérification
des informations fournies. La demande est alors transmise à la préfecture
qui procédera à l'émission de la carte d'identité.
Dans le cas des certificats électroniques, l'AC peut être comparée
à la préfecture (ou l'Etat) qui assume la responsabilité
des pièces d'identité qu'elle délivre.
L'ensemble des procédures (demande, contrôle, émission,…)
qui existe pour les cartes d'identité existe de la même
façon pour les certificats électroniques. Elles sont mises en
œuvre à travers une infrastructure qui est l’ICP.
L’ICP est constituée de l'ensemble des matériels, logiciels,
personnes, règles et procédures nécessaire à une
Autorité de Certification pour créer, gérer et distribuer
des certificats X509.
Une ICP est donc une structure à la fois technique et administrative
permettant une mise en place, lors de l’échange de clef, de relations
de confiance entre des entités morales et/ou physiques et/ou logiques.
Les fonctions principales d'une ICP sont :
· Émettre et révoquer des certificats
· Publier les certificats dans un annuaire
· Éventuellement, fournir un service de dépôt
et de recouvrement des clés privées
Elle est constituée par :
· Une autorité de certification (AC)
· Une autorité d'enregistrement (AE)
· Un opérateur de certification (OC)
· Un annuaire de publication de certificats
· Un service de validation
· Éventuellement, un service de dépôt de clés
I.4.1. L’AUTORITE D’ENREGISTREMENT
L’AE a pour tâche principale de recevoir et de traiter les demandes
de création, de renouvellement et de révocation de certificats.
Pour cela, elle doit :
· assurer le contrôle des données identifiant le demandeur
de certificat,
· valider les demandes de révocation,
· assurer lors de la délivrance d’un nouveau certificat (sur
date de péremption atteinte) un recouvrement des certificats afin d’assurer
la continuité pour la fonctionnalité signature et/ou chiffrement.
Elle travaille en étroite collaboration avec l’opérateur de
certification ; elle possède un bi-clef certifié pour s’authentifier
et pour accomplir les tâches qui lui incombent.
L'AE comprend en général 2 composants :
· une interface permettant aux utilisateurs de faire leurs demandes,
· une interface de gestion réservés aux opérateurs
de l'AE permettant de valider les demandes.
I.4.2. OPERATEUR DE CERTIFICATION
L'Autorité de Certification délègue à l'Opérateur
de Certification toutes les opérations nécessitant la
clé privée de l’AC : création et distribution sécurisée
des certificats, révocation, production de cartes à puces…
L'OC gère en collaboration avec l’autorité d’enregistrement
les cycles de vie des certificats. En fonction de la politique de certification
ce peut être lui qui génère les bi-clefs pour le compte
des utilisateurs.
Pour des raisons de sécurité, l'Opérateur de Certification
n'est en général pas connecté au réseau. En effet
la compromission de la clef privée de l'AC étant le risque majeur
dans une ICP, tout doit être fait pour l'éviter. Cela entraîne
en particulier que le transfert des requêtes entre l'AE et l'OC n'est
pas automatique.
En outre, la sécurisation physique de l'OC doit également
être étudié avec soin.
I.4.3. ANNUAIRE DE PUBLICATION
Les certificats émis par une ICP doivent être rendus publiques
afin que les différents partenaires qui les utilisent puissent s’échanger
leur clé publique. Pour cela, les certificats sont publiés dans
un annuaire d’accès libre.
Cet annuaire peut également contenir le certificat de l'AC et les
CRLs. Des annuaires LDAP sont généralement utilisés pour
cette fonction.
I.4.4. SERVICE DE VALIDATION
Un certificat émis par une ICP peut devenir invalide pour différentes
raisons :
· perte ou vol de la clé privée associée
· fin de mandat
· date de péremption
· …
Le cas de la date de péremption est traité par le fait que
les certificats contiennent les dates de début et de fin de validité.
Dans les autres cas, l’ICP doit procéder à la révocation
des certificats concernés.
L’utilisateur (service ou personne) d’un certificat doit donc avoir un moyen
de vérifier que ce certificat est valide à un instant donné.
Pour cela, une ICP doit fournir un service de validation permettant à
tout instant de vérifier la validité des certificats qu’elles
délivrent.
La méthode la plus employée jusqu’à maintenant est
la publication d’une liste appelée Certificate Revocation List (CRL)
qui est la liste des numéros de série des certificats révoqués.
Une CRL a un format standardisé et est signée à l’aide
de la clé privée de l’AC émettrice. Elle peut être
subdivisée en plusieurs CRLs, ceci pour des raisons de performances.
Elle peut être publiée via le même annuaire de publication
que les certificats.
La technique des CRL s’avère peu optimisée que ce soit pour
des raisons de performances (volumes des certificats à gérer)
ou d’efficacité. En effet les CRLs ne permettent pas de diffuser rapidement
l’information de révocation d’un certificat, ce qui peut-être
très préjudiciable dans les cas d’applications nécessitant
un haut niveau de sécurité.
Cette technique devrait être progressivement remplacée par
un nouveau protocole : OCSP. Un client OCSP pourra vérifier la validité
d’un certificat donné en interrogeant un serveur OCSP. Cela permettra
la diffusion quasi instantanée de l’information concernant la révocation
d’un certificat.
I.4.5. POLITIQUES DE CERTIFICATION
De même que la sécurité se met en place en suivant une
politique de sécurité définie préalablement, la
mise en place d’une ICP oblige à une définition de politiques
de certification : « un ensemble de règles indiquant, ce pour
quoi le certificat est applicable et par qui, et quelles sont les conditions
de leur mise en œuvre au sens juridique, administratif et technique ».
La règle de base étant avant tout que les certificats et les
moyens de mise en œuvre soient définis en fonction de l’utilisation
que l’on veut en faire. Les facteurs principaux à prendre en compte
sont :
· Étude de la population/des utilisateurs à qui est
destiné le certificat en tenant compte à la fois des caractéristiques
des utilisateurs, de l’utilisation qui sera faite du certificat (signature,
chiffrement entre entités morales et/ou physiques, accès à
des applications sécurisées) et de la mise en place des critères
d’attribution.
· Étude des moyens de collecte des informations, de leur validation
et de la création des certificats.
· Définition de la durée de vie des clefs (privée,
publique et/ou de session), des certificats, de la consolidation de ceux-ci,
de la gestion des listes de révocations.
· Étude des moyens de distribution des certificats via des
communications sécurisées de type «VPN» ou sur un
support style « carte de crédit » avec récupération
en main propre ou par un agent de sécurité sur site.
· Sécurité des ICP au sens implantation physique, et
sécurité des annuaires supports des informations publiques en
tenant compte de l’infrastructure, de l’administration et du coût de
gestion.
· Définition des services nécessitant une haute disponibilité
(exemple : gestion des listes de révocation).
· Prise en compte de la nécessité d’un recouvrement
des clefs privées et de l’interaction avec l’autorité suprême
et/ou avec d’autres communautés (interopérabilité pour
certifications croisées).
· Étude du support matériel/logiciel du certificat
chez l’utilisateur en tenant compte de la vétusté des postes
de travail et en prévoyant des évolutions aisées.
· Prise en compte de l’impact sur les structures existantes : physiques
et organisationnelles.
· Définition de la formation/information des acteurs.
Tout ceci sera transcrit dans un document qui constituera la Politique de
Certification (PC) de l'AC. C'est la PC qui définira le niveau de sécurité
associé à un certificat. Par exemple, si la PC spécifie
que pour obtenir un certificat, une personne devra se présenter avec
une pièce d'identité, la valeur du certificat obtenu sera plus
grande que si on se contentait de vérifier l'adresse électronique
de la personne.
La Déclaration des Pratiques de Certification (DPC) a pour but de
décrire les détails des processus techniques mise en œuvre au
sein des différentes composantes de l'ICP (CA, RA,...), conformément
à la PC.
En résumé, la PC spécifie des objectifs de sécurité
qu'il est nécessaire d'atteindre pour la sécurisation de l'application
utilisatrice des services de l'ICP, alors que la DPC spécifie les moyens
mises en œuvre pour atteindre ces objectifs.
Les politiques de certifications peuvent permettre d'établir des
normes communes d’interopérabilité et des critères d’assurance
communs entre plusieurs organismes.
I.4.6. PROTECTION DES CLES PRIVEES
La mise en place d'une ICP dans le but de déployer des applications
utilisant les certificats X509 n'a de sens que si un niveau de confiance suffisant
peut être établi entre les différents protagoniste.
Vis à vis de l'ICP elle-même, la confiance est apportée
par sa politique de certification et les moyens mis en œuvre pour la faire
respecter.
Le point faible concerne les possesseurs de certificats, car ce sont eux
qui ont la responsabilité de la protection de leur certificat et de
la clé privée associée.
En effet si on veut pouvoir faire confiance à un certificat, il est
nécessaire que la clé privée associée soit correctement
protégée. Ceci est vrai aussi bien pour les certificats de personnes
que pour ceux de serveurs.
Concernant les certificats de personnes, il est absolument indispensable
de mettre en place une formation dans le but de faire comprendre aux utilisateurs
ce qu'est un certificat, sa fonction et pourquoi il faut protéger la
clé privée associée.
Le choix du support physique des certificats et de la clé privée
associée dépendra du niveau de sécurité que l'on
veut atteindre :
- un fichier sur disque dur
Cette solution a l'avantage d'être facile à mettre en œuvre.
Mais elle implique que le niveau de sécurité du certificat et
de la clé privée sera directement dépendant du niveau
de sécurité de l'ordinateur (poste de travail ou serveur) sur
lequel ils seront installés. De plus le certificat et la clé
privée peuvent facilement être installés sur différents
postes de travail.
- une carte à puce
Cette solution, plus chère, matérialise le certificat et la
clé privée sous la forme d'une carte. Elle facilite l'"éducation"
des utilisateurs qui associe mieux le certificat à une pièce
d'identité personnelle.
Il est clair que dans le cas d'applications sensibles, seule une solution
à base de cartes à puce pourra apporter un niveau de sécurité
raisonnable.
I.4.7. FORMATS DE MESSAGES
Pour permettre le transfert des requêtes et des certificats entres
les composant d'une ICP ainsi qu'entre l'ICP et ses utilisateurs, plusieurs
formats de messages ont été standardisés :
- PKCS7 : format de données signées. Permet par exemple le
transfert d'un ou de plusieurs certificats.
- PKCS10 : format de requête de certification d'une clé publique
- PKCS12 : format de stockage de certificats et de clés privées.
C'est ce format qui est utilisée par exemple pour la sauvegarde d'un
certificat et de sa clé privée.
- Etc.
Les certificats X509 ainsi que ces différents types de messages utilisent
un encodage appelé DER (Distinguished Encoding Rules) qui est un sous-ensemble
de l'encodage BER (Basic Encoding Rules). Le format DER des certificats numériques
se prête mal aux applications du type courrier électronique car
il contient des octets qui pourraient être "malmenés" par certains
logiciels de transfert de messages. Le format PEM (Privacy Enhanced Mail)
y remédie en utilisant l'encodage base 64.
I.4.8. LES STANDARDS
Le groupe de travail PKIX à été mis en place en automne
1995 afin d'ériger un standard X.509 orienté vers les applications
Internet. La portée du travail de PKIX a augmenté au-delà
de ce premier but. PKIX ne travail plus seulement à partir des normes
de l'ITU PKI, mais développe également de nouveau standard sur
l’utilisation des PKI basés sur X.509 au niveau d'Internet, en particulier
:
· Une instanciation des certificats X.509v3 et des listes de révocation
(Certificate Revocation List, CRL) X.509v2 pour une infrastructure adaptée
à l'Internet. En effet, un certificat X.509v3 est une structure de
données complexe, composée de nombreux champs, et comportant
de nombreuses extensions optionnelles et de nombreuses options. Cette particularité
permet l'utilisation des certificats X.509 pour beaucoup de situations et
d'environnements mais rend difficile la création de produits interopérables.
C'est pourquoi le groupe PKIX a défini, dans le RFC 2459, une instanciation
particulière de la norme X.509 pour l'Internet en décrivant
le contenu des certificats et la liste des extensions obligatoires et optionnelles.
· Des protocoles d'exploitation, qui permettent de distribuer les
certificats et les listes de révocation aux systèmes qui les
utilisent. Divers systèmes de distribution sont développés,
en particulier des procédures basées sur LDAP, HTTP, FTP, et
X.500.
· Des protocoles de gestion, qui permettent aux différentes
entités composant la PKI (autorités de certification, possesseurs
de certificats...) de dialoguer et d'échanger les informations relatives
à la gestion de l'ensemble : demande de création ou de révocation
de certificat, certification réciproque entre autorités de certification...
· Des règles d'usage et des considérations pratiques
: exigences en matière d'identification des sujets, sécurité
physique, règles pour la révocation des certificats...
II. Mise en place d’une PKI avec un annuaire LDAP
II.1. Organisation d'une PKI
Parallèlement à l'autorité de certification, l'autorité
d'enregistrement, qui gère le contrôle des données identifiant
le demandeur d'un certificat, a aussi la charge d'authentifier les demandes
de révocation qui seront ensuite traitées par l'autorité
de certification. Laquelle assure ensuite la distribution sécurisée
des certificats électroniques vers l'utilisateur et l'annuaire. Une
fois l'utilisateur ainsi identifié, l'autorité de certification
délivre des certificats qui répondent le plus souvent à
la norme X.509 V3 définie par l'ITU-T (International Telecommunication
Union-Telecommunication Standardization Sector).
Dans une infrastructure à clé publique ; pour obtenir un certificat
numérique, l'utilisateur fait une demande auprès de l'autorité
d'enregistrement. Celle-ci génère un couple de clé (clé
publique, clé privée), envoie la clé privée au
client, enregistre l’utilisateur selon une procédure et des critères
définis par l'autorité de certification qui certifie la clé
publique et appose sa signature sur le certificat, parfois fabriqué
par un opérateur de certification (fig.2).
Figure 2 : Organisation d’une PKI
(1): L’utilisateur effectue une demande auprès de l’autorité
d’enregistrement.
(2): L’autorité d’enregistrement recueille les données personnelles
d’identification et récupère éventuellement la clé
publique de son infrastructure de PKI, puis enregistre le demandeur et lui
envoie la clé privée.
(3): L’autorité d’enregistrement expédie l’identifiant de
l’utilisateur, et éventuellement la clé publique, à
l’autorité de certification en assurant à la fois l’intégrité
et la confidentialité du message.
(4): L’autorité de certification va alors créer le certificat.
Suivant les PKI, le demandeur reçoit son certificat signé directement
ou via l’autorité d’enregistrement. Pour retirer son certificat, il
signe les chartes expliquant les formalités d’utilisation, etc.
(5) : Le certificat généré par l’autorité de
certification est émis à destination du service de publication.
(6) : Le certificat et la clé publique sont rendus disponibles par
publication dans des annuaires LDAP.
Les flux entre les différentes entités de la PKI dans le schéma
sont du type (RFC 2510, 2559):
Transaction opérationnelle,
Transaction de gestion,
Publication des certificats et des CRL.
Les transactions opérationnelles sont les échanges de message
qui sont inclus dans les documents du protocole opérationnel et qui
fournissent le transport pour les certificats, les CRL, et les informations
de statut. Les transactions de gestion (Management transactions), sont les
échanges de message décrits dans les documents "protocole de
gestion" qui fournissent les services de "messages" aux transactions de gestion
ou aux opérations internes de la PKI. Le service de publication est
employé pour distribuer des certificats et les CRL vers un dépôt.
En général, les échanges entre l'autorité d'enregistrement
(impliquant souvent des interactions d'utilisateur) et l'entité d'extrémité
se font en rapport avec le sujet de l’entité d’extrémité
pour l'enregistrement, la livraison de certificat, les processus de gestion
de clef et le cycle de vie du certificat. Cependant, en aucune circonstance
la RA n'effectue réellement des rapports de confiance sur le sujet
de la EE. Il en découle que seule la CA peut délivrer un certificat
ou lancer une révocation de certificat et générer une
CRL.
II.2. Gestion des clefs
L'utilisation de bi-clefs certifiés entraîne la nécessité
de la publication en toute confiance de la clef publique. Cette publication
doit assurer la validité de clé et l'appartenance de cette clé
à la bonne personne. La publication des certificats (des clefs publiques)
est faite en utilisant les structures d'annuaires de type LDAP (Lightweight
Directory Access Protocol) (RFC 2251), les certificats révoqués
sont regroupés dans des listes de révocations (CRL) qui sont
des structures de données signées et dont le format est défini
par le protocole X509 V2, ce format peut permettre une distribution des CRL
via les annuaires LDAP comme Netscape Directory Server d'iplanet ou bien
OpenLDAP.
Les certificats contiennent des informations obligatoires, comme le nom
du propriétaire et la durée de validité du certificat.
Ces données sont complétées par les informations demandées
au niveau de l'autorité de certification. La clé publique de
l'autorité de certification, récupérée le plus
souvent auprès de l'annuaire, est utilisée par le destinataire
pour authentifier le certificat.
II.3. Dépôt
Le dépôt est utilisé pour le stockage public des certificats
et des CRLs. Originellement, le dépôt était un annuaire
X.500. Habituellement, le dépôt utilisé avec la PKI est
un annuaire LDAP. Les annuaires LDAP sont spécialement supportés
par PKIX via les protocoles opérationnels. Bien que les opérations
avec un protocole de gestion comme le CMP (Certificate Management Protocol)
puissent fournir un support de requête pour obtenir certains certificats
ou des CRLs, LDAP peut être employé directement comme protocole
de consultation pour le même type d'information.
En plus du stockage des certificats et des CRLs, d'autres entrées
dans l'annuaire LDAP telles que les objets de CA peuvent être utilisées
pour stocker des informations additionnelles.
II.4. Publication et accessibilité des certificats
Pour que tout utilisateur puisse trouver le certificat d'un correspondant,
la PKI doit les rendre publiquement accessibles. Elle les poste pour cela
dans des annuaires, X.500 ou simplement «LDAP».
Les annuaires possèdent une structure en arbre qui facilite les recherches.
La PKI postera également dans les annuaires les Listes de Certificats
Révoqués (CRL), qui permettront aux applications clientes de
venir consulter l'état de validité d'un certificat.
Il est à la charge des applications d'implémenter LDAP pour
aller chercher les certificats et consulter les CRL. Un protocole pour consulter
les CRL est OCSP (Online Certificate Status Protocol), via un serveur qui
prend en charge cette vérification. La PKI n'a pas à se soucier
particulièrement de la sécurisation de ses communications avec
l'annuaire : les certificats ne sont pas confidentiels, et ils sont signés
(si un faux certificat remplace un vrai, les applications clientes invalideront
pas la signature). Il est cependant important de noter que la structure même
de l'annuaire peut être de nature confidentielle, si elle doit contenir
par exemple des informations sensibles d’utilisateurs. Le standard SASL, en
train d'émerger, permettra d'établir des communications sécurisées
avec les annuaires. La figure 3 présente l’exemple d’une structure
typique d'un annuaire afin d’intégrer la gestion des certificats.
Figure 3 : Configuration d’un annuaire LDAP pour gérer les certificats
II.5. Révocation des certificats (CRL)
Une PKI doit permettre de révoquer des certificats. Chaque certificat
possède un champ Serial Number, c'est ce numéro qui est inscrit
dans une liste des certificats révoqués (CRL) en cas de révocation.
Lorqu'une application cliente utilise un certificat, elle devrait consulter
la CRL. Si le numéro de série du certificat n'est pas présent,
c'est qu'il est valide.
Les CRL sont signées par l'AC et doivent être accessibles en
LDAP dans un annuaire.
Il faudra aussi prendre soin de bien spécifier les procédures
organisationnelles pour procéder à une révocation pour
:
- Qu'aucun certificat ne soit révoqué de façon non
légitime,
- Prévoir la méthode d'authentification des requêtes
de révocation...
- ...etc
II.6. Vérification des certificats et des signatures
Normalement, lors de chaque utilisation d'un certificat (chiffrement, vérification
de signature, authentification...) l'application qui l'utilise devrait en
vérifier la validité. Cela consiste à :
Vérifier la signature que le CA y a apposé (intégrité
et authenticité)
Vérifier qu'il est valide en vérifiant les dates de validité
Vérifier qu'il n'a pas été révoqué,
en allant consulter la CRL correspondante.
Dans le cas des simples AC, les clients étant les navigateurs, ils
n'ont pas aujourd'hui de fonctionnalités automatiques de consultation
de CRL, elle doit se faire manuellement... et c'est laborieux. OCSP est récemment
apparu sur Netscape 6, désactivé par défaut.
III. Le protocole LDAP pour les PKI
Un standard pour le développement d’une Infrastructure de clés
publiques pour Internet est spécifié dans le RFC 2559. Le standard
PKIX décrit le protocole basé sur LDAPv2 pour fournir un accès
aux dépôts des PKI dans le but d’assurer une gestion et une publication
des certificats et des CRLs.
Ce protocole définit notamment comment ajouter, effacer ou modifier
l’information sur ces supports de stockage.
Les entités d’extrémité et les CAs utilisent LDAPv2
pour consulter le service de dépôt et accéder aux informations
en utilisant un sous-ensemble du protocole LDAPv2.
Un profil du protocole définit la manière de récupérer
de l’information sur un dépôt et la gestion des informations
de PKI dans un dépôt.
III.1. Pourquoi la norme X.509 ?
Dans le cadre de l’authentification avec les annuaires, la norme X.509 fait
partie du standard OSI X.500 pour les annuaires. Il définit le modèle
des données d’un certificat (c’est-à-dire les attributs userCertificate,
caCertificate, crossCertificatePair, certificateRevocationList…).
Il définit des mécanismes pour l’authentification. Le certificat
inclut le DN de l’utilisateur et le DN du CA qui a signé le certificat.
Les évolution de la norme X.509 pour satisfaire les exigences de
PKIX sont les suivantes :
X.509v3(1997)
- Nouveau mécanisme d’extension
- Extensions prédéfinies :
- Des informations sur les clés : ID, utilisation…
- Des informations de politique : certificate policy,…
- Des extensions sur l’utilisateur et la CA : nom alternatif,…
- Des contraintes de chemin de certification
X.509v4(2000)
- Vérification des chaînes de certificats avec des CAs de différents
domaines et hiérarchies.
- Amélioration dans le domaine des révocations de certificat
- Nouvelles caractéristiques dans les certificats en attribut
- Définition de l’usage des certificats en attribut pour le
contrôle d’accès et l’autorisation d’accès
III.2. Le stockage des informations de PKI dans les annuaires LDAP
L’entrée d’une CA possède :
- son propre certificat auto-signé
- les certificats émis à cette CA par une autre CA
- les certificats émis par cette CA à une autre CA
- éventuellement, la CRL complète émise par cette CA
L’entrée d’un utilisateur possède :
- les certificats émis pour cet utilisateur
III.3. Le schéma LDAPv2
Le schéma défini dans le RFC 2587 est un support pour PKIX
dans un environnement LDAPv2. Il définit les classes d’objet auxiliaires
que doivent supporter les serveurs LDAP utilisés en tant que service
de dépôt de PKIX et que doivent comprendre et utiliser les clients
LDAP échangeant des messages avec les serveurs afin de chercher, ajouter
ou modifier des informations de PKI.
Les principaux objets de PKIX qui doivent être représentés
dans un service de dépôt sont :
- l’utilisateur
- la CA
Voici des classes d’objet standard pour les entrées LDAP et les types
d’attributs standards pour les informations :
- pkiUser OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND
auxiliary
MAY CONTAIN {userCertificate}
ID joint-iso-ccitt(2)
ds(5) objectClass(6) pkiUser(21)}
- pkiCA OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND
auxiliary
MAY CONTAIN {cACertificate |
certificateRevocationList |
authorityRevocationList |
crossCertificatePair }
ID joint-iso-ccitt(2)
ds(5) objectClass(6) pkiCA(22)}
III.3.1. L’ENTREE DE L’UTILISATEUR
Dans certains cas, l’entrée de l’utilisateur peut déjà
exister et l’information spécifique PKIX est alors ajoutée à
l’entrée existante. Dans les autres cas, l’entrée peut ne pas
exister avant l ‘émission du certificat, et dans ce cas, l’entité
qui ajoute le certificat dans le dépôt doit aussi y créer
l’entrée.
La classe d’objet auxiliaire pkiUser peut être utilisée pour
représenter les sujets des certificats dont l’attribut est userCertificate.
Un utilisateur peut obtenir un ou plusieurs certificats d’une ou plusieurs
CAs, stockés dans la même entrée de l’annuaire, par exemple.
L’attribut userCertificate doit être utilisé pour représenter
ces certificats dans l’entrée de l’annuaire représentant l’utilisateur
concerné.
III.3.2. L’ENTREE DE LA CA
Comme pour les utilisateurs, les CAs sont représentées dans
l’annuaire comme des éléments auxiliaires d’entrées qui
représentent un objet plus générique, tel que des organisations,
des unités organisationnelles, etc.
La classe d’objet auxiliaire pkiCA peut être utilisée pour
représenter les CAs dont les attributs sont caCertificate, crossCertificatePair,
certificateRevocationList, authorityRevocationList.
L’attribut caCertificate de l’entrée d’une CA dans un annuaire peut
être utilisé pour stocker les certificats auto-signés
(s’il y en a) et les certificats émis à ce CA par d’autres CAs
avec les mêmes moyens d’identification que ceux utilisés par
cette CA (utilisation des CRL).
Pour l’attribut crossCertificatePair, le nom de l’émetteur dans un
certificat doit correspondre au nom du sujet dans l’autre certificat et vice
versa.
L’attribut certificateRevocationList, s’il est présent dans une entrée
particulière de la CA, contient les CRLs.
III.3.3. LES ASPECTS SECURITE
Les CAs ont des exigences supplémentaires, notamment en ce
qui concerne la modification des informations de PKI. L’authentification
simple seulement, qui est supportée par LDAPv2, ne suffit pas pour
ces objectifs. Il est recommandé d’utiliser des moyens d’authentification
plus forts ou, si l’authentification simple est utilisée, des moyens
de protéger en confidentialité les mots de passe (c’est-à-dire
d’accepter les modifications uniquement via des réseaux physiquement
sécurisés, d’utiliser IPsec, un tunnel SSH ou TLS ou SSL).
Sans une telle authentification, il est possible qu’il y ait une attaque
de déni de service où l’attaquant remplace les certificats
valides avec des certificats corrompus.
Pour le service de modification des annuaires LDAP, il y a des considérations
de sécurité spécifiques liées aux contrôles
d’accès. Seul le CA a des permissions de contrôle d’accès
aux différentes entrées (CA, utilisateur).
III.4. Les insuffisances du protocole LDAP utilisé pour les infrastructures
de clés publiques
Le point important est l’utilisation globale des DNs. De ce fait, chaque
RelativeDN doit être unique. Les DNs doivent être lisibles lorsqu’ils
apparaissent dans les certificats avec des noms basés sur des chaînes
de caractères. PKIX et la norme X.509 suggèrent donc l’utilisation
d’un RDN bi-valué :
- un Common Name (cn) pour une lisibilité par l’utilisateur
- un Serial Number (sn) pour une valeur unique de DN
Il est notamment possible d’ajouter une adresse mail dans l’extension Subject
Alt Names du certificat afin d’aider à identifier le sujet du certificat.
III.4.1. LES LIMITATIONS DE LDAPV2
LDAPv2 ne possède qu’un nombre limité de schémas pour
le support d’authentification afin de se connecter au serveur, en particulier
l’utilisation de mot de passe chiffré ou de TLS, n’est pas supporté.
LDAPV2 ne supporte qu’un seul serveur d’annuaire alors que LDAPv3 définit
la communication entre serveur via le service de referral. Il est de la responsabilité
de l’utilisateur de pré-configurer son client LDAP avec l’ensemble
des serveurs LDAP requis, et de choisir le serveur approprié pour chaque
récupération de certificat et CRL.
LDAPv2 ne permet pas le transfert des certificats car ils sont convertis
en ASCII et sont modifiés. LDAPv3 définit les attributs
de PKI en attributs binaires (et tente de les changer en LDAPv2) : userCertifiate
; binary, caCerticate ; binary, certificateRevocationList ; binary, authorityRevocationList
; binary, etc.
Il n’est pas possible de chercher ou récupérer des certificats
particuliers si un utilisateur en possède plusieurs dans son entrée.
Dans LDAPv3, différents certificats sont stockés soit dans des
types d’attributs différents de l’entrée soit dans des entrées
différentes (entrées filles, sœurs ou des sous-arbres spécifiques
à une application).
C’est pour ces raisons que l’IETF a remplacé la standardisation du
protocole LDAPv2 par le protocole LDAPv3. Cependant le protocole LDAPv3 est
bien plus complexe que LDAPv2 et de nombreuses caractéristiques de
LDAPv3 ne sont pas essentielles dans l’utilisation de PKIX.
III.4.2. PROBLEMES DES ANNUAIRES DISTRIBUES
Les moyens de trouver les serveurs d’annuaires :
- L’utilisateur interroge en circuit fermé un ou plusieurs serveurs
d’annuaires
- Des liens de références pour lier les serveurs d’annuaires
ensemble
- Des extensions au certificat qui pointent vers les serveurs d’annuaires
Les referrals ou le chaînage pour transmettre les requêtes d’un
serveur à un autre
- Les referrals existent dans LDAPv3 (mais pas dans LDAPv2)
- Le chaînage LDAP est supporté par certains serveurs
La distribution de l’authentification quand les requêtes passent par
différents serveurs
III.4.3. LES SOLUTIONS EN TRAVAUX
Pour trouver les serveurs :
- L’utilisation du DNS SRV records
- La pré-configuration des clients avec les adresses des serveurs,
en dur
- L’ajout de références propriétaires à des
serveurs
Pour l’authentification distribuée :
- La configuration avec les username/password du client dans tous les serveurs
LDAP, ou pas d’authentification
- L’utilisation de serveurs proxy qui possèdent leur propre username/password
auprès des serveurs distants, et effectue un mappage des noms locaux
III.4.4. LES SOLUTIONS FUTURES POUR JOINDRE LES SERVEURS
L’utilisation des extensions de certificat définies par PKIX :
- Authority Information Access pour aller vers les CA supérieures
- Subject Information Access pour aller vers les CA de certification croisée
III.4.5. LES SOLUTIONS FUTURES POUR L’AUTHENTIFICATION DISTRIBUEE
X.500 supporte 3 mécanismes :
- les opérations signées
- les requêtes chaînées
- l’utilisation de l’opération de comparaison pour le username/password
LDAP ne supporte actuellement pas :
- les opérations signées
- le chaînage
- la comparaison mais les serveurs peuvent être implémentés
afin de supporter cette opération
Cependant, LDAP pourrait utiliser le dispositif de proxy qu’offre SASL pour
qu’un serveur local LDAP puisse valider l’identité de l’utilisateur
auprès d’un serveur LDAP distant.
La méthode de proxy SASL est ajoutée à OpenLDAP mais
un certain nombre de problèmes apparaissent :
- Si le premier serveur est , d’abord, compromis, alors un accès
non-autorisé au second serveur est réalisé
- Des connexions SASL séparées entre les deux serveurs sont
requises pour chacune des requêtes du client. Pour résoudre ce
problème, un nouveau contrôle sur l’identité de l’utilisateur
devra être ajouté pour chaque requête LDAP. L’identité
du client devra à nouveau être présentée lors de
l’accès à un autre serveur.
III.5. Un schéma LDAPv3 pour les certificats X.509
Le schéma LDAPv3 offrira des solutions aux problèmes rencontrés
avec LDAPv2 pour la recherche et la récupération de certificats
et de CRLs
Les CAs peuplent les annuaires avec les informations de PKI en utilisant
un sous-ensemble du protocole LDAPv3.
III.5.1. POURQUOI? LES MOTIVATIONS
1)Problème d’avoir plusieurs certificats pour une entité :
comment le client peut-il trouver le bon certificat? Il faut alors spécifier
le CA générateur.
2)Trouver une manière facile et simple d’implémenter une solution
3)La solution devrait être utilisable dans le cadre d’un annuaire
LDAP distribué à large échelle basé sur les certificats
III.5.2. LES DISPOSITIFS DE LDAPV3
LDAPv3 supporte les assertions de valeurs d’attribut multiples dans les
composants des RDN et l’ordre des ces valeurs n’est pas déterminant.
Par exemple, cn=John+serialNumber=123 est la même chose que serialNumber=123+cn=John.
LDAPv3 inclut le concept de notification de déconnexion qui peut
être envoyée par le serveur au client. Celle-ci est utilisée
par le serveur pour notifier au client qu’il est en panne, de telle sorte
que le client puisse distinguer entre une panne dans le réseau et
une panne du serveur.
L’attribut altServer est utilisé par les serveurs pour pointer vers
des serveurs alternatifs qui peuvent être contactés si ce serveur
est temporairement indisponible. Cet attribut doit se trouver sur l’entrée
rootDSE du serveur et doit être disponible et accessible au client lors
d’une recherche. S’il n’existe pas de serveurs alternatifs, cet attribut doit
pointer sur le serveur lui-même.
Dans un annuaire distribué avec plusieurs serveurs, LDAPv3 supporte
le mécanisme de referrals pour permettre à un serveur, qui ne
peut pas satisfaire la requête d’un client, de référer
le client à un autre serveur qui est susceptible de satisfaire sa requête.
Le protocole LDAPv3 est infiniment extensible grâce à deux
mécanismes : les opérations étendues et les contrôles
sur les opérations existantes (extended operations, controls).
III.5.3. LE SCHÉMA LDAPV3 : UNE SOLUTION SIMPLE
La standardisation menée par l’IETF sur le protocole LDAPv3 propose
un ensemble de champs du certificat et des extensions susceptibles d’étre
recherchés : approche méta-donnée.
Il faut ensuite pouvoir analyser le certificat et stocker l’ensemble des
éléments dans des attributs LDAP.
III.5.3.1. La classe d’objet auxiliaire du certificat X.509
La définition de la classe d’objet représentant un certificat
X.509 est la suivante :
x509certificate object class
( 1.3.6.1.4.1.10126.1.5.4.2.1
NAME 'x509certificate'
STRUCTURAL
MUST ( x509serialNumber $ x509signatureAlgorithm
$ x509issuer $
x509validityNotBefore
$ x509validityNotAfter $ x509subject $
x509subjectPublicKeyInfoAlgorithm
)
MAY ( mail $ x509subjectKeyIdentifier
$ x509keyUsage $
x509policyInformationIdentifier
$
x509subjectAltNameRfc822Name
$ x509subjectAltNameDnsName $
x509subjectAltNameDirectoryName
$ x509subjectAltNameURI $
x509subjectAltNameIpAddress
$ x509subjectAltNameRegisteredID $
x509isssuerAltNameRfc822Name
$ x509isssuerAltNameDnsName $
x509isssuerAltNameDirectoryName
$ x509isssuerAltNameURI $
x509isssuerAltNameIpAddress
$ x509isssuerAltNameRegisteredID $
x509extKeyUsage $ x509cRLDistributionPoint
) )
III.5.3.2. Les règles additionnelles
Les nouvelles règles de correspondance tirées de la norme
X.509 :
- Certificate Equality Match
- Certificate flexible matching
- CRL Equality Match
- CRL flexible matching
- Rules for Attribute Certificates
Certificate Equality Match
L’utilisateur fournit :
- Le Numéro de Série du certificat et
- Le Nom de l’Emetteur
Certificate Match
L’utilisateur donne est un des attributs suivants :
- Le Numéro de Série du certificat
- Le Nom de l’Emetteur
- La Validité du certificat
- La Validité de la clé privée
- L’ID de la clé du Sujet du certificat
- L’ID de la clé de l’Autorité
- L’ID de l’algorithme de la clé publique du sujet
- Le Nom du sujet
- Etc.
CRL Equality Match
- Nom de l’émetteur de la CRL
- La date d’émission
CRL Match
- Le Nom de l’émetteur de la CRL
- Le nombre de CRL minimum
- Le nombre de CRL maximum
- La raison de la révocation
- La date de la révocation
- Le point de distribution de la CRL
- L’ID de la clé de l’autorité
Les entrées doivent avoir une des deux classes d’objet auxiliaires
suivantes :
- pkiUser
- pkiCA
De cette manière, l’entrée contiendra le certificat binaire
dans un des deux attributs suivants :
- userCertificate
- caCertificate
Structure du DIT dans un annuaire de personne, par exemple :
Structure DIT dans un dépôt de certificats :
III.5.3.3. Les aspects de sécurité du protocole LDAPv3
Les informations de PKI recherchées dans les serveurs LDAPv3 (certificats
et CRLs) sont signées numériquement et pour cette raison des
services d’intégrité supplémentaires ne sont pas
forcément requis. Cependant, les clients qui recherchent des CRLs,
n’ont pas de moyen de vérifier l’identité du serveur.
IV. Références
Internet X.509 Public Key Infrastructure Certificate Management Protocols
(RFC 2510), C. Adams, S. Farrell, mars 1999.
http://www.ietf.org/rfc/rfc2510.txt
Internet X.509 Public Key Infrastructure LDAPv2 Schema (RFC 2587), S. Boeyen,
T. Howes, P. Richard, juin 1999.
http://www.ietf.org/rfc/rfc2587.txt
Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2
(RFC 2559), S. Boeyen, T. Howes, P. Richard, avril 1999.
http://www.ietf.org/rfc/rfc2559.txt
Internet X.509 Public Key Infrastructure Operational Protocols – LDAPv3,
D. W. Chadwick, janvier 2002.
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-v3-05.txt
Ce document décrit les dispositifs du protocole LDAPv3 nécessaires
pour mettre en place une infrastructure de clés publiques basée
sur les certificats X509 et les CRLs
Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PKIs,
D. W. Chadwick, juin 2002.
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pki-schema-00.txt
LDAPv3 DN strings for use with PKIs, D. W. Chadwick, avril 2002.
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dnstrings-00.txt
Slides présentation LDAP
http://database.sarang.net/database/ldap/presentation/sld001.htm