Resumen

  • RFC 9925 es un estándar propuesto del IETF de febrero de 2026 que define id-alg-unsigned, sin parámetros y con un valor de firma de longitud cero.
  • El objeto conserva información del sujeto, pero no una prueba aportada por un emisor. Repetir el sujeto en el campo emisor sirve para interoperar, no convierte el objeto en autofirmado ni autoemitido.
  • Los consumidores que no verifican firmas X.509 pueden aceptarlo. Los validadores de rutas de certificación deben rechazarlo siempre que ocupe el lugar de una firma.
  • Quitar una autofirma decorativa ahorra tamaño post-cuántico, evita reutilizar una clave entre protocolos y permite representar claves KEM que no pueden firmar.
  • La confianza se traslada al mecanismo de adquisición e instalación. Un comprobante debe registrar los bytes, la prueba externa, el aprobador, el almacén, el alcance y la retirada.

El formato dice certificado; la prueba dice otra cosa

El identificador 1.3.6.1.5.5.7.6.36 no anuncia una firma débil. Anuncia que no hay firma. Los parámetros se omiten y el campo de valor está vacío. La ausencia queda así dentro de la máquina de estados: puede ser leída por un consumidor diseñado para no verificar esa firma, pero no puede avanzar por un camino que exige una prueba criptográfica del emisor.

Ese detalle evita una peligrosa negociación implícita. Un validador ordinario que no reconozca el algoritmo debería fallar. Un software especializado puede aceptarlo únicamente en el contexto donde otra protección ya autentica el material. La aplicación no debe interpretar “registrado” como “válido” ni “X.509” como “emitido”.

El problema social aparece cuando la interfaz oculta el estado. Un icono verde, una columna titulada “Emisor” o una carpeta llamada “certificados de confianza” puede conferir una autoridad visual que el objeto no posee. La RFC no provoca esa confusión; de hecho, ofrece la información exacta para corregirla.

Hace falta el nodo, no el enlace

La propia RFC usa un grafo. Un certificado normal enlaza información sobre un sujeto con la prueba de un emisor. El sujeto y el emisor son nodos; la firma da contenido al enlace.

Sin embargo, una aplicación a veces necesita solo los datos de un nodo. Una ancla de confianza inicia la validación desde una clave ya elegida. Un entorno TLS cerrado puede autenticar una clave mediante una huella recibida por otro canal. Una clave de encapsulación puede necesitar nombre y extensiones sin tener capacidad de firma.

Una autofirma satisfacía la gramática, pero no elegía la clave para el operador. RFC 5280 ya separa ambos planos: la representación autofirmada de una ancla no forma parte de la ruta prospectiva. El algoritmo recibe nombre, clave y parámetros como entradas fiables entregadas por un procedimiento fuera de banda. Además, la selección de la autoridad de confianza es local y puede variar según la aplicación.

RFC 9925 elimina el enlace ornamental. Su beneficio es que obliga a mirar el punto de origen real. ¿Quién decidió que este nodo podía iniciar una ruta o identificar a un par? ¿En qué equipo? ¿Para qué nombres y propósito?

Un emisor escrito que no emitió nada

El campo de emisor de X.509 no puede quedar vacío. Por eso el perfil permite copiar el nombre del sujeto o utilizar un nombre marcador específico. Ninguna opción crea un acto de emisión. El texto advierte que el valor es un recurso de compatibilidad y que el objeto no se considera autofirmado ni autoemitido.

Aquí la teoría del Policy Mirror de Lu Heng se vuelve una prueba de interfaz. El registro correcto debe reflejar la autoridad que existe. Mostrar el marcador como una entidad que “emitió” el certificado fabrica una relación. Dibujar una flecha de vuelta al sujeto hace lo mismo.

También deben desaparecer normalmente el identificador de clave de autoridad y el nombre alternativo del emisor. En cambio, restricciones básicas y usos de clave pueden describir si el sujeto pretende actuar como CA o como entidad final. Describir una función no otorga permiso para confiar en ella.

IANA asigna un nombre, no autoridad

El registro SMI de IANA hace que el estado sea interoperable. Un parser puede reconocer id-alg-unsigned y aplicar la regla publicada. Esa asignación no confirma la identidad del sujeto, no revisa una implementación y no ordena instalar la clave.

La función del código es precisamente distinguir la no-prueba. Si un validador lo acepta dentro de una ruta, ha omitido la operación necesaria. RFC 9925 equipara ese riesgo a confusiones de algoritmo conocidas. RFC 8725 formula el principio general: la biblioteca y su llamador deben acordar un conjunto permitido y comprobar que el algoritmo declarado coincide con la operación realizada.

Por eso una prueba de conformidad necesita dos resultados separados. El parser reconoce correctamente el identificador. El validador lo rechaza correctamente cuando se espera una firma. El primero no sustituye al segundo.

Menos teatro puede significar más seguridad

Una autofirma que nadie valida añade poco a la confianza. Con algoritmos post-cuánticos puede ocupar muchos bytes. En una entidad final puede obligar a usar la misma clave tanto para el protocolo real como para X.509, abriendo una superficie entre contextos. Una clave KEM ni siquiera puede ejecutar la operación.

La no-firma explícita elimina esa ceremonia. Conserva la clave para su propósito, deja al software antiguo fallar de forma cerrada y hace visible que la integridad debe venir de fuera. No es una excepción universal: donde se requiere una firma, el objeto es inválido.

La objeción más fuerte sostiene que el sistema local ya conoce la clave y que documentarlo todo podría ser costoso. Es cierto que una instalación cerrada no necesita inventar otra PKI. Pero “fuera de banda” puede significar una huella comparada, un firmware firmado, un repositorio protegido o la decisión manual de una persona. Esos mecanismos no tienen el mismo titular ni la misma capacidad de corrección.

La instalación es el acto de poder

RFC 6024 distingue la ancla, el gestor y el almacén. Permite imaginar ámbitos por dispositivo o aplicación, operaciones de alta, baja y sustitución, autenticación del proveedor, autoridad para cambiar el almacén, detección de repetición y recuperación.

Esta arquitectura muestra que importar no es un gesto neutral. Quien instala el objeto decide qué clave podrá iniciar una relación de confianza. Una huella confirma bytes, pero no nombres autorizados. Un canal seguro confirma el origen inmediato, pero no necesariamente el mandato. Los privilegios de administrador permiten ejecutar, pero no prueban que la política aprobó el alcance.

La decisión necesita por ello una cadena legible.

Comprobante de origen y alcance

El comprobante identificaría el objeto por su digest, no solo por su archivo. Incluiría clave del sujeto, función declarada, algoritmo sin firma y una regla explícita que prohíba usarlo como firma de ruta.

Después registraría fuente y adquisición: repositorio, imagen, ceremonia o persona; método externo de integridad; identidad de quien suministra; norma que le permite proponer confianza. El tercer bloque nombraría al aprobador, fecha, almacén, dispositivos y aplicaciones, espacios de nombres, políticas, propósitos y vigencia.

El cierre conservaría sustitución, baja, revisión, responsable y recuperación. La vista pública no necesita revelar credenciales ni todos los contenidos del almacén. Puede mostrar digest, alcance, autoridad, estado, linaje y vía de corrección.

El comprobante no convierte al IETF en emisor ni centraliza la confianza. Evita que una decisión local quede disfrazada de propiedad del archivo.

Límite de la evidencia

No hay en las fuentes una cifra de adopción ni prueba de que un producto gestione mal el perfil. La carta de LAMPS demuestra ámbito de trabajo, no despliegue. IANA demuestra asignación, no aprobación.

Tampoco toda autofirma carece de valor: una aplicación puede emplearla como control de corrupción, y entonces el objeto no firmado necesita un hash externo u otra integridad. No todo contenedor sin firma será una ancla.

La conclusión verificable es exacta: el sujeto permanece, el emisor no prueba nada, el validador debe rechazar y la confianza llega por otro camino. Ese camino merece su propio registro.

Fuentes

  1. Lu Heng, «The Policy Mirror»
  2. RFC 9925, certificados X.509 sin firma
  3. RFC 5280, perfil de certificados y CRL X.509
  4. RFC 4158, construcción de rutas de certificación
  5. RFC 5914, formato de anclas de confianza
  6. RFC 6024, requisitos de gestión de anclas
  7. RFC 8446, TLS 1.3
  8. RFC 8725, buenas prácticas de JSON Web Token
  9. IANA, números SMI
  10. IETF, carta del grupo LAMPS