Summary

  • RFC 3058 assigned separate identifiers and parameter rules to IDEA content encryption and IDEA key wrapping. That made the wire representation exact, but support remained optional and context still determined whether parameters were absent, NULL, or carried an eight-octet IV.
  • A signed S/MIME capability was an ordered claim about a client, not an execution receipt. Actual use still depended on both endpoints, local preference, private agreement, legal constraints, key access, successful unwrap and successful content processing.

A name for two different jobs

Cryptographic software cannot interoperate on the phrase “use IDEA.” A CMS message needs an algorithm identifier, parameters and a place for every value. It also needs to distinguish the algorithm protecting the message content from the algorithm protecting the content-encryption key. RFC 3058, published as an Informational document in February 2001, supplied that precision.

One object identifier named IDEA in CBC mode for content encryption. A second named the IDEA key-wrap algorithm. The distinction was not decorative. The first operated on message content with a 128-bit secret key and 64-bit blocks. The second took a 16-octet content-encryption key, joined it to an eight-octet checksum and produced a 32-octet wrapped value. A client could not replace either identifier with a generic declaration of enthusiasm for the cipher.

The OIDs lived under a private-enterprise branch associated with Ascom. Their value was coordination: independent implementations could emit the same identifier for the same function. Registration did not say that every S/MIME client contained the code, that every user could enable it, or that an encrypted message had reached anyone. It made a choice legible before it made the choice available.

Absence, NULL and an IV are not synonyms

RFC 3058 gave the content-encryption identifier an IDEA-CBCPar structure containing an optional IV of exactly eight octets. When that IV appears in the parameters, the implementation uses it and does not place it at the front of the ciphertext. When the parameter is omitted, the first 64 bits of ciphertext become the IV. The RFC described that second form but said it should not be used in CMS or S/MIME.

The key-wrap identifier followed a different rule: its parameters field had to be NULL. The two S/MIME capability advertisements followed a third rule: their parameters had to be absent. Those three states can look like variations of “nothing” in casual documentation. In ASN.1 they are different bytes and different instructions.

That difference is the quiet center of the document. An identifier is not a complete instruction until its context and parameter convention are known. A parser that treats absent and NULL as interchangeable can reject a valid structure or accept one whose semantics were never agreed. A dashboard that records only “IDEA” loses the evidence necessary to reproduce the message.

The RFC's own later erratum reinforces the point. Errata ID 5913, held for document update, says the ASN.1 symbol IDEA-CBC should begin with the lowercase-compatible form id-IDEA-CBC. The numeric OID is unchanged. Human label, ASN.1 source identifier and registered number are related, but they are not one object.

The wrap had a random inside and a fixed outside

The wrap procedure was deliberately exact. It appended an eight-octet integrity-check value to the 16-octet content key. It generated an eight-octet random IV and encrypted that 24-octet value in IDEA-CBC. It then prefixed the random IV, reversed all 32 octets and encrypted again using the fixed outer IV 4adda22c79e82105. Unwrapping ran the operations backward and rejected a checksum mismatch.

The fixed outer IV is easy to misread when separated from the full construction. It did not remove the fresh inner IV. Conversely, the presence of randomness and a matching checksum did not prove who authorized the message, whether the recipient wanted this algorithm, or whether the decrypted content was meaningful. The checksum answered a narrow processing question about the unwrapped key.

CMS separated these layers because each had a different purpose. A content-encryption key protected the body; a key-encryption key protected that content key; the wrap format transported it; the envelope identified algorithms and recipients. A successful operation at one layer was not a receipt for all the others.

Capability was signed, ordered and incomplete

S/MIME clients could publish SMIMECapabilities in a signed attribute. RFC 3058 supplied exact DER byte strings for IDEA-CBC and IDEA key wrapping and placed them in different logical categories. The ordering could express preference. Later S/MIME specifications continued to describe the list as partial: a client did not have to enumerate everything it supported.

A verified signature therefore established who made a capability claim in that signed message, subject to certificate and signing-time checks. It did not interrogate the recipient's current process. Software could be upgraded or reconfigured. A provider module could be absent. A key could be inaccessible. Policy might disable an implemented algorithm. The capability might have been omitted even when support existed, because the list was not required to be exhaustive.

RFC 3058 itself kept selection outside the registry. It said the sender's decision could involve received capabilities, private agreements, user preferences and legal restrictions. If users required IDEA, both clients had to support it and the preference had to be set. The OID registry could eliminate ambiguity about the bytes; it could not exercise any of those authorities.

The licence sat beside the wire format

The historical IPR notice said Ascom held patents on IDEA, offered non-exclusive licences on reasonable and non-discriminatory terms, and allowed non-commercial use free. That notice is evidence about the boundary the document presented in 2001, not legal advice about today. It shows that protocol availability and legal availability were understood as separate matters even within the same RFC.

An implementation could recognize the OID yet omit the algorithm. A developer could possess code while an organization declined the licensing or policy conditions. A recipient could advertise support while a sender's local rules selected something else. The specification did not collapse those decisions into its technical registration.

Later standards changed the surrounding baseline. RFC 3370 separated common CMS algorithm conventions from the core syntax. RFC 5652 standardized a later CMS version. RFC 8551's S/MIME 4.0 suite names AES-based modes and ChaCha20-Poly1305 at defined requirement levels while retaining capability and out-of-band selection logic. That history does not prove IDEA was deployed, and absence from a later mandatory list is not the same as deleting its OIDs.

RFC 3058's durable lesson is not that IDEA won or lost. It is that standardization can make a decision reproducible without making it universal. A number identifies the choice. Parameters tell a parser how to read it. A signed capability attributes a claim. Policy and law decide whether it may be selected. Only a real exchange can show whether both endpoints completed the work.

Sources

Lu Heng did not write or approve RFC 3058. His essays are used only as disclosed analytical lenses for separating symbolic registration from executable behavior.