[ID: CMC_RFC5272bis_UPDATE_2024] [STATUS: IESG_SUBMITTED_EVALUATION] [KEYWORDS: CMC, RFC5272bis, CMS, PKI, CertificateEnrollment, LAMPS] [LAYER: L7 – Application / PKI Management]

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

RFC 5272bis/5273bis: Certificate Management over CMS (CMC) の最新更新

【背景と設計目標】

PKIにおける複雑な証明書発行・管理フローをCMS（Cryptographic Message Syntax）に基づき統合し、最新の暗号アルゴリズムへの適応と相互運用性の向上を目指す。

CMCは、従来のPKCS #10やSCEPでは対応が困難であった、複数エンティティの署名、属性情報の付与、および高度な登録局（RA）経由の通信を標準化するために設計されました。今回の更新ドラフト（rfc5272bis/rfc5273bis）は、旧規格（RFC 5272/5273/6402）を統合・整理し、最新の暗号要件（PQC等への将来的な対応準備）とIESGの現代的なセキュリティ要件に準拠させることを目的としています。

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

CMCは、End Entity (EE)、Registration Authority (RA)、Certification Authority (CA) 間の多段構成をサポートします。

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

    Note over EE, CA: Full PKI Request Flow
    EE ->> RA: Full PKI Request (SignedData with PKIData)
    RA ->> RA: Validate Proof of Possession (PoP)
    RA ->> CA: Forwarded PKI Request (with RA Signature)
    CA ->> CA: Generate Certificate / Revocation List
    CA ->> RA: Full PKI Response (SignedData with PKIResponse)
    RA ->> EE: Forwarded PKI Response
    EE ->> EE: Verify Signature & Store Certificate
    EE ->> RA: Certificate Confirmation (Optional)

1. Request: クライアントは証明書署名要求を含む PKIData を作成し、CMS SignedData でラップして送信します。

2. Mediation: RAは中継時に独自の署名や制御情報を付与でき、エンタープライズ環境でのポリシー適用が可能です。

3. Response: CA/RAからの応答も SignedData で保護され、ステータス情報や発行済み証明書が含まれます。

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

CMCメッセージは、CMS ContentInfo をベースとした再帰的なカプセル化構造を持ちます。

+-----------------------------------------------------------+
| CMS ContentInfo (Object Identifier: id-ct-PKIData)        |
+-----------------------------------------------------------+
|  SignedData (Signature over PKIData)                      |
|  +-----------------------------------------------------+  |
|  | PKIData (ASN.1 Sequence)                            |  |
|  | +-------------------------------------------------+ |  |
|  | | controlSequence (Sequence of TaggedAttribute)   | |  |
|  | | - Transaction ID / Sender Nonce / Body ID       | |  |
|  | +-------------------------------------------------+ |  |
|  | | reqSequence (Sequence of TaggedRequest)         | |  |
|  | | - TST (Tagged Certification Request)            | |  |
|  | | - CRM (Certificate Request Message - RFC 4211)  | |  |
|  | +-------------------------------------------------+ |  |
|  | | cmsSequence (Sequence of TaggedContentInfo)     | |  |
|  | +-------------------------------------------------+ |  |
|  | | otherMsgSequence                                | |  |
|  | +-------------------------------------------------+ |  |
|  +-----------------------------------------------------+  |
+-----------------------------------------------------------+

【技術的な特徴と比較】

CMCは、他の証明書管理プロトコルと比較して「柔軟性」と「CMS親和性」に優れています。

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

1. Proof of Possession (PoP): クライアントが秘密鍵を実際に所有していることを、署名や特定の属性（Tag-based PoP）によって証明します。

2. リプレイ攻撃防止: Sender Nonce および Recipient Nonce を controlSequence 内に含めることで、メッセージの再利用を防止します。

3. 完全性と機密性: CMSの SignedData による改ざん検知に加え、EnvelopedData を用いることで、要求内容そのものを暗号化し、機密性を保持することが可能です。

4. ダウングレード攻撃: 更新ドラフトでは、サポートする署名アルゴリズムの最小要件を引き上げ、脆弱なアルゴリズムの強制を排除しています。

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

ネットワークエンジニアおよび開発者は、以下の3点に留意する必要があります。

1. 暗号ライブラリの更新: rfc5272bis では SHA-256 以降の利用が強く推奨（一部必須）されており、古いライブラリ（SHA-1依存など）の実装は見直しが必要です。

2. RA運用の柔軟性: CMCは多段階のRA構成を標準でサポートしているため、DMZに配置したRAによる審査フローなど、高度なセキュリティ設計が容易になります。

3. トランスポートの独立性: HTTP以外のトランスポート（ファイル転送やメール）でも動作するため、エアギャップ環境や非同期通信が必要な産業用制御システム（ICS）への適用にも適しています。