Resumen

  • RFC 3657 dio a Camellia identificadores CMS distintos para cifrar contenido y envolver claves. El cifrado CBC exige un IV presente de 16 octetos; el identificador de envoltura, en cambio, exige que los parámetros estén ausentes.
  • La capacidad S/MIME utiliza una tercera forma: un parámetro NULL. El OID de envoltura identifica el tamaño de la clave de cifrado de claves (KEK), no necesariamente el de la clave de contenido (CEK) envuelta.

El mismo nombre no significa la misma operación

En un sobre CMS, «Camellia» no basta para descifrar qué operación realizó el emisor. El receptor debe saber si el algoritmo protegió el contenido o envolvió la clave de cifrado del contenido (CEK), e interpretar el identificador según esa función. RFC 3657, publicada en enero de 2004 como documento Standards Track, fijó esas convenciones para Camellia: una familia de OID para cifrado CBC del contenido y otra para envolver claves. RFC 3657

La diferencia aparece en los parámetros. Para id-camellia128-cbc, id-camellia192-cbc e id-camellia256-cbc, el campo parameters de AlgorithmIdentifier DEBE estar presente y contener el vector de inicialización, un valor de 16 octetos. El IV forma parte de la descripción del cifrado de contenido; no se deduce del nombre del cifrado. La RFC también remite a la regla CMS de relleno del texto claro. RFC 3657 RFC 5652

Para envolver la clave, la expectativa se invierte. Los tres OID de envoltura Camellia incluyen un arco de tamaño, pero los parámetros de su AlgorithmIdentifier DEBEN estar ausentes. La construcción de envoltura define el uso de su valor inicial interno; ese campo no transporta un IV. El tamaño del OID se refiere a la clave de cifrado de claves (KEK), no obliga a que la CEK envuelta tenga el mismo tamaño. Las implementaciones DEBEN admitir longitudes iguales; si admiten longitudes distintas, la KEK DEBE ser igual o mayor que la CEK. Por eso la RFC establece un límite de codificación e interoperabilidad, no un único tamaño para todas las claves de un sobre. RFC 3657 RFC 3394

Un tercer formato para anunciar capacidad

RFC 3657 también define cómo un cliente S/MIME anuncia su soporte de Camellia en SMIMECapabilities. El OID de capacidad va acompañado por un parámetro NULL. No contradice la ausencia de parámetros del identificador de envoltura: son estructuras ASN.1 diferentes y cumplen funciones distintas. Tampoco es NULL la misma representación en el cable que un parámetro ausente. Para hacer verificable la forma anunciada, la RFC incluye las codificaciones DER para los tres tamaños de clave. RFC 3657 RFC 2633

La lista de capacidades está firmada, ordenada por preferencia y solo describe parcialmente lo que el emisor admite. Ayuda a una decisión posterior junto con acuerdos privados, preferencias del usuario y restricciones legales. No es una negociación en vivo, una prueba de la configuración actual del destinatario ni evidencia de que un mensaje concreto usó Camellia. Para identificar la operación seleccionada hay que inspeccionar los campos de cifrado del contenido y gestión de claves del sobre, no limitarse a una declaración previa de capacidad. RFC 3657

La conformidad depende de mantener separados los contextos

Una revisión de interoperabilidad debería comparar las tres situaciones por separado. Para el cifrado CBC del contenido: confirmar el identificador, el tamaño de clave y el IV presente de 16 octetos. Para la envoltura: comprobar que no haya parámetros y que las longitudes efectivas de KEK y CEK respeten el soporte declarado por la implementación. Para la capacidad: comparar el valor DER firmado —incluido NULL— y el orden de preferencia. Confundir estos contextos puede producir una diferencia de análisis o negociación aunque todos los sistemas digan admitir el mismo cifrado.

RFC 3657 indica que la envoltura con Camellia sigue la construcción de RFC 3394 sustituyendo AES por Camellia, dado que ambas tienen bloques de 128 bits. El valor inicial de integridad predeterminado es la constante A6A6A6A6A6A6A6A6. Si al desenvolver la clave no se recupera ese valor, el receptor devuelve error y no entrega datos de clave. También se permiten valores iniciales alternativos para el alcance de integridad propio de una aplicación. Esa comprobación se refiere a la clave envuelta bajo la construcción especificada; no autentica al emisor, el contenido CMS ni la autoridad del usuario para actuar sobre datos descifrados. RFC 3657 RFC 3394

Esta es una reconstrucción histórica de un contrato de codificación, no una recomendación de seguridad ni un censo de despliegue. Los registros generales de algoritmos CMS y los perfiles posteriores aportan contexto, pero no demuestran qué productos implementaron RFC 3657 ni con qué frecuencia. La lección es más acotada: el identificador de algoritmo es un campo tipado. Hay que leer juntos el OID, la presencia de parámetros y la estructura que lo contiene. RFC 3370 RFC 8419

Fuentes