要約

  • RFC 9734 は、IM のアイデンティティ資格情報を署名する鍵の用途として id-kp-imUri、OID 1.3.6.1.5.5.7.3.40 を登録した。汎用の TLS クライアント／サーバー認証とは分離するための識別子である。
  • EKU が表すのは鍵の目的である。アカウントの URI は subjectAltName、信頼経路は PKI 検証、期待名との一致はアプリケーション、現在の支配と権限はアカウント・端末・グループの各ポリシーが担う。
  • MLS の X509Credential は証明書公開鍵と LeafNode の署名鍵を結ぶ。それでも、許容する参照識別子の選択と検証はアプリケーションと Authentication Service に残る。

夜間当番のアカウントを新しい端末へ移す。古い端末にも有効期限内の証明書が残り、どちらも同じ IM URI を提示する。二枚の証明書に id-kp-imUri があり、どちらのチェーンも通ったとき、新しい端末だけを参加させる根拠はどこにあるのか。

EKU にはない。

RFC 9734 は 2025 年 2 月、インスタントメッセージのクライアント識別資格に用いる X.509 の Extended Key Usage を標準化した。一般的な id-kp-clientAuth や id-kp-serverAuth を使うと、IM 用に発行した証明書が別プロトコルで受け入れられる可能性が広がる。そのため発行者には、狭い id-kp-imUri と汎用 EKU を併記しないことが推奨される。

これは重要な防御である。ただし、防御の意味は「何に使ってよいか」を限定することであり、「誰が今そのアカウントを持つか」を決めることではない。

証明書の中でも、目的と名前は別の証拠である

RFC 5280 では、Extended Key Usage は認証された公開鍵の用途を示す。Subject Alternative Name は証明書主体に識別子を結び付ける。URI の場合は uniformResourceIdentifier として格納される。

したがって id-kp-imUri が存在しても、そこからアプリケーションが期待する im: URI は導けない。逆に subjectAltName に正しい URI があっても、IM 資格用の狭い用途が自動的に付くわけではない。署名チェーンが正しくても、アプリケーションが期待した URI を知るわけではない。

RFC 3860 は im: URI を INSTANT INBOX の識別子として定義し、S/MIME の IM 操作用証明書では参照整合性のため subjectAltName に対象 URI を含めるよう勧告する。同時に、抽象サービス自体にはアプリケーション層の配送保証がない。宛先を記述できることと、その人へ届いたことは最初から別である。

XMPP でも同じ圧縮は許されない。RFC 6121 の JID はアカウントやリソースを識別する一方、roster の更新などには送信者の権限確認が要る。識別子の正しさは操作権限の代用にならない。

40 という番号は相互運用の座標である

IANA の SMI レジストリ は PKIX の Extended Key Purpose に 40 を割り当てる。これにより発行者と実装は同じ OID を同じ目的で解釈できる。レジストリは個別のアカウント審査や端末登録を行わない。

RFC 9734 は EKU を critical にするかどうかを発行者へ委ねる。RFC 5280 は、アプリケーションが特定用途の存在を受け入れ条件にできるとする。つまり効果は実装の拒否経路で決まる。

id-kp-imUri を数えるだけでは導入実態を誤る。clientAuth、serverAuth、anyExtendedKeyUsage が併記されていないか。critical な未知拡張を正しく拒否するか。IM 用途がない証明書を IM 検証器が受け入れないか。同じ鍵が別プロトコルへ持ち出されていないか。これらを一緒に見なければ、狭い OID は広い運用の飾りになる。

チェーン検証には「期待した名前」という入力がない

証明書経路の検証は、署名、有効期間、信頼アンカー、制約、ポリシー、Key Usage、EKU を処理する。ある PKI ポリシーで証明書を受け入れられるかは判断できるが、利用者がどの IM アカウントを認証しようとしたかは生成できない。

RFC 9525 はサービス識別の文脈で、証明書が提示する識別子とクライアントが期待する参照識別子を分ける。この語彙は IM でも有用である。証明書側の名前だけ保存しても、比較対象がなければ同一性の判断を再現できない。

一枚の証明書が複数 URI を持つ場合、どれを採るかはアプリケーションの問題である。エイリアスが変更された場合、旧 URI の署名は消えない。検証記録には参照識別子、提示識別子、比較規則、信頼アンカー、ポリシー、時刻、結果、理由が必要だ。

MLS は鍵のすり替えを防ぐが、アカウント政策を決めない

RFC 9420 の X509Credential では、末端証明書の公開鍵と LeafNode の signature_key が同一でなければならない。これは credential と MLS 署名鍵の対応を固定する重要な規則である。

その後の識別判断は Authentication Service に残る。アプリケーションがメンバーに期待する参照識別子を持ち、credential が提示識別子を提供する。サービスは提示識別子が credential に正しく結び付くこと、さらに参照識別子を認証することを検証する。追加や更新で新しい credential が現れれば、所定の時点で再検証する。

監査可能な参加判断は少なくとも次を分離する。

  1. 証明書公開鍵と LeafNode 署名鍵の一致。
  2. チェーン、期間、制約、EKU の受理。
  3. 期待 URI と提示 URI の一致。
  4. その端末が、そのグループ、その role、その epoch に参加できるというローカル決定。

一つのアカウントを複数端末が共有できるため、アカウント URI はクライアント固有の座標ではない。RFC 9420 も、アプリケーション識別子がクライアントを一意にしない場合を認め、leaf index は epoch 内でのみ意味を持つとする。管理端末と私物端末を区別するなら、別の登録証拠が必要になる。

発行後、時間が証拠の意味を変える

アカウント停止、端末紛失、人事変更、tenant 移行、グループからの除外は証明書の有効期間より速く起こり得る。静的証明書は自分を書き換えない。

RFC 6960 の OCSP は good、revoked、unknown を返す。good の最小限の意味は、対象シリアルの証明書が有効期間内に失効として記録されていないことだ。発行済みであることや総合的な有効性まで保証しない。thisUpdate、nextUpdate、producedAt により、その回答の時間的範囲が決まる。

RFC 9734 が参照する draft-barnes-mimi-identity-arch-02 は、短期証明書、OCSP、CRL などを E2E 識別の候補として論じる。これは作業中の草案であり、実装済みという証拠ではない。それでも、失効情報は証明書外から供給されるという境界は明確である。

緑の表示を、再現できる証拠へ戻す

発行時には要求 URI、アカウント証明方式、権威、ポリシー版、鍵保有証明、subjectAltName、EKU、シリアル、有効期間を残す。検証時には参照と提示の両識別子、比較規則、経路、信頼アンカー、EKU 判定、失効源、鮮度、失敗時動作を残す。MLS では LeafNode、credential 指紋、Authentication Service の判断、group ID、epoch、端末、参加規則を残す。配送結果は配送系が実際に観測した範囲だけを記録する。

規範のテキスト、XML、RFC Editor 情報、errata、IETF 履歴は文書の来歴を示すが、製品導入を示さない。

Heng Lu の動くコードを優先する原則は、どの拒否条件が実際に実行されたかを問う。最小の初期仕様は共通層を用途 OID に絞り、アカウントや参加判断を局所責任として見える形にする。現実の層を守れば、登録番号、証明書拡張、名前一致、権限、結果を一つの事実に混ぜずに済む。

RFC 9734 は「検証済み」を増やしたのではない。用途について、より小さく正確に語る手段を増やした。

出典