Résumé

  • Dans la version 03, le condensat du contexte précédent pouvait être calculé avant toute signature ; un opérateur pouvait donc faire signer la chaîne à rebours.
  • La version 04 exige que le successeur signe un condensat de la preuve précédente complète, signature réelle comprise, et refuse les anciennes chaînes dans le profil fort.
  • Cette correction établit une dépendance entre artefacts cryptographiques, pas une heure fiable, une lecture attentive, une décision finale ni l’exécution de l’action.

Le mot « après » semblait contenu dans les signatures. Il ne l’était pas. Le 6 septembre, draft-schrock-ep-quorum-04 a reconnu cette différence et remplacé une affirmation trop large par une construction plus étroite.

La version 03 faisait signer à chaque approbateur un contexte contenant prev_context_hash, le condensat du contexte de son prédécesseur. Le texte en déduisait qu’un approbateur ultérieur avait nécessairement signé après le précédent et en connaissance de son approbation.

Or le contexte existait avant la preuve. L’orchestrateur pouvait préparer toute la série, solliciter d’abord la dernière personne, remonter jusqu’à la première, puis remettre les signatures dans l’ordre attendu. Les calculs passaient ; l’histoire temporelle restait fausse.

La signature précédente entre enfin dans le lien

Le profil EP-QUORUM-SIGNOFF-CHAIN-v1 calcule maintenant SHA-256 sur un séparateur de domaine, un octet nul et la représentation JCS UTF-8 de l’objet de signature précédent complet. La signature effectivement transportée fait donc partie de l’entrée. Le résultat devient prev_signoff_hash dans le contexte signé du successeur.

Le premier contexte doit omettre le champ. Un premier lien nul, un profil absent ou inconnu, l’ancien prev_context_hash, un mélange de formats ou la substitution d’une autre signature valide font échouer la chaîne forte. Même si deux signatures valides couvrent le même contexte, elles produisent deux liens différents : le successeur doit signer à nouveau.

La propriété acquise est précise. Sous les hypothèses annoncées sur les signatures et les condensats, la preuve suivante dépend d’une preuve antérieure déjà complète. Elle ne date pas cette preuve sur une horloge de confiance. Les valeurs issued_at restent déclaratives. Elle n’atteste ni l’écran vu, ni la lecture de la décision précédente, ni la compréhension, ni le consentement libre.

Le quorum ne choisit pas ses propres autorités

Le prédicat vérifie la politique, les signatures, l’action exacte, les rôles, la distinction des identifiants humains et des clés, le seuil, l’ordre, le profil fort éventuel et la fenêtre déclarée. Une signature correcte d’une personne inscrite mais hors rôle ne compte pas. Une seule clé enregistrée sous deux noms ne fabrique pas deux contrôleurs. Une piste incomplète n’autorise rien.

Mais la politique attendue et l’annuaire des approbateurs doivent venir d’une source authentifiée extérieure au paquet. L’artefact ne peut pas se présenter lui-même comme constitution. Le projet de reçus de base rappelle aussi qu’une clé inscrite prouve la signature de cette clé ; l’identité civile située derrière l’identifiant dépend du contrôle d’enrôlement.

L’admission progressive n’est qu’un filtre anticipé. L’exécuteur doit recalculer tout le prédicat, car il ne fait pas confiance au travail de l’orchestrateur. Même satisfait, le quorum reste une preuve d’approbation. L’organisation décide encore si l’action est autorisée ; le système doit l’exécuter ; l’effet doit être observé ; la consommation unique doit empêcher la réutilisation.

Trois programmes ne font pas trois preuves indépendantes

La version 04 annonce l’accord de vérificateurs JavaScript, Python et Go sur un corpus commun, notamment des chaînes anciennes signées à rebours. C’est un contrôle de cohérence utile au sein d’un même dépôt. Ce n’est ni une implémentation indépendante, ni une preuve formelle, ni une interopérabilité observée, ni un déploiement.

Le document est une soumission individuelle à vocation informative, sans action IANA. Sa présence dans le Datatracker ne lui confère pas un consensus de l’IETF. La bonne lecture est celle d’une spécification minimale : réparer l’invariant commun sans laisser cet invariant absorber les décisions locales, la procédure humaine ou la réalité de l’effet.

Sources

  1. Fiche du Datatracker de l’IETF
  2. EP-QUORUM, version 04
  3. EP-QUORUM, version 03
  4. EP Authorization Receipts, version 12
  5. RFC 8785 : JSON Canonicalization Scheme
  6. Web Authentication, niveau 2
  7. RFC 2119 : mots-clés normatifs
  8. RFC 8174 : portée de la casse des mots-clés
  9. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  11. Running-Code Primacy