Summary

  • A CMS AuthEnvelopedData object can correctly name AES-GCM, carry the required parameters and pass tag verification without proving the key-scoped historical claim that its nonce was never reused.
  • RFC 5084 therefore requires automated key management and identifies a fresh content-authenticated-encryption key for each content as the safe construction; algorithm support is not the same receipt as lifecycle control.

The review screen is reassuring. The content type parses. The algorithm identifier resolves to AES-GCM. The nonce is twelve octets. The authentication tag verifies. Every fact on the screen may be true, and the conclusion “the nonce was unique” may still be unsupported.

RFC 5084 binds AES-CCM and AES-GCM to the Cryptographic Message Syntax authenticated-enveloped-data content type. Its work is deliberately concrete. It assigns three object identifiers for each mode, one for each AES key size. It says where the content-encryption algorithm identifier belongs, defines the ASN.1 parameter structures, specifies the permitted authentication-tag lengths and connects the CMS authenticated attributes to the additional authenticated data supplied to the cipher.

That precision makes one absence especially important. The envelope contains the nonce used for this encryption operation. It does not contain a trustworthy census of every other operation performed with the same content-authenticated-encryption key.

For both CCM and GCM, RFC 5084 states the invariant at key scope: nonce values used with any given key must not contain duplicates. Reusing a nonce/key combination for different messages destroys the security properties. The current object's tag can be recomputed and checked. It cannot search another host, an old archive, a failed region or a restored virtual machine for the same pair.

This is why syntax and history need separate receipts. A twelve-octet GCM nonce is the recommended efficient size. Length says nothing about whether a cloned worker generated the same twelve octets yesterday. A random-looking value says nothing about whether a generator state was restored. A database constraint in one region says nothing about a key shared across three regions.

The standard's operational answer is stronger than “be careful.” RFC 5084 says implementations must use an automated key-management system because safe use with statically configured keys is extremely difficult. It describes four general CMS techniques: key transport, key agreement, symmetric key-encryption keys and password-derived key-encryption keys. Each meets this requirement when a fresh content-authenticated-encryption key, or CEK, is generated for every content.

That construction changes the bookkeeping problem. If each object receives a fresh CEK, repeating a nonce value in another object does not repeat the key/nonce pair. A long-lived CEK can also be operated safely, but then the sender owns a durable, atomic nonce namespace for the full scope and life of that key. The standard does not invent the database, counter service or failover protocol. Those are deployment controls, and they carry their own proof burden.

The parameter fields remain real controls. For AES-GCM, the GCMParameters structure carries the nonce and an ICV length from twelve through sixteen octets; twelve is the default and recommendation. The declared length must match the value in the CMS mac field. For AES-CCM, parameters are also mandatory. Its nonce ranges from seven to thirteen octets, and its permitted ICV lengths run from four through sixteen even octets. RFC 5084 recommends twelve. It also explains the CCM trade-off between nonce length and the length field used to encode content size.

A parser should reject an absent required parameter, an impossible value or a tag-length mismatch. Passing those checks establishes that one object fits the encoding contract. It does not establish that the chosen tag length meets a local risk policy, that the key came from an adequate random source, or that another sender did not share the same CEK and allocator state.

The protected surface also needs precise language. RFC 5083 defines AuthEnvelopedData; RFC 5084 makes its authenticated attributes the AAD for CCM or GCM. They are authenticated without being encrypted. The encrypted content and authenticated attributes are covered by the MAC. Unauthenticated attributes are not promoted merely because they travel in the same container.

That last boundary belongs in application design. A valid tag proves that the protected inputs match the key and bytes used for verification. It does not turn an unauthenticated label into an authorization instruction. Nor does it prove the identity of a human, the legitimacy of the content, the intended recipient's business role or the outcome after plaintext release.

RFC 5116 makes the general AEAD interface explicit: key, nonce, plaintext and associated data enter; ciphertext and tag emerge. An algorithm can specify limits and failure behavior, but it cannot infer whether a protocol or implementation reused a nonce beyond the evidence supplied to it. NIST SP 800-38D likewise treats IV uniqueness as a critical operational requirement for GCM.

Key history must therefore be identifiable without exposing keys. A useful receipt binds the object to a non-secret key-epoch identifier, allocator namespace and allocation event. It records whether the CEK was freshly generated for this content or came from a longer-lived epoch. It preserves the exact authenticated-attribute encoding, nonce, ciphertext hash, tag length, verification result and software version. It keeps plaintext and key bytes out of ordinary logs.

Consider a regional failover. Two senders share one CEK. The primary allocates counter 4,201 and encrypts a message. Replication lags. The secondary takes over from 4,200 and emits a different message with the same next value. Both CMS objects are well formed. Both can be parsed later. Each may even have been accepted by its recipient. The failure exists only when the two operations are joined by their actual key epoch.

The inverse error is possible too. Two objects show the same nonce bytes but use genuinely distinct fresh CEKs. A monitor that ignores key identity declares a collision where the prohibited pair did not recur. Evidence must be scoped tightly enough to detect the real failure without manufacturing a false one.

An operational chain should preserve, separately:

  1. the original CMS object bytes and content type;
  2. the algorithm OID and decoded parameters;
  3. the non-secret CEK epoch or fresh-key generation receipt;
  4. the nonce-allocation namespace and atomic allocation event;
  5. the exact authenticated attributes and their encoded AAD;
  6. the ciphertext hash, tag bytes or protected tag receipt, and ICV length;
  7. recipient selection and key-management branch;
  8. parser, key-unwrapping and tag-verification results;
  9. historical duplicate checking at the true key scope;
  10. plaintext release policy; and
  11. application authorization and outcome.

This is an operating recommendation, not extra syntax attributed to RFC 5084. It applies Heng Lu's reality-layer discipline to authenticated encryption: an algorithm name, encoded object, verified tag, historical uniqueness claim, recipient decision and business result are adjacent records. None inherits the authority of the next merely by appearing first.

Sources