要約

  • IESGは8月24日、draft-ietf-rats-endorsements-09をInformational RFCとして公開することについてラストコールを開始した。期限は9月7日で、第09版が正式な審査対象のまま、最終判断はまだない。
  • Anton Sokolovは署名付きの公開コメントで、主張内容が不変であることと、Endorserの資格が評価時にも有効であることを区別し、過去のEvidenceをT1とT2のどちらで評価するのかを問うた。
  • 著者側は、CoRIMに内容と署名の独立した有効期間がすでにあると説明した。コメント投稿者は回答を受け入れ、編集者はその区別を本文にも残すことにした。
  • PR 76は8月28日にマージされた。現在のEditor's Copyはrim-validity、signature-validity、失効、トラストアンカーを説明するが、その段落は番号付き第09版には入っていない。
  • コメント、回答、差分、マージ、次の番号版、プロトコル方針、評価結果、IESG処分を結ぶ「コメント処理レシート」があれば、編集判断をIETF承認に見せかけずに改善の履歴を残せる。

ラストコールは結論ではなく入口である

8月24日のIESG告知は、RATS Endorsements第09版をInformational RFCにするようRATS Working Groupから要請を受けたと伝え、9月7日まで実質的な意見を募った。これは公開決定ではない。

取材時点のDatatrackerは「In Last Call」、revision 09、telechat日なしを示していた。GitHubのmainが先へ進んでも、この正式記録は自動では更新されない。番号付き草案、編集途中のソース、IESGの処分は、参照先も権限も異なる。

RATSでは、Attesterがシステム状態に関するEvidenceを出し、VerifierがReference Values、Endorsements、Appraisal Policy for Evidenceなどを用いて評価する。Verifier OwnerがEvidence評価方針の権限を持ち、Relying Party OwnerはAttestation Resultをどう使うかを決める。Endorserは追加情報を提供する役割であり、署名したことだけで最終判断者にはならない。

第09版の第5節は、Endorsement自体の鮮度をどう示すかを個別プロトコル文書に委ね、証明書の有効期間を例に挙げる。その直後、Environmentの不変な性質を表すstatic claimについては、内容が動的に変わらないため追加の鮮度処理は不要だとする。

文章を分けて読めば矛盾はない。続けて読むと、「内容がstaticなら時間に関する問題はすべて解決した」と受け取る余地が生まれる。

内容が止まっていても、信頼の根拠は動く

Anton Sokolovは公開コメントで、二つの時間を切り分けた。ハードウェアの性質は変わらなくても、メーカー証明書は期限切れになり、鍵は失効し、VerifierのTrust Anchor Storeから該当アンカーが外れることがある。主張の不変性と、それを主張した主体のstandingは独立している。

さらに、T1で生成されたEvidenceをT2で評価する場合、Endorserのstandingをどちらの時点で見るべきか、と問うた。コメントは公開に賛成しながら明確化を求めたもので、脆弱性、被害、実装障害を報告したものではない。

この論点の発見者は公の投稿者である。記事が独自に加えるのは、論点を横取りすることではなく、公開意見がどの回答と変更に結び付き、その変更がいつ次の制度状態へ移ったかを検証可能にする方法だ。

著者のThomas Fossatiはまず確認文を提示した。Endorser-standingの確認はclaim-contentの時間性とは論理的に独立し、T1かT2かはプロトコルまたはappraisal policyの判断だという整理である。Sokolovは賛同し、選択がAttestation Resultから読めることが望ましいと付け加えた。

次の返答は、既存の機構を示した。Fossatiによれば、CoRIM processorは内容とEndorser署名に別々のvalidity windowを持ち、署名の有効性、失効、トラストアンカー状態を評価時に確認する。Attestation ResultがVerifierを識別できれば、そのエンジンがT2を使ったことも解釈しやすい。Sokolovは懸念を取り下げ、新機構より既存機構で答えられたことを歓迎した。

ここで会話を閉じることもできた。編集者は、会話だけでなく草案にも跡を残した。

PR 76は「二つ」より多くの時間を見せた

PR 76は8月25日に開かれ、複数の編集コミットを経てDave ThalerとHenk Birkholzのapprovalを受け、8月28日にbb53db0c7c6203f82cfad9cd3c4b5eaf8b6fd624でマージされた。

現行のEditor's Copy第5節は、単なる証明書失効の注意書きではない。同じファームウェア測定値Hでも、脆弱性が判明する前のEndorsementはtrusted、判明後のEndorsementはuntrustedという判断になり得る、と説明する。この二通は、standingを保った同じEndorserが署名していてもよい。そこで、どの内容が当該時点に適用されるかをrim-validityで区切る。

別に、Endorserの鍵・証明書・トラストアンカーの状態がある。これはsignature-validityで境界を持ち、例示されたCoRIM processorでは失効およびアンカー状態とともに評価時点で確認される。T1かT2かの決定は個別プロトコルまたは方針が文書化すべきものとされた。

したがって、実務上は少なくとも三つの変化がある。Environmentの値、Endorserがその値に与える評価、Endorser自身のstandingである。一つの緑色の「valid」に畳み込めば、各検査は正しくても全体の理由が失われる。

マージ済みと発行済みの間に線を引く

PR 76の差分、レビュー、approval、merge commitは公開されている。それでも、現在のレンダリング名はdraft-ietf-rats-endorsements-latestであり、revision 10でもRFCでもない。Datatrackerのrevision 09には追加段落がない。

これは編集作業の不整合ではない。Internet-Draftは更新される作業文書で、次の番号版を提出する前にレビュー結果を統合する場所が必要だ。問題は、後の説明からラベルが落ちる場合である。「編集者が修正をマージした」「Working Groupが09版を提出した」「IESGが公開を承認した」は、それぞれ別の行為である。現時点で証明できるのは最初の二つだけで、しかも同じ本文を指していない。

Heng Luのmandate launderingという見方を当てると明瞭になる。リポジトリは編集者が受け入れたbytesを示せるが、IESGの権限を作れない。一方、公式の09版だけを見て新しい修正を「存在しない」と扱うのも、実際の編集状態を消してしまう。必要なのは統合ではなく、接続である。

コメント処理を一枚のレシートにする

証拠はすでにMail Archive、GitHub、Editor's Copy、Datatrackerにある。新しい審査機関を設けず、これらを一つの処理レシートで結べる。

レシートの最初には、投稿の安定URL、日時、投稿者、対象revisionとsection、そしてaccepted、partly accepted、existing mechanismでanswered、deferred、rejectedなどの処分を書く。次に編集者の返答、issueまたはPR、headとmerge commit、reviewer、merge時刻、変更点と非変更点の短い説明を置く。

その先に、変更を初めて含む番号付きInternet-Draft、IESG state、存在する場合はRFC番号を接続する。本件なら、content-validityとEndorser-standingの各window、Evidence time、appraisal time、T1/T2を選ぶpolicy owner、結果を解釈できるVerifierまたはpolicy versionも必要だ。

最後にnon-conclusionを残す。コメントが有益でもIETF consensusとは限らない。ソースがマージされても公開承認ではない。署名が正しくても、主張の真実性、組織的な権限、デバイスのtrustworthinessを単独では保証しない。

私的な会話を公開する必要はない。公開URL、hash、role、timestamp、dispositionで足りる。このレシートはメーリングリストやIESGを置き換えるためではなく、ある層の証拠が次の層の権限を装うのを防ぐためにある。

情報源