Résumé

  • RFC 1421 installait la protection PEM aux extrémités, au niveau de l’agent utilisateur ou au-dessus. Les relais SMTP existants pouvaient transporter l’objet sans comprendre sa cryptographie, et les champs ajoutés ou transformés entre les extrémités restaient hors de la protection.
  • MIC-CLEAR fournissait le même choix d’authentification et d’intégrité que MIC-ONLY, mais supprimait l’encodage imprimable destiné à résister aux modifications du système de messagerie. Le texte demeurait lisible sans logiciel PEM ; sa signature, elle, ne devenait pas vérifiable pour autant.
  • Le MIC portait sur une forme canonique ASCII terminée par CRLF. Une transformation banale et non réversible pouvait donc provoquer un échec réel sans prouver à elle seule une attaque. Résultat cryptographique, cause et qualification de sécurité étaient trois faits différents.

La sécurité du courrier électronique ancien ne se jouait pas seulement dans une clé. Elle se jouait dans le trajet séparant la phrase que l’on voyait de la suite d’octets que l’on prétendait avoir signée.

En 1993, ce trajet traversait un système déjà peuplé. Les agents utilisateurs composaient des messages dans leurs formats locaux. Les serveurs les relayaient. Des passerelles changeaient d’environnement. Les conventions de fin de ligne variaient. Les mécanismes de transfert pouvaient encapsuler, annoter ou réexpédier. Exiger d’abord le remplacement de l’ensemble aurait condamné le service de confidentialité avant sa première adoption.

RFC 1421 choisit donc une superposition de bout en bout. L’émetteur traitait le corps près de son agent utilisateur ; le destinataire le décodait et le contrôlait à l’autre extrémité. Les relais intermédiaires n’avaient pas à devenir des processeurs PEM. Un site pouvait ajouter le service localement sans obtenir l’autorisation technique de tous les nœuds du chemin.

Cette liberté reposait sur une limite nette. Les champs ajoutés ou modifiés par les relais n’étaient pas couverts. La protection visait le texte encapsulé, pas tout ce qu’un lecteur pouvait associer au message : ni l’ensemble de l’enveloppe, ni chaque ligne de trace, ni le chemin réellement emprunté.

Un même courrier possédait ainsi plusieurs chronologies. SMTP enregistrait des acceptations successives. Les en-têtes extérieurs accumulaient des transformations. L’objet PEM conservait sa propre grammaire. Enfin, le destinataire produisait un verdict de contrôle. Les appeler tous « message sécurisé » aurait détruit la capacité de comprendre un échec.

Le transport commun n’avait pas à devenir un juge

Le pari de déploiement était modeste au sens fort. RFC 1421 confinait le nouveau mécanisme aux extrémités et refusait de le transformer en obligation pour les serveurs SMTP. Il cherchait à augmenter les possibilités de l’utilisateur, non à l’empêcher d’envoyer du courrier ordinaire. Le texte reconnaissait qu’un agent utilisateur entièrement digne de confiance n’était pas une hypothèse générale.

Cette répartition protégeait l’adoption. L’exploitant d’un relais gardait son outil. Le développeur d’une extrémité pouvait expérimenter. Mais la charge n’avait pas disparu : l’émetteur devait connaître les capacités du destinataire, et les deux extrémités devaient partager un mécanisme de clés et une interprétation des transformations.

Une adresse acceptée par SMTP n’annonçait pas la présence de PEM. Un 250 à la suite de RCPT TO établissait une étape de transport, pas la capacité du logiciel final à décoder, déchiffrer ou vérifier. Le format commun ne fabriquait pas une relation de sécurité à partir d’une relation de livraison.

Le document énumérait aussi les problèmes laissés de côté : contrôle d’accès, confidentialité du flux, exactitude de la liste d’adresses, maîtrise du routage, preuve ou non-répudiation de réception, rattachement automatique d’un accusé, détection des doublons et prévention du rejeu. Cette liste empêchait la cryptographie du corps de devenir une affirmation générale sur le courrier.

Le MIC portait sur une reconstruction

Le point de départ était une forme locale : jeu de caractères, représentation des lignes et stockage propres à la machine. Le traitement PEM la convertissait en une forme canonique inspirée de l’inter-SMTP, composée d’ASCII avec des fins de ligne CRLF. Le bourrage de points propre à SMTP n’appartenait pas à cette forme.

Le MIC était calculé sur ces octets canoniques. Le chiffrement, s’il était choisi, partait du même objet. RFC 1421 résumait la chaîne générale par Encode(Encrypt(Canonicalize(Local_Form))), en retirant les étapes inutiles selon le type de message. À l’arrivée, l’extrémité effectuait les opérations inverses avant de produire sa forme locale.

Cette architecture rendait possible l’échange entre machines différentes. Elle ne signait pas une idée abstraite. Deux écrans pouvaient montrer des paragraphes visuellement identiques tout en soumettant des octets différents au MIC. Inversement, le texte transporté pouvait avoir reçu un emballage différent tout en redevenant exactement le même objet canonique après inversion.

RFC 822 séparait les champs d’en-tête d’un corps ASCII constitué de lignes. RFC 821 définissait la phase DATA et ses règles de transparence. PEM reprit cette discipline parce qu’elle était déjà comprise par l’écosystème. La ressemblance n’autorisait pas à confondre le résultat canonique avec une transaction SMTP effectivement observée.

Trois formes, trois coûts de compatibilité

ENCRYPTED ajoutait la confidentialité à l’authentification et à l’intégrité. Le corps canonique était chiffré, puis rendu transmissible par un alphabet imprimable restreint.

MIC-ONLY ne cachait pas le contenu, mais l’encodait encore. Le destinataire avait besoin d’un processeur PEM pour retrouver le texte. En échange, les transformations habituelles des relais avaient moins de prise sur la représentation signée.

MIC-CLEAR conservait le même choix de services d’intégrité et d’authentification que MIC-ONLY, tout en supprimant l’encodage imprimable. Le gain était humain : quelqu’un dépourvu de PEM voyait immédiatement le contenu. La perte était précisément mesurée : cette personne ne pouvait pas contrôler la signature.

La lisibilité et la vérifiabilité n’étaient donc pas deux degrés d’un même voyant. La première venait de la représentation en clair. La seconde exigeait une clé utilisable, des champs de contrôle cohérents, une reconstruction canonique correcte et un MIC concordant.

Cette différence avait un effet social. Un texte compréhensible peut créer de l’urgence avant que l’interface n’affiche son origine. Plus l’accès est facile, plus l’écart entre persuasion et preuve doit rester visible.

Une transformation bénigne pouvait laisser une alarme exacte mais incomplète

L’encodage de MIC-ONLY formait une armure contre certaines modifications du système de transfert. MIC-CLEAR y renonçait. Sa vérification supposait donc soit un chemin qui ne modifiait pas le texte, soit une connaissance suffisante des modifications pour les inverser.

La conversion des fins de ligne illustrait le problème. Après une livraison SMTP, un système pouvait avoir remplacé CRLF par sa convention locale avant que le module PEM ne reçoive le corps. Le vérificateur devait alors recanoniser le texte, retrouver la représentation inter-SMTP et seulement ensuite calculer le MIC de référence.

La réexpédition ajoutait un autre emballage. RFC 1421 reprenait les limites de RFC 934. Une ligne en clair commençant par un tiret pouvait recevoir le préfixe réversible afin de ne pas ressembler à une limite d’encapsulation. Le MIC avait été calculé avant cette opération. La couche qui avait introduit l’échappement devait donc le retirer avant le contrôle.

Un échec du MIC constatait une divergence. Il ne racontait pas encore son histoire. Une falsification était possible ; une conversion locale impossible à inverser l’était aussi. RFC 1421 indiquait expressément qu’un échec MIC-CLEAR n’était pas nécessairement un événement de sécurité.

L’interface devait conserver ce contexte. Le type du message devait accompagner le signal d’échec. Pour un message syntaxiquement valide dont le MIC échouait, le contenu ne devait pas apparaître comme fiable sans avertissement sur l’authenticité et l’intégrité, suivi d’une confirmation positive de l’utilisateur. La norme n’effaçait ni le risque ni l’incertitude.

La proximité visuelle ne prolongeait pas la signature

Les champs de contrôle PEM se trouvaient dans un en-tête encapsulé à l’intérieur du corps extérieur. Le format autorisait des annotations non protégées autour des limites, plusieurs objets et des niveaux de réexpédition. Une phrase voisine d’un objet signé restait une phrase voisine.

De même, un MIC valide ne confirmait ni les adresses extérieures, ni le routage, ni la réception humaine. Il disait qu’un objet canonique avait passé un contrôle sous un chemin de clés donné. La livraison, l’identité de l’auteur humain, le consentement, la lecture et l’action appartenaient encore à d’autres preuves.

RFC 1423 isolait algorithmes, modes et identifiants dans un document séparé. Cette modularité permettait de faire évoluer la surface cryptographique sans redéfinir toute la grammaire. RFC 1421 et RFC 1423 sont aujourd’hui Historiques ; leurs algorithmes ne constituent pas une recommandation actuelle.

MIC-CLEAR laisse une leçon moins confortable qu’une victoire de la cryptographie. Le réseau installé pouvait continuer à transporter du texte. Le lecteur pouvait continuer à lire. En contrepartie, chaque réécriture devait demeurer attribuable, réversible ou explicitement inconnue. La compatibilité ne supprimait pas le travail ; elle le déplaçait vers celui qui devait prouver.