Support de S/MIME

ce contrôle téléchargé
par les utilisateurs, le formulaire
New Message utilise le protocole
S/MIME pour créer des messages. A
noter que cette fonctionnalité requiert
IE 6.0 et Windows 2000 ou ultérieur –
faute de quoi, l’option de téléchargement
n’apparaîtra pas. Le support de
l’OS de base est nécessaire parce que
le cryptage et le décryptage s’effectuent
par le biais de l’application
Windows CryptoAPI standard.
L’OWA utilise le protocole S/MIME
3 pour le cryptage et la signature, mais
il permet aussi la lecture, la réponse à 
et la retransmission des messages
e-mail qui sont signés numériquement
ou cryptés conformément au
protocole S/MIME 2. Voir Internet
Engineering Task Force (IETF) Request
f o r C o m m e n t s ( R F C ) 2 6 3 3
(http://www.rfc-editor.org/rfc/rfc2633.
txt) pour la spécification des messages
S/MIME 3. A noter que OWA supporte
la signature et le cryptage des seuls
messages e-mail. Pas ceux des
messages de calendrier ou d’agenda,
comme des demandes de réunion.
L’OWA utilise le cryptage par clé
publique pour signer numériquement
et crypter des messages. Par conséquent,
une PKI (public key infrastructure)
doit être en place et les utilisateurs
de l’OWA doivent y être inscrits
avec des certificats valides. L’OWA utilise
la clé publique du destinataire
(contenue dans son certificat) pour
crypter les messages. L’OWA extrait ces
certificats à  partir d’AD (Active
Directory) ou des contacts stockés
dans la boîte à  lettres de l’utilisateur.
(Contrairement à  Outlook, l’OWA n’assume
aucune gestion de certificats,
comme créer un contact à  partir de
l’envoyeur du message et stocker le
certificat avec le contact.) OWA peut
crypter le e-mail adressé à  des groupes
Active Directory et à  des listes de distribution
(DL, distribution lists) personnelles
stockées dans le dossier
contacts d’un utilisateur. Quand un utilisateur
ajoute des destinataires à  une
fenêtre de création d’un nouveau message,
Exchange résout les adresses des
destinataires, extrait leurs certificats, et
utilise leurs clés publiques pour crypter
le message. Exchange effectue
toute la validation de certificats
(comme la vérification de la CRL – certificat
revocation list – pour s’assurer
que chaque certificat est encore valide)
afin que le client n’interagisse pas directement
avec le PKI sur Internet.
Si un destinataire n’a pas un certificat
valide, Exchange en avertit l’émetteur
du message et lui donne la possibilité
d’envoyer le message – bien que
le destinataire n’ait pas le moyen de le
décrypter et de le lire. En visualisant les
propriétés d’un destinataire à  partir de
la liste d’adresse globale, illustrée figure
3 on voit si le destinataire a un
certificat valide et peut lire des messages
cryptés.
L’envoyeur doit aussi posséder un
certificat numérique valide pour pouvoir
signer un message. D’ailleurs le
contrôle S/MIME s’assure auprès de
Win2K que l’envoyeur a un certificat.
Vous pouvez ranger le certificat dans le
stockage de certificats local (ou en un
point quelconque accessible par l’application
CryptoAPI) ou sur une carte
intelligente, en supposant qu’un lecteur
de carte intelligente de type
Windows équipe la machine sur laquelle
l’OWA s’exécute. Si l’OWA ne
peut pas trouver un certificat de type
logiciel valide, il invite l’utilisateur à  insérer
toute ID de type matériel en sa
possession.
Les utilisateurs peuvent se servir
des options par défaut pour la signature
et le cryptage, ou utiliser les deux
boutons qui apparaissent sur le formulaire
de création d’un nouveau message.
Les options sélectionnées par
l’utilisateur sont stockées dans les propriétés
http://schemas.microsoft.com/
exchange/smimesign et http://schemas.
microsoft.com/exchange/smimee
ncrypt dans la boîte à  lettres de l’utilisateur.
Les administrateurs peuvent
aussi forcer la signature et le cryptage
des messages en mettant à  1 les valeurs
des registres alwaysSign et always-
Encrypt (de type REG_DWORD). Vous
trouverez ces valeurs dans la sous-clé
HKEY_LOCAL_MACHINE\SYSTEM\Cur
rentControlSet\Services\MSExchangeOWA sur le serveur Exchange.
Le contrôle S/MIME interagit avec
la fenêtre de création d’un nouveau
message. Les messages créés par le
biais de cette fenêtre ont une classe de messages différente des autres messages.
(Les clients e-mail comme
Outlook utilisent la classe d’un message
principalement pour déterminer
comment afficher le message – par
exemple, IPM.NOTE.SMIME au lieu de
l’habituel IPM.NOTE). Les autres
classes de messages qui apparaissent
quand le contrôle S/MIME est en vigueur
sont IPM.NOTE.SMIME.MULTIPARTSIGNED
(par exemple, quand un
attachement existe) et REPORT.
IPM.Note.SMIME.MultipartSigned.IPN
RN (par exemple, pour une réception
de lecture générée à  partir d’un message
sécurisé). Comme Outlook utilise
les mêmes classes de messages, le traitement
des messages S/MIME avec
Outlook ou de l’OWA est entièrement
pris en charge.
La présence du contrôle S/MIME
ouvre la porte à  un autre genre de traitement
parce que les messages MIME
entièrement formés sont désormais
construits sur le client et soumis au
serveur. Cette approche permet de
faire glisser les attachements dans une
fenêtre Create message et simplifie le
traitement des attachements. Sans le
contrôle S/MIME (disponible uniquement
avec le premium client), vous devez
consulter les attachements et choisir
ceux que vous voulez ajouter ou
enlever du message. Avec le contrôle
S/MIME, vous pouvez utiliser un clic
pour attacher un fichier, ou faire un
clic droit sur un fichier et l’enlever en
utilisant le menu contextuel qui apparaît.
Vous pouvez aussi faire glisser des
images directement dans le corps d’un
message, copier des images de pages
Web, et même faire glisser un message
de la vue du dossier dans l’OWA et l’incorporer
directement dans le nouveau
message.