要約

  • draft-sparysh-pala-audit-00は2026年9月3日に告知された。Datatracker上は個人Internet-Draftであり、IETFの支持や正式な地位、RFC stream、担当Area Directorはない。
  • 草案はPALA-1を既存の監査記録用wire formatとして提示し、v1.0は凍結済みだとする。Palimpsestsプロジェクトが凍結を行ったのは8月9日で、IETFへの投稿より前だった。
  • 草案は五つの実装を報告するが、著者の参照実装と、仕様本文から作られた四つの実装を区別する。後者が使ったのはプロジェクト提供のベクトルであり、独立ベクトルではない。
  • v1.0タグを対象にした後続実装は、曖昧さとspanの対応付けに関する欠落を発見した。草案は凍結後に仕様が変わったと述べる一方、wireとベクトルは維持されたとしている。
  • 凍結対象、プロジェクト内の決定者、IETFでの状態、指摘、変更種別、判断理由、旧実装への影響を別々に記す台帳が必要だ。

二つの時計を一つにしない

IETFの告知は9月3日、PALA-1: A Tamper-Evident Audit Record Format for Constrained and Disconnected Deploymentsを紹介した。Datatrackerの分類は明快である。これはactiveなindividual I-Dで、誰でも提出できる。IETFの支持を受けた文書ではなく、標準化手続上の正式な地位もない。締め切り時点でRFC streamとResponsible ADは記録されず、IESG stateは「I-D Exists」だった。

本文のヘッダーはInformationalを想定しているが、Datatrackerの集約欄はintended RFC statusを空欄にしていた。どちらも承認を意味しない。RFC Editorの説明によれば、I-Dは作業文書であってRFCではなく、公開されたからといって承認済み、または将来RFCになるとは限らない。個人提案をWorking Groupが採用することはあり得るが、採用は議論と改訂を始める一段階にすぎない。

もう一つの時計は先に止まっている。Palimpsestsは8月9日のcommit 50b47edb1ed8で、プロジェクト仕様をDraftから「Frozen — v1.0」に変えた。そこでの約束はwireに絞られている。wireを変えるなら新しいformat_versionにし、profile固有の名前空間は追加的に発展できる。9月のI-D本文も、既存のwire formatをそのまま提示しており、I-Dで改訂するものではないと明記する。

この順番自体に問題はない。プロジェクトが利用者のために形式を安定させてから、標準化コミュニティーに持ち込むことはできる。重要なのは二つの時計を混ぜないことだ。プロジェクトの凍結はIETF consensusの証拠ではない。IETFで未採用だからといって、プロジェクトが実装者にした互換性の約束まで消えるわけでもない。

running codeが凍結に実体を与えた

PALA-1のfreezeは単なるバージョン名ではない。Implementation Status節は五つの実装を挙げる。著者のreference implementation、明示したcontamination boundaryの下で共同メンテナーが作った実装、そして実装時点ではプロジェクト外部にいた三人の実装である。最後の三人のうち一人は、その後メンテナーになった。

草案はこの内訳を注意深く説明する。参照実装以外の四つは、仕様本文から作られ、既存実装には触れず、公開されたプロジェクト提供のtest vectorsと結果を照合した。つまり「本文からの独立実装」ではあるが、「独立したベクトルを持つ独立実装」ではない。失敗、曖昧さ、独自のadversarial inputも報告し、数字だけを販売材料にしていない。

running-code primacyは、コードが反対意見を封じるという意味ではない。文章の曖昧さを再現可能な差に変えるという意味である。二つのverifierが異なるchain headを出す、GENESIS欠落の分類が食い違う、公開材料だけではMerkle rootを再計算できない——そうなれば議論は具体化する。検証記録は、著者の自己申告より強い出発点を審査者に与える。

RFC 7942もrunning codeを、その程度の権限にとどめる。Implementation Statusには成熟度、coverage、version compatibility、license、実装経験、相互運用報告を載せられる。Working Groupは判断材料として使えるが、記載はIETFのendorsementではない。情報は時間とともに古くなるため、RFC出版前には通常削除される。実装は証拠を増やすが、意思決定者にはならない。

凍結後の指摘が示した欠落

五番目の実装記録は、成功数より価値がある。草案によると、当時外部にいた実装者がpala1-v1.0タグを対象にし、公開ベクトルとデモの試験を通したうえで独自の攻撃的ケースを作り、八つの曖昧さとspan pairingの抜けを記録した。

仕様は、クラッシュなら閉じていないspanが目に見えて残るべきだとしていた。ところが、対応付けの検査が定義されず、利用者が何を目にするかがverifier間で一致しなかった。処置は、不完全なtrailを直ちに偽造と判定することではなく、未対応spanをadvisory findingとして表に出すことだった。I-Dはこれを「freeze後に仕様を変えた」runと説明し、発見と理由と結論を公開記録にしたとする。

wireが変わったという証拠ではない。むしろ、プロジェクトの方針は、文章・解釈の修正とfields・offsets・vectorsの変更を分けている。ここが統治上の要点になる。byteが同じでも意味が明確になることはある。必須のverification verdictを変えずに診断情報を追加できる。profileを改訂してもenvelopeは壊れない。どの種類かによって、古いreaderとwriterの負担は異なる。

台帳がなければ、両極端の読み方が生まれる。freeze後に一文変わっただけで「v1.0は凍結されていない」と言う人と、vectorsが同じだから「何の意味も変わっていない」と言う人だ。問うべきは、変更対象、分類者、既存実装に必要な行動である。

凍結された「もの」を特定する

プロジェクトのPALA-1 specificationは156-byteのfixed header、TLV extension、record type、hash chainを定める。未知のformat version、record type、TLVに遭遇しても、verifierはchainを検証し続け、「解釈不能」と報告し、未知であることだけを理由にchain全体を拒否してはならない。

将来版でもoffsetを維持するparsing spineも定義される。magic、format version、header length、record type、sequence、boot ID、previous hash、body length、body digestである。この骨格を凍結する価値は、十年後のreaderが未知のrecordを飛び越し、次の境界を見つけ、chainを検証できることにある。すべての意味を永久に固定することとは違う。

profileは別の対象だ。EVENTのbody、集計項目、Merkle leafの情報源、ORIGIN_ROLEの語彙を決める。一つのchainは一つのprofileに従い、そのprofileはdeployment documentationで示す。共通envelopeを薄く保ち、domain固有の将来選択を現場に残す設計である。

証拠の強さも同様に分かれている。PALA-1は内部整合性、外部anchorに対する完全性、外部witnessに対する時点存在を一つのbooleanにしない。整ったchainでもrecording actorが真実を記録した証明にはならない。これは弱点の隠蔽ではなく、仕様が答えられない問いまで権威を拡張しない姿勢だ。

小さなfreeze-and-change台帳

必要なのは、全commitを承認制にする分厚い制度ではない。互換性の約束と審査記録を結ぶ薄い表で十分だ。

freeze側には、exact commit、tag、vector hash、freeze actor、時刻、exit test、未解決事項を残す。scopeはwire bytes、固定parsing spine、normative semantics、profile、implementation guidance、test artefactsに分ける。「v1.0 frozen」は見出しであって、完全な記録ではない。

後続issueにはstable ID、審査対象revision、affected section、change classを置く。change classはeditorial、interpretive、semantic rule、profile、additive extension、test-vector repair、wire-incompatibleなどだ。decisionを行ったproject roleまたはIETF role、理由、そしてno change、clarification、advisory、profile update、extension、compatibility note、new version、deferredのどれかを記す。

互換性の欄には、v1 readerがrecord boundaryを見つけられるか、chainを検証できるか、unknown recordをrejectせず報告できるか、v1 writerがconformantのままか、profile versionが必要かを書く。訂正は過去を消さずappendする。

機関状態はさらに独立させる。individual I-D、venue discussion、WG adoption、consensus、IESG approval、RFC publicationは別々のstateである。project maintainerはローカルfreezeを管理できるがIETFを代表しない。Working Groupは提案を審査できるがprojectの既存利用者を所有しない。実装者はv1を採用、拒否、forkでき、それを機関承認と呼ぶ必要はない。

二種類の抑制を守る

RFC 2026は、prior implementationとtestingを、technical excellence、明確な文書、openness、fairness、timelinessと並べる。仕様は議論、審査、経験に基づくrevisionを受ける。複数実装は重要だが、手続を短絡する投票券ではない。

PALA-1の順序は、建設的な統治テストになる。プロジェクトは約束をwire互換性に絞り、running evidenceを公開した。IETFは個人投稿を自動でendorsementにしない。変更台帳があれば、後続指摘に対して両方の抑制を維持できる。

Heng Luのminimum initial specificationという視点では、共通層は相互運用に必要な厚さまでにすべきだ。実装は言葉を現実で試す。不変部分を壊さない将来判断はローカルに残す。adoptionは、権限を持つ主体が明示的なstate changeを行うまでvoluntaryである。

次のPALA-1が何も変えない可能性もある。reviewが現行設計を支持する、clarificationを求める、profile問題を見つける、new wire versionを要求する可能性もある。今はどれも断定できない。断定できるのは一つだけだ。frozenという一語に、凍結対象の同一性、compatibility、authorship、IETF authorityのすべてを背負わせてはいけない。

出典

  1. IETF Internet-Draft告知
  2. IETF Datatracker：PALA-1
  3. IETF Datatracker：履歴
  4. IETF archive：draft-sparysh-pala-audit-00
  5. Palimpsests：PALA-1 project specification
  6. commit 50b47edb1ed8：PALA-1 v1.0を凍結
  7. Palimpsests：独立検証記録
  8. Palimpsests：test vectors
  9. Palimpsests：independent runs
  10. RFC 7942：Running CodeのImplementation Status
  11. RFC 2026：Internet Standards Process
  12. RFC Editor：How RFCs Are Created
  13. Heng Lu：Running-Code Primacy
  14. Heng Lu：Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption