要約

  • RFC 10004は、全エンティティ、クライアント、サーバー、EE、RA、CAに異なる要件を割り当てる。一つの構成要素が複数の役割を同時に持つこともある。
  • 監査可能な準拠記録には、版、役割グラフ、条件機能、アルゴリズム、構成時点、取引経路、結果を結び付ける必要がある。

監査人が二つの箱を見た。左は申請を受け、右へ転送する。右は証明書を発行する。左の箱には「CMC準拠」とある。しかし、その札は左向きのサーバー機能を指すのか、右向きのクライアント機能を指すのか、登録機関としての義務まで含むのかを示していなかった。

これは架空の場面であり、特定製品の評価ではない。RFC 10004を運用資料として読むと、準拠の主語を省けない理由が見える。

単純なCMCでは、エンドエンティティがクライアント、認証局がサーバーである。RAを挿入すると、RAは申請者に対してサーバー、CAに対してクライアントになる。RAは複数置け、申請内容で経路が変わり、すべてのRAがすべての申請を見るとは限らない。

RFC 10004は要件を六つの適用範囲に分ける。全エンティティ、全クライアント、全サーバー、EE、RA、CAである。役割は製品名に固定されず、通信の辺と設定された業務によって重なる。

メッセージ構造と制御はRFC 10002、転送方式はRFC 10003が定める。RFC 10004は、各役割が何を実装すべきかを定める。RFC Editorの記録と正誤表検索は判定対象の版を固定する。

共通の下限として、全エンティティはFull PKI Request、SimpleとFullのPKI Response、CRMF、HTTP転送を扱う。サーバーにはSimple PKI RequestとPKCS 10の実装が推奨される。だが実運用を左右するのは、その後の役割別表と条件注記である。

RAと連携するよう設計されたCAには、RA向け制御の一部が必須になる。RAが本人確認や鍵生成を担う環境では、EEのResponse Body要件も強くなる。Encrypted POPとDecrypted POPは、鍵共有、署名できないハードウェア鍵、委任されたPOPの有無で適用が変わる。

つまり、同じソフトウェアでも役割を追加すれば準拠範囲が変わる。昨年の試験が正しくても、新しいRA経路の根拠にはならない。

暗号要件も経路依存である。SignedDataのRSA-SHA256、EnvelopedDataのAES、所定長を持つAES-GCM、RSA鍵配送が基礎になる。DH、PBKDF2、AES Key Wrap、HMAC-SHA256は機能条件に応じて必要になる。RFC 5652はCMS、RFC 5754はSHA-2、RFC 5084は認証付き暗号を規定する。

ライブラリにアルゴリズムがあることと、一件の申請で正しいアルゴリズムとパラメータが使われたことは別である。実装能力、設定、実行、次の機関による受理を一つの判定に畳んではならない。

所有証明では責任主体がさらに重要になる。CAは発行前にPOPを強制しなければならないが、限定された場合にはRAへ委任できる。DH方式はRFC 6955にある。必要な記録は「POP対応」ではなく、誰が、どの申請に、どの方式と委任規則を適用したかである。

基準には時間もある。RFC 10004はRFC 5274を置き換え、RFC 6402の更新を統合した。古いSHA-1中心の基準からSHA-256へ移る一方、後方互換のため旧方式の提供を許す。これは旧利用者を把握して移行するための猶予であり、永続的な既定値ではない。

証明書が出ても、依拠の判断は別に残る。RFC 5280がPKIXの証明書と経路検証を扱う。CMC準拠は、名称への権利、経路受容、アプリケーション権限、サービス結果を証明しない。

Heng LuのReality Layersは、標準、能力、構成、実行、発行、利用を分離する。Running-Code Primacyは実行挙動を優先し、Minimum Initial Specificationは共通契約を検証可能な最小範囲に留める。

準拠票に必要なのは、ソフトウェア版、RFCと正誤表、各辺のクライアント・サーバー方向、EE・RA・CAの役割、条件機能、暗号設定、方針版、申請が通ったRA、処理された制御、POP判断、応答、証明書受理である。見えなかったRAを、後から見えたことにしてはならない。

出典