Résumé

  • Une autorité de certification signe un lien entre une identité et une clé publique ; un centre de séquestre détient une capacité privée. Le premier acte ne prouve pas le second.
  • Une copie d’une clé à long terme ne garantit ni la récupération par le propriétaire, ni l’unicité d’une signature, ni le déchiffrement d’une session protégée par confidentialité persistante.

La confiance n’est pas un rôle unique

Dans RFC 1984, l’IAB et l’IESG reconnaissent l’utilité d’une hiérarchie de certification. Une autorité signe l’association entre une identité et une clé publique ; une autorité supérieure peut certifier sa clé. Un gouvernement peut légitimement fournir ce service pour ses relations avec les citoyens.

Rien dans cette fonction n’exige la clé privée du sujet. Le certificat rend une assertion vérifiable. Le séquestre augmente le nombre de personnes capables de déchiffrer ou de signer. Employer dans les deux cas l’expression « tiers de confiance » masque donc la question décisive : quelle action le tiers peut-il accomplir ?

Un certificat valide établit une signature de l’autorité, sous une politique donnée. Il ne prouve pas que la clé privée n’existe qu’à un endroit, que le terminal n’a pas été compromis ou que le titulaire est l’unique auteur possible d’une opération.

La récupération appartient à celui qui supporte la perte

Pour des fichiers conservés, un client peut préférer une copie récupérable et accepter le risque supplémentaire de garde. RFC 1984 laisse ce choix au client. Une clé utilisée seulement pendant une conversation n’a pas le même besoin de survie.

Le séquestre obligatoire poursuit une autre finalité. Si l’État détient la seule copie supplémentaire et que le propriétaire ne peut pas l’obtenir après une perte, le dispositif n’est pas un service de continuité pour ce propriétaire. Le mot « récupération » ne dit pas qui en bénéficie.

Le reçu de dépôt n’est qu’un début. Il faut encore démontrer que la clé est actuelle, complète et intacte, que l’accès a été autorisé, que le propriétaire peut effectivement restaurer ses données et que l’usage laisse une trace contrôlable.

Une clé de signature partagée produit deux auteurs possibles

La signature et l’authentification reposent sur une hypothèse d’exclusivité. Dès qu’un dépositaire peut utiliser la même clé privée, il peut créer une opération apparemment valable. Le titulaire peut contester une transaction en accusant le dépositaire ; si l’État conserve la clé, l’origine même d’une preuve peut être discutée.

Le risque ne dépend pas d’un abus déjà constaté. Le modèle de preuve a changé dès la copie. Une clé de confidentialité peut justifier une politique de sauvegarde adaptée aux données ; cela ne justifie pas la duplication d’une clé de signature. L’usage de la clé doit précéder la règle de garde.

Quand la juridiction la plus restrictive dessine le produit

RFC 1984 décrit un effet industriel. Une entreprise présente dans plusieurs pays peut choisir le mécanisme faible accepté partout, afin d’éviter plusieurs versions. La règle la plus restrictive devient alors le plafond de sécurité de marchés qui ne l’imposaient pas.

Maintenir des variantes préserve une protection plus forte, mais crée des branches de code, des tests, des mises à jour et des risques de mauvaise distribution. Une licence d’exportation prouve seulement qu’un élément précis a été autorisé sous certaines conditions. Elle ne prouve ni sa disponibilité mondiale, ni son installation, ni son interopérabilité, ni sa sûreté.

Le séquestre ne réconcilie pas deux États qui se méfient l’un de l’autre. Chacun peut vouloir que ses entreprises utilisent un chiffrement fort contre l’autre, sans lui remettre les clés. Le mécanisme commun exige alors un accord de juridiction, d’autorisation et de responsabilité plus difficile que l’échange commercial initial.

Déchiffrer l’enveloppe n’est pas lire la lettre

Un utilisateur déterminé peut chiffrer le contenu avant de l’envelopper dans le mécanisme séquestré. La clé réglementaire ouvre l’enveloppe et révèle un autre texte chiffré. Le fait de réussir un déchiffrement ne prouve donc pas que toutes les sessions sont lisibles, ni qui a créé le message, ni que l’accès était légitime.

Le texte distingue aussi la clé privée à long terme de l’état d’une session. Avec la confidentialité persistante, une compromission avant ou après la conversation peut ne pas restituer son contenu ; il faudrait contrôler la machine pendant l’échange. RFC 1984 précise que cette description est simplifiée. La conclusion défendable est étroite : la possession d’une clé durable ne constitue pas, à elle seule, un reçu pour les anciens textes clairs.

La taille de clé est également un facteur, non un verdict. Une clé courte peut devenir cassable pendant la durée de confidentialité requise. Une clé longue ne répare pas une mauvaise génération aléatoire, une implémentation vulnérable, un terminal compromis ou une garde défaillante.

En 2015, le changement de statut de l’IETF a fait du texte inchangé une Best Current Practice, aujourd’hui BCP 200. Ce reçu établit la continuité d’une position technique, pas l’adoption d’un produit ou la conduite d’un État.

L’apport historique de RFC 1984 tient ainsi à ses séparations : certifier n’est pas garder ; garder n’est pas restaurer pour le propriétaire ; restaurer n’est pas signer ; posséder une clé longue durée n’est pas posséder une conversation passée.

Documents primaires

RFC 1984 TXT · RFC 1984 HTML · fiche RFC Editor · fiche IETF · changement de statut · historique · scrutin IESG · présentation IAB · présentation IESG · entrée IETF existante