Summary

  • RFC 5409 uses BF or BB1 IBE to encrypt a CMS content-encryption key, not the whole message directly.
  • The recipient identity is a DER-encoded structure carried with CMS recipient information; algorithm OIDs select the IBE scheme.
  • A valid CMS envelope and a successful decryption still do not prove application permission or durable business acceptance.

The envelope has more than one identity boundary

CMS carries encrypted content and a content-encryption key (CEK). RFC 5409 defines how BF and BB1 IBE protect that CEK and how IBERecipientInfo records the recipient identity. The sender therefore commits to several bytes before anyone sees plaintext: the identity encoding, the identity type, the algorithm identifier and the public parameters used to calculate the IBE public key.

Those fields are evidence, not decoration. A recipient can possess the right mailbox but fail because the DER encoding, district, serial or identity namespace differs. Conversely, a service can decode a valid recipient object and still deny the resulting request. Treating “CMS opened” as “the recipient was authorised” collapses cryptographic processing into policy.

OIDs select an algorithm, not a policy

RFC 5409 assigns identifiers for BF and BB1 in the CMS keyEncryptionAlgorithm field and defines the originator-recipient-information (ORI) values needed for IBE. An OID tells an implementation which algorithm and syntax to use. It does not certify parameter freshness, PKG approval, tenant membership or the business object named inside the decrypted content.

Keep a replayable record of the DER recipient object, OID, parameter fingerprint, CEK hash, PKG request and decryption result. If a library “helpfully” normalises an identity before lookup, that transformation belongs in the evidence chain. A CMS parser that accepts two encodings may still hand the application two different principals.

Decryption ends before acceptance

After CMS unwraps the CEK and the content decrypts, the application may reject a role, quota, tenant or object state. A timeout after a successful unwrap does not prove that a write failed, and a readable payload does not prove that it was committed. Store request ID, policy decision and durable commit separately from CMS status.

The leadership question is simple: can an operator show which identity bytes, OID, parameter set and PKG decision produced the plaintext, and then show the independent application decision? If not, the envelope is a receipt without a trustworthy outcome.