Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)
Extracted elements (20)
Camellia key wrapping follows the AES key wrap algorithm (RFC 3394) directly because Camellia and AES share identical block size (128 bits) and key sizes (128, 192, 256 bits), making the algorithm directly applicable.
Camellia was designed for flexibility across 32-bit processors, 8-bit smart card processors, cryptographic hardware, and embedded systems, with excellent key setup time and key agility superior to AES, justifying its inclusion as an optional CMS algorithm.
The constant IV A6A6A6A6A6A6A6A6 supports a strong integrity check: if unwrapping produces this value, the probability that key data is corrupt is 2^-64, providing a probabilistic integrity guarantee over the wrapped period.
Camellia's interface is identical to AES (128-bit block size, 128/192/256-bit key sizes), enabling direct reuse of the AES key wrap algorithm from RFC 3394 and alignment with RFC 3565 (AES in CMS) conventions.
An S/MIME client SHOULD announce supported cryptographic functions using the SMIMECapabilities attribute, which MUST be signed, and whose OIDs MUST be ordered by preference within functional categories.
For Camellia key-encryption OIDs, the AlgorithmIdentifier parameters field MUST be ABSENT, because the key wrapping procedure itself defines IV usage.
If an S/MIME client is required to support Camellia symmetric encryption, the SMIMECapabilities attribute MUST contain the appropriate Camellia OID, with the parameter CamelliaSMimeCapability ::= NULL.
If users require Camellia for symmetric encryption, it MUST be supported by S/MIME clients on both the sending and receiving side, and MUST be set in user preferences.
Implementations MAY use different KEK and CEK sizes; the OID specifies only the KEK key size and makes no statement about the size of the wrapped Camellia CEK.
Implementations MUST support the CEK and KEK having the same length. If different lengths are supported, the KEK MUST be of equal or greater length than the CEK.
The AlgorithmIdentifier parameters field MUST be present for Camellia CBC content encryption, and MUST contain the 16-octet initialization vector (CamelliaIV).
Alternative initial values are permitted to extend integrity scope beyond just the wrapped key period or to handle key data that is not a multiple of 64 bits; NIST may define alternatives in future key management publications.
The Camellia key unwrap algorithm takes a KEK K and (n+1) 64-bit ciphertext blocks {C[0]..C[n]}, producing n 64-bit plaintext blocks {P[1]..P[n]}, and returns an error if the recovered initial value does not match the expected IV.
The Camellia key wrap algorithm takes a KEK K and n 64-bit plaintext blocks {P[1]..P[n]}, producing (n+1) 64-bit ciphertext blocks {C[0]..C[n]}, performing s=6n encryption steps.
The default initial value (IV) for the key wrap integrity check is the 64-bit hexadecimal constant A6A6A6A6A6A6A6A6; if unwrap recovers any other value, an error must be returned.
Three OIDs identify Camellia content-encryption in CBC mode for 128-, 192-, and 256-bit key sizes: id-camellia128-cbc, id-camellia192-cbc, and id-camellia256-cbc, defined under the Japanese NTT OID arc.
Three OIDs identify Camellia key-encryption (key wrap) for 128-, 192-, and 256-bit KEK sizes: id-camellia128-wrap, id-camellia192-wrap, and id-camellia256-wrap.
Security considerations from the CMS specifications (RFC 3369, RFC 3370) and the AES key wrap algorithm (RFC 3394) apply to this document. No security problems have been found on Camellia per CRYPTREC and NESSIE evaluations.
CamelliaCBCParameter is defined as CamelliaIV, an OCTET STRING of exactly 16 bytes, used as the initialization vector for CBC mode encryption.
SMIMECapability SEQUENCE for Camellia MUST be DER-encoded as specific hex strings: 128-bit key is '30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 02 05 00', 192-bit ends in '03 05 00', 256-bit ends in '04 05 00'.