Resumen

  • El 28 de septiembre, Key Transparency Architecture pasó a AD Evaluation::Revised I-D Needed después de que la directora del Área de Seguridad pidiera separar al propietario de una etiqueta de la parte que confía en ella.
  • Una búsqueda, una firma del árbol y una prueba de consistencia pueden ser válidas sin decir quién autorizó la consulta, quién podía cambiar la vinculación o quién debe volver a comprobarla.
  • La operación necesita un recibo con roles: propietario, solicitante, decisión de acceso, modo de despliegue, firmante, límites temporales, estado previo y seguimiento pendiente.

El indicador puede estar en verde y el problema seguir abierto. La prueba coincide con la raíz, la firma es correcta y la nueva respuesta continúa la vista que el cliente guardó. Matemáticamente, no hay objeción.

Pero esa comprobación no dice si quien preguntó era dueño de la etiqueta o una parte que necesitaba la clave de otro usuario. Tampoco identifica la regla que permitió revelar el dato, la autoridad que podía modificarlo ni a quién corresponde verificar más tarde que una versión recién observada no desapareció. Confundir esas preguntas con el resultado criptográfico transforma una propiedad limitada en una aprobación institucional total.

El IETF acaba de detenerse en esa frontera. El 28 de septiembre de 2026, Deb Cooley publicó sus comentarios como directora del Área de Seguridad sobre la revisión 09 de Key Transparency Architecture. El historial del Datatracker registra el cambio a AD Evaluation::Revised I-D Needed. El texto sigue siendo un borrador destinado a un RFC informativo: no es un estándar publicado ni evidencia de una implantación.

La observación central parece terminológica. El documento define User / Account, pero más adelante utiliza “label owner” para quien posee la etiqueta y “user” para quien consulta la etiqueta ajena. Cooley propone distinguir propietario y relying party. El cambio importa porque uno es el sujeto de la vinculación y el otro toma una decisión sobre esa persona. Sus permisos, daños y obligaciones posteriores no son equivalentes.

La transparencia de claves trata un problema específico de la mensajería cifrada de extremo a extremo. El operador suele distribuir las claves públicas con las que los usuarios establecen sus conversaciones. Si sustituye una clave por otra controlada por un atacante, el cifrado puede funcionar y, sin embargo, proteger al interlocutor equivocado. La arquitectura coloca esas asociaciones en un registro criptográficamente protegido y de solo anexado. Search, Update y Monitor devuelven pruebas, y las respuestas futuras deben extender la vista que cada cliente ya observó.

Una bifurcación queda fijada, pero no se descubre sola. La arquitectura exige además un tercero de confianza, un canal anónimo o comparación entre pares. El tercero firma una cabeza reciente del árbol y el usuario acepta la hipótesis de que no colabora con el registro para autenticar una bifurcación. En los otros caminos, el cliente busca la contradicción. La validez de la prueba depende así de una vigilancia que continúa después de la respuesta.

Los tres modos de despliegue reparten esa vigilancia de manera desigual.

En Contact Monitoring, el propietario revisa periódicamente su última etiqueta. Quien consultó una versión recién añadida debe regresar para confirmar que permaneció visible el tiempo suficiente para que el dueño pudiera detectarla. El borrador exige permitir ese Monitor incluso si la política ya impide repetir la Search o Update anterior. Revocar acceso presente no borra el deber probatorio creado por una observación autorizada en el pasado.

En Third-Party Auditing, el registro conserva la mayor parte de la operación y obtiene firmas periódicas de un auditor. El valor de la firma depende de dónde comenzó la auditoría y de cuánto retraso admite la configuración. Una afirmación auténtica puede ser demasiado antigua para una decisión concreta.

En Third-Party Management, un gestor externo almacena y opera la mayor parte del servicio. El operador sigue aplicando el control de acceso y autenticando nuevas versiones antes de reenviar las solicitudes aceptadas. El modelo supone que ambos no coluden. La revisión pide añadir una búsqueda válida al diagrama: mostrar solo las operaciones de Alice sobre su propia entrada oculta la ruta de la parte que necesita consultar la clave de otro.

La revisión 05 del protocolo Key Transparency convierte estas diferencias en parámetros. La configuración declara el modo, las claves de firma y VRF, la ventana razonable de monitorización y, cuando existe auditor, su clave, posición inicial y retraso máximo. Dos firmas verificadas no expresan la misma garantía si una procede del operador, otra de un gestor y otra de un auditor sujeto a demora.

El estado local también forma parte del mecanismo. El cliente conserva una vista previa para obligar a que la siguiente sea consistente. Si pierde ese estado, disminuye su capacidad de detectar una bifurcación o un dato que el registro oculte después. La arquitectura recomienda gestión por un tercero cuando el estado es efímero, como en una página web, o puede eliminarse de forma adversaria. La revisión pide ejemplos y una explicación más clara del “estado inválido permanente”, cuya detección puede exigir que el usuario continúe conectado durante un periodo limitado.

El control de acceso pertenece a la aplicación. Puede limitar consultas a contactos, exigir autenticación o imponer cuotas. El registro demuestra cómo trató una operación; no demuestra que la aplicación estuviera autorizada a revelar esa etiqueta a ese solicitante. Por eso la revisión reclama una terminología ACL coherente en lugar de alternar “amigos” y “acceso”.

Privacidad y borrado introducen un calendario distinto. La aplicación puede podar datos de usuario expirados o inaccesibles, mientras algunos elementos criptográficos continúan hasta agotar su vida máxima. Una función aleatoria verificable oculta las etiquetas. El comentario propone tratar RFC 9381 como referencia normativa si el lector debe comprender la VRF y reunir la discusión de privacidad.

También hay una dependencia editorial. El informe del shepherd llama a la arquitectura fundamento del protocolo. La revisión advierte que las referencias a ese protocolo deben ser ejemplos si la arquitectura se publica primero. Además, pide explicar por qué se compara con RFC 6962, versión desplegada de Certificate Transparency, y no solo con RFC 9162. MLS aporta el contexto de las credenciales en grupos cifrados, no una prueba de uso de KT.

La respuesta operativa no es otro hash. Es un recibo que conserve, junto a la prueba, el rol del solicitante, el propietario, la política y su versión, el modo, el firmante, el tamaño y tiempo del árbol, la demora aceptada, el estado previo y la futura tarea de Monitor. Ese registro permite separar una prueba inválida, una revelación no autorizada pero bien probada, una vista antigua del auditor, un seguimiento omitido y un cliente sin continuidad.

La próxima revisión puede resolver los comentarios de otra manera. El límite ya está claro: un historial append-only hace detectable el engaño; solo una asignación explícita hace responsable a alguien de detectarlo.

Fuentes