Spécification du couplage de LDAP et DNSsec pour la publication de clés publiques

Version 4
Auteurs : Maryline Maknavicius-Laurent, Francis Dupont
Date : octobre 2003
URL : http://www-lor.int-evry.fr/~maknavic/CADDISC/

1. Le nommage dans CADDISC

Le domaine enst.idsa.prd.fr bénéficiant des fonctionnalités DNSsec et étant donc signé, il apparaît intéressant que les écoles du GET soient rattachées à ce domaine là, comme suit :
- INT : int-evry.caddisc.enst.idsa.prd.fr
- ENST de Bretagne : enst-bretagne.caddisc.enst.idsa.prd.fr
- ENIC : enic.caddisc.enst.idsa.prd.fr
- ENST : enst.caddisc.enst.idsa.prd.fr
Par la suite, nous prenons l'exemple de l'INT et la notation suivante :
'int-evry.DNSsec'='int-evry.caddisc.enst.idsa.prd.fr'

2. Le schéma de certification

Pour des raisons pratiques, nous considérons que l'INT dispose d'une seule CA (INT root CA) qui a son certificat enregistré dans le serveur int-evry.DNSsec et l'annuaire LDAP de l'INT. Il est tout à fait possible et même recommandé d'avoir une hiérarchie de CA à deux niveaux : un CA racine et un autre CA de classe 1 (INT class1 CA) habilité par le CA racine à gérer les certificats du personnel de l'INT. Pour des raisons d'ordre pratique, pour éviter de devoir gérer plusieurs logiciels OpenCA, nous avons opté pour une seule CA. Notez que le certificat de classe 1 devrait alors être enregistré dans l'annuaire LDAP uniquement. Les certificats à utiliser sont présentés dans l'annexe 1.

Le CA racine gère ici l'ensemble des certificats des personnels et machines de l'INT. Pour assurer un chemin de certification continu entre DNSsec et LDAP, il faut veiller au contenu des champs issuerAltName et subjectAltName des certificats qui doivent identifier l'annuaire de publication des certificats du CA et du détenteur.
Le contenu des bases DNSsec et LDAP est donné ci-dessous, mais uniquement pour les aspects certificat :

- le serveur DNSsec de l'INT :
Le certificat du CA racine de l'INT dans un CERT RR avec nom de domaine int-evry.DNSsec

Le certificat du CA racine contient :
issuer : cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR
issuerAltName : DNS:int-evry.DNSsec, URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?cACertificate?
subject : cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR
subjectAltName : DNS:int-evry.DNSsec, URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?cACertificate?

- le serveur LDAP de l'INT :
Le certificat du CA racine

Le certificat de l'utilisateur contient :
   issuer : cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR
   issuerAltName : DNS:int-evry.DNSsec, URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?cACertificate?
   subject : cn=userName,ou=PKI,o=INT, c=FR
   subjectAltName : userName@int-evry.fr (rfc822Mailbox)
   cRLDistributionPoint : URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?certificateRevocationList?

Figure 1 : Base LDAP de l'INT

Noter que les chemins des entrées dans l'exemple ci-dessus sont tout à fait indicatifs, l'essentiel étant de faire apparaître le bon chemin dans les champs issuerAltName, subjectAltName, et cRLDistributionPoint des certificats.

3. La base LDAP

Il n'est pas important que les certificats du personnel/machine soient disponibles dans un chemin particulier de la base. La recherche LDAP pourra être étendue à l'arbre entier.
Logiquement l'entrée définie par c=FR,o=INT,ou=PKI de la classe pkiUser pourra comprendre un sous-arbre contenant les certificats du personnel et des machines (e.g. serveur SCVP , serveur web). Dans ce sous-arbre, l'entrée c=FR,o=INT,ou=PKI,cn=user correspondra à un utilisateur du site et comprendra l'ensemble des certificats de cet utilisateur, le domaine d'application de ces certificats étant précisé dans le certificat (champ KeyUsage). De la même façon, l'entrée c=FR,o=INT,ou=PKI,cn=machine correspondra à une machine du site et comprendra les certificats associés à cette machine.
L'entrée définie par c=FR,o=INT,ou=PKI-CA,cn=CADDISC INT root CA pourra comprendre les certificats de l'autorité CA racine.

4. Le protocole SCVP

Le protocole SCVP (Simple Certificate Validation Protocol) (draft-ietf-pkix-scvp-12) permet à une application intégrant un client SCVP de vérifier la validité d'un certificat et la chaîne de certification en interrogeant un serveur SCVP.

La requête SCVP peut comprendre les certificats à vérifier et la réponse SCVP, les statuts de ces certificats ainsi qu'une signature portant sur la réponse. La signature peut être générée par le responder SCVP dont la clé est certifiée par le CA racine. Le certificat du responder SCVP doit préciser sa fonction de responder SCVP dans le champ extKeyUsageSyntax de son certificat.

Le certificat du serveur SCVP contient :
   issuer : cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR
   issuerAltName : DNS:int-evry.DNSsec, URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?cACertificate?
   subject : cn=INT SCVP responder,ou=PKI,o=INT,c=FR
   subjectAltName : URI:ldap://pivert.int-evry.fr:9009/cn=pivert.int-evry.fr,ou=PKI,o=INT,c=FR?userCertificate?
   cRLDistributionPoint : URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?certificateRevocationList?
   extKeyUsageSyntax : id-kp-SCVPSigning # vraisemblablement, étant donné que SCVP n'est pas encore standardisé

5. L'architecture retenue pour la vérification des certificats

Les efforts de développements de CADDISC portent sur le serveur SCVP. Ainsi la vérification des certificats sera faite de façon centralisée. Le serveur SCVP intègre un client DNSsec et un client LDAP. Suivant les certificats à charger, le serveur LDAP ou le resolver DNSsec sera interrogé.

Figure 2 : Architecture SCVP

6. La vérification de certificats

Le responder SCVP vérifie d’abord que le certificat ne fait pas partie d’une liste de révocation de certificats (CRL). Pour cela, il va chercher la liste CRL dans la base LDAP à l’adresse à l'adresse URI mentionnée dans le champ cRLDistributionPoint du certificat.
Ensuite, le serveur effectue la vérification de certificats en deux phases, une phase ascendante pour récupérer les certificats et une phase descendante de vérification des signatures. Dans la phase ascendante, deux étapes sont nécessaires. Tout d’abord, le serveur SCVP remonte la chaîne de confiance depuis le certificat à vérifier jusqu’au CA racine en faisant appel à LDAP. Puis il passe le relais à un resolver DNSsec qui va lui retourner un certificat vérifié au sens de DNSsec. Il n’aura plus qu’à vérifier que ce certificat est le bon. Enfin, il n’aura plus qu’à vérifier les signatures des certificats.

7. D'autres applications possibles de CADDISC

Certaines applications ne transportent pas de certificats mais se contentent de donner une référence, comme IKEv2 (draft 5) de la suite IPsec. Pour ces applications, les certificats doivent être publiés dans des annuaires accessibles.

8. Langage de programmation

La programmation du serveur SCVP se fera en C comme les développement DNSsec de l'ENST de Bretagne.

9. Références

Maryline Maknavicius-Laurent, Michel Gardie, " LDAP et la certification ", Version 2.1, SP1.1 du projet CADDISC, février 2003.
Francis Dupont, " DNSsec et la certification ", Version 1, SP1.2 du projet CADDISC, février 2003.
M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, " X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP ", rfc 2560, June 1999.
R. Housley, W. Ford, W. Polk, D. Solo, " Internet X.509 Public Key Infrastructure Certificate and CRL Profile ", rfc2459, January 1999
T. Howes, M. Smith, " The LDAP URL Format ", rfc 2255, December 1997.
C. Kaufman, " Internet Key Exchange (IKEv2) Protocol ", draft-ietf-ipsec-ikev2-05.txt, February 2003.
R. Housley, W. Polk, W. Ford, D. Solo, " Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile ", rfc 3280, April 2002.
Paul Albitz, Cricket Liu, " DNS et Bind ", 4e édition, O'Reilly, ISBN : 2-84177-150-4, janvier 2002, pp. 486.
A. Malpani, R. Housley, T. Freeman, "Simple Certificate Validation Protocol (SCVP) ", draft-ietf-pkix-scvp-12.txt, June 2003.

Annexe 1 : Les certificats dans le cas d'une hiérarchie de CA à 2 niveaux

- le serveur LDAP de l'INT :
Le certificat du CA racine

Le certificat du CA de classe 1 contient :
issuer : cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR
issuerAltName : DNS:int-evry.DNSsec, URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?cACertificate?
subject : cn=CADDISC INT Class 1 CA,ou=PKI-CA,o=INT,c=FR
subjectAltName : URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT Class 1 CA,ou=PKI-CA,o=INT,c=FR?cACertificate?
cRLDistributionPoint : URI:ldap://pivert.int-evry.fr/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?certificateRevocationList?

Le certificat de l'utilisateur contient :
   issuer : cn=CADDISC INT class 1 CA,ou=PKI-CA,o=INT,c=FR
   issuerAltName : DNS:int-evry.DNSsec, URI:ldap://pivert.int-evry.fr:9009/cn=CADDISC INT root CA,ou=PKI-CA,o=INT,c=FR?cACertificate?
   subject : cn=userName,ou=PKI,o=INT, c=FR
   subjectAltName : userName@int-evry.fr (rfc822Mailbox)
   cRLDistributionPoint : URI:ldap://pivert.int-evry.fr/cn=CADDISC INT class 1 CA,ou=PKI-CA,o=INT,c=FR?certificateRevocationList?

Annexe 2 : La certification au GET

On suppose que les écoles du GET disposent chacune d'un CA racine et d'une hiérarchie de CA en interne. Dans ce rapport, un seul CA est défini sous l'autorité du CA racine, mais il n'y a aucune contre-indication pour qu'une hiérarchie de CA à plusieurs niveaux soit définie. Le chemin de certification sera plus long et donc le responder SCVP devra vérifier un plus grand nombre de certificats.

Figure 3 : Organisation des CA au GET

Annexe 3 : Un certificat pour le serveur LDAP ?

Pour la publication de certificats, le serveur LDAP n'a pas besoin de posséder de clés publiques/privées. Le certificat garantit à lui seul la sécurité de son contenu. Par contre, pour la publication d'autres types d'informations (e.g. relatives au personnel...), il est intéressant que le serveur LDAP dispose d'un certificat (c=FR, o=INT, cn=rootDSE). Cela lui permettra d'assurer l'authenticité et l'intégrité des informations publiées.