Resumen

  • El 24 de septiembre de 2026, la IESG concluyó que una taxonomía de la IRTF sobre claves y anclas de confianza instaladas por fabricantes está relacionada con cinco grupos de trabajo de la IETF, pero que esa relación no impide publicarla.
  • El borrador distingue formas de generar, transferir y custodiar claves sin clasificarlas por seguridad. Sigue siendo un Internet-Draft destinado a la vía informativa, no un RFC ya publicado.
  • Una decisión sobre compatibilidad editorial no acredita el método aplicado a dispositivos concretos ni la posibilidad de sustituir una clave de firma perdida.

En una auditoría de compra, la pregunta aparentemente sencilla es quién puede firmar la próxima actualización del equipo. La respuesta no se encuentra en el nombre de la técnica con que nació su clave. Tampoco se encuentra en la noticia de que la IESG no objeta que se publique un texto que organiza esas técnicas. Para contestar hacen falta registros del proceso usado en esa familia de equipos y de la autoridad que el fabricante conservó después de venderlos. El paso de vocabulario a prueba es justo el que la noticia del 24 de septiembre no dio.

La IESG examinó draft-irtf-t2trg-taxonomy-manufacturer-anchors-21, procedente del grupo de investigación Thing-to-Thing de la IRTF. Su respuesta afirma que existe relación con ANIMA, LAMPS, TEEP, RATS y SUIT, sin conflicto que bloquee la publicación como RFC informativo. También pide que la IRTF considere los comentarios del Datatracker y decida si corresponde incorporarlos. El registro actual conserva el documento como borrador activo y sitúa la siguiente etapa en la IRTF tras terminar la revisión de la IESG. La respuesta no le ha asignado un número de RFC.

El alcance de la revisión está fijado en RFC 5742. Cuando el texto llega por la vía IRTF, la IESG busca conflictos con trabajos de normalización de la IETF; el juicio sobre los méritos técnicos corresponde a la IRSG. «Está relacionado, pero puede publicarse» es uno de los resultados previstos. No significa que la IETF haya aprobado un estándar, certificado una fábrica o recomendado desplegar una arquitectura de claves. El propio borrador advierte que no cuenta con el respaldo de la IETF ni tiene rango formal en su proceso de estándares.

La taxonomía sí permite formular preguntas mejores. Una clave privada puede generarse dentro del equipo, fuera de él y luego transferirse, surgir de una semilla o quedar ligada a un elemento seguro; cada ruta coloca la exposición y la responsabilidad en lugares distintos. Además, el ancla que permite arrancar un dispositivo no tiene necesariamente el mismo cometido que la que autoriza nuevas versiones de software, servicios privados o el alta en una red. El borrador separa riesgos de reemplazar, añadir, dañar o quitar anclas, de la sustracción de la clave privada asociada y de una pérdida de acceso sin robo alguno.

La pérdida sin robo merece atención. Si se pierde el poder de firmar actualizaciones, puede que el propio mecanismo de actualización ya no sirva para instalar una nueva ancla. El texto contempla intervención física e incluso reemplazo del equipo según el diseño. Pregunta cuánto tiempo transcurre entre la primera inicialización y el bloqueo, cuánto deben poder validarse las identidades y cómo se conserva la capacidad de firmar del fabricante. No puntúa las respuestas ni acusa a un producto existente. La existencia de esas preguntas no demuestra que un proveedor las haya resuelto.

Para un lote o una clase de dispositivos, el comprador podría pedir un recibo acotado de custodia de anclas. Debe distinguir las funciones de arranque, actualización y alta; identificar el método de aprovisionamiento observado, el momento de bloqueo y al responsable de las claves de firma del fabricante; y enlazar pruebas fechadas de rotación, pérdida y sustitución con la persona que acepta las excepciones. Una versión pública no necesita revelar claves privadas, identidades individuales ni planos de fábrica. Es una propuesta editorial de rendición de cuentas, no una obligación creada por la IRTF.

La respuesta de la IESG tampoco documenta una brecha o un fallo de equipos. Abre espacio para que la investigación tenga un lenguaje común. La decisión de confiar un servicio a dispositivos concretos sigue perteneciendo a quienes pueden exigir pruebas de su origen y mantenerlos cuando el primer esquema de claves deje de funcionar.

Fuentes