Resumen

  • draft-mcewan-adkm-problem-statement-00 describe el vacío de interoperabilidad para que un identificador estable evolucione su estado de claves sin pedir a un emisor administrativo una nueva autorización en cada paso ni depender de un consenso mundial obligatorio.
  • El límite operativo consiste en separar la facultad de firmar hoy de la facultad de establecer el estado que gobernará mañana. Una clave activa puede ser válida para trabajo ordinario y resultar insuficiente para autorizar por sí sola una sucesión arbitraria.
  • La historia válida, la frescura, la búsqueda de ramas conflictivas, la recuperación, la decisión de la aplicación y el efecto observado necesitan comprobantes distintos.

El peor momento para descubrir la política de sucesión es después de comprometer la clave operativa. Sin embargo, muchos sistemas lo hacen exactamente así. Comprueban una firma de rotación, ven que la clave antigua autorizó la nueva y concluyen que el incidente está cerrado.

La conclusión puede invertir la realidad. Si el atacante poseía la clave antigua y esa clave bastaba para nombrar a la siguiente, la rotación no expulsó al atacante. Le entregó una identidad nueva con una genealogía impecable.

El Internet-Draft individual Autonomous Decentralized Key Management Problem Statement, fechado el 20 de septiembre de 2026, formula el problema sin fingir que ya existe una solución. Pregunta cómo conservar un identificador durante rotaciones, sustituciones de emergencia, cambios de umbral, delegaciones, recuperaciones y revocaciones, y cómo verificar la historia resultante sin una autorización externa repetida ni una única infraestructura mundial de consenso.

Separar facultades antes de separar claves

Key State abarca claves públicas, umbrales, funciones y otros parámetros de autorización. Key Event establece o modifica ese estado. Controller es quien puede aprobar una o más transiciones conforme al estado actual y a las reglas del protocolo.

Por eso una firma correcta no basta. Una clave puede firmar mensajes de aplicación y no tener facultad para reducir el umbral. Puede iniciar una rotación, pero necesitar que participe una capacidad de recuperación. Puede delegar un rol limitado sin poder borrar a los demás controladores. Puede revocarse sin nombrar sola a una sucesora ilimitada.

Superficie Qué prueba Qué no prueba por sí sola
Firma de la clave activa Esa clave firmó esos bytes Era suficiente para esa clase de transición
Política de transición Roles, umbrales y versión aplicados Las credenciales seguían bajo control legítimo
Historia enlazada El estado sigue una cadena permitida Es la cadena más reciente y única
Aprobación de recuperación Participó una capacidad separada Todas las capacidades seguían independientes
Evidencia de consistencia Se observó o no un conflicto en cierto alcance No existe una rama desconocida
Decisión de aplicación La política local aceptó el estado La operación terminó con éxito

Una prueba portátil no trae el presente consigo

Local Evidence Verification permite verificar un estado y la historia autenticada que conduce a él con pruebas disponibles localmente, sin consultar de forma síncrona a una autoridad designada. Es útil en entornos aislados o con conectividad intermitente.

El texto advierte que eso no prueba que el estado sea el último. Un estado histórico puede seguir siendo criptográficamente válido. Dos historias incompatibles pueden pasar sus verificaciones por separado. La prueba dice algo sobre la cadena presentada, no sobre todo lo que existe fuera del dispositivo.

Conviene guardar tres resultados diferentes: validez de la historia, frescura suficiente para el uso concreto y ausencia observada de conflicto dentro de un alcance. Una consola de mantenimiento puede tolerar una observación del día anterior; un servicio que firma transferencias puede exigir minutos, varios observadores y una política más estricta.

La recuperación tiene un estado terminal

El borrador reconoce un límite que ningún eslogan elimina: si el atacante obtiene todos los secretos y capacidades de recuperación que el protocolo considera suficientes para autorizar estados futuros, no existe garantía de recuperación.

La arquitectura debe publicar su matriz de compromiso: solo la clave activa; una participación de un umbral; la clave activa y una participación de recuperación; control del dispositivo sin el secreto externo; todos los secretos operativos y de recuperación; aislamiento de observadores durante el proceso. Para cada combinación debe indicar si la continuidad es recuperable, quién puede vetar, qué espera es obligatoria y cuándo hay que establecer una nueva raíz de confianza.

Equivocación sin un orden total global

ADKM no obliga a insertar cada evento en una secuencia mundial única. Eso evita depender de la disponibilidad, gobernanza y finalización de un solo sistema. También permite que un controlador malicioso muestre historias distintas a grupos distintos.

El borrador menciona observadores independientes, gossip, cruces y transparencia, pero no selecciona ninguno. Certificate Transparency y Key Transparency enseñan cómo los encabezados de árbol, pruebas de consistencia, monitores y cruces vuelven detectables determinadas inconsistencias. No convierten la falta de alerta en una prueba universal de unicidad.

Todo comprobante de observación debe conservar alcance, hora, estado previo recordado, contrapartes consultadas y condiciones de red. Un eclipse, una partición, la propagación tardía, la revelación selectiva o la colusión cambian lo que significa «no vimos otra historia».

Qué aportan los sistemas vecinos

RFC 5280 y RFC 6960 forman parte de un modelo maduro con autoridades de certificación, anclas y estado de certificados. ADKM no pretende sustituirlo. RFC 9162 hace auditable la emisión de certificados. RFC 7401 muestra identificadores autocertificables. DID Core comparte un modelo de datos mientras cada método define actualización, recuperación y versiones.

El vacío que plantea ADKM es otro: un modelo común, independiente de la aplicación, para la sucesión autorizada por el controlador y la verificación de la historia, sin imponer un emisor externo por transición ni un libro mayor universal.

Canonizar no autoriza

JCS, CBOR determinista y dCBOR pueden hacer que dos implementaciones firmen los mismos bytes. Sin esa disciplina, un mismo evento lógico puede producir hashes distintos.

Pero los bytes canónicos no otorgan derecho a bajar un umbral, no demuestran que un secreto de recuperación sea independiente y no establecen frescura. Eliminan una ambigüedad de representación, no una disputa de autoridad.

El recibo que falta

El recibo de transición debe nombrar el identificador y su vínculo inicial, el hash del estado anterior, la secuencia o época, el tipo de evento, las claves y roles anteriores y nuevos, los umbrales, la versión exacta de política, cada aprobación con su clase de autoridad, la intervención de recuperación, el perfil de representación, el hash del evento, las observaciones, el alcance de la búsqueda de conflictos y la regla de frescura.

Después, la aplicación emite otro recibo: qué estado aceptó, para qué operación, bajo qué política local y con qué resultado. Autenticidad del estado, autorización de la aplicación y efecto no son sinónimos.

Lo que no afirma el documento

La revisión 00 es un Internet-Draft individual, pensado como Informational y con caducidad el 24 de marzo de 2027. No prueba adopción por un grupo, consenso del IETF, implementación, despliegue, interoperabilidad, incidente ni seguridad de un producto. Tampoco elige formato, almacenamiento, red de observadores o recuperación.

Fuentes