要約

  • RFC 9939 は RFC 5958 の PrivateKeyInfo と EncryptedPrivateKeyInfo に CMS content type を割り当てる。
  • OID は想定する構文を知らせる。秘密鍵の所持、適切な保護、復号、目的に対する権限、依拠側の受容を知らせるものではない。

鍵移送の台帳では、きれいに読めたラベルが結論に見えやすい。id-ct-privateKeyInfo という値を確認し、ツールが成功を返し、そのまま「鍵は承認済み」と書く。しかし、そこには構文、保管、暗号保護、復元、用途、依拠判断という異なる層がある。

RFC 9939 は一つの PrivateKeyInfo と一つの EncryptedPrivateKeyInfo を CMS で運ぶための名前を定める。CMS content-type arc の decimal 52 は id-ct-privateKeyInfo、53 は id-ct-encrPrivateKeyInfo である。さらに ASN.1 module identifier と application/cms の inner content type を登録する。この名前付けは、受信実装が何を解析するかを揃えるためのもので、鍵を使う主体や目的を決めるためのものではない。

RFC 5958 の構造は、version、algorithm identifier、private key、任意の属性、任意の public key を含み得る。暗号化された形は encryption algorithm と encrypted data を含む。値がその文法に合うことは確認できる。それでも、受信者が復号秘密を持つこと、復元した鍵が意図した公開鍵や証明書に対応すること、保存が許容されること、特定の署名や復号に使う許可があることは別に確認しなければならない。

RFC 5652 の CMS は署名、認証、暗号化などの包み方を提供するが、利用プロトコルが環境に合う algorithm を選ぶ。RFC 5959 は暗号化された private-key information の algorithm convention を示す。RFC 5958 が私鍵情報の漏えいはなりすましにつながり得ると注意する以上、content type だけを保護の判定にしてはならない。

残すべきものは短い証拠束である。オブジェクト hash、OID、parser/version、algorithm、外側の保護、recipient または key-management の証拠、許可された復号・integrity 結果、用途、保存先、そして別個の依拠判断である。Heng Lu の言う実行コードは、自分が解析した事実を確立できる。しかしその結果だけで、別の責任境界にある鍵使用権を発行することはできない。

Sources