Résumé

  • RFC 1505 proposait un champ Encoding facultatif pour décrire l’ordre, la longueur en lignes et les transformations des parties d’un message. Cette description guidait le décodage sans certifier l’auteur, la sûreté du résultat ni le droit d’agir.
  • Son format FS pouvait transporter propriétaire, groupe, ACL, mot de passe, dates et application. Ces attributs appartenaient au système d’origine ; leur projection vers des comptes et des droits locaux demeurait une décision du domaine qui contrôlait le décodeur.
  • Le document acceptait le format SHAR tout en interdisant son exécution automatique. Registre de mots-clés, CRC, signature, restauration de fichier, autorisation et effet observé restaient des preuves différentes.

Un propriétaire sans compte correspondant

Supposons qu’une archive reçue annonce que le fichier appartient à l’utilisateur 47, au groupe OPER, avec le droit d’exécuter pour $SYSTEM. Le décodeur sait lire les champs. Sur la machine destinataire, l’utilisateur 47 peut appartenir à quelqu’un d’autre, OPER peut ne pas exister et $SYSTEM peut n’avoir aucun équivalent.

Copier les valeurs à l’identique ne préserverait donc pas nécessairement le sens. Cela pourrait donner à un inconnu les droits d’un administrateur local. Remplacer tous les noms par le compte du destinataire éviterait une partie du risque, mais effacerait la provenance. Refuser la restauration protégerait la machine tout en rendant l’archive moins utile.

RFC 1505 plaçait ce conflit au cœur de son encodage FS. Il voulait représenter des répertoires, entrées, fichiers, segments et données issus de systèmes très différents : Unix, DOS, VMS, Primos ou Macintosh. Les attributs comprenaient le nom d’affichage, le commentaire, le type, les dates de création, modification et accès, le propriétaire, les groupes, les ACL, le mot de passe, les tailles de bloc et d’enregistrement, ainsi que l’application associée.

Ce vocabulaire rendait le transport possible. Il ne créait pas une administration commune.

Les droits décrits restaient des droits étrangers

La syntaxe d’ACL de RFC 1505 associait des identifiants à des lettres : ajouter, supprimer, lister, modifier la protection, lire, utiliser, écrire, exécuter ou accorder tout droit. Quatre rôles réservés — $OWNER, $GROUP, $SYSTEM et $REST — facilitaient la représentation de protections connues de plusieurs environnements.

Mais un rôle transportable n’est pas un principal local. Le destinataire devait décider si $OWNER désignait l’auteur du message, le propriétaire déclaré dans l’archive, l’utilisateur qui lançait le décodage ou un compte créé spécialement. Chacune de ces réponses produisait un état différent.

Le problème touchait aussi le temps. Le format pouvait transmettre une date avec une précision supérieure à celle du système cible. RFC 1505 demandait alors au décodeur d’ignorer l’excédent de précision. La valeur reçue, la valeur représentable et la valeur effectivement écrite formaient trois enregistrements, non une seule date universelle.

Une restauration honnête devait donc conserver la déclaration originale, indiquer la perte ou l’ambiguïté, puis enregistrer la règle locale appliquée. Afficher seulement « attributs restaurés » masquait la décision la plus importante.

Le mot de passe en clair révélait le véritable responsable

Le format FS autorisait un attribut password contenant le mot de passe d’accès de l’élément. RFC 1505 considérait que sa présence en clair n’ajoutait pas nécessairement un nouveau secret, puisque le contenu protégé suivait dans le même encodage.

La phrase suivante fixait pourtant une limite décisive. Si le décodeur installait réellement ce mot de passe sur un élément créé, la sécurité ou l’insécurité de cette action relevait du domaine applicatif qui contrôlait le décodeur. Il en allait de même des ACL et des autres protections.

Le message pouvait donc transporter une chaîne appelée « mot de passe ». Il ne pouvait pas, par ce nom, imposer qu’elle devienne un secret local, remplace une protection existante ou prouve l’équivalence entre deux comptes. L’autorité venait de la politique d’arrivée, non du champ reçu.

Cette distinction évite une fausse idée de fidélité. Copier parfaitement un mécanisme de protection dans un environnement où il change de portée n’est pas une restauration parfaite. C’est une nouvelle attribution de droits.

Une archive reconnue n’était pas une commande approuvée

La même limite apparaissait plus brutalement avec SHAR, le format d’archive shell. RFC 1505 le prenait en charge mais en déconseillait l’usage. Une archive pouvait contenir des commandes que le destinataire ne souhaitait pas exécuter ; le décodeur ne devait donc pas lancer automatiquement les instructions décodées. L’avertissement valait aussi pour tout futur type contenant des commandes destinées à la machine réceptrice.

Reconnaître SHAR prouvait que le mot-clé avait été compris. Extraire les instructions prouvait que le format avait été décodé. Aucun de ces résultats ne prouvait qu’un utilisateur autorisé avait accepté l’exécution, que l’interpréteur convenait, que les ressources étaient bornées ou que les effets attendus s’étaient produits.

Entre la réception et l’action, il fallait une coupure visible : quarantaine, inspection, choix d’un environnement restreint, décision humaine ou politique explicite, puis journal de l’exécution réelle. Sans cette coupure, la syntaxe du correspondant devenait un ordre local.

Le champ décrivait une succession, pas une capacité générale

RFC 822 avait organisé le message en un en-tête et un corps séparés par une ligne vide. RFC 1505 ajoutait une description compacte des parties du corps dans le champ Encoding, afin de ne pas parsemer le texte de structures qui gêneraient les anciens lecteurs.

Chaque sous-champ correspondait à une partie dans son ordre d’apparition. Il pouvait indiquer un nombre décimal de lignes puis un ou plusieurs mots-clés. La ligne vide de séparation, composée uniquement de CRLF, n’entrait dans le compte d’aucune partie. La dernière partie pouvait omettre son nombre.

Les mots-clés imbriqués étaient ordonnés. Le décodeur les parcourait de gauche à droite ; l’encodeur les écrivait dans l’ordre inverse des transformations appliquées. Une suite comme uuencode LZW tar décrivait donc un chemin, non trois boutons interchangeables.

Les commentaires entre parenthèses pouvaient être transmis aux clients, mais ne devaient jamais commander l’interprétation du contenu. Le document séparait déjà, dans la même ligne, le texte explicatif et les jetons de contrôle.

Un parseur pouvait vérifier le nombre de lignes et suivre la chaîne de transformations. Il ne savait toujours pas si l’étiquette disait vrai, si le résultat était digne de confiance ou si l’étape suivante était autorisée.

« Signature » pouvait n’être qu’une formule finale

Dans RFC 1505, le mot-clé Signature désignait la zone de signature ordinaire d’un courriel ou d’un article Usenet. Elle pouvait contenir le nom de l’expéditeur ou une phrase favorite, souvent ajoutée automatiquement. Text Signature décrivait donc une partie de présentation, pas une vérification cryptographique.

PEM, PEM-Clear et PGP avaient leurs propres mots-clés. Ils pouvaient signaler chiffrement, contrôle d’intégrité, bloc de clé ou signature détachée. Là encore, le mot extérieur n’épuisait pas la preuve : il fallait connaître les octets couverts, le résultat algorithmique, la provenance de la clé et la confiance locale accordée au nom revendiqué.

RFC 1505 remarquait même qu’un type imbriqué après PGP pouvait révéler à un observateur qu’il s’agissait de texte ou d’une transaction EDI. Un chiffrement réussi n’effaçait donc pas toutes les informations de contexte.

Regrouper ces états sous un voyant « signé » aurait confondu une formule de politesse, un objet cryptographique, une validation mathématique et une autorité reconnue.

Un compte de lignes et un CRC avaient chacun une portée étroite

L’encodage LZJU90 combinait compression et représentation en caractères imprimables choisis pour survivre aux conversions entre ASCII et EBCDIC. Sa dernière ligne indiquait la taille originale et un CRC. Après décompression, le décodeur devait retrouver les mêmes valeurs.

Ce contrôle pouvait révéler une corruption ou une mauvaise décompression. Le compte du champ Encoding répondait à une autre question : combien de lignes de texte encodé appartenaient à la partie. Ni l’un ni l’autre n’authentifiait l’expéditeur, ne validait une ACL et n’autorisait l’exécution.

La chaîne de preuves devait garder séparément le message brut, la plage de lignes, l’ordre des mots-clés, les versions du parseur et du décodeur, le résultat des transformations, le contrôle d’intégrité, la provenance du message, la projection locale des attributs, l’approbation d’une action et l’effet observé.

Une valeur verte à une étape ne devait pas remplir les cases suivantes.

L’enregistrement d’un mot-clé ne certifiait pas son usage

RFC 1505 demandait l’enregistrement auprès de l’IANA des nouveaux mots-clés non privés et réservait durablement le préfixe X- aux usages propres aux implémentations. Le registre réduisait les collisions de vocabulaire et reliait un nom à une documentation.

Il ne garantissait pas qu’un décodeur particulier le prenait en charge, que son code était sûr, que le message utilisait honnêtement le nom ou que le résultat pouvait être exécuté. La coordination portait sur la désignation ; l’implémentation, la politique et l’effet restaient locaux.

Une expérience contemporaine de MIME

Albert Costanzo, David Robinson et Robert Ullmann publièrent RFC 1505 en août 1993. Le document était Experimental, ne définissait pas un Internet Standard et remplaçait RFC 1154. Une note de l’IESG signalait qu’une technologie standards-track existait déjà dans le même domaine : MIME, alors décrite par RFC 1341.

Cette chronologie interdit de raconter RFC 1505 comme un brouillon devenu MIME. Les spécifications MIME ultérieures, dont RFC 2045, révisèrent la lignée propre à MIME. Elles placèrent des en-têtes et des frontières explicites dans les parties du corps. Elles offrent une comparaison utile, mais ne prouvent pas une obsolescence formelle de RFC 1505.

L’expérience concurrente reste éclairante parce qu’elle rend visible la frontière entre une description partagée et un pouvoir local. Plus un format transporte fidèlement des commandes et des protections, plus le destinataire doit conserver la trace de la décision qui leur donne — ou refuse — un effet.

Ce que les sources n’établissent pas

Les RFC conservées établissent des formats, un statut, des avertissements et une lignée documentaire. Elles ne mesurent aucun déploiement de RFC 1505, ne prouvent la conformité d’aucun logiciel de courrier, ne décrivent aucun incident SHAR réel et ne montrent aucune ACL ou aucun mot de passe effectivement installé depuis un message.

RFC 1341 et RFC 2045 documentent MIME sans démontrer que MIME a formellement rendu RFC 1505 obsolète. Un RFC publié ne prouve pas un code en production. Un CRC exact ne prouve pas l’auteur. Un mot enregistré ne certifie pas une exécution. Une ACL reçue n’accorde aucun droit dans un autre domaine.

Le message pouvait préserver la mémoire d’une protection étrangère. La machine destinataire gardait la responsabilité de ne pas transformer cette mémoire en privilège local sans mandat.

Sources