Resumen

  • RFC 9943 permite probar que un servicio de transparencia registró una declaración firmada bajo una política concreta y emitió un recibo con pruebas verificables. Eso describe un registro, no una aprobación general del artefacto.
  • Elegir a qué emisor creer, qué recibo aceptar, qué regla local aplicar y quién puede liberar o bloquear una versión sigue siendo una decisión de la organización responsable de reparar el daño.

La transparencia empieza la investigación; no la clausura

La expresión “el componente tiene un recibo de transparencia” puede sonar como un veredicto. En RFC 9943 es una afirmación mucho más acotada y por ello más útil. El documento, publicado en junio de 2026 como RFC IETF de Standards Track, define una arquitectura para hacer transparentes declaraciones firmadas sobre artefactos de cadena de suministro. No define un sistema que conceda permisos de lanzamiento.

Un emisor puede firmar una declaración sobre una imagen, un paquete o un firmware: una lista de componentes, una atestación, un aviso de vulnerabilidad o de fin de vida, entre otros contenidos serializables. Un Transparency Service —TS— puede registrar esa declaración. El registro aplica la Registration Policy del TS, introduce la declaración en una estructura de datos verificable y genera un Receipt. Así, un lector puede comprobar propiedades de esa estructura, incluida la inclusión de la declaración.

La capacidad tiene importancia. Un historial append-only vuelve más difícil ocultar o alterar silenciosamente una afirmación. Puede dar a un auditor material para comprobar consistencia o para revisar declaraciones de un emisor. Sin embargo, el registro no convierte una declaración en análisis de riesgo, autorización contractual, decisión de seguridad, prueba de compatibilidad ni mandato para desplegar. Hace visible una pieza de evidencia; no asume las consecuencias de usarla.

No confundir cuatro hechos

El primer hecho es que un emisor firmó. Una firma válida vincula una clave con un contenido y las metadatas previstas. No demuestra sin más que el emisor es el que una organización esperaba, que tenía competencia para hacer esa afirmación o que el contenido es cierto.

El segundo es que un TS registró. RFC 9943 define el registro como la presentación de la declaración, la aplicación de una política, la incorporación a la estructura verificable y la producción de un recibo. La política de registro es una condición previa basada en metadatos y cabecera no opaca. Puede ser amplia, estrecha o especializada. El resultado sólo afirma qué controles hizo ese servicio con esa política; no certifica todos los controles que necesita cada destinatario.

El tercero es que una parte que confía verificó un recibo aceptable. La norma exige que esa parte confíe en la clave o certificado y la identidad asociada de al menos un emisor de recibos. Le permite decidir que basta un recibo y aplicar después políticas de validación propias. Por tanto, ningún recibo trae incorporada una regla universal de aceptación. Alguien debe seleccionar el servicio, las claves, el perfil de prueba, las condiciones de vigencia y los emisores relevantes.

El cuarto es una decisión operativa. Un responsable de entrega puede autorizar una versión; seguridad puede retenerla; compras puede admitirla dentro de un contrato; operaciones puede mantener una versión en ejecución y rechazar la siguiente. Son decisiones con mandatos y remedios distintos. Un recibo técnicamente correcto no las toma por delegación.

Mantener las cuatro separadas evita errores prácticos. Una declaración puede estar registrada y el cliente puede no confiar en su emisor. Un recibo puede verificarse y, aun así, una regla local puede impedir el despliegue por una exposición nueva, una licencia o una incompatibilidad. Una emergencia puede requerir una excepción temporal; eso no justifica borrar la cadena, sino registrar por separado quién autorizó la excepción, hasta cuándo y cómo se revisará.

La política también tiene tiempo

RFC 9943 reconoce que un TS puede actualizar su Registration Policy o sus anclas de confianza. A la vez, el servicio debe conservar información suficiente para que un auditor reproduzca las verificaciones exigidas por la política vigente cuando ocurrió el registro. La lectura correcta de un recibo incluye, por tanto, la política, el momento, la clave, el TS y la declaración exacta, no sólo la pregunta binaria de si una firma verifica.

Ese límite no inmoviliza a un servicio. Las claves cambian y las políticas deben endurecerse o ajustarse. Impide otra cosa: que una política nueva reescriba sin aviso el significado de una inscripción antigua, o que un recibo viejo sea presentado como si fuese la política de liberación actual de una empresa.

Tampoco la posición en el registro prueba toda una cronología. El RFC advierte que, salvo que la política lo anuncie, no puede suponerse que el orden de las declaraciones en la estructura coincida con el orden en que fueron emitidas. Un índice de log no prueba que un aviso antecediera a un parche, que un revisor conociera la información antes de decidir o que la decisión ocurrió al mismo tiempo. Esos vínculos necesitan sus propios sellos de tiempo y custodios.

La transparencia tampoco convierte una declaración en verdad. RFC 9943 contempla declaraciones falsas, modificaciones posteriores y afirmaciones contradictorias de distintos emisores sobre el mismo artefacto. Permite inspeccionar el historial y escoger a quién creer. No instala un árbitro universal de exactitud.

Falta con frecuencia el recibo de decisión

Es común encontrar la huella del artefacto, la atestación firmada, el recibo y el nombre de una política. La acción decisiva queda en cambio en una conversación, un botón de consola o una aprobación urgente sin custodia visible. Cuando aparece un problema, se puede demostrar que algo se registró, pero no por qué la organización dejó pasar ese software.

Por eso conviene un recibo de decisión de lanzamiento, deliberadamente separado de SCITT. Para cada autorización, retención, denegación o excepción relevante, debería unir la versión inmutable; la declaración y el emisor; el TS; la versión y hora de la política de registro; el resultado de verificación y su revisión posterior; la política local o excepción aplicada; la autoridad que decidió; el resultado; la fecha de vencimiento o gatillo de revisión; y el camino de corrección, apelación o reversión.

No es un requisito que imponga RFC 9943. Es una forma de no atribuir a la norma un poder que no reclama. Los detalles confidenciales de pruebas, clientes o amenazas pueden permanecer protegidos. La autoridad autorizada, sin embargo, debe poder reconstruir qué prueba condujo a qué decisión y cómo puede corregirse.

La automatización conserva el mismo límite. Una tubería puede verificar un recibo y ejecutar una regla predefinida. El registro debe decir qué versión de la regla se ejecutó, quién la adoptó, qué entradas evaluó y qué resultado produjo. “El log lo permitió” oculta el hecho central: una institución o una persona eligió antes la regla que el automatismo aplicó.

Un estándar de evidencia no gobierna el riesgo ajeno

La norma deja fuera de alcance la gestión y el almacenamiento de declaraciones, así como el descubrimiento y la notificación de cambios entre participantes. Esa reserva permite que un fabricante, un hospital, un organismo público y un mantenedor voluntario examinen la misma evidencia sin fingir que comparten un único mandato de riesgo.

El problema aparece cuando una propiedad técnica se usa para lavar una decisión institucional. Compras dice que la debida diligencia terminó porque hay una declaración inscrita. Entrega dice que un recibo de inclusión equivale a la aprobación del responsable de riesgo. Operaciones dice que una firma de emisor sigue autorizando un componente después de una información nueva. En cada caso, un dato verdadero pero limitado carga una decisión que nadie dejó atribuida.

La práctica más sólida sigue tres pasos: verificar la prueba por la propiedad que demuestra; conservar la política y el tiempo que le dan sentido; y registrar quién decidió utilizar esa evidencia. Así se puede distinguir un fallo criptográfico de un fallo de gobierno sin reducir uno al otro.

Fuentes

  1. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains
  2. IETF Datatracker: RFC 9943
  3. RFC 9942: CBOR Object Signing and Encryption (COSE) Receipts
  4. RFC 9162: Certificate Transparency Version 2.0
  5. RFC 9052: CBOR Object Signing and Encryption (COSE): Structures and Process