Resumen

  • La revisión 03 de un borrador del grupo LAMPS, publicada el 14 de septiembre, actualizaría el RFC 5652 y prohibiría id-data en los usos nuevos de CMS SignedData.
  • Clasifica un uso según el momento en que una especificación define por primera vez la aplicación, desde la futura publicación del documento, no según la implementación o el despliegue del software.
  • Los usos existentes reciben orientación de migración y verificación en vez de la misma prohibición absoluta, porque un cambio general puede romper la interoperabilidad con remitentes desplegados.
  • Sigue siendo un Internet-Draft activo con estatus BCP previsto: no es un RFC, una norma adoptada, evidencia de explotación ni prueba de que un producto sea vulnerable.

Una frontera fechada en el futuro

La revisión 03 añade una afirmación directa al encabezado y al resumen. Si se aprueba, actualizaría el RFC 5652, el estándar vigente de Cryptographic Message Syntax, al prohibir el tipo id-data para usos nuevos de CMS SignedData.

La definición nueva es decisiva. Un uso es nuevo cuando una especificación, desde la fecha de publicación del futuro documento, define por primera vez cómo construir o procesar SignedData para una aplicación. Da igual que esa especificación posterior sea un RFC o registre un identificador de tipo de contenido en IANA. Lo anterior a la publicación es un uso existente.

Es una línea formal clara, pero aún no está operativa. La ficha de Datatracker muestra un borrador activo de un grupo de trabajo cuyo estatus previsto es Best Current Practice. El RFC 2026 define los Internet-Drafts como documentos de trabajo. La revisión puede orientar el examen actual, pero no modifica STD 70 por el solo hecho de haberse publicado como borrador.

La fecha del texto no es la del despliegue

La comparación oficial introduce dos relojes que no conviene fundir.

La definición clasifica por la primera especificación. Otra frase dice que la prohibición para usos nuevos no altera retroactivamente la conformidad de implementaciones ya desplegadas. Son ideas compatibles, pero describen pruebas distintas. Un protocolo puede estar especificado sin un despliegue amplio. Un programa puede aparecer mucho después de su texto fundador. Un remitente antiguo puede seguir activo tras una especificación sucesora.

El borrador no publica un censo que una esos estados, ni afirma hacerlo. Sus apéndices enumeran RFC que usan id-data y analizan la aplicabilidad, pero una referencia normativa no mide instalaciones. Del mismo modo, una fila de IANA puede identificar un objeto y su referencia sin demostrar qué rutas de código lo aceptan, si el receptor exige signedAttrs o si una clave firma en varios contextos.

El riesgo depende del comportamiento. RFC 5652 permite omitir signedAttrs cuando el tipo encapsulado es id-data. El borrador explica cómo una firma podría entonces verificar una estructura que el firmante no quiso firmar expresamente. También limita el hallazgo: algunos protocolos exigen atributos firmados; una verificación correcta puede impedir el ataque; la estructura del mensaje puede reducir su utilidad; y existen mitigaciones. «Existente» no equivale a «vulnerable» y «nuevo» no certifica una implementación segura.

La compatibilidad no es una nota al margen

Para usos nuevos, la revisión dice que id-data MUST NOT utilizarse. Si el contenido es MIME, el tipo propuesto mimeData SHOULD emplearse salvo justificación para un identificador específico. El texto solicita tres actuaciones a IANA, pero los valores siguen como TBD. Los registros actuales de números SMI y tipos internos CMS no convierten marcadores en asignaciones.

Los usos existentes siguen otra vía. Al actualizar el protocolo deberían retirar id-data. Si lo conservan, el texto pide una justificación que permita evaluar el compromiso de seguridad. Una extensión compatible puede ser un mal momento para imponer una ruptura; una versión mayor u otro cambio ya incompatible puede crear la oportunidad adecuada.

No es una excepción escondida. Es el juicio de interoperabilidad expreso del borrador. Puede haber remitentes desplegados que no produzcan signedAttrs como espera una regla endurecida. Un MUST universal haría que receptores nuevos rechazaran tráfico antiguo legítimo antes de disponer de migración. La cuestión de gobierno es dejar constancia de dónde se ejerció la flexibilidad y con qué evidencia.

La regla atraviesa claves y aplicaciones

La revisión 03 añade separación de claves. Exigir atributos firmados en un protocolo no basta si la misma clave se usa en otro protocolo o en una versión antigua donde no son obligatorios. El borrador plantea claves distintas o una mitigación uniforme para todas las operaciones de esa clave.

También asigna responsabilidad a las bibliotecas CMS generales. Los usos nuevos deben comprobar el tipo esperado y la presencia obligatoria de atributos. Si la biblioteca no aplica reglas específicas del protocolo, debe exponer el tipo recibido a la aplicación para que esta decida.

La superficie de control incluye autores de especificaciones, mantenedores de bibliotecas, propietarios de aplicaciones, custodios de claves e IANA. Cada uno conserva una parte del estado. Ninguno puede demostrar en solitario que un despliegue completo migró sin romperse.

Un inventario de transición sin condena colectiva

Un inventario público breve haría auditable la frontera. Por cada uso conocido de CMS SignedData registraría: primera especificación y fecha; tipo de contenido y regla de signedAttrs; clase de evidencia de despliegue sin inventar cifras; posible reutilización de claves; próxima oportunidad de cambio incompatible; motivo para conservar o sustituir id-data; propietario de la especificación, próxima revisión e historial de correcciones.

Es una propuesta de Daniel Kade, no una obligación del borrador. No declararía inseguros todos los usos antiguos. Distinguiría una especificación antigua con verificación exigida, un despliegue cuyo comportamiento se desconoce y una especificación nueva sometida a la regla prospectiva.

La fecha de publicación puede seguir siendo la frontera formal. El inventario aporta el mapa operativo.

Fuentes