要点

  • draft-ietf-anima-rfc8366bis-36は2026年9月9日に公開された。IESG EvaluationのAD FollowupにあるInternet-Draftであり、RFCでも承認済みProposed Standardでもない。
  • 更新時、MASAは新しいRegistrar Voucher Requestを検証し、Domain証明書の失効状態を調べ、前回以後に変わった方針を適用する。所有者の更新停止指示やsupport contract終了も結果を変え得る。
  • 新VoucherはMASAが許可した結果を署名で示す。一方、どの状態情報と方針版が判断に使われたかを運ぶ共通レコードではない。各実装の内部ログについて公開資料から一般化はできない。
  • Daniel Kadeは、wire上のVoucherとは分離した更新判断receiptを提案する。機密を公開せず、MASAやDomain所有者から権限を移さない設計であり、草案の要求ではない。

更新は初回審査の縮小版ではない

第36版は9月9日に登場した。Datatrackerの履歴には新稿の提出と、Revised I-D NeededからAD Followupへの移動が残る。文書はStandards Trackを目指すが、現時点では作業中だ。将来承認された場合にのみRFC 8366を廃止し、RFC 8995を更新する。

35版から36版への差分では、更新時に何を省き、何を残すのかが書き直された。初回発行では、申請者の本人性やpledgeの帰属を確かめる重い確認が必要になり得る。更新はその全工程を繰り返さない。代わりに、以前成立した関係がまだ有効かを確認する。

まずRegistrarが新しいRVRを署名する。MASAはそれを常に検証し、申請側がDomainの秘密鍵へ今もアクセスできることを確かめる。次にDomain identity certificateの失効状態を調べる。さらに、前回発行後に変わった方針を適用する。草案は、Domain所有者が今後の更新停止を求めた場合と、support contractが終了した場合を例に挙げる。

「軽量」は判断が消えたという意味ではない。初回より狭い入力集合を、サービスが自動で評価できるという意味だ。

pledgeが必要とする情報と、監査が必要とする情報

Registrarはprior-signed-voucher-requestに古いVoucherを含め、新しいRVRへ署名する。これにより、継続対象と新しい鍵所持証明が結び付く。

MASAが発行するVoucherは、pledgeが安全にonboardingできるDomainと条件を示す。制約の大きな端末に、契約管理や失効照会の全記録を読ませる必要はない。第36版はmanufacturer-proprietary属性についても、VoucherがRegistrarなどに保存され得る以上、機密性を必要とするデータを入れてはならないとする。

この分離は妥当だ。しかし後日の問いは別に残る。署名は「MASAが許可した」ことを示せる。どのOCSP応答やCRLをいつ観測したのか、どの方針版が動いたのか、契約系がどの状態classを返したのか、例外承認があったのかまでは示さない。

もちろん、実際のMASAが内部ログにそれらを保存している可能性はある。資料は欠落を立証していない。ここで問題になるのは、組織や製品を越えて結果と根拠を対応させる共通の形がないことだ。

一台単位で終わらせられる権限

第36版は、Voucherが一つのserial numberだけを扱う理由も説明する。以前の案は正規表現で複数pledgeをまとめられた。しかし一台だけ所有関係が変わったとき、束全体の更新を止めるのは過大だった。

したがって一台一Voucherはencoding上の都合ではない。拒否の範囲を、変化した支配関係の範囲に合わせる仕組みでもある。serial numberが世界で一意になるわけではないため、issuerのscopeは引き続き必要だ。

判断記録も同じ粒度を守るべきだ。fleet全体の成功率では争われた一台を説明できない。一方で、物理所在地や契約本文を公開する必要もない。対象を固定できる参照と、判断結果のclassがあればよい。

時計の信頼は発行判断とは別に扱う

草案は短命で単独失効できないVoucherを、programmaticに更新する考え方を採る。「短命」の実時間は各onboarding方式が決める。Voucher自体に独立した失効物はなくても、証明書chainの失効は効く。

nonceを持たないVoucherでは、pledgeがexpires-onと内部時計を比較する。第36版は、攻撃者がonboarding中のNTP streamを支配し得るため、ネットワーク時刻を無条件に信頼できないと指摘する。信頼できる耐改ざん時計がなければ、nonceで新しい一時Voucherを取得する方がよい。

MASA側の問いは「発行時に何を見たか」であり、pledge側の問いは「消費時にfreshnessを判断できたか」である。一つのvalid flagへ畳むと、発行、端末時計、Domain照合のどこに境界があったか分からなくなる。

wire形式を変えない最小receipt

更新判断receiptはVoucher本体の外に置ける。記録すべきなのは、古いVoucherと新RVRのdigest、pledgeとissuer scope、固定DomainとMASAのidentity、要求時刻と決定時刻、Domain鍵所持確認、証明書状態の方式・参照・観測時刻・freshness・結果、更新方針IDと版、必要な場合の契約状態class、例外権限、最終判断、新しい有効期間、次回reviewまたは停止triggerである。

詳しい契約や証明書materialはアクセス制限したままでよい。digestとcontrolled codeなら、後で同じ判断を追える。異なるメーカーの商用方針を統一する必要もない。各MASAが自分のどの方針を使ったかを固定すれば足りる。

これはHeng LuのMinimum Initial Specificationが示す境界に合う。独立した参加者が再現するための最小部分だけを揃え、残りの選択は責任主体に残す。The Policy Mirrorの観点では、自動実行が統治方針を不可視にしてはならない。

このreceiptはDaniel Kadeの編集提案であり、ANIMA WGやIESGが採用した仕様ではない。

証拠の限界

RFC 8995はBRSKIの役割とauditの背景を、RFC 5280とRFC 6960は証明書状態の基盤を示す。別のMASA運用草案もなおInternet-Draftである。

これらはrevision差分と権限構造を裏付けるが、実被害、不正更新、古い失効情報、契約紛争、導入率、ログ欠落を証明しない。よって本稿は自動化を危険だとは断定しない。示せるのは、更新が複数入力を持つ新しい支配判断として明文化された一方、共通Voucherはその結論を運ぶものだという境界だけである。

参照資料