Résumé

  • RFC 3183 proposait à titre expérimental des services S/MIME exécutés par des passerelles et des autorités de domaine ; une signature de domaine valide attestait une sortie contrôlée sans toujours nommer la personne à l’extérieur.
  • Signature d’origine, signature de domaine, signature de revue, signature d’attributs et déchiffrement de domaine correspondaient à des actes différents. Les réunir sous l’étiquette « signé » supprime l’identité de l’autorité et la portée de sa décision.

Un domaine peut savoir qui a écrit. Il peut vérifier cette personne par une signature interne, une liaison authentifiée ou une autre procédure locale. Il peut ensuite autoriser la sortie du message. Mais ce savoir interne ne voyage pas automatiquement avec l’objet cryptographique que reçoit le monde extérieur. C’est la tension centrale de RFC 3183, publié en octobre 2001 sous le titre Domain Security Services using S/MIME avec le statut Experimental.

Le texte visait les agents de transfert, gardes, pare-feu et passerelles de traduction qui intervenaient pour une organisation. Les raisons pouvaient être pratiques : postes sans infrastructure de clés, PKI incompatibles, formats internes différents, magasins de messages qui remaniaient les contenus, contrôles de sécurité ou obligations d’audit au périmètre. Les auteurs ne prétendaient pas trancher la querelle entre sécurité de bout en bout sur le poste et sécurité exercée par le domaine. Ils définissaient des fonctions composables.

La première discipline consistait à ne pas confondre leurs signatures.

La signature de l’émetteur identifie l’émetteur et le contenu. La signature de domaine est une signature par procuration. Avant de la produire, le signataire du domaine doit authentifier l’émetteur, soit en vérifiant sa signature interne, soit grâce à un mécanisme extérieur à S/MIME. Il doit aussi valider les autres signatures pertinentes. Un échec interdit l’émission de la signature de domaine.

Cette procédure autorise une affirmation forte mais bornée. Après vérification, RFC 3183 permet d’authentifier l’origine au travers du domaine. Pourtant, pour l’affichage, le texte distingue deux cas. Si une signature personnelle de l’émetteur est présente, le certificat peut fournir son nom. Sans elle, le destinataire ne peut supposer que le domaine d’origine. Le domaine a peut-être correctement reconnu Marie dans son propre environnement ; le destinataire possède néanmoins l’attestation du domaine, pas le certificat personnel de Marie.

L’action réelle, sa représentation et l’observation publique restent donc séparées. Une personne compose un message. Un mécanisme local l’authentifie. Une autorité décide de libérer une représentation. Un destinataire vérifie la signature de cette autorité. Dire seulement « l’auteur est authentifié » fusionne quatre événements dont les preuves et les responsables ne sont pas identiques.

La signature de revue rend visible un autre pouvoir. Elle signifie que le signataire a examiné le message et l’a approuvé pour transmission. Une garde peut l’exiger avant d’ouvrir la frontière. Elle ne transforme pas le réviseur en auteur et, selon RFC 3183, n’authentifie pas l’émetteur. Elle ne prouve pas non plus la vérité du contenu, sa conformité juridique, sa livraison ou son acceptation. Elle prouve un visa de circulation.

La signature d’attributs supplémentaires lie des attributs du SignerInfo au message. Une vérification correcte démontre qu’une autorité donnée a lié certaines données à certains octets. Elle ne garantit pas, sans preuve distincte, que le fait extérieur décrit par l’attribut était vrai, actuel ou encore pertinent pour une décision ultérieure. La cryptographie fixe une relation ; elle ne fabrique pas la réalité à laquelle la donnée prétend se référer.

Pour que les machines gardent ces sens séparés, RFC 3183 définissait l’attribut signé SignatureType. L’erratum vérifié 3757 corrigea une omission : l’identifiant de cet attribut, id-aa-signatureType, est 1.2.840.113549.1.9.2.28. Cette correction permet d’identifier sans ambiguïté le type de preuve. Elle ne change aucune portée : un visa de revue ne devient pas une signature d’auteur par la simple réparation d’un OID.

Le chiffrement déplaçait encore l’autorité. Une autorité de confidentialité de domaine pouvait chiffrer ou déchiffrer au nom des utilisateurs. Ce choix répondait à des contraintes d’exploitation, mais concentrait les clés et introduisait un lieu où le texte clair réapparaissait. La compromission d’une clé de domaine pouvait toucher de nombreux utilisateurs. Après déchiffrement par l’autorité destinataire, la confidentialité dépendait aussi de l’aval. Sans signature que l’utilisateur final puisse vérifier indépendamment, le compte rendu favorable d’une autorité compromise ne suffisait plus à garantir l’intégrité.

Les procédures relatives aux listes de diffusion et aux objets CMS imbriqués rendent l’histoire plus concrète. Une passerelle pouvait vérifier, déchiffrer, retirer une enveloppe, conserver certains attributs, ajouter sa signature, rechiffrer et entourer le tout d’une nouvelle couche préservant l’historique d’expansion de liste. Le message n’était pas simplement « signé ». Chaque signature portait sur des octets situés à une étape particulière, avant ou après une transformation particulière.

Les RFC S/MIME et CMS contemporaines fournissaient les conteneurs ; des normes ultérieures ont remplacé ou actualisé ces bases. Elles ne prouvent ni un déploiement général de RFC 3183 ni son passage rétrospectif au rang de norme Internet. De même, un registre IANA atteste une attribution d’identifiant, pas son emploi dans le monde.

L’apport historique tient alors à une grammaire de la responsabilité. L’individu émet. Le domaine authentifie et libère. Le réviseur autorise la transmission. L’autorité d’attributs lie une assertion. L’autorité de confidentialité ouvre l’enveloppe. Le destinataire observe. Un voyant vert unique ne peut représenter cette chaîne sans effacer les frontières mêmes qui permettraient, plus tard, de demander des comptes.