[META] { “protocol”: “CMC”, “rfc_status”: “draft-ietf-lamps-rfc5272bis (IESG Approved/RFC Editor Queue)”, “category”: “PKI / Security”, “technical_depth”: “Expert”, “style”: “Technical-First” } [/META]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
RFC 5272-bis: Certificate Management over CMS (CMC) の最新更新と実装への影響
【背景と設計目標】
既存のRFC 5272を現代の暗号スイートへ適応させ、複雑なPKI環境下での証明書ライフサイクル管理をCMS（RFC 5652）基盤で標準化する。
CMCは、単純な証明書署名要求（CSR）を超え、登録局（RA）や認証局（CA）間での多段署名や暗号化、証跡の保持を可能にすることを目的としています。本ドラフト（5272bis）は、アルゴリズムの現代化（SHA-2からSHA-3、PQC準備）と、曖昧だったエラー処理の厳格化を主な目標としています。
【通信シーケンスと動作】
CMCは通常、トランスポート層（HTTPやTCP）に依存しない構造ですが、一般的には以下のフローで動作します。
sequenceDiagram
participant "EE as End Entity (Client)"
participant "RA as Registration Authority"
participant "CA as Certification Authority"
EE ->> EE: キーペア生成 & CSR作成 (PKCS#10)
EE ->> RA: Full PKI Request (CMS SignedData)
Note over RA: 署名の検証・ポリシーチェック
RA ->> CA: リクエストの転送 (再署名/カプセル化)
CA ->> CA: 証明書発行
CA -->> RA: Full PKI Response (CMC Response)
RA -->> EE: 証明書および信頼チェーンの配布
このシーケンスの特徴は、リクエスト自体がCMSで保護されているため、トランスポート層が保護されていなくても、証明書の要求内容の完全性と送信元の真正性が担保される点にあります。
【データ構造 / パケットフォーマット】
CMCメッセージは、CMSの ContentInfo 構造内にカプセル化されます。以下に Full PKI Request の論理構造を示します。
+-------------------------------------------------------+
| CMS ContentInfo (oid: id-ct-PKIData) |
+-------------------------------------------------------+
| PKIData ::= SEQUENCE { |
| controlSequence SEQUENCE OF TaggedAttribute, |
| reqSequence SEQUENCE OF TaggedRequest, |
| cmsSequence SEQUENCE OF TaggedContentInfo, |
| otherMsgSequence SEQUENCE OF TaggedOtherMsg |
| } |
+-------------------------------------------------------+
| TaggedRequest ::= CHOICE { |
| tCC [0] TaggedCertificationRequest, -- PKCS#10 |
| crm [1] CertReqMsg, -- CRMF |
| orm [2] TaggedPbm -- (PBM) |
| } |
+-------------------------------------------------------+
| Control Attributes (Examples): |
| - Transaction ID (id-aa-cmc-transactionID) |
| - Sender Nonce (id-aa-cmc-senderNonce) |
| - Proof of Possession (PoP) |
+-------------------------------------------------------+
【技術的な特徴と比較】
CMCと他の主要な証明書管理プロトコルを比較します。
| 機能・特性 | CMC (RFC 5272bis) | EST (RFC 7030) | SCEP |
|---|---|---|---|
| ベースプロトコル | CMS (Cryptographic Msg Syntax) | HTTP / TLS | HTTP / PKCS#7 |
| トランスポート | 任意 (HTTP, Mail, File) | HTTPS必須 | HTTP |
| セキュリティ | メッセージ単位の署名・暗号化 | TLSセッション + ID/PW | 共有鍵 / PKCS#7署名 |
| 署名検証 | RAによる委任署名を強力にサポート | TLSクライアント認証 | 限定的 |
| 柔軟性 | 非常に高い (多段RAに対応) | 中程度 (単純なEnrollment) | 低い (レガシー) |
| ユースケース | 軍用・高信頼政府系PKI | ネットワーク機器 (ZTP) | 一般エンタープライズ |
【セキュリティ考慮事項】
リプレイ攻撃耐性:
senderNonceおよびrecipientNonceを使用したチャレンジ・レスポンス・メカニズムにより、攻撃者が過去のリクエストを再送することを防ぎます。Proof of Possession (PoP): 秘密鍵の所有証明を厳格に行うため、リクエスト内に
Signatureだけでなく、特定の属性（例：id-aa-cmc-popLinkWitness）を含めることで、バインディング攻撃（他人の公開鍵を自分の名前で登録する攻撃）を防止します。前方秘匿性 (PFS): CMC自体はメッセージ保護に焦点を当てていますが、トランスポートにTLS 1.3を併用することが推奨され、通信路自体のPFSを確保します。
【まとめと実装への影響】
ネットワークエンジニアおよびプロトコル開発者が留意すべき点は以下の3点です。
ASN.1 パーサの堅牢化: CMCは複雑なASN.1ネスト構造を持つため、脆弱なパーサはバッファオーバーフローやDoSの標的になります。最新のDERライブラリの使用が必須です。
アルゴリズムの移行: 5272bisでは、レガシーなRSA-PKCS#1.5からRSASSA-PSSやECDSA、さらにEdDSAへの移行が強く意識されています。
状態管理の実装: 多くのPKIリクエストは非同期で行われます（CAの承認待ち）。
transactionIDをキーとしたセッション状態の適切な維持が、システム全体の可用性に直結します。
