Summary

  • RFC 3537 put a one-octet length before an HMAC key and padded the resulting record to the block boundary required by its 3DES or AES wrapping path.
  • A valid unwrap can return the intended bytes, but its integrity result does not identify an HMAC algorithm, authorized use or data origin.

Imagine a mail gateway that opens a CMS AuthenticatedData package. One key is protected for a recipient; the recipient’s system unwraps it, recovers a precise run of bytes and continues processing. The envelope did its job. Yet the successful unwrap has answered a narrow question: did this representation survive the relevant key-wrap integrity check? It has not, by itself, answered which hash function should consume the bytes, whether this service may use them, whose authority placed them there, or whether the package is current.

That distinction is the historical contribution of RFC 3537. Published in May 2003 as a Standards Track Proposed Standard from the S/MIME working group, it adapted established 3DES and AES wrapping methods for HMAC keys whose lengths and parity properties did not fit the inherited constructions. The document named CMS AuthenticatedData as one application. It was a key-transport mechanism, not a complete authorization or provenance format.

A byte count, then the bytes

Each construction begins with LENGTH || KEY. LENGTH is one octet, followed by that many octets of key material. The wrapper adds the fewest random padding octets needed to make the record a multiple of eight bytes. “Arbitrary length” in the introduction therefore means that the key need not match the older wrap algorithms’ fixed sizes; it does not mean an unbounded length field. The RFC does not present this as an application policy for maximum key size.

The pad is not a free-floating annotation. It sits inside the wrapped representation and is covered by the applicable integrity construction. On unwrap, the receiver first checks the encoded object’s integrity, separates the length, key and remainder, and rejects a pad longer than seven octets. That allows it to recover a byte string without guessing where the key ends. But random padding carries no semantic label: it cannot say “HMAC-SHA-256 for this tenant’s audit records” or “valid only until this rotation.”

Two inherited protection paths

RFC 3537 does not invent one common cipher transform. Its 3DES path follows RFC 3217’s wrapping construction, accommodates a key without 3DES parity requirements, includes an eight-octet checksum, and uses a random initialization vector before the outer fixed-IV step. Its AES path reuses the RFC 3394 key-wrap algorithm and adds the length-and-padding record before wrapping. The AES integrity value and the 3DES checksum are not interchangeable details; each is interpreted according to its own construction.

That is why RFC 3394’s extra AES register remains a different story. RFC 3394 owns the A value mixed through the transform and checked before candidate plaintext is released. RFC 3537 owns the HMAC-key envelope around that mechanism: how a variable-length key is framed so it can be wrapped and recovered. The earlier RFC 3058 article likewise remains distinct; it covers IDEA wrapping and its separate capability and checksum questions. RFC 3217 is context for the 3DES branch, not the thesis here.

The algorithm identifiers make another boundary visible. RFC 3537 assigns OIDs to HMAC-key wrapping with 3DES and with AES, and requires NULL parameters. Those names tell a CMS-aware consumer which wrapping operation is represented. They are not the identity of the HMAC digest that later consumes the recovered key. RFC 2104’s key guidance concerns HMAC; RFC 3537’s OID concerns the envelope. Treating the latter as the former would collapse two protocol layers.

Integrity can be true while origin is unknown

The security section says the KEK must be protected and warns that a compromised KEK may expose every HMAC key wrapped under it. It then states the more subtle limit: the wrap functions provide confidentiality and data integrity but do not necessarily provide data-origin authentication. Anyone possessing the KEK can create a message that passes the integrity check. If origin authentication is required, the KEK-distribution mechanism must authenticate its origin, or a digital signature can supply that evidence.

This is not a claim that the algorithms fail their stated checks. It is a statement about what those checks attest. If a system treats “unwrap succeeded” as “the intended authority approved this key for this operation,” it has assigned a role to a receipt that does not carry that role. The cryptographic object may be well formed and intact while its source, purpose or authorization remains unproven.

A correction to the record, not the algorithm

RFC Editor Verified Erratum 254 corrects one value in the 3DES test vector: the PAD line should read be62fe, not 38be62. The corrected value agrees with the bytes shown in the following LKEYPADICV line. This is an editorial repair to a published vector, not a change to the wrap procedure or evidence of a deployed cryptographic failure.

The broader lesson is architectural rather than algorithmic. A system may need a recoverable key, but it also needs separately authenticated evidence for the digest, intended operation, principal, origin and validity period. A signed manifest or a protocol-specific authenticated context can carry those decisions; the key-wrap envelope should not be credited with fields it never encoded. RFC 3537 drew a useful transport boundary. Systems remain auditable when they preserve it.

Sources