draft-ietf-lamps-rfc5272bis: Certificate Management over CMS (CMC) 最新更新仕様の解説

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

draft-ietf-lamps-rfc5272bis: Certificate Management over CMS (CMC) 最新更新仕様の解説

【背景と設計目標】

現代の多様な暗号アルゴリズム（PQC含む）やAEADに適合し、レガシーなPKI管理プロトコルを最新のセキュリティ基準へ更新する。

本仕様は、長年にわたりエンタープライズPKIおよびデバイスプロビジョニングの基盤となってきた「RFC 5272（Certificate Management over CMS）」を完全に置き換える、または近代化するために設計された更新規格です。従来のアルゴリズム制限を排除し、ポスト量子暗号（PQC）の導入や現代的な認証付き暗号（AEAD）の統合を容易にすることを目標としています。

【通信シーケンスと動作】

CMCは、End Entity（EE）、Registration Authority（RA）、およびCertification Authority（CA）の間で、CMS（Cryptographic Message Syntax）でカプセル化されたメッセージをやり取りします。以下は、RAが介在する「Full PKI Request」の標準的な通信シーケンスです。

sequenceDiagram
    autonumber
    participant "EE as End Entity (Client)"
    participant "RA as Registration Authority (RA)"
    participant "CA as Certification Authority (CA)"

    Note over EE: Generate Key Pair &
Construct PKIData (CMS SignedData)
    EE ->> RA: 1. Full PKI Request (With Proof-of-Possession)
    Note over RA: Verify EE Signature & PoP
Wrap with RA Signature
    RA ->> CA: 2. Nested Full PKI Request (Double SignedData)
    Note over CA: Validate RA/EE Signatures
Issue Certificate & Construct PKIResponse
    CA ->> RA: 3. Full PKI Response (CMS SignedData / EnvelopedData)
    Note over RA: Verify and/or Re-encrypt Response
    RA ->> EE: 4. Forwarded Response (Targeted to EE)
    Note over EE: Verify CA Signature &
Install Certificate

シーケンス詳細解説

  1. EEによるリクエスト生成: クライアントは秘密鍵の所有証明（PoP: Proof-of-Possession）を含む PKIData 構造体を生成し、CMSの SignedData（または AuthenticatedData）としてカプセル化して送信します。

  2. RAによる検証とネスト処理: RAはEEの署名を検証後、独自のポリシー属性（追跡IDや追加の身元確認情報）を不可分な形で結合するため、EEのCMSメッセージ全体を自らの署名で再ラップ（Nested CMS）します。

  3. CAによる証明書発行: CAは最外殻のRA署名と内包されたEEの署名の双方を検証し、妥当であれば証明書を発行します。レスポンスは PKIResponse 構造体としてCMS化されます。

【データ構造 / パケットフォーマット】

CMCの核となる PKIData および PKIResponse はASN.1で定義され、CMSオブジェクト（ContentInfo）として表現されます。以下にその内部構造を示します。

+------------------------------------------------------------------------+
| CMS ContentInfo (ContentType: id-ccts-pkiData / id-ccts-pkiResponse)   |
+------------------------------------------------------------------------+
| SignedData (Ensures Integrity, Authenticity, and Proof-of-Possession) |
+---+--------------------------------------------------------------------+
    | PKIData / PKIResponse Content (Visualized ASN.1 Structure)         |
    +--------------------------------------------------------------------+
    | Offset (Hex) | Field Name          | Type / Description            |
    +--------------+---------------------+-------------------------------+
    | 0x00         | controlSequence     | SEQUENCE OF TaggedAttribute   |
    |              |                     | - Transaction IDs, Nonces     |
    | 0xNN         | reqSequence         | SEQUENCE OF TaggedRequest     |
    |              |                     | - PKCS#10 or CRMF Requests    |
    | 0xMM         | cmsSequence         | SEQUENCE OF TaggedContentInfo |
    |              |                     | - Nested or enveloped CMS     |
    | 0xXX         | otherMsgSequence    | SEQUENCE OF OtherMsg          |
    |              |                     | - Vendor-specific payloads    |
    +--------------+---------------------+-------------------------------+

[TaggedAttribute (Control Attribute Detail)]
+------------------------------------------------------------------------+
| bodyPartID (32-bit Integer: 1..4294967295 for correlation)             |
+------------------------------------------------------------------------+
| attrType   (OBJECT IDENTIFIER - e.g., id-cmc-senderNonce)              |
+------------------------------------------------------------------------+
| attrValues (SET OF ANY - e.g., OCTET STRING containing high-entropy)   |
+------------------------------------------------------------------------+

【技術的な特徴と比較】

評価軸 CMC (draft-rfc5272bis) EST (RFC 7030) ACME (RFC 8555) CMP (RFC 4210 / 9483)
ベーストランスポート 抽象化（HTTP、ファイル、CoAP等） HTTPS (TLS必須) HTTPS (TLS/TCP) 任意 (TCP, HTTP, CoAP)
メッセージフォーマット CMS (Cryptographic Message Syntax) PKCS#10 / ASN.1 JSON (JWT/JWS) ASN.1 (CRMF/DER)
暗号アジリティ 極めて高い (PQC / ハイブリッド) 中 (TLS/クライアント鍵に依存) 高 (JWAに依存) 高 (RFC 9483によるPQC適応)
Head-of-Line (HOL) 影響 トランスポート非依存（セッションレス） TLS上（HTTP/3で解消可能） HTTP/3対応で解消可能 なし (メッセージ完結型)
マルチホップ（RA経由） ネイティブ対応 (ネスト構造) 困難 (TLS終端が必要) 非対応 (直接CA接続を想定) ネイティブ対応
ゼロトラスト適合度 高 (ペイロード自律暗号化) 中 (セッションセキュリティ依存) 低 (ドメイン検証依存) 高 (エンドツーエンド保護)

【セキュリティ考慮事項】

  1. リプレイ攻撃およびインラインインジェクションへの耐性: senderNonce および recipientNonce を制御属性（controlSequence）に強制的にバインドすることで、攻撃者が過去の有効な証明書要求を傍受し、再送信して同一のキーペアに対する新しい証明書を不正に取得することを防止します。

  2. ダウングレード攻撃の完全排除: 本更新ドラフトでは、利用可能な暗号化/署名アルゴリズムのネゴシエーション中に強度の低いアルゴリズムへ誘導されるダウングレード攻撃を防ぐため、サポートされているアルゴリズムのリスト自体を、CMS SignedDataによって署名された整合性保護対象（Signed Attributes）に含めて検証することを義務付けています。

  3. 耐量子暗号（PQC）と前方秘匿性（PFS）: 古典的暗号（RSA/ECDSA）の崩壊に備え、ML-DSAやML-KEMといった最新のPQCアルゴリズムをカプセル化（EnvelopedData）および署名（SignedData）で混在して利用できる「ハイブリッド暗号方式」が体系化され、超長期的な前方秘匿性を担保します。

【まとめと実装への影響】

  1. 暗号アジリティの実装必須化: 開発者は、静的に固定された暗号ライブラリから脱却し、ASN.1パーサがポスト量子暗号のOIDおよびハイブリッド署名（Dual Signatures）を正しくハンドリングできるように実装を更新する必要があります。

  2. RA（登録機関）の役割再定義: 本仕様の適用により、RAは単なる中継点ではなく、ネストされたCMSのパース、認可ポリシーの注入、および署名の再付与を行うアクティブなノードとして振る舞うため、RA実装におけるASN.1インジェクション脆弱性の排除が強く求められます。

  3. 産業分野（IoT/社会インフラ）への波及: トランスポート層に依存しないメッセージ自己防衛（Self-protecting Message）の特性は、コネクティビティが不安定な組込みデバイスや工場内ネットワーク（OT）におけるゼロトラストな鍵管理スキームの標準アーキテクチャとなります。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました