Résumé

  • Le RFC 1805 proposait un certificat signé par un tiers de confiance, portant l’empreinte d’un fichier et une date, utilisable quel que soit le site d’où provient le fichier.
  • La manière de reconnaître l’auteur restait ouverte dans le protocole. L’implémentation Betsi décrite chez Bellcore utilisait les renseignements téléphoniques et un rappel pour confirmer l’inscription.

Un fichier peut voyager sans garder l’adresse de son premier serveur. La confiance dans son auteur, elle, ne tient pas dans la seule adresse. Aviel Rubin s’est attaqué à cette différence dans le RFC 1805, publié en juin 1995. Sa proposition associait une empreinte cryptographique et une date à un certificat signé par un tiers. L’utilisateur pouvait obtenir le fichier ailleurs et vérifier les octets. L’élément savoureux est le détour très terrestre choisi par l’implémentation Betsi de Bellcore : pour relier un auteur à une clé publique, le tiers allait jusqu’à consulter l’annuaire et appeler le numéro trouvé.

Le texte part d’une méfiance plus profonde que celle d’un mauvais serveur. Le programme chargé de vérifier un téléchargement peut lui-même être altéré. Croire ce programme sur parole reviendrait à lui demander de rédiger son propre certificat de bonne conduite. Rubin décrit donc des messages ASCII et des mécanismes de signature courants, que différents logiciels peuvent traiter. Trois rôles structurent le système : l’auteur, l’utilisateur et un tiers de confiance. Chacun détient une pièce de la preuve ; aucun bouton vert ne remplace toute la chaîne.

Les cinq phases sont l’inscription de l’auteur, sa vérification, la certification du fichier, sa distribution et le contrôle final. La deuxième phase n’est volontairement pas définie une fois pour toutes. Une application peut choisir sa méthode d’identification, à condition que le certificat indique ensuite laquelle a été utilisée. C’est essentiel : une signature rattache un message à une clé, mais l’attribution de cette clé à une personne demande une enquête distincte.

Betsi, qui fonctionnait aux États-Unis selon le RFC, obtenait un numéro par les renseignements locaux, rappelait l’auteur et vérifiait les informations enregistrées, notamment la clé publique. L’appel appartient à cette implémentation, pas à toute méthode future.

L’auteur enregistré calcule l’empreinte du fichier puis signe une demande envoyée au tiers. Celui-ci vérifie la demande et renvoie un certificat qu’il signe à son tour. On y trouve l’empreinte, la fonction de hachage, la date, le nom de l’auteur et la méthode de vérification de son identité. Le lieu du fichier est facultatif dans la demande. Voilà la charnière du dispositif : la relation certifiée porte sur les octets et le temps, pas sur un répertoire FTP. Le fichier et le certificat peuvent être distribués ensemble par des chemins que le lecteur ne prend pas pour des garants.

Le lecteur doit ensuite faire plusieurs gestes distincts. Il obtient la clé publique du tiers par des sources indépendantes, vérifie sa signature, juge la méthode d’identification annoncée, recalcule l’empreinte du fichier reçu et compare les deux résultats. Il contrôle la date si elle compte pour sa décision. Enfin, il consulte la liste de révocation signée, actuelle et complète du tiers. La belle signature sur un certificat révoqué n’est pas un raccourci acceptable.

Au bout de la chaîne, l’affirmation est précise : les octets reçus correspondent à ceux certifiés à une date donnée, sous les conditions d’identité et de révocation qui ont été examinées. Le certificat ne choisit pas à la place de l’utilisateur s’il faut exécuter le logiciel. L’histoire du téléphone n’est donc pas une plaisanterie sur la lenteur des années 1990. Elle montre que l’indépendance vis-à-vis du lieu de stockage ne supprime pas le besoin d’un acte d’identification situé et vérifiable.