Summary

  • 個人提出の現行インターネットドラフトは、RATS を理解する Identity Document Service が証明結果を受け、RATS 非対応のサービスにも扱える鍵、トークン、資格情報を発行する構成を示している。
  • この構成では、証拠、評価方針、配置場所、発行根拠となったクレームが変化しても、従来型サービスは固有の有効期限や失効規則だけで資格情報を受け入れ続け得る。
  • Daniel Kade は、証拠の時点、検証者と依拠当事者の方針版、クレーム分類、ワークロード鍵、変更事象を資格情報のネイティブな失効・状態機構へ結ぶ「証明―資格情報リース」を提案する。これは編集上の提案であり、IETF の合意ではない。

変わったのは場所だけだった

この設計境界は、攻撃を仮定しなくても現れる。ワークロードが Evidence を提示し、Verifier が当時の方針で評価し、Identity Document Service(IDS)が通常の資格情報を発行する。秘密鍵は外へ出ず、経路も保護され、従来型サービスは以前からの検証処理を使う。ここまでは意図どおりである。

その後、オーケストレーターが負荷調整のためにワークロードを移す。draft-bdnr-rats-trustworthy-credentials-02 は、ドイツからフランスへのライブマイグレーションにより Country=Germany が正しくなくなる一方、Region=Europe はなお正しい場合を挙げる。移動そのものは故障でも侵害でもない。それでも、国に依存する権限と地域に依存する権限では結論が分かれる。

下流のサービスに見えるものは変わらない。証明書は期限内、トークンの署名も正しい。したがって、サービスは自らの規則に忠実でありながら、すでに失われた前提に基づく権限を受け入れ得る。問題は検証の誤りではなく、二つの有効性体系を接続した後の責任である。

変更範囲を狭める価値

このドラフトが解こうとする制約は現実的だ。すべての依拠サービスに RATS の Evidence、Attestation Result、評価方針を実装するのは難しい。第三者製バイナリで変更できない場合もあれば、言語や実行環境が合わない場合、規制上の再審査や組織間調整が重い場合もある。全サービスの改修を前提にすれば、一番動かしにくいシステムが導入速度を決める。

そこで、Credential Broker、Key Broker、Credential Authority が RATS の Relying Party と IDS を兼ねる。ワークロードは一つの仲介者に状態を証明し、仲介者は受理可能なら既存サービスが理解する Identity Document を返す。これは鍵、トークン、資格情報の総称で、短期にも長期にもなり得る。ドラフトは鍵仲介、事前配備された所持証明用資格情報、新たな所持証明用資格情報または短期ベアラートークンの発行を扱う。

狙いは、まさに変更の爆発半径を小さくすることだ。TLS や既存の証明書・トークン検証を保ち、秘密鍵をワークロード内に残せる。この利点を捨てて全サービスを RATS 対応にする必要はない。ただし、複雑さは消えず、仲介者へ移る。入口で証明を見えなくした主体が、後の信頼変化も従来方式に翻訳しなければならない。

結果、方針、資格情報は別の時計を持つ

RFC 9334 では、Verifier が Appraisal Policy for Evidence を使って Evidence を評価し、Attestation Result を作る。その後、Relying Party が Appraisal Policy for Attestation Results を用いて、特定用途に十分かを判断する。正真正銘の結果であることと、利用を認めることは同じではない。

さらに、Evidence には用途に応じた鮮度が要り、Attestation Result にも有効な時間幅がある。状態や方針は結果が作られた直後にも変わり得るため、RFC 9334 は競合時間を完全には消せないとする。古い結果を有効期間外まで使わないことは最低限の規律であって、期間内の不変を保証するものではない。

IDS が資格情報を発行すると、第三の時計が始まる。証明書の notBefore と notAfter、トークンの有効期限、失効リストやオンライン状態確認の更新周期である。従来型サービスはこの時計を読めるが、元になった Evidence の時点や評価方針版は通常読めない。証明判断が五分相当の情報に依存するのに資格情報を八時間使えるなら、その差はなくなったのではなく、資格情報の背後へ隠れただけだ。

有効期間を短くするだけでも足りない。十分快速な再証明があっても、すでに流通している資格情報へ新判断を反映する規則が必要になる。失効も、どの資格情報がどのクレームに依存するかが分かり、各依拠サービスが実際に状態を確認して初めて効く。

正しい署名が古い意味を運ぶ

RFC 7515 による JWS は、保護された内容が改変されておらず、署名鍵によって署名されたことを確かめる。RFC 5280 に基づく証明書パス検証は、発行者、名称、制約、期間、設定された失効情報を扱う。所持証明は対応する秘密鍵の制御を示す。しかし、いずれも発行理由となった Evidence の再評価ではない。

従来型サービスが通常の規則で資格情報を受理するのは、その視界では正しい。RATS を知らないよう意図的に設計されたサービスへ「なぜ場所の変化を見なかったのか」と問うのは責任の取り違えだ。IDS は発行時に、変化速度の異なる二つの世界を結んだ。一方に Evidence、Endorsement、参照値、Verifier 方針があり、他方に期限、鍵更新、状態確認、失効がある。その結合を発行後も運用状態として残す必要がある。

単なる監査ログでは不十分だ。インシデント後に「当時は受理可能だった」と確認できても、利用時の権限は止まらない。必要なのは、根拠が変わったときに既存の資格情報へ届く制御経路である。

クレームごとに劣化の仕方が違う

国と地域の違いは、Attestation Result を一個の信号として扱う危うさを示す。配置運営者が変わっても測定対象のソフトウェアは同じかもしれない。設定が変わってもセキュアブートは維持されるかもしれない。評価方針の改訂が一つのアルゴリズムだけを不許可にすることもある。

そこで、資格情報が与える能力ごとに最小限必要なクレームを結び付ける。欧州域内の権限なら国の変更は直ちに失効理由ではない。ドイツ国内処理を条件とする権限なら国は強い依存関係になる。一枚の粗い資格情報に両方を入れると、部分的な訂正ができない。継続させれば過剰権限、全面失効すれば無関係な業務停止になる。

クレーム粒度は可用性と安全性の間の説明責任を作る。変化のたびに全資格情報が落ちる設計は、運用者に信号を無視する誘因を与える。一方、署名が通る限り何も変えない設計は、根拠を失った権限を保存する。なぜある能力を止め、別の能力を残したのかを後から検証できることが重要だ。

申請経路の身元をワークロードと混同しない

ドラフトは EST クライアントがハイパーバイザーやオーケストレーターに置かれ、ワークロードの TCB 外にいる場合を考える。そのクライアントが通信相手として認証されても、返すべきワークロード資格情報の身元を決めてはならない。Evidence と attestation が身元を定め、秘密鍵はワークロード内に残すべきだ。

この区別は発行後にも必要になる。移動や再評価の事象を、単に申請を中継したオーケストレーターのセッションではなく、証明されたワークロード鍵と資格情報へ結び付ける。そうしなければ、通信路ごとの認証は成功していても、別のワークロードを更新または失効させることがあり得る。

LAMPS の CSR attestation ドラフトは隣接する責任を明示する。CA または RA が attestation を使うなら、複数の attestation statement 同士と、CSR の公開鍵との結合に責任を持つ。また、利用要件を Certification Practice Statement に記すべきだとする。これは結合責任を考える材料だが、現在の trustworthy credentials ドラフトに完成済みの仕組みがあることを意味しない。

WIMSE の workload credentials ドラフトも、ワークロード身元を表す資格情報と所持証明を分ける。鍵を持っている事実は提示者を確かめるが、発行時の場所やソフトウェア状態が今も正しいとは証明しない。

証明―資格情報リースという接続記録

Daniel Kade が提案するのは、IDS が維持する「証明―資格情報リース」である。新しい公開資格情報形式を従来型サービスへ要求するものではない。サービスはこれまでどおり期限と失効を扱い、IDS は RATS 側の変化をそのネイティブな機構へ写す。

第一に、資格情報の識別子と種類、ワークロード身元、ワークロード保持公開鍵、所持証明の結合を記録する。次に、発行時の Evidence epoch と鮮度上限、Verifier とその Evidence 評価方針版、IDS の Attestation Result 評価方針版を記録する。方針や Verifier が変わったとき、影響対象を検索できなければ再評価は偶然に頼ることになる。

第二に、能力とクレーム分類の依存表を持つ。国、地域、測定ソフトウェア、鍵保護、運用環境を区別し、必須、参考、寿命短縮だけに利用、といった強さを示す。生の Evidence 全体を複製する必要はない。保護された参照、時点、結果ダイジェストで接続し、保存とプライバシーを制限できる。

第三に、リースの上限を定める。継続観測と確実な状態伝達が同等の制御を与えない限り、資格情報の寿命が最短の重要依存関係を無説明に越えないようにする。常に最短の証明書を選べという主張ではない。長くするなら、どの仕組みが差を閉じるかを明示せよという要求である。

最後に、変更事象と動作を対応させる。移動、鍵更新、Verifier 方針変更、参照値の撤回、ソフトウェア変更、修復失敗、Endorsement 変更に対し、再証明、再発行、範囲縮小、一時停止、失効、または影響なしという理由付き判断を定義する。IDS は動作を記録するだけでなく、各依拠サービスの通常機構へ届いたことを検証する。

失効フラグの先にある最後の一マイル

データベース上の状態を revoked に変えても、利用が止まったとは限らない。状態をキャッシュするサービス、接続開始時だけ確認するサービス、オンライン照会をせず短期資格情報の自然失効を待つサービスがある。既存セッションの扱いも異なる。リースには実際の伝達経路と最大遅延が必要だ。

監査対象は、移動を誰が通知したか、IDS がどれほど早くクレーム依存を再評価したか、どの証明書状態またはトークン失効方式を使ったか、到達不能なサービスをどう扱ったか、置換資格情報の範囲をどう狭めたか、である。API が失効要求を受理した時刻だけでは、権限が止まった時刻を示せない。

例外にも終了条件を持たせる。Verifier 障害の間に三十分だけ継続を許すなら、承認権者、対象、期限、補完的な監視、事後処理を残す。可用性のための一時措置が、古い状態から更新し続ける恒久的な迂回路になってはならない。

現行文書から言える範囲

trustworthy credentials ドラフトは、ベアラートークン経路に別プロトコルまたは拡張が必要で、/serverkeygen も詳細化が要ると明記する。相互認証された機密・完全性保護チャネルや鍵保管には触れるが、発行後の全統治を完成させた文書ではない。

研究基準日現在、これは正式な IETF の立場を持たない個人ドラフトで、変更も失効もあり得る。LAMPS と WIMSE の文書も進行中のドラフトである。凍結した資料には、特定サービスの導入、一般的な資格情報寿命、移動事故、法令違反、性能、採用率を示すデータはない。本稿のリースは標準要件でも実装済み機能でもなく、ドラフト自身が示した状態変化に対する統治案である。

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-bdnr-rats-trustworthy-credentials-02
  5. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/
  6. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/history/
  7. https://author-tools.ietf.org/iddiff?url1=draft-bdnr-rats-trustworthy-credentials-01&url2=draft-bdnr-rats-trustworthy-credentials-02
  8. https://www.rfc-editor.org/rfc/rfc9334.html
  9. https://www.rfc-editor.org/rfc/rfc9711.html
  10. https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-29
  11. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02
  12. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08
  13. https://www.rfc-editor.org/rfc/rfc7030.html
  14. https://www.rfc-editor.org/rfc/rfc5280.html
  15. https://www.rfc-editor.org/rfc/rfc7515.html