Summary

  • RFC 3657 assigned Camellia distinct CMS identifiers for content encryption and key wrapping. CBC content encryption requires a present 16-octet IV; the key-wrap algorithm identifier requires parameters to be absent.
  • A signed S/MIME capability entry uses a third form, NULL. The key-wrap OID names the key-encryption key size, not necessarily the content key being wrapped.

The same name is not the same operation

In a CMS envelope, “Camellia” is not enough information to decode what a sender did. The receiver needs to know whether the cipher protected the message content or wrapped the content-encryption key (CEK), and then interpret the algorithm identifier in that role. RFC 3657, published in January 2004 as a Standards Track document, supplied those conventions for Camellia. It added one family of identifiers for CBC content encryption and another for key wrapping. RFC 3657

The split is visible in the parameters. For id-camellia128-cbc, id-camellia192-cbc and id-camellia256-cbc, the AlgorithmIdentifier parameters MUST be present and contain the initialization vector as a 16-octet value. The IV is part of the content-encryption description, not a value to infer from the cipher name. The RFC also directs that plaintext padding follow the CMS rule. RFC 3657 RFC 5652

Key wrapping reverses the parameter expectation. The three Camellia wrap identifiers include a key-size arc, but their AlgorithmIdentifier parameters MUST be absent. There is no IV field to carry there: the wrapping construction specifies how it uses its internal initial value. The identifier's size denotes the key-encryption key (KEK), not a promise that the wrapped CEK has the same size. Implementations MUST support equal CEK and KEK sizes; when they support different sizes, the KEK MUST be at least as long as the CEK. RFC 3657 therefore defines an encoding and compatibility boundary, not a rule that every envelope uses one key size throughout. RFC 3657 RFC 3394

A capability is a third encoding context

RFC 3657 also specifies how an S/MIME client announces Camellia support in SMIMECapabilities. The capability OID is accompanied by a NULL parameter. That does not contradict the absent parameters on the key-wrap identifier: these are different ASN.1 structures with different meanings. Nor does NULL mean “no parameters” in the same wire representation. The RFC even gives DER encodings for the three key sizes so implementations can compare the advertised form precisely. RFC 3657 RFC 2633

The capability list is signed, ordered by preference and only a partial account of what the sender supports. It is an input to a later sender decision, alongside private agreements, user preferences and legal restrictions. It is not a live handshake, a test of the recipient's current configuration, or proof that a message was encrypted with Camellia. To describe the operation, a reader must inspect the envelope's selected content algorithm and key-management fields, not just a prior capability advertisement. RFC 3657

Conformance lives at the boundaries

This three-way distinction changes what an interoperability review should compare. For CBC content encryption, check that the identifier selects the intended key size and that a 16-octet IV is present. For key wrap, check that parameters are absent and that the actual KEK and CEK lengths satisfy the implementation's supported relationship. For capability processing, compare the signed DER value—including its NULL parameter—and the order in which preferences were communicated. Conflating those contexts can create a parse or negotiation mismatch even though every system says it supports the same cipher.

RFC 3657 says Camellia wrapping follows the RFC 3394 construction with AES replaced by Camellia, relying on their common 128-bit block size. Its default wrapping integrity value is the fixed A6A6A6A6A6A6A6A6; if unwrapping does not recover that value, the receiver returns an error and does not return key data. The RFC also allows alternative initial values for application-specific integrity scope. That check concerns the wrapped key data under the specified construction; it does not authenticate the sender, the CMS content, or a user’s authority to act on decrypted content. RFC 3657 RFC 3394

This is a historical reconstruction of an encoding contract, not a security endorsement or deployment survey. The broader CMS algorithm registry and later profiles provide context, but do not establish which products implemented RFC 3657 or how often. Its lasting lesson is narrower: the algorithm identifier is a typed protocol field. Its OID, parameter presence and surrounding structure have to be read together. RFC 3370 RFC 8419

Sources