要約

  • RFC 9908はIETF Proposed Standardで、2026年1月に公開され、RFC 7030とRFC 9148を更新する。
  • CSR Attributesにおける属性OIDと値の符号化、とくにX.509拡張値を明確にし、CertificationRequestInfoTemplateを追加する。
  • サーバーは一部記入済みのテンプレートを送り、要求する値を固定し、クライアントが決める欄を空欄として残せる。ただし、これはCSRの承認、署名、CAポリシーを意味しない。

要点は、/csrattrsが「利用可能な属性の一覧」だけでなく、後続CSRの要求形状を表せるようになったことだ。クライアントはOIDと値を読んだとき、「フィールドが存在しない」「フィールドは存在するが値が省略されている」「サーバーが値を提示している」を区別しなければならない。ASN.1の存在・不在・オプション値を一つの真偽値に潰してはならない。

CertificationRequestInfoTemplateにはsubjectを含められるが、subject自体はオプションである。サーバーにRDN要件がある場合に現れ、RDNは値を省略してクライアントに供給させることもできる。サーバーがRDN値を提示したなら、クライアントはその値を使うことが期待される。値がなければ、適切な値をクライアントが供給する。したがって空欄は「制約なし」ではなく、クライアントに割り当てられた明示的なスロットだ。

サーバーに鍵の要件がなければsubjectPKInfoは存在しない。存在する場合、そのアルゴリズムは期待される鍵ペアの種類を示す。subjectPublicKeyは通常存在しないが、RSAモジュラス長の要件を表す必要がある場合にはプレースホルダーを運べる。この値をクライアントの最終公開鍵と扱ってはならない。

この整理はACPとBRSKIの登録に直結する。サーバーは/csrattrsを通じて特定のsubjectAltNameを伝える必要があり、単に拡張属性の種類を列挙するだけでは足りない。RFC 8994のautonomic control planeとRFC 8995のブートストラップが背景にある。RFC 9908は既存EST利用との後方互換性を意図しているが、ESTの認証やCAの発行ポリシーを置き換えるものではない。

**Theo March 分析：**テンプレートは制約の表現であって承認通知ではない。サーバーがテンプレートを送ってもCSRを署名・承認したことにはならず、認証はESTの手順で、CAの判断はCAポリシーで行われる。応答をデコードできたというだけで、要求がCSRや最終証明書へ正しく継承されたとも言えない。

出典