{ “topic”: “CMC (Certificate Management over CMS) Update”, “status”: “IESG Review / draft-ietf-lamps-rfc5272bis”, “target_rfc”: “RFC 5272 (Obsoleting RFC 2797)”, “technical_keywords”: [“CMS”, “PKI”, “ASN.1”, “LAMPS”, “Certificate Request”, “RA/CA”] }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
RFC 5272-bis: Certificate Management over CMS (CMC) 更新ドラフト
【背景と設計目標】
PKI運用の複雑性を解消し、CMSを基盤とした高度な証明書ライフサイクル管理と最新暗号への適応を、既存実装との互換性を保ちつつ実現する。
従来のPKCS #10等では不十分だった「証明書の更新」「失効要求」「アーカイブ」といった一連のワークフローを、Cryptographic Message Syntax (CMS) の署名・暗号化枠組みの中でカプセル化し、トランスポート層に依存しない堅牢な管理プロトコルを提供することが目標です。
【通信シーケンスと動作】
CMCは、エンドエンティティ(EE)、登録局(RA)、認証局(CA)の間で「Full PKI Request」と「Full PKI Response」をやり取りします。以下はRAを経由する標準的なシーケンスです。
sequenceDiagram
participant "EE as End Entity (Client)"
participant "RA as Registration Authority"
participant "CA as Certification Authority"
Note over EE: Generate Key Pair & PKCS#10
EE ->> RA: Full PKI Request (SignedData)
Note over RA: Verify Signature / Add RA Metadata
RA ->> CA: Full PKI Request (Forwarded)
Note over CA: Issue Certificate
CA ->> RA: Full PKI Response (Cert + CMC Status)
RA ->> EE: Full PKI Response (Cert/Response)
Note over EE: Import Certificate
Request: EEは公開鍵と属性を含むリクエストを作成し、CMS
SignedDataで保護して送信します。RA処理: RAはアイデンティティを確認し、必要に応じて制御属性を追加（二重署名）してCAへ送ります。
Response: CAは発行結果やステータスコードを含めたレスポンスを返し、EEは自身の秘密鍵に対応する証明書を受け取ります。
【データ構造 / パケットフォーマット】
CMCメッセージはASN.1で定義され、CMS ContentInfo 内にラップされます。以下は Full PKI Request の概念的な構造です。
+-----------------------------------------------------------+ | CMS ContentInfo (oid: id-signedData) | +-----------------------------------------------------------+ | SignedData | | +-------------------------------------------------------+| | | EncapsulatedContentInfo (oid: id-cct-PKIData) || | | +---------------------------------------------------+ || | | | PKIData | || | | | +-----------------------------------------------+ | || | | | | controlSequence (Sequence of TaggedAttribute) | | || | | | | - CMC Status Info / Transaction ID / etc. | | || | | | +-----------------------------------------------+ | || | | | | reqSequence (Sequence of TaggedRequest) | | || | | | | - tPKCS10 / tCRMF | | || | | | +-----------------------------------------------+ | || | | | | cmsSequence (Sequence of TaggedContentInfo) | | || | | | +-----------------------------------------------+ | || | | | | otherMsgSequence | | || | | | +-----------------------------------------------+ | || | | +---------------------------------------------------+ || | +-------------------------------------------------------+| | | SignerInfos (Signatures from EE or RA) || | +-------------------------------------------------------+| +-----------------------------------------------------------+
【技術的な特徴と比較】
CMCは、軽量なEST (Enrollment over Secure Transport) と、重厚なCMP (Certificate Management Protocol) の中間に位置し、エンタープライズPKIに適した柔軟性を持ちます。
| 特徴 | CMC (RFC 5272-bis) | CMP (RFC 4210) | EST (RFC 7030) |
|---|---|---|---|
| ベース形式 | CMS (RFC 5652) | 独自ASN.1メッセージ | HTTP / TLS |
| 柔軟性 | 非常に高い（多段RA対応） | 最高（全PKI機能網羅） | 低（単純な登録に特化） |
| トランスポート | 任意（HTTP, Mail, File） | 任意 | HTTP専用 |
| 多重化 | 1メッセージで複数要求可 | 可能 | 不可 |
| アルゴリズム | 最新(PQC, EdDSA)対応 | 対応（更新中） | 暗号スイートに依存 |
【セキュリティ考慮事項】
Proof of Possession (PoP): リクエスト者が秘密鍵を実際に所有していることを、署名またはチャレンジレスポンスにより強制します。
リプレイ攻撃耐性:
nonce属性またはtransactionIDを用いて、過去の有効なリクエストの再送を防止します。整合性保護: CMSの署名構造を利用するため、RAがリクエストを中継する際も、EEの元々の意思（署名）を壊さずに管理情報を付与できます。
前方秘匿性 (PFS): 通信路のTLSが提供しますが、CMC自体はCMS
EnvelopedDataを用いることで、トランスポート層が保護されていない環境でもコンテンツの秘匿を維持可能です。
【まとめと実装への影響】
ネットワークエンジニアおよびプロトコル実装者が注目すべき点は以下の3点です。
アルゴリズムの更新への対応: 新しいドラフトでは、Post-Quantum Cryptography (PQC) や EdDSA 等の最新アルゴリズムをCMS上で扱うための記述が整理されており、将来的な暗号移行（Crypto-Agility）への備えとなります。
RA/LRAの実装負荷: CMCはRAにおけるポリシ制御（承認フロー）の組み込みが前提となるため、単純な証明書発行以上のロジックをゲートウェイに実装する必要があります。
ライブラリの依存性: CMS（RFC 5652）の実装ライブラリ（OpenSSL, Bouncy Castle等）に強く依存するため、これらのパーサーの脆弱性管理がそのままPKI基盤のセキュリティに直結します。
