Summary

  • KEYTRANS autentica el resultado de una búsqueda autorizada y ayuda a detectar vistas incoherentes, pero no normaliza la política de aplicación que admite o bloquea la petición antes de la operación criptográfica.
  • draft-ietf-keytrans-architecture-09 permite en gran medida controles arbitrarios —autenticación, relaciones y límites de frecuencia—, mientras draft-ietf-keytrans-protocol-05 conserva el derecho limitado a continuar la monitorización necesaria después de revocar nuevas búsquedas.
  • Daniel Kade propone un recibo de política de consulta con versión, clase de solicitante y relación, operación, código de decisión, época del registro, excepción y corrección, sin publicar etiquetas, grafo social, credenciales ni historial completo. Es orientación editorial, no una exigencia de KEYTRANS o del IETF.

La respuesta verificable puede comenzar con una decisión invisible

La transparencia de claves responde a una debilidad real del cifrado de extremo a extremo. Si el servicio que distribuye claves públicas sustituye una por otra que controla, puede interponerse en una conversación aparentemente protegida. Un historial consultable y protegido criptográficamente permite verificar los vínculos entre identidad y clave, conservar estado y detectar una vista divergente.

La promesa tiene un límite deliberado. La carta activa de KEYTRANS exige que la existencia de una cuenta y sus datos se revelen sólo a clientes autorizados para preguntar. La arquitectura reparte el trabajo: el protocolo autentica asociaciones y evolución del árbol; la aplicación circundante decide quién puede ejecutar Search, Update o Monitor.

Su ejemplo básico deja clara la frontera. Alice puede buscar a Alice y Bob y actualizar a Alice. La búsqueda de Fred y la actualización de Bob quedan bloqueadas en el transporte. No llegan a generar una prueba. Quien recibe la respuesta de Alice puede comprobar su afirmación matemática; no obtiene un objeto equivalente que explique la ausencia de respuesta para Fred.

No es un defecto. Una norma general no conoce el significado local de amigo, compañero, miembro del mismo inquilino, cliente de pago, sospecha de abuso o cuota. El borrador permite por ello reglas ampliamente arbitrarias y deja a la aplicación la forma de rechazar y quizá explicar. El error sería hacer que «prueba transparente» signifique también «política de entrada transparente».

Lo que demuestra la prueba

El borrador de protocolo combina un árbol de prefijos y un árbol de registro. El primero asigna una pareja etiqueta-versión a un compromiso y permite probar inclusión o ausencia. El segundo conserva raíces sucesivas para verificar coherencia temporal. SearchResponse aporta cabeza, valor, apertura y el material necesario para reconstruir las raíces relevantes.

La garantía descrita por la arquitectura es precisa: si el usuario verifica bien y realiza la monitorización necesaria, obtiene seguridad de que el operador ejecutó la operación correctamente y de forma coherente con lo que otros habrían visto para la misma etiqueta aproximadamente al mismo tiempo. Una bifurcación o una vista demasiado antigua debe detectarse bajo los supuestos del despliegue.

La prueba no contiene las entradas de la política aplicativa. No dice si Alice y Bob eran contactos, si Fred agotó una cuota, si estaba activa una excepción antiabuso, si una empresa permitía consultas entre departamentos o qué versión evaluó la solicitud. Su exactitud concierne a una clave de búsqueda, no al derecho de una persona a presentarla.

Los RFC 6962 y 9162 ofrecen una comparación limitada. La transparencia de certificados hace verificables inclusión y coherencia sin integrar en la prueba todas las decisiones de confianza de cada consumidor. KEYTRANS añade búsqueda privada y seguimiento por cuenta, pero conserva el mismo límite institucional entre evidencia autenticada y política de uso.

Denegar protege privacidad y también ejerce poder

El acceso no es un obstáculo que deba eliminarse. Un desconocido quizá no deba saber que una identidad existe. Un contacto anterior puede perder la facultad de conocer cambios posteriores. El operador puede insertar entradas falsas para ocultar tamaño de población o ritmo de actualización. Abrir el directorio a todos destruiría esas propiedades aun si cada respuesta fuese criptográficamente perfecta.

La puerta protege, pero decide. Una regla antigua puede impedir que un corresponsal autorizado obtenga la nueva clave. Dos dispositivos con estados de relación distintos pueden recibir decisiones diferentes sin que el registro se bifurque. Un límite cambiado puede impedir una verificación durante una emergencia. Una excepción sin vencimiento puede seguir revelando existencia después de acabada la relación.

En todos esos casos el árbol puede ser honesto. Responde correctamente a lo que lo alcanza. La discrepancia está en qué peticiones se convirtieron en operaciones. Llamar transparente al sistema completo sin declarar la frontera otorga al árbol una autoridad que no observó.

La auditoría, sin embargo, puede empeorar la privacidad. Registrar para siempre quién buscó a quién y cuándo crea un grafo social y operativo. RFC 6973 obliga a pensar en minimización, retención y uso secundario; RFC 7258 incluye características y correlación del tráfico. La rendición de cuentas no autoriza reconstruir el conjunto de datos que la denegación pretendía ocultar.

La revocación descubre una máquina de estados

Contact Monitoring muestra que no hay un único interruptor. Quien consultó antes una versión puede necesitar seguir vigilándola para que una modificación maliciosa no escape a la detección. Por eso ciertas operaciones Monitor deben continuar incluso cuando Search o Update ya no estarían permitidas. Una apertura del compromiso puede demostrar la autorización anterior.

Hay al menos cuatro estados: permiso de buscar, posesión de un resultado, retirada del permiso para nuevas búsquedas y permiso limitado para monitorizar ese resultado previo. «Acceso revocado» los mezcla. Puede cerrar correctamente descubrimiento futuro y romper por error la obligación probatoria previa. También debe impedirse que Monitor se convierta en una vía para aprender contenido posterior a la revocación.

La Reasonable Monitoring Window aporta tiempo. Las entradas distinguidas actúan como puntos comunes y el cliente retiene estado suficiente para detectar conducta indebida. La política debe mantener ese camino pese a borrado de cuenta, sustitución de dispositivo, cambio de relación o cuota. La prueba original no dice si lo hizo.

La versión de política es, por tanto, operativa. Permitir Search crea una obligación posterior. Si la regla se reemplaza sin una transición conservada, un Monitor denegado no puede clasificarse como fallo, decisión de privacidad o defensa antiabuso. La época de política debe vincularse con la época del árbol sin exponer la relación personal.

Los terceros cambian la visibilidad

En Third-Party Management, las operaciones llegan primero al operador. Éste aplica acceso y reenvía las aceptadas al gestor. El gestor suele conocer etiquetas, valores, historial y frecuencia de consultas, pero los rechazos quizá nunca lo alcancen ni incluyan su motivo.

En Third-Party Auditing, el auditor aprende número, orden y tiempo aproximado de cambios, mientras etiquetas y valores permanecen ocultos. Esa separación sirve, pero no le muestra todas las solicitudes bloqueadas. Puede aprobar con honestidad la historia que vio mientras una puerta incoherente funciona delante.

RFC 9458 y RFC 9614 muestran que separar quién conoce al cliente de quién conoce la petición reduce exposición. También muestran que importan colusión, sincronización, conjuntos pequeños e infraestructura compartida. Mandar cada admisión y rechazo a un almacén único recuperaría la correlación. El objetivo debe ser evidencia mínima para probar la regla declarada.

En un despliegue entre servicios, dirigir la solicitud al registro correcto también es poder. La arquitectura permite a una entidad controladora actuar como proxy anónimo, pero desaconseja fusionar registros de modo que impida sus políticas. El proxy protege una capa y puede, a la vez, unir identidad, destino y decisión. Su política y retención deben ser observables de forma limitada.

Un recibo, no un expediente de búsquedas

La propuesta de Daniel Kade es un recibo de política de consulta fuera de la prueba criptográfica. No altera KEYTRANS. Hace verificable la puerta sin publicar el grafo social.

Empieza por identificador y versión inmutable de política. Registra clase de operación: Search, Update, primer Monitor o continuación. Usa clases de solicitante —propietario, contacto actual, antiguo contacto con monitorización, mismo inquilino, no autenticado— y de relación, no nombres. El objetivo puede representarse mediante un resumen local con clave rotatoria que no sirva para rastreo entre servicios.

Luego vincula la decisión a una franja temporal, servicio y configuración o época del registro. Distingue permitir, denegar, limitar, estado obsoleto, continuación previa y excepción temporal. Nombra regla, autoridad de excepción, vencimiento y vía de corrección. No guarda usuarios, etiquetas, claves, credenciales, mensajes, direcciones IP completas, relaciones exactas, identificadores duraderos ni historia individual completa.

La supervisión puede apoyarse en contadores breves y agregados: códigos por versión, pares sintéticos de clases permitidas y prohibidas, continuidad de Monitor tras revocar Search, excepciones vencidas y diferencias entre escenarios equivalentes. Una prueba independiente crea cuentas controladas, forma y termina una relación, rota una clave y verifica el itinerario sin copiar peticiones reales.

El borrado confirma la separación

La arquitectura distingue datos de usuario y material criptográfico. Valores inaccesibles de manera permanente pueden borrarse, mientras salidas VRF o compromisos quizá deban persistir para otras pruebas. El protocolo no transmite al registro la política aplicativa.

Un compromiso restante no prueba por qué terminó el acceso ni que el borrado se ejecutó correctamente. El recibo sólo puede enlazar la transición que autorizó borrar con la observación de la capa de datos. Copias, réplicas y deberes jurídicos requieren evidencia propia. Persistencia matemática y supresión de datos son estados conectados, no equivalentes.

Lo que sigue sin demostrarse

La arquitectura 09 y el protocolo 05 son Internet-Drafts del grupo de trabajo, no RFC. El primero aspira a Informational; ambos pueden cambiar. La carta define mandato, no adopción en servicios.

Las fuentes no prueban despliegue, tasa de denegación, daño, discriminación, incidente, legalidad o rendimiento. Este recibo es orientación editorial, no acusación ni requisito técnico.

La conclusión es estrecha: KEYTRANS puede probar que una búsqueda admitida se resolvió correctamente contra estado autenticado. No audita la decisión anterior que determinó si existiría. La privacidad necesita esa puerta y la responsabilidad necesita poder probarla. Proteger el grafo no exige dejar que la raíz del árbol hable por la política.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-09
  5. https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/
  6. https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/history/
  7. https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-protocol-05
  8. https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/
  9. https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/history/
  10. https://datatracker.ietf.org/doc/charter-ietf-keytrans/
  11. https://www.rfc-editor.org/rfc/rfc6962.html
  12. https://www.rfc-editor.org/rfc/rfc9162.html
  13. https://www.rfc-editor.org/rfc/rfc6973.html
  14. https://www.rfc-editor.org/rfc/rfc7258.html
  15. https://www.rfc-editor.org/rfc/rfc9420.html
  16. https://www.rfc-editor.org/rfc/rfc9458.html
  17. https://www.rfc-editor.org/rfc/rfc9614.html