要約

  • 草案08は、複数のVOPRF評価を一つの証明で検査する方式と、位置ごとに応答が欠け得る汎用方式を分けている。
  • 各トークンには新しいnonceが必要だが、HTTP 200、206、あるいは有効なバッチ証明だけでは、最終化・永続保存・一回限りの使用・サービス結果の個数は分からない。
  • 運用者は段階ごとの個数を突き合わせる必要がある。ただし、その台帳が発行と後日の償還を結ぶ追跡装置になってはならない。

一括発行を倉庫の入荷にたとえると、問題は見えやすい。発注書に八十個と書かれ、配送車が到着し、封印も正しい。それでも棚に八十個あるとは限らない。箱の中身を照合し、不良品を除き、在庫システムの取引を確定して、初めて「使える八十個」になる。

匿名トークンでは、暗号証明の強さがこの当たり前を隠す。「証明が通った」という表現が、倉庫の全工程を終えたかのように聞こえるからだ。

draft-ietf-privacypass-batched-tokens-08 は2026年5月4日付のInternet-Draftで、Privacy Pass WGからIESGへ提出されている。だが調査時点の状態は AD Evaluation::Revised I-D Needed であり、RFCではない。IANAの現行Token Types表にも、草案が提案する 0x0005 はまだ載っていない。

一つの「バッチ」に二つの設計思想がある

Amortized Privately Verifiable方式では、同じ私的検証型の複数のblinded elementをまとめる。発行者は要素ごとに評価し、入力列と出力列全体に対する証明を一つ作る。クライアントはその証明を検証してから、各位置のauthenticatorを取り出す。

Generic方式は、通常のTokenRequestを並べるコンテナである。異なる登録済みtoken typeも混在できる。応答は各位置にoptional valueを持ち、空なら、その要求について発行者が失敗したか拒否したことを示す。一部だけ発行した場合はHTTP 206を返し、後続要求の処理を続ける。

前者は共同の検証ゲートを持つ。後者は部分成功を位置ごとに見せる。どちらも「バッチ成功」という一個の状態に丸めれば、本来の回復情報を失う。

実務では、要求数、受理数、応答ありの位置数、最終化成功数、永続コミット数、利用可能残高を分ける必要がある。これらが一致するのは、すべてが正常に進んだ後だけだ。

nonceが新しくても、在庫台帳は自動では生まれない

amortized方式では、クライアントはトークンごとに新しい32バイトnonceを生成する。token inputにはtoken type、challenge digest、発行者のkey identifierも入る。複数の入力が一つの要求に乗っても、暗号上は各トークンが別の入力を持つ。

ところが実装は、i番目の評価結果をi番目のnonceへ正しく戻さなければならない。順序の入れ替え、切り詰め、境界の取り違えは、バッチ証明という大きな成功表示の内側で起こり得る。

さらに、最終化後にはストレージの責任が始まる。データベースへの書込み前にプロセスが落ちる。半分だけ書いて再起動する。再試行で新しい有効トークンが増える。古いバックアップが、すでに使った記録を復活させる。

fresh nonceは暗号入力の再利用を防ぐ条件であって、行の重複、二重選択、バックアップの整合性を証明しない。ここを混同すると、正しいプロトコルの上に間違った残高が構築される。

位置対応の情報は最終化とコミットに必要な期間だけ保持し、その後は縮小すべきだ。永続batch IDを各token recordと償還ログへ残せば、監査基盤そのものが相関器になる。

半分になるのは主に証明コストである

草案は、BlindEvaluateBatch の計算量が Nr に対して線形だと明記する。各blinded elementの評価は残る。減るのは証明生成の重複であり、Nr が大きくなると実用上のコストが個別発行 Nr 回のおよそ半分に近づくという説明だ。

解析、通信、quota判定、クライアント状態、最終化、保存まで半分になるわけではない。Generic方式も本質的に線形である。

また、共同証明は共同の失敗範囲を作る。未対応type、発行者が持たないtruncated key ID、上限を超える個数、あるいは一個でもdeserializeできないblinded elementがあれば、amortized要求は422となる。クライアント側でも証明検証に失敗すれば全体を中止する。

大きなバッチは効率を上げるが、一つのparser、一つの鍵、一回のadmission、一つのproof gateの背後に、より多くの将来利用を置く。大きさはベンチマークだけでなく、相関した損失を回復する費用で決めるべきだ。

206は「失敗」ではなく、欠けた場所を読む命令である

Generic方式が価値を持つのは、不完全さを隠さないからだ。中間の位置が空でも、その後の位置に応答が続き得る。

クライアントは206だから本文を捨ててはいけない。2xxだから全件を数えてもいけない。optional responseを一つずつ確認し、空を飛ばし、非空値を対応するtoken typeの手続で最終化し、永続コミットできた分だけ残高へ加える。

草案は、同じtoken typeの要求に複数のtruncated token key IDが混在する場合を206の例に挙げる。鍵移行期の設定ずれを示す可能性がある。全件再送だけを行えば、この有用なシグナルを消してしまう。

会計式は次のようになる。

requested ≠ response-present ≠ finalized ≠ committed ≠ available ≠ redeemed

「issued」という一語を使うなら、誰の視点かを書かなければならない。issuerが返した、clientが最終化した、storeが確定した、という事実は別々である。

retryは通信ライブラリの既定値にしてはならない

206を受けた後、空の位置だけを再試行するのか、全体を作り直すのか。通信断のとき、発行者がすでにquotaを消費したかどうかをどう判断するのか。最終化後にstoreが落ちた場合、再発行すべきか、ローカル取引を復旧すべきか。

これらはローカル状態なしには決められない。全体再試行は新しい正当なトークンを追加で作るかもしれない。部分再試行には正確な位置対応が要る。再試行しない方針は残高を守るが、業務を在庫切れにすることもある。

位置ごとに、秘密を露出しないrequest digest、type、key epoch、応答の有無、finalization、commitを記録する。timeoutだけを再試行許可にしてはいけない。timeoutは観測が途切れた事実であり、相手が何もしなかった証拠ではない。

上限は能力値であると同時に配分ルールである

発行者はamortized batchの最大個数を定められる。Generic側でも上限を超えた要求を無視できる。Security Considerationsは、clientごと、keyごとの制限も勧める。

上限が大きいほど、clientは一回のattestationや接続から多くの将来在庫を持てる。オフライン耐性は上がるが、漏洩時のbearer valueも増える。上限が小さいほど、発行者は利用に近い位置に残り、時間的な観測も増え得る。

したがって上限は単なる実装定数ではない。所有者、版、変更記録、例外、監視が必要な配分政策である。IETFが揃えるべきものはwire formatとエラー意味であり、すべての運用者のquotaではない。

IANAの行は導入証明ではない

草案08は0x0005と四つのmedia typeを求めている。今回凍結したIANA表には0x0005がない。Security ADの9月20日コメントも、suggested valueや参照の整理、HTTP Directorateのearly reviewを求めている。

これは通常の標準化作業である。却下でも、脆弱性認定でもない。ただし証拠の順番を守る好例だ。Internet-Draftの提案、IANA allocation、software support、interoperability、実際の交換、finalization、inventory、application outcomeは互いの代わりにならない。

shepherd write-upは、小さなWGでの強い合意とimplementation reportを述べる。全実装一覧や相互接続結果は示していない。したがって「実装報告のあるIESG評価中の仕組み」と書くのが妥当である。

監査のために匿名性を売り渡さない

RFC 9576はattestation、issuance、redemptionのcontextを分ける。Privacy Passのプライバシーは、誰がどの観測を結合できるかに依存する。

バッチには時刻、サイズ、発行者、key epoch、ネットワーク入口というメタデータがある。ローカル台帳が恒久的なbatch ID、端末、アカウント、後日の償還を結べば、暗号上のblindnessを運用ログが打ち消す。

集計値と一方向digestを優先し、位置対応の保持期間を短くし、発行ログと償還分析の権限を分ける。batch IDをorigin requestへ持ち込まない。例外的な調査で結合するなら、目的、期間、承認を限定する。

求めるのは「在庫が合う」という証拠であって、「第912バッチの37番が後にどの行動へ使われたか」を平時から検索できる能力ではない。

不足しているreceiptを三層で作る

Batch層には、方式、issuer endpoint、token type、challenge/config digest、key epoch、requested count、HTTP status、response vector length、proof/response digest、適用上限、時刻を置く。

Position層には、一時的なrequest digest、応答有無、deserialize、finalization、local record digest、commit statusを置く。順序の証明が終われば削除規則に従う。

Inventory層には、opening balance、committed additions、quarantine、deletion、selection、confirmed redemption、ambiguous outcome、closing balanceをtransactionalに置く。200を受けてNrを足すのではなく、finalize済み・非重複・durable commit済みのrecordだけをavailableへ足す。

償還は別のreceiptを持つ。challenge適合、提示、replay state、origin authorization、application effectを記録する。二つのreceiptの連結は保護され、目的が限定されなければならない。

全体は次の鎖になる。

設定 -> attest -> request -> admit -> respond -> finalize -> commit -> select -> redeem -> authorize -> observe

一括発行が短縮するのは費用であり、権限の境界ではない。