Resumen

  • RFC 3058 asignó identificadores y reglas de parámetros distintos al cifrado de contenido IDEA y a la envoltura de claves IDEA. La representación quedó definida, pero el soporte siguió siendo opcional y el contexto determinaba si los parámetros faltaban, eran NULL o contenían un IV de ocho octetos.
  • Una capacidad S/MIME firmada era una afirmación ordenada del cliente, no un recibo de ejecución. El uso real seguía dependiendo de ambos extremos, la preferencia local, acuerdos privados, restricciones legales, acceso a claves, desenvoltura correcta y procesamiento del contenido.

Un nombre no basta para dos tareas

El software criptográfico no puede interoperar con la frase «usar IDEA». Un mensaje CMS necesita identificador, parámetros y lugar para cada valor. También debe separar el algoritmo que protege el contenido del que protege su clave. Publicado como Informational en febrero de 2001, RFC 3058 aportó esa precisión.

Un OID nombraba IDEA-CBC para cifrar el contenido; otro, la envoltura de claves IDEA. El primero trabajaba con clave secreta de 128 bits y bloques de 64. El segundo tomaba una clave de contenido de 16 octetos, la unía a una comprobación de ocho y producía 32 octetos envueltos. «Soporta IDEA» borraba dos funciones distintas.

Los OID estaban bajo una rama de empresa privada ligada a Ascom. Su valor era coordinador: implementaciones independientes podían emitir el mismo número para la misma función. El registro no decía que todo cliente S/MIME tuviera el código, que cualquier usuario pudiera habilitarlo ni que un mensaje hubiera llegado a una persona. Hizo legible una opción; no la hizo disponible.

Ausente, NULL e IV no significan lo mismo

El identificador de contenido admitía IDEA-CBCPar, con un IV opcional de exactamente ocho octetos. Si aparecía allí, debía usarse y no incluirse al principio del texto cifrado. Si el parámetro faltaba, los primeros 64 bits del texto se interpretaban como IV, aunque RFC 3058 desaconsejaba esa forma en CMS o S/MIME.

La envoltura seguía otra regla: sus parámetros debían ser NULL. Los anuncios S/MIME seguían una tercera: los parámetros debían estar ausentes. En documentación informal, los tres parecen «nada». En ASN.1 son bytes e instrucciones diferentes.

Ese es el núcleo discreto del documento. Un identificador solo es instrucción completa con su contexto y convención de parámetros. Un analizador que intercambia ausencia y NULL puede rechazar una estructura válida o aceptar un significado no acordado. Registrar solo «IDEA» impide reproducir el mensaje.

La errata 5913, retenida para actualización, lo subraya: el símbolo ASN.1 IDEA-CBC debería ser id-IDEA-CBC para comenzar con minúscula, sin cambiar el OID numérico. Nombre humano, identificador fuente ASN.1 y número registrado están relacionados, pero no son el mismo objeto.

Aleatoriedad dentro y constante fuera

La envoltura estaba definida paso a paso. Se añadía una comprobación de ocho octetos a la clave de contenido de 16; un IV aleatorio de ocho cifraba esos 24 octetos con IDEA-CBC. Después se anteponía el IV aleatorio, se invertían los 32 octetos y se cifraban de nuevo con el IV exterior fijo 4adda22c79e82105. El proceso inverso rechazaba una comprobación incorrecta.

El IV fijo puede engañar si se separa del diseño completo: no elimina el IV nuevo del interior. A la inversa, aleatoriedad y comprobación válida no prueban autorización, preferencia del destinatario ni utilidad del contenido. La comprobación responde una pregunta limitada sobre la clave recuperada.

CMS separaba capas porque cumplían trabajos diferentes. La clave de contenido protegía el cuerpo; una clave de cifrado protegía aquella clave; la envoltura la transportaba; el sobre identificaba algoritmos y destinatarios. El éxito de una capa no acreditaba las demás.

Capacidad firmada, ordenada y parcial

Un cliente podía publicar SMIMECapabilities como atributo firmado. RFC 3058 dio bytes DER exactos para IDEA-CBC y la envoltura, en categorías lógicas distintas; el orden expresaba preferencia. Especificaciones posteriores mantuvieron que la lista era parcial y no tenía que enumerarlo todo.

Una firma validada atribuía la afirmación dentro de aquel mensaje, con las verificaciones de certificado y tiempo pertinentes. No interrogaba al proceso actual del destinatario. El software podía actualizarse o reconfigurarse; un proveedor podía faltar; una clave podía ser inaccesible; una política podía desactivar un algoritmo implementado. También podía existir soporte no anunciado.

RFC 3058 dejó la selección fuera del registro. Citó capacidades recibidas, acuerdos privados, preferencias y restricciones legales. Si el usuario exigía IDEA, ambos clientes debían soportarlo y la preferencia debía configurarse. El OID eliminaba ambigüedad sobre bytes, no ejercía esas autoridades.

La licencia seguía junto al formato

El aviso histórico decía que Ascom poseía patentes, ofrecía licencias no exclusivas en condiciones razonables y no discriminatorias y permitía gratuitamente el uso no comercial. Es evidencia de la frontera presentada en 2001, no asesoría jurídica actual. La normalización no borraba la capa de licencia entonces declarada.

Una implementación podía reconocer el OID sin incluir el algoritmo. Un desarrollador podía tener código y una organización rechazar sus condiciones. El receptor podía anunciar capacidad y la política del emisor elegir otra cosa. El registro técnico no absorbía esas decisiones.

RFC 3370 separó después las convenciones algorítmicas comunes del núcleo CMS; RFC 5652 definió una versión posterior de CMS; RFC 8551 asignó requisitos a AES y ChaCha20-Poly1305 manteniendo las capacidades y la selección externa. Esa evolución no demuestra despliegue de IDEA, ni su ausencia de una lista moderna borra sus OID.

La lección duradera no es si IDEA ganó o perdió. La normalización puede hacer reproducible una decisión sin volverla universal. El número identifica, los parámetros indican cómo leer, la capacidad firmada atribuye una afirmación y la política y el derecho condicionan la selección. Solo un intercambio real demuestra que ambos extremos terminaron el trabajo.

Fuentes

Lu Heng no escribió ni aprobó RFC 3058. Sus ensayos se usan solo como lente analítica declarada para separar registro simbólico de conducta ejecutable.