要約

  • IESGは9月2日、証明書申請に遠隔アテステーションを載せる草案の第29版について最終意見募集を開始した。締め切りは9月16日で、まだRFCとして承認された文書ではない。
  • 同じ形式識別子を複数の検証者が扱う場合、宛先選択の曖昧さを解く責任は、その形式の仕様に置かれている。

証明書の申請システムに検証サービスを追加するとき、「対応形式が一致する」という説明は出発点になる。ただし、それだけでは受信した証拠をどの検証者に渡すか決まらないことがある。形式を読める相手が複数いれば、処理先を選ぶための約束が要る。

9月2日に公表されたIESGの最終意見募集は、この分担を示す草案を対象としている。文書は draft-ietf-lamps-csr-attestation-29。Proposed Standardへの移行を検討し、9月16日まで意見を求めている。告知は導入実績やRFC承認を意味しない。

草案はPKCS#10とCRMFの証明書申請に、遠隔アテステーションのデータを載せる構造を定める。標準化された形式も独自形式も想定する。認証局CAや登録局RAは、自ら検証する構成と、外部の検証者に処理を依頼する構成を採れる。

共通の入れ物が決めないこと

第29版の4.3節は、同じアテステーション形式のオブジェクト識別子、OIDに複数の検証者が対応する場合を取り上げる。解決策として、構造が同じでも検証者や検証の種類ごとにOIDを分ける方法と、明示的なヒントを持つラッパーで包む方法を推奨する。具体的な配送先選択とnonce選択の仕組みは、各形式の仕様で明確にする。

OIDをサーバーのアドレスとして扱うという話ではない。形式の識別と、その形式を扱うサービスの選択は異なる。草案はすべての形式に一律の宛先規則を与えるのではなく、規則を完成させる側を示している。

実装では、この対応関係を管理する主体が重要になる。対応表を変えれば、証拠を評価するサービスが変わり得るからだ。接続仕様には、読める形式だけでなく、採用する選択規則と、ヒントがない場合や矛盾する場合の扱いも記されている方がよい。これは互換性の説明を、実際の処理に近づける。

外側の登録と内側の形式を分ける

確認時点のIANAのS/MIME属性表では、番号59は id-aa-evidence として掲載されている。草案は番号を維持したまま id-aa-attestation に改称するよう求める。この登録はCSRの外側の属性に関するもので、検証サービスの一覧ではない。

内部に載せる各証明形式のOIDについては、4.2節が形式の仕様作成者に割り当てを委ねる。作成者は自ら管理する識別子の枝を用いる。外側の登録項目を見ても、個々の導入先がどの検証者を選ぶかは分からない。維持する対象も責任者も違うためだ。

RFC 9334のRATSアーキテクチャでは、検証者の管理者が証拠の評価方針を定め、結果を利用する側の管理者がその利用方針を定める。処理先の選択は、単なるデコード機能だけでなく、評価の前提を選ぶ行為にもなり得る。同じ組織が両方の役割を担っても、責任の違いは残る。

運用上の確認方法としては、同じ形式に対して仕様で定めた選択条件を変え、意図した検証者が選ばれるか試すことが考えられる。これは本稿の提案であり、IETFの追加義務ではない。また、配送が成功しても、その後の確認は残る。第29版は申請公鍵とアテステーションの結び付きを確かめる責任をCAまたはRAに置いている。

今回確認した資料には、誤配送の事故やサービス切り替え費用の実測値はない。最終意見募集で注目すべきなのは、この設計上の分担だ。共通の入れ物が接続作業を軽くしても、処理先の互換性は明示された別の約束に依存する。

出典

  1. IESGの最終意見募集
  2. CSRアテステーション草案第29版
  3. RFC 9334
  4. IANAのSMI番号登録