要点： ILMのリクエスト属性を使うと、RAプロファイルで証明書要求に必要な項目、各値の取得元、クライアントが決して設定してはいけない値を宣言できます。要求者はPKIを学ぶ代わりに短いフォームに答えるだけで済み、信頼性の保証は従来どおり維持されます。

誰も証明書そのものが欲しいわけではありません。証明書がないと動かなくなるものを動かしたいのです。それ以上の質問は、自社のポリシーのために要求者へ課している負担です。

社内証明書を要求する開発者が通常直面することを考えてみてください。どのテンプレートか？ どの鍵アルゴリズムと鍵長か？ どの拡張と鍵用途か？ Subjectには何をどの順序で入れるか？ 複数あるSubject Alternative Nameのどの種類を使うのか？

それぞれの質問には正解があります。しかし、その答えを知っているのが開発者であることはほとんどありません。そこで過去の要求をコピーしたり、同僚に聞いたり、推測したりします。そして要求が却下され、同じことが繰り返されます。

その一方で、PKIチームは「遅い」と非難されます。実際には、そもそも要求者が決めるべきでなかった判断を取り締まるよう求められているのです。

リクエスト属性が実際に宣言するもの

ILMのRAプロファイルは、リクエスト属性の設定を持てるようになりました。この設定はフォーム定義ではなく、ポリシーの宣言です。要求にどの属性があるかを定め、それぞれを値の取得元に結び付けます。

重要なのはその結び付けです。値は要求者から収集することも、プラットフォームが導出することも、ポリシーで固定することもできます。その結果、これまでWikiページに書かれていた3種類の知識をプロファイルに組み込めます。

値の取得元 誰が決めるか 代表例
収集 要求者 証明書の対象となるホスト名
導出 プラットフォーム 認証済みアイデンティティから取得する所有者とグループ
ポリシーで固定 PKIチームが一度だけ決定 鍵アルゴリズム、鍵用途、拡張セット
リクエスト属性は、各値をその判断を正当に所有する主体に結び付けます。

この表は役割分担として読むことができます。要求者に尋ねるのは、本人が本当に知っていることだけです。それ以外は導出済み、またはすでに決定済みです。

ポリシーを要求そのものに反映する

正しい値を収集するフォームを用意するだけでは、問題の半分しか解決できません。その値を証明書署名要求へ正しく反映する必要があります。

ILMは属性フィールドのマッピングを生成されるPKCS#10要求へ反映します。そのためCSRは、クライアントライブラリが偶然組み立てた内容ではなく、プロファイルのポリシーを表します。Subjectと拡張は、要求者が入力した同じ宣言から構築されます。

アップロードされた要求も同じように扱われます。独自のCSRを持ち込んだ場合、ILMは無条件に受け入れるのではなく、RAプロファイルのリクエスト属性ポリシーに照らして検証します。また、要求を先に登録して後から発行できるため、ワークフロー上必要であれば、事前登録と発行を別のステップにできます。

プロトコル・クライアントが対処できるエラー

ここが、全体をシームレスに感じられるかどうかを左右する細部です。多くの証明書要求は人間からではありません。無人で動作するACME、EST、SCEP、CMPクライアントから送られます。

そのようなクライアントがポリシーに違反したとき、汎用エラーでは役に立ちません。クライアントは意味を解釈できず、有効な再試行もできず、実行可能な情報を報告することもできません。数日後に誰かがログを読むことになります。

ILMは、リクエスト属性ポリシーの違反をACME、EST、SCEP、CMPそれぞれのネイティブなエラーとして返します。エラーがプロトコル自身の語彙で届くため、クライアントは適切に動作できます。さらに、CSR-attributesエンドポイントから期待されるリクエスト属性セットを取得できるため、クライアントは要求を組み立てる前に必要事項を確認できます。

推測して却下されるより、プラットフォームに必要事項を尋ねる方が優れたプロトコルです。

カスタムコードなしで拡張を扱う

証明書拡張は、組織が独自ツールを保守することになる典型的な理由です。ポリシーで1つカスタム拡張が必要になるだけで、発行経路にパッチが入りがちです。

ILMは証明書拡張用のカスタムOIDレジストリを備え、認識しているシステム拡張を登録し、システムOID一覧を返すエンドポイントを公開します。これによりカスタム拡張は設定で扱えます。さらに、EMAILのようなプラットフォームRDNコードもSubject名で受け付けるため、よくある要求却下の原因を取り除けます。

シームレスであることは、統制が緩いことではない

ここまでの内容を、統制を緩める話だと受け取るのは簡単です。しかし実際は逆であり、その違いは重要です。

以前は、要求者がCSRにほぼ何でも入れられ、プラットフォームが後から問題を見つける役割でした。今はプロファイルが許可内容を宣言し、クライアントに制御させるべきでない値は導出または固定され、アップロードされた要求も同じポリシーで検証されます。つまり、要求者への質問が減り、間違える機会も減ります。

PKIへの信頼は、ポリシーが一貫して適用されることから生まれます。利用者にポリシーを理解していると証明させることから生まれるわけではありません。したがって、難しさをプロファイル側へ移すことは、保証を弱めるのではなく強めます。

率直に言えば、ポリシーを書く人は依然として必要です。リクエスト属性が「PKIで何を許可すべきか」を決めるわけではありません。その判断を明示的かつ再利用可能にし、推測する人々が毎回解釈する代わりに、一か所で強制できるようにします。

主なポイント

  • RAプロファイルはリクエスト属性を宣言し、それぞれを「収集」「導出」「ポリシーで固定」の値取得元に結び付けます。
  • 属性マッピングは生成されるPKCS#10要求へ反映されるため、CSRにはクライアントの推測ではなくポリシーが反映されます。
  • アップロードされたCSRも同じポリシーで検証され、要求を事前登録して後から発行することもできます。
  • ポリシー違反はACME、EST、SCEP、CMPのネイティブエラーとして返され、クライアントは事前に期待される属性セットを照会できます。
  • カスタムOIDレジストリと受け入れ可能なプラットフォームRDNコードにより、拡張の処理を設定として扱えます。

リクエスト属性はILM Core 2.19.0で提供されました。このリリースのその他の内容は、2.19.0で何が変わったかをご覧ください。証明書の有効期間短縮を受けて自動化を進める場合は、47日証明書へのカウントダウンとILMで構築できる10のこともご覧ください。自社環境向けのプロファイル設計については、お問い合わせください。