PKI au-delà  de l’entreprise

supporter un
nombre illimité de niveaux de CA ;
Microsoft a utilisé jusqu’à  35 niveaux
dans ses tests.)

Le modèle CA hiérarchique présente
un sérieux inconvénient. Vous ne
pouvez pas facilement utiliser le modèle
pour établir des relations d’approbation
au-delà  des limites de l’entreprise. Cette incapacité est due essentiellement
au fait que le modèle hiérarchique
ne supporte pas la subordination
qualifiée – un mécanisme qui
définit et impose les règles de politique
de sécurité CA à  partir d’un CA
parent pour restreindre les pouvoirs
d’un CA subordonné.

La PKI .NET Server supporte à  la
fois la certification croisée et la subordination
qualifiée et procure ainsi un excellent moyen d’établir des relations
d’approbation de certificats avec les CA
de vos partenaires extranet. Le CA de
votre société peut émettre des certificats
destinés aux CA de vos sociétés
partenaires et réciproquement. Toutes
les parties peuvent intégrer des règles
dans leur certificat de certification croisée
pour en limiter le domaine d’émission
et d’utilisation.

Certification croisée et extranets sécurisés. Le modèle de confiance de
la PKI hiérarchique n’est pas conçu pour
établir des relations d’approbation audelà 
de l’entreprise. Il est difficile de mapper
un modèle de PKI hiérarchique pour
sécuriser des extranets. Dans une
structure d’extranet sécurisé classique,
chaque entité participante utilise son
CA ou sa hiérarchie de CA. La plupart des
sociétés ont aussi des politiques de
sécurité de CA différentes.

Le seul moyen d’établir l’interopérabilité
PKI NT entre des sociétés
consiste à  les inclure dans une hiérarchie.
Comme tous les participants ont
peut-être déjà  une hiérarchie ou un CA
en place, cette exigence signifie qu’il
faut complètement reconstruire l’infrastructure
de confiance de la PKI. Avec
la PKI Win2K, vous pouvez aussi utiliser
des listes de confiance de certificat.
Les CTL sont une fonction à  base de
GPO (Group Policy Object) qui permet
de distribuer des certificats CA dans
une forêt Win2K et de marquer ces certificats
comme trusted pour une certaines
période ou pour certaines applications
qualifiée PKI.

La certification croisée que permet
la PKI .NET Server offre une manière
beaucoup plus souple de sécuriser les
extranets et de définir les relations
d’approbation de la PKI. Dans une hiérarchie
CA, la certification est unidirectionnelle
: un CA parent émet un certificat
destiné à  un CA subordonné.
Dans une certification croisée, la certification
est bidirectionnelle : les deux
CA émettent des certificats l’un vers
l’autre. La PKI .NET Server supporte la
certification croisée sous deux formes
basiques. La subordination qualifiée se
produit entre des CA qui font partie de
la même société (ou de la même forêt,
en terminologie AD) ; la vraie certification
croisée se produit entre des CA
qui appartiennent à  des organisations
différentes (ou à  des forêts différentes). Pour savoir comment la
certification croisée affecte les utilisateurs
de PKI, voir l’encadré «
Certification croisée et l’utilisateur des
PKI ».

La génération d’un certificat de
certification croisée .NET Server se fait
en trois étapes. Premièrement, vous
créez une spécification de policy et l’intégrez
dans un fichier de configuration
capolicy.inf. Capolicy.inf est un fichier
de configuration à  base de texte que
vous devez créer manuellement ; vous
pouvez facilement le modifier dans un
éditeur de texte comme Bloc-Notes.
Vous pouvez stocker le fichier à  l’endroit
de votre choix, à  la condition de
pouvoir y accéder au moyen de l’utilitaire
ligne de commande Certreq.

Deuxièmement, vous utilisez Certreq, le fichier capolicy.inf et une requête
de certificat CA au format Public-
Key Cryptography Standards #10
(PKCS #10) pour générer un message
au format CMS (Cryptographic
Message Syntax). (PKCS #10 et CMS
sont deux standards qui définissent le
format des messages cryptographiques.)

Troisièmement, le CA génère le
certificat de certification croisée en utilisant
le message au format CMS. (Pour
plus d’informations sur la certification
croisée et la subordination qualifiée,
voir l’information mise à  jour consultable
à  http://www.microsoft.com/windows.
netserver.)

Subordination qualifiée et imposition
de la policy CA. Dans les PKI Win2K et NT, la relation d’approbation
entre un CA parent et un CA subordonné
est complète, c’est-à -dire
qu’une fois que le CA parent a émis un
certificat CA subordonné, le CA subordonné
peut émettre des certificats –
sans restrictions. La PKI .NET Server
offre la subordination qualifiée, avec
des moyens pour définir et imposer
des contraintes de noms, la policy
d’application et les règles de policies
d’émission. (Pour une brève explication
de ces règles, voir l’encadré
« Règles de policy de PKI .NET
Server ».)

Vous pouvez utiliser les modèles
de certificats version 2 de .NET Server
pour définir les règles de restriction de
policy pour les certificats utilisateur,
machine, CA subordonné et service.
(Pour plus d’informations sur les modèles
de certificats version 2, voir l’encadré
« Modèles de certificats version
2 »). Vous devez définir toutes les restrictions
de policy pour les certificats
de certification croisée au moyen du fichier
capolicy.inf.