Résumé

  • Un envoi OpenPGP peut viser à la fois des clés PQ/T et traditionnelles pour éviter une rupture de service ; RFC 9980 précise que ce choix ne confère pas la confidentialité post-quantique au message.
  • La preuve porte sur la liste effective des clés destinataires et les paquets PKESK émis, non sur la présence d’une nouvelle clé dans un annuaire.

Une clé nouvelle ne transforme pas le message rétrospectivement

Dans un tableau de migration, il est tentant d’écrire « destinataire prêt pour le post-quantique » dès qu’apparaît une sous-clé ML-KEM-768+X25519. Cette formule mélange plusieurs faits. RFC 9980 standardise des identifiants, des formats et des opérations cryptographiques. Il ne certifie ni le logiciel qui émet, ni celui qui reçoit, ni l’identité rattachée à une clé, ni le déploiement d’une organisation.

Surtout, OpenPGP peut placer plusieurs paquets de clé de session chiffrée à clé publique, ou PKESK, dans le même message. Pendant une transition, le RFC autorise l’envoi simultané à des clés PQ(/T) et à des clés traditionnelles afin de ne pas interrompre les échanges. C’est parfois un choix raisonnable. Mais il laisse au moins une voie de déchiffrement traditionnelle vers la même clé de session. La section 3.1 en tire la conséquence exacte : si toutes les clés de destinataires ne sont pas PQ(/T), la confidentialité du message n’est pas post-quantique.

La question de direction devient donc précise. Pour une catégorie de messages, qui décide qu’un destinataire classique peut rester ? Quelle clé a effectivement été sélectionnée ? Quel paquet a quitté le client ? Quelle capacité du correspondant a été vérifiée, et jusqu’à quelle date l’exception est-elle admise ? Une étiquette de boîte aux lettres ne répond à aucune de ces questions.

Deux composants dans une clé ne signifient pas deux destinataires interchangeables

Le chiffrement composite de RFC 9980 réunit ML-KEM et un mécanisme ECDH dans une même clé destinataire PQ/T. Les deux encapsulations produisent des parts de clé ; celles-ci, avec le texte chiffré ECDH, la clé publique et le contexte du protocole, alimentent un combineur qui produit la clé servant à envelopper la clé de session. C’est une construction unique, liée au protocole.

Un PKESK traditionnel ajouté à côté ne devient pas pour autant un composant de cette construction. Il offre une deuxième manière indépendante d’atteindre la même clé de session. Le vocabulaire « hybride » peut masquer cette différence si l’on ne regarde que les noms des algorithmes. Pour l’assurance recherchée ici, la forme du message importe : une clé composite qualifiée n’élève pas une enveloppe qui contient aussi une sortie classique.

Cette distinction ne commande pas mécaniquement de bloquer tout envoi compatible. Elle interdit plutôt de faire disparaître la décision dans un réglage technique. Un service peut conserver un chemin traditionnel pour une relation critique, une reprise documentée ou une contrainte temporaire. Il doit alors classer ce chemin comme exception, avec un responsable, une portée et un terme, au lieu de laisser la compatibilité se propager aux messages qui exigent une autre garantie.

La signature suit une logique de transition différente

RFC 9980 traite les signatures autrement. Un expéditeur peut signer avec une clé PQ(/T) et une clé traditionnelle afin qu’un logiciel ancien puisse encore s’appuyer sur cette dernière ; une signature uniquement PQ/T n’est pas rétrocompatible. Lors de la vérification, une implémentation peut accepter les deux. Si elle sait qu’un pair dispose d’une clé PQ/T et évalue le risque d’un ordinateur quantique pertinent, elle peut préférer ignorer la signature traditionnelle de ce pair.

Il ne s’agit pas d’une règle universelle d’identité ou d’autorisation. Une signature valide ne prouve ni la qualité du contenu, ni le mandat de l’auteur, ni le consentement du destinataire. Elle montre qu’une politique de signature et une politique de chiffrement ne doivent pas être écrasées dans un seul indicateur « PQ activé ».

Les faits utiles sont observables et limités

Les algorithmes asymétriques PQ(/T) requièrent normalement des clés et certificats v6 ou ultérieurs ; ML-KEM-768+X25519 peut aussi apparaître dans certaines sous-clés de chiffrement v4. Le RFC impose un socle d’implémentation et IANA enregistre les identifiants 30 à 36. Aucune de ces lignes n’établit le comportement d’un produit précis.

Un contrôle proportionné conserve donc les métadonnées cryptographiques nécessaires — ensemble de destinataires, versions, algorithmes et PKESK émis — sans aspirer le contenu des messages. Il rattache cette preuve à une classe de messages et à la décision d’exception. C’est assez pour vérifier l’affirmation ; ce n’est pas une licence pour constituer une nouvelle archive de correspondance.

Sources