RFC 5208：PKCS #8 の構文は秘密鍵保護の証明ではない

要約

RFC 5208 の PrivateKeyInfo と RFC 5958 の OneAsymmetricKey は、秘密鍵材料を共通の構文で運ぶ。未暗号化のコンテナは表現であり、暗号化、アクセス制御、HSM 保管、安全な消去を証明しない。
復号、数学的検証、公開鍵との対応、保管先、利用認可、暗号処理、アプリケーション受理には、それぞれ別のレシートが必要である。

PKCS #8 が解いたのは、アルゴリズムごとに違う秘密鍵を共通の外枠で受け渡す問題だった。RFC 5208 の PrivateKeyInfo は、版、秘密鍵アルゴリズム、秘密鍵を入れる OCTET STRING、任意の属性から成る。内側の解釈はアルゴリズム登録に委ねられる。

この設計は小さいから強い。パーサーはバイト列が文法に合うと判断できる。しかし、そのバイトがどこで生成され、平文で保存されたか、チケットに添付されたか、どのプロセスが読んだかまでは語れない。構文上の成功は保管履歴ではない。

RFC 5958 は後継の OneAsymmetricKey に公開鍵を任意で加え、複数の鍵を運べる CMS コンテンツ型を定めた。同時に、非対称鍵パッケージの内容は保護されていないと明記する。必要なら別の保護コンテンツ型で包む。ここで形式と保護は意図的に分離されている。

RFC 7468 では、未暗号化の形に PRIVATE KEY、EncryptedPrivateKeyInfo に ENCRYPTED PRIVATE KEY を使う。後者は暗号アルゴリズム識別子と暗号化データを持つ。秘密鍵情報を符号化する工程と、それを暗号化する工程は別である。

したがって監査記録も分けるべきだ。外側の ASN.1 が読めたこと、KDF と暗号のパラメータ、提示された資格情報、完全性確認、復号結果、平文の寿命を一つの imported に丸めてはいけない。保護が外れた時刻と場所こそ重要な境界になる。

RFC 8018 は、パスワードが小さな候補空間から選ばれやすいため、探索攻撃への配慮が必要だと説明する。暗号方式の OID が存在しても、パスワードの質、salt、反復回数、実装の上限が適切だった証拠にはならない。

PKCS #8 のオブジェクトは、生成プロセスのメモリ、ローカルファイル、転送経路、ソフトウェアキーストア、クラウド KMS、HSM を移動できる。その間に構文は変わらなくても、支配者と露出面は何度も変わる。

.p8、application/pkcs8、正しい PEM 境界は HSM 在駐証明ではない。HSM のオブジェクト ID も、外部に平文コピーが残らないこと、非エクスポート属性、バックアップ先、操作権限まで自動的には証明しない。

必要なのは、入力ハッシュ、転送保護、インポート主体、スロット、オブジェクト ID、エクスポート方針、複製先、操作ログ、一時ファイルの削除を結ぶ保管レシートである。構文レシートはその最初の一枚にすぎない。

RFC 5958 は公開鍵を同梱できる。ECC や RSA のアルゴリズム固有構造にも公開成分が含まれる場合がある。それでも、期待する証明書やアカウントに対応するかは独立して確認しなければならない。公開鍵を導出または検証し、信頼記録と比較する工程が要る。

RFC 8479 は、特定の RSA/DSA パラメータ生成を後から検証するための入力を属性として保存する方法を示す。入力が保存されたことと、検証が実行されて合格したことは別である。ここでも「材料」と「結果」を混同してはならない。

鍵が数学的に正しく、公開鍵も一致していても、利用ポリシーが呼び出しを拒否することはある。署名が生成されても、メッセージ、コンテキスト、時刻、証明書チェーン、アルゴリズム方針が違えばアプリケーションは拒否する。成功は段階ごとに止まり得る。

RFC 5208 は 2008 年の Informational 文書で、2010 年の Standards Track RFC 5958 に置き換えられた。後継は名称、公開鍵フィールド、版規則、CMS コンテンツ型を追加した。一方、互換性のため旧来の v1 形状も残る。

資産台帳の「RFC 5958 対応」は、エクスポーター、インポーター、バックアップ、復旧ツールが同じ動作をする証拠ではない。実装版、受理した実バイト、未知フィールドの扱い、負試験、往復保存、災害復旧で確認する必要がある。

秘密鍵移動には、原本バイト、テキスト復号、ASN.1、平文/暗号化種別、KDF、復号、数学的検証、公開鍵対応、保管先、エクスポート性、認可、暗号操作、出力検証、アプリケーション受理、削除の各レシートを残す。

PRIVATE KEY は表現を示す。復号成功は平文への到達を示す。公開鍵一致は対応を示す。HSM ログは特定境界内の操作を示す。署名検証は一つのメッセージに対する結果を示す。どれも隣の層を代理できない。

共通仕様には必要最小限の構文だけを任せ、保管と認可は現場の明示的な方針で決める。稼働コードが生んだ検証可能な結果を一次証拠にし、その結果へ至った経路を説明できるだけの来歴を残すべきだ。