Resumen

  • El identificador rsaEncryption no anuncia que el titular de la clave acepte RSA-KEM; RFC 9690 reserva esa afirmación para evidencia adicional y acotada.
  • La decisión de envío necesita unir certificado, procedencia y vigencia de la capacidad, dos KDF, longitud de KEK, algoritmo de wrap y tipo de contenido CMS.

Una clave pública permite ejecutar una operación. No obliga a su titular a mantener activo el software correspondiente. Esa diferencia parece obvia hasta que un inventario reduce el certificado a «RSA: sí» y un compositor de mensajes convierte esa casilla en «RSA-KEM: sí».

RFC 9690 corta esa inferencia: el OID rsaEncryption puede identificar la clave sin indicar que el destinatario aceptará RSA-KEM. La cadena puede validar y el módulo cumplir la longitud exigida, mientras el endpoint usa otro mecanismo, otro conjunto de componentes o ninguna ruta KEM.

Además, hay dos derivaciones. RSA-KEM cifra un entero aleatorio nuevo z y deriva de él un secreto compartido. Después, KEMRecipientInfo aplica su propia KDF para obtener la KEK que desempaqueta la clave de contenido. Las dos KDF pueden ser distintas. KDF3/SHA-256 y AES-Wrap-128 forman el mínimo obligatorio, pero no agotan las opciones.

Capacidad parcial, no promesa permanente

El destinatario puede anunciar RSA-KEM mediante SMIMECapabilities en un mensaje firmado, conforme a RFC 8551, o mediante la extensión de RFC 4262. Esa señal supera a una conjetura sobre la clave, pero sigue siendo parcial. Hay que conservar quién la firmó, cuándo, con qué certificado y qué parámetros declaró.

Una capacidad vista meses atrás no prueba que la configuración siga activa. Su ausencia tampoco demuestra necesariamente incompatibilidad, porque la lista es parcial. El registro debe poder caducar y debe distinguir un atributo histórico de una extensión emitida con el certificado.

Cuando la clave se destina solo a RSA-KEM, id-rsa-kem-spki expresa una intención más precisa. Sin parámetros, la derivación interna usa KDF3/SHA-256; con parámetros, GenericHybridParameters limita KDF, longitud de KEK y wrap en el mensaje. Si existe keyUsage, solo admite keyEncipherment. Sigue sin ser una prueba de custodia actual, decapsulación o aceptación de la aplicación.

La migración dejó dos contratos

RFC 5990 colocaba RSA-KEM en KeyTransRecipientInfo y concatenaba C y WK. RFC 9690 usa el KEMRecipientInfo de RFC 9629, con kemct y encryptedKey separados. La compatibilidad hacia atrás existe, pero no borra la necesidad de declarar qué contrato eligió el emisor.

Un log verificable conserva la versión de procesamiento, el certificado, la señal de capacidad y la tupla concreta. También separa los resultados del receptor: longitud y rango del ciphertext, operación de clave privada, derivación del secreto, derivación de KEK, unwrap, autenticación o descifrado y decisión de la aplicación. Haber construido bien el mensaje no prueba ninguno de esos pasos remotos.

Un recibo operativo

El recibo debería incluir huella y ruta del certificado; OID y bytes exactos de parámetros; keyUsage; origen, firmante y edad de la capacidad; KDF/hash internos; KDF CMS; longitud de KEK; wrap; tipo de contenido; y elección explícita entre RFC 5990 y RFC 9690.

Rotación de certificado, actualización del cliente, retirada de un algoritmo, cambio de contenido o primer fallo específico de la tupla deben forzar una renovación. Si la voluntad actual no puede demostrarse, el sistema confirma o usa un mecanismo autorizado por separado; no adivina a partir de rsaEncryption.

RFC 8017, RFC 3394, RFC 4086 y RFC 5280 cubren representación RSA, wrap, aleatoriedad y validación X.509. Ninguno observa el estado vivo del destinatario.

La especificación mínima de Lu Heng explica por qué conviene fijar un suelo estrecho sin fingir uniformidad futura. Su marco de capas de realidad mantiene separados certificado, anuncio, estructura, cálculo privado y decisión. La primacía del código en ejecución exige que la última afirmación proceda del receptor real, no de un identificador interpretado por el emisor.

Fuentes