Composants de la gestion des clés

la clé publique ne doit jamais
quitter sa machine – après tout, quiconque
possède une copie peut se faire
passer pour Charlie. (Idéalement,
Charlie utiliserait une carte intelligente
ou autre dispositif matériel ; ces dispositifs
génèrent la paire de clés en interne
et la clé publique n’est jamais visible
hors du dispositif.) Muni d’une paire de
clés, Charlie doit générer une demande
de certificat et l’envoyer à  son émetteur
de certificats. Celui-ci, ou la CA
(Certificate Authority), est chargé de valider
la requête et de décider l’envoi, ou
non, du certificat demandé. La plupart
des installations Exchange utilisent Microsoft Certificate Services, mais vous
pouvez aussi utiliser un CA tierce partie,
comme ceux qu’offrent le United States
Postal Service et VeriSign.

Après avoir émis un certificat, la CA
le publie généralement dans un stockage
de certificats. Dans le cas de
Charlie, le stockage pourrait être le répertoire
Exchange 5.5 ou AD (Active
Directory), selon la CA qui a émis le certificat.
Donna peut désormais rechercher
Charlie dans la GAL (Global
Address List) et extraire son certificat,
obtenant ainsi sa clé publique et instaurant
des communications sécurisées
avec lui.

Le puzzle comporte une autre pièce.
Exchange ne sait rien des systèmes à  clés
publiques – c’est un serveur de mail et de
collaboration. De même, la CA ne sait
rien du e-mail. Intervient ici le Exchange
KMS (Key Management Server). Le KMS
génère des clés pour les utilisateurs, maintient des sauvegardes de cryptage
privé et de clés de signatures publiques,
et maintient la CRL (certificate revocation
list), que les clients utilisent pour contrôler
la validité des certificats. Le KMS fournit
le lien entre la CA et le client e-mail.