Résumé

  • Le RFC 9787, publié en août 2025 comme RFC informatif et non comme spécification Standards Track, distingue implicitement deux états d’autorité : le brouillon encore modifiable et le message réellement envoyé. Il recommande de protéger le premier contre un stockage distant potentiellement lisible sans pour autant donner accès aux destinataires.
  • Lorsqu’un brouillon est chiffré, il doit l’être uniquement pour le certificat de l’utilisateur ou pour une clé secrète équivalente que lui seul possède. Un autre client ne peut reprendre ce brouillon que s’il accède à la même boîte et au secret capable de le déchiffrer ; le partage sûr de ce matériel entre plusieurs MUA reste un problème reconnu mais non résolu par le RFC.
  • Un MUA conforme ne doit pas signer le brouillon avec la clé de signature normale de l’utilisateur. Le RFC motive cette séparation par le risque qu’une signature non répudiable sur un texte inachevé soit interprétée comme un engagement. Il s’agit d’une propriété de conception cryptographique et d’une recommandation opérationnelle, non d’une règle juridique universelle.
  • La proposition éditoriale développée ici est un reçu de garde de l’intention du brouillon : une preuve minimale de la façon dont un objet provisoire a été conservé, repris et finalement envoyé. Ce reçu n’est ni défini ni exigé par le RFC 9787.

Le brouillon n’est pas encore le message

La section 9.5 du RFC 9787 part d’un comportement ordinaire : de nombreux Mail User Agents enregistrent les messages en cours dans un dossier Drafts. La difficulté commence lorsque ce dossier se trouve sur une infrastructure qui n’est pas entièrement sous le contrôle de l’utilisateur, par exemple une boîte IMAP distante. Enregistrer le texte en clair peut alors exposer un contenu que l’auteur n’a ni achevé ni envoyé.

Le point important n’est pas de prédire si le message final sera confidentiel. Au moment d’une sauvegarde automatique, le client peut précisément ne pas connaître cette décision. L’auteur peut encore choisir d’envoyer en clair ou de chiffrer. Pour cette raison, le RFC dit qu’un MUA SHOULD chiffrer tous les brouillons, sauf s’il sait explicitement que le message final ne sera pas chiffré ou que le dossier Drafts ne peut pas être lu par un attaquant potentiel.

Cette protection crée une frontière inhabituelle mais cohérente. Le brouillon doit rester récupérable par son auteur tout en restant inaccessible aux personnes auxquelles il pourrait plus tard être adressé. Lorsqu’un brouillon est protégé, le RFC exige donc qu’il soit chiffré uniquement pour le certificat de l’utilisateur ou pour une clé secrète équivalente détenue uniquement par lui. Le destinataire pressenti n’obtient pas un droit de lecture simplement parce que son adresse figure déjà dans le travail de composition. Le chiffrement pour les destinataires n’intervient qu’au véritable envoi.

Le même raisonnement vaut pour la signature. Un MUA conforme MUST NOT signer le brouillon avec la clé de signature normale de l’utilisateur. Le RFC explique qu’une signature non répudiable sur un texte encore provisoire peut être présentée, si ce brouillon fuit, comme l’indice d’un engagement que son auteur n’avait pas encore décidé de prendre. Il évoque la possibilité d’une autre clé pour coordonner cryptographiquement des brouillons entre plusieurs MUA, mais ne définit pas ce mécanisme.

Il serait excessif d’en tirer une théorie générale du consentement ou de la responsabilité juridique. Le RFC ne fournit pas une règle de droit sur la valeur d’une signature dans tous les contextes. Son point est plus étroit : la clé que l’utilisateur emploie normalement pour attester un message achevé ne doit pas être transformée, par automatisme, en sceau apposé sur chaque état transitoire de sa rédaction.

La continuité multiappareil déplace le problème vers les clés

Chiffrer un brouillon pour son seul auteur paraît simple tant qu’un seul MUA existe. La réalité opérationnelle devient plus dure dès que le même utilisateur veut commencer sur un appareil, continuer sur un autre, sauvegarder à nouveau, puis envoyer depuis un troisième.

Pour qu’un second MUA reprenne le brouillon, deux conditions doivent se rejoindre : il doit voir la même boîte et posséder un secret permettant de déchiffrer l’objet sauvegardé. Le RFC le dit explicitement, puis renvoie le problème du partage de certificats et de clés secrètes entre MUA à ses travaux futurs. Son appendice A.4.1 constate l’usage de plusieurs clients par un même utilisateur et envisage qu’une version future fournisse des orientations pour le partage efficace et sûr de ce matériel. L’appendice A.4.2 examine aussi la possibilité de mécanismes secrets portables, sans transformer cette piste en solution générale.

Voilà le centre du problème : la sauvegarde distante est facile lorsque le serveur peut tout lire ; elle devient plus exigeante lorsqu’il ne doit conserver qu’un objet chiffré. La synchronisation de l’objet ne suffit plus. Il faut aussi assurer la continuité de l’autorité de déchiffrement.

Une mauvaise continuité produit plusieurs échecs possibles. Un deuxième client peut voir le brouillon sans pouvoir l’ouvrir. Une restauration peut récupérer le ciphertext mais pas le secret correspondant. À l’inverse, un mécanisme conçu pour rendre toutes les reprises transparentes peut élargir excessivement le nombre de clients capables de lire et de modifier le brouillon. RFC 9787 identifie le besoin mais ne normalise pas le protocole qui résoudrait cette tension.

\Draft, \Drafts et $draft décrivent un état, pas toute sa sécurité

Les protocoles de courrier disposent déjà de moyens pour dire qu’un objet est un brouillon. IMAP4rev2 définit le drapeau \Draft. Le RFC 6154 définit l’usage spécial \Drafts pour une boîte destinée aux messages en cours de composition et non encore envoyés.

JMAP Mail possède de son côté le mot-clé $draft. Son exemple de soumission montre un message sauvegardé comme brouillon qui, après une soumission réussie, perd l’état $draft et quitte le dossier de brouillons pour le dossier Sent.

Ces mécanismes sont importants précisément parce qu’ils rendent visible une transition d’état. Ils ne constituent pourtant pas à eux seuls une politique cryptographique du brouillon. Savoir qu’un objet est marqué comme brouillon ne dit pas qui peut le déchiffrer, quelle clé a été utilisée, quels autres clients possèdent cette clé, ni si la clé de signature ordinaire a été sollicitée pendant la phase de composition.

L’état applicatif et l’état d’autorité se recouvrent donc sans être identiques. Le premier dit « ceci est encore un brouillon ». Le second doit répondre à une question plus exigeante : « qui pouvait effectivement le lire, le modifier ou lui attacher une preuve cryptographique à cet instant ? »

La cryptographie existe ; son orchestration pour les brouillons reste une autre question

S/MIME 4.0 et OpenPGP fournissent des primitives et formats de protection pour les messages. Cela ne démontre pas qu’un mécanisme uniforme de clé de brouillon multiappareil soit largement déployé.

C’est une distinction essentielle pour lire RFC 9787 sans transformer une recommandation en description du marché. Les sources examinées ici n’établissent ni taux de conformité des fournisseurs, ni prévalence d’un modèle particulier, ni fréquence mesurée de fuite de brouillons, ni effet juridique déterminé, ni protocole standard universel de partage de clés spécialement consacré aux brouillons. Au cutoff de cette analyse, aucun erratum correspondant n’était listé dans la recherche du RFC Editor. La fiche du RFC le classe bien comme Informational.

Un reçu de garde de l’intention du brouillon

Il reste alors une lacune de preuve. Un système peut chiffrer correctement ses brouillons et pourtant ne conserver, après l’envoi, aucun élément compact permettant de reconstruire la frontière entre le texte provisoire et l’objet effectivement expédié.

La proposition éditoriale de Daniel Kade est de produire un reçu de garde de l’intention du brouillon. Ce reçu n’est pas une exigence du RFC 9787 et ne prétend pas devenir une nouvelle couche de courrier. Il s’agit d’une preuve auxiliaire, étroitement attachée à la continuité du même objet pendant trois moments : sauvegarde, reprise multiappareil, envoi.

Le reçu conserverait une référence d’objet et de version ; la classe du point de stockage ; la portée et la classe de la clé réservée à l’auteur ; l’ensemble des clients autorisés à déchiffrer et modifier ; l’état du dernier rédacteur ou de la dernière fusion ; l’indication vérifiable que la clé de signature normale n’a pas servi à signer cette version du brouillon — ce qui est différent d’affirmer que cette clé n’existait pas sur l’appareil ; l’absence de chiffrement pour les destinataires avant l’envoi ; puis, lorsque l’envoi se produit réellement, l’événement d’envoi, le client responsable, son temps et une empreinte de l’ensemble final de

destinataires.

S’y ajouteraient l’empreinte de l’objet, l’état de nettoyage ou de tombstone, ainsi que le responsable du reçu et sa date de revue ou d’expiration.

Cette preuve doit être délibérément plus pauvre que le courrier. Elle ne devrait contenir ni corps du message, ni objet, ni liste complète des destinataires, ni clé secrète, ni identifiant inutile, ni copie de journaux généraux.

Même une empreinte cryptographique ordinaire ne produit pas automatiquement de l’anonymat. Une valeur issue d’un espace de faible entropie peut être testée par énumération, et plusieurs enregistrements apparemment minimaux peuvent être corrélés. Une conception prudente préférerait, selon le besoin de vérification, une preuve calculée sous clé ou un accès contrôlé, une finalité explicite et une rétention courte. L’objectif n’est pas d’accumuler une nouvelle histoire de la rédaction, mais de préserver juste assez de preuve pour distinguer la garde d’un brouillon de l’acte qui l’a fait devenir message envoyé.

Trois grilles éditoriales, aucune nouvelle doctrine IETF

Trois idées formulées par Heng Lu peuvent servir ici de grilles de lecture, à condition de ne pas les attribuer à l’IETF.

Running-Code Primacy rappelle utilement qu’une recommandation ou une architecture proposée ne doit pas être décrite comme une réalité de déploiement. Appliqué au brouillon chiffré, cela impose de distinguer le comportement recommandé par RFC 9787 de ce que des produits exécutent effectivement.

Minimum Initial Specification encourage une frontière commune réduite. Ici, cette discipline conduit à ne pas transformer le reçu proposé en registre total de la rédaction : il suffit de prouver les transitions d’autorité indispensables.

Enfin, Reality Not Advocacy oblige à séparer trois plans : ce que le RFC exige ou recommande, ce que l’on peut raisonnablement inférer de ses contraintes, et ce que cet article propose comme amélioration de preuve. Ces textes sont des cadres éditoriaux employés par BTW ; ils ne constituent pas une doctrine IETF.

Sources