Summary

  • RFC 9939 assigns CMS content types to the RFC 5958 PrivateKeyInfo and EncryptedPrivateKeyInfo structures, including OIDs ending in CMS content-type decimals 52 and 53.
  • A content-type OID identifies the syntax a CMS processor should expect. It is not proof of private-key possession, decryption, adequate protection, allowed purpose or an accepting relying decision.

An archive review showed a familiar but dangerous shortcut. A record said the package carried id-ct-privateKeyInfo; the parser accepted it; the ticket therefore called the key “approved.” Three different layers had been compressed into one word.

RFC 9939 is deliberately narrower. It gives CMS names to one PrivateKeyInfo and one EncryptedPrivateKeyInfo from RFC 5958. id-ct-privateKeyInfo occupies the CMS content-type arc’s decimal 52; id-ct-encrPrivateKeyInfo occupies decimal 53. The RFC also records a module identifier and the two application/cms inner-content-type labels. Those assignments make a receiver’s structural expectation explicit. They do not create a new key-management policy.

That distinction matters because the structures already carry sensitive but limited facts. RFC 5958’s compatible PrivateKeyInfo / OneAsymmetricKey form describes a version, an algorithm identifier, private-key octets, optional attributes and, in the newer form, an optional public key. EncryptedPrivateKeyInfo names an encryption algorithm and carries encrypted data. None of those fields says which human or service may use the recovered material, whether the recipient can recover it, or whether that use is appropriate for a requested transaction.

CMS widens the available protective vocabulary without erasing the decision boundary. RFC 5652 describes an encapsulation syntax that can sign, digest, authenticate or encrypt content; protocols using CMS select algorithms appropriate to their environment. RFC 5959 gives conventions for algorithms used with EncryptedPrivateKeyInfo. RFC 5958 warns that private-key disclosure can enable masquerade and that the package contents are not protected merely because the content type exists. The correct label is therefore one input to a receipt, not the receipt’s final verdict.

Keep the receipt small and replayable: raw object hash, the content-type OID, parser/version result, key and protection algorithm identifiers, envelope and recipient/key-management evidence, integrity and decryption result where authorized, public-key or certificate correspondence where relevant, authorized purpose, destination and retention boundary, then the separately accountable relying decision. Heng Lu’s Running-Code Primacy applies cleanly: a parser can prove what it parsed. It cannot award authority over secret material that belongs to an accountable policy boundary.

Sources