要約

  • draft-birkholz-did-x509-03 は、葉を先頭にした提示チェーンの末尾証明書を経路検証用アンカーとして使い、非葉証明書のフィンガープリントと葉の述語を照合する。
  • そのアンカーはアルゴリズムへの入力であり、依拠当事者のトラストストアへ自動登録されるものではない。CA、DID、利用文脈を受け入れるローカル方針が別途必要になる。
  • 解析、信頼、メッセージ署名、目的別認可、永続化、外部効果は個別の受領証に分けるべきだ。第03版は独立提出の Informational Internet-Draft で、RFC でも IETF 標準でもない。

改札機に、利用者が改札機そのものの信頼設定まで持ち込めるとしたらどうなるだろう。カードの署名連鎖は美しく閉じ、記載事項も一致する。しかし最後に「この発行者を認める」と決めたのがカード自身なら、検査は信頼判断ではなく自己完結した主張になる。

did:x509 第03版が示す境界は、この比喩より精密である。永続的な DID 文書レジストリを置かず、DID が証明書の条件を示し、解析時にチェーンを提示する。そこから公開鍵と検証関係を再構成できる。ただし再構成可能性は、受け手が発行者を採用したという意味ではない。

一枚の証明書ではなく集合を指す

識別子は did:x509:0 に続き、フィンガープリント方式、フィンガープリント、少なくとも一つの述語を持つ。SHA-256、SHA-384、SHA-512 が対象で、フィンガープリントは中間 CA または末尾アンカーなど非葉証明書に対して計算される。述語は葉証明書を絞り込む。

subject は選んだ主体名属性の部分集合一致、san は電子メール、DNS、URI のいずれか一値、eku は Extended Key Usage の OID を調べる。fulcio-issuer は https:// を復元して Fulcio issuer 拡張と照合し、その拡張が存在し non-critical であることを求める。

同じ DID に複数の葉チェーンが対応できるため、証明書更新を越えて識別子を維持できる。一方、緩い述語は予想以上に広い証明書集合を認める。組織名の一部が合うこと、SAN にドメインがあること、特定 EKU があることは、特定のリリース承認や資源操作の権限を意味しない。述語は候補を選ぶ仕組みであり、業務権限そのものではない。

チェーン末尾の「信頼」は局所的な呼称である

x509chain には完全な DER 証明書を base64url 化してカンマ区切りで入れる。順序は葉から始まり、ルートまたはアンカーが最後に来る。二枚未満は拒否される。

解析器は RFC 5280 の証明書経路検証を行う。署名だけでなく、基本制約、名前制約、ポリシー、鍵用途、critical 拡張、アルゴリズム、検証時刻を扱う。そのうえで DID のフィンガープリントが非葉証明書に一致するか、全述語が葉に一致するかを確認し、葉公開鍵から JWK と DID 文書を得る。

この処理では末尾証明書を trust anchor と呼ぶ。しかしそれは今回の経路検証を閉じるための入力である。受け手が管理するトラストストアに同じ証明書が採用されているとは限らない。送信側が提示した末尾証明書を無条件にローカル信頼へ昇格させれば、証拠提出者が審判者まで選ぶことになる。

RFC 9360 は COSE が運ぶ証明書チェーンについて、受信した材料でアプリケーションの設定済みトラストアンカーを黙って更新してはならないとする。同じ統治原則がここにも必要だ。

受領証 確認できること まだ確認できないこと
DID 構文 バージョン、方式、述語が正しく符号化されている 正当なチェーンが条件を満たすか
提示チェーン検証 指定条件で葉から末尾証明書まで経路が成立する 末尾証明書を組織が信頼するか
指紋・述語一致 DID の表す証明書集合に入る その集合が目的に対して十分狭いか
ローカル信頼 この文脈で CA または DID を受け入れる 対象メッセージの署名が正しいか
署名検証 対象バイトを解決鍵で検証できる 署名者がその行為を許されているか
認可・コミット 主体、操作、資源の許可と保存が確認できる 主張された外部効果が生じたか

DID の可読部分を先に信じてはいけない

述語は文字列中に見えるため、アプリケーションが組織名やドメインを直接抜き出したくなる。第03版は、検証済みチェーンによる解析前に識別子要素を認可へ使わないよう求める。

構文上正しい DID は誰でも作れる。著名な組織名を含めても、それだけでは CA も葉証明書も何も承認していない。チェーン照合後でさえ、受け手の CA 採用判断が残る。文字列、証明書、ローカル信頼、署名、用途認可を順序どおりにつなぐ必要がある。

時刻を変えれば同じチェーンの結論も変わる

草案は、現在時刻または署名時刻のような文脈上適切な時点で経路検証することを認める。現在は期限切れでも、真正な過去の署名時には有効だった可能性がある。JWT や CWT の iat は、存在するだけで信頼できる時刻にはならない。RFC 7519 と RFC 8392 のクレームを、完全性と採用方針の両面で評価しなければならない。

失効確認はアプリケーションが要求する場合に CRL、OCSP などで行う。証明書透明性、endorsement、脆弱なアルゴリズムの拒否も追加できる。「有効」という一語では、時刻、失効要求、応答の鮮度、アルゴリズム方針を再現できない。

RFC 9597 や RFC 9943 の透明性・登録受領証にも共通するのは、証拠を運ぶ形式と、それを受け入れる制度を分ける考え方である。

更新操作がないことは権力がないことではない

did:x509 には DID 文書の更新操作も更新認可もない。無効化操作とその認可もない。作成はローカルで、解析は DID と提示チェーンの組み合わせで行う。

一致する全証明書が期限切れまたは失効すれば、事実上使えなくなる。しかし CA が同じ述語を満たす新しい葉を発行できれば復活する。したがって「無効化らしさ」は不可逆な DID 操作ではない。CA の運営権、述語の幅、依拠当事者の許可リストこそが継続性を決める。

複数チェーンが同じ DID を満たすと、解決される葉鍵も異なり得る。監査記録には安定した DID だけでなく、そのメッセージに実際に使ったチェーンと verification method を残す必要がある。

実装は一覧より差分を見る

第03版は Microsoft の実装に加え、Nuts Foundation、署名、SCITT、CCF、confidential container の利用例を記す。Microsoft の README、実装仕様、テストベクトルは、実行可能な比較材料になる。

とりわけ重要なのは、Nuts 実装と第03版の間で eku の範囲や otherName SAN 拡張に差があるという記載だ。実装数は相互運用性を証明しないが、具体的差分は次に試すべき境界を教える。実装情報は寄稿者の申告であり、IETF の承認ではない。

第02版は Standards Track を意図していた。第03版は Informational に変更し、信頼モデル、操作、解析、プライバシー、実装状況を拡充した。Datatracker、履歴、I-D 公告から確認できるのは、独立提出の作業中文書であることだ。RFC でも IETF 製品でもない。

W3C DID Core と DID Specification Registries は DID 文書や検証関係の全体枠組みを与えるが、この方式の標準化状態を変更しない。

判断を再現するための台帳

正確な DID とデコード済み述語、順序付き DER 証明書、証拠パッケージのハッシュ、経路構築・検証結果、検証時刻、名前・ポリシー・制約・鍵用途・critical 拡張・アルゴリズムの判断、失効と透明性、フィンガープリントが一致した証明書、全述語の結果、ローカル信頼規則と版、生成 DID 文書と JWK、署名対象と covered bytes、署名結果、目的別の主体・資源・操作、コミット識別子、外部観測を保存する。

未実施は成功へ置き換えない。失効確認を方針上求めなかったなら not_required_by_policy であり good ではない。ローカル信頼を見ていなければ not_evaluated であり trusted ではない。

Lu Heng の Minimum Initial Specification は、共有層を検証可能な最小機構にとどめ、将来の判断をローカルに残す。Running-Code Primacy は実装差と効果の軌跡を重視する。The Policy Mirror はトラストストアを管理する主体を可視化し、Reality Layers は文字列、証明書、判断、実行を一つの成功記号に潰さない。

出典