Resumen
draft-ietf-keytrans-architecture-09usa una lápida en el registro antiguo para indicar que la versión vigente de una etiqueta está en el nuevo y para impedir que la falta de acceso haga parecer actual un valor anterior.- El borrador, por separado, mantiene la vigilancia de ambos registros y exige que el antiguo siga operativo el tiempo necesario para que todos los usuarios, incluidos quienes pasan mucho tiempo sin conexión, terminen de monitorizarlo.
- Hace falta un recibo de retirada que una cabeza final, canales de distribución, cohortes, pruebas de cierre, excepciones, responsable de la decisión y condición de recuperación. Ese recibo es una propuesta de este artículo, no una norma de KEYTRANS.
La migración parece terminada hasta que vuelve el teléfono que nadie había contado. Guardó una cabeza de árbol meses antes del cambio, quedó apagado y reaparece cuando el servicio ya escribe en otro registro. La aplicación actual conoce el destino nuevo; el extremo antiguo ya no responde. El usuario puede obtener la clave presente, pero no verificar la continuidad entre lo que conservaba y el estado final del registro que desapareció.
El borrador de arquitectura no oculta esa pérdida. Si el registro antiguo se apaga antes de que un usuario complete la vigilancia, ese usuario podría quedar sin capacidad para detectar algunas conductas indebidas del registro viejo. Una operación correcta de copia no basta para cerrar una obligación de prueba.
La lápida es, por tanto, una señal de precedencia. No es un acta de jubilación.
El problema exacto que resuelve la lápida
Un servicio con cifrado de extremo a extremo todavía puede controlar la información que asocia una identidad con una clave pública. Si el proveedor sufre una intrusión o actúa de mala fe, puede sustituir claves o mostrar vistas distintas. Key Transparency propone un registro consultable y protegido criptográficamente para que titulares y contactos comprueben de manera continuada una visión globalmente coherente.
La carta del grupo KEYTRANS delimita la ambición. El mecanismo se integra en servicios más completos; no pretende resolver por sí solo la interoperabilidad de aplicaciones, la recuperación de cuentas ni todas las capas de autenticación. La política de vida del cliente queda así en manos del despliegue concreto.
Cambiar de registro no es una anomalía. Puede responder a una rotación de claves, otra suite criptográfica, un modo distinto, más capacidad o la recuperación de un fallo. La arquitectura recomienda que el cliente pueda tratar varios registros independientes. También exige una política común que dirija Search, Update y Monitor. Esa política conserva una única lectura cuando los registros son honestos y mantiene detectable un comportamiento desleal.
En la migración gradual, Search empieza por el registro antiguo. Solo consulta el nuevo si la última versión de la etiqueta antigua es una lápida definida por la aplicación. Las actualizaciones normales van al registro nuevo; el viejo recibe únicamente la lápida que falte. Si el nuevo no está disponible, el cliente no puede escoger la versión premigración como sustituto cómodo.
Ese resultado es valioso. No confirma la exactitud semántica del valor migrado, la revisión por su titular, la recepción por cada cliente ni la conclusión de la vigilancia histórica.
Dos registros, dos cierres diferentes
La arquitectura indica que ambos registros se vigilan como si fueran independientes. El nuevo abre una cadena de evidencia; el antiguo todavía debe cerrar la anterior. Primero deja de aceptar modificaciones en un punto definido. Después permite que los clientes unan su estado retenido con la cabeza final. En el nuevo, los titulares procesan una Update para la versión migrada y verifican su contenido.
Un porcentaje de instalación mezcla estados que no son equivalentes. Un cliente actualizado puede no haberse ejecutado. Una conexión al registro nuevo puede no incluir la comprobación de la etiqueta propia. Un dispositivo principal puede estar al día mientras una copia de seguridad devuelve después una cabeza anterior. Una cuenta dormida no equivale automáticamente a una renuncia.
Por eso el borrador evita fijar un número universal de días. Habla de mantener el registro antiguo el tiempo suficiente y menciona a usuarios fuera de línea durante periodos considerables. La promesa razonable será distinta para una mensajería empresarial crítica, un servicio de consumo o un cliente web sin estado durable. Convertirla en constante técnica borraría quién asume la decisión.
La forma de vigilancia también importa. El sistema puede apoyarse en un auditor o gestor externo, en consultas anónimas o en intercambio entre pares. Cada modo cambia los supuestos de no colusión, la frecuencia de control y el estado que debe conservar el usuario. Disponibilidad no es sinónimo de detectabilidad.
La cabeza final necesita una institución alrededor
Para la migración inmediata, el texto propone distribuir por un canal fiable el tamaño final del árbol y la raíz del registro antiguo. Los clientes emiten su última consulta Monitor hasta ese punto. Los titulares inician la vigilancia del registro nuevo procesando la Update de su versión migrada y comprobándola.
El punto final puede viajar en una etiqueta conocida del registro nuevo o junto con el código de la aplicación. Ambos canales permiten que muchos clientes reconozcan la misma frontera criptográfica. Ninguno prueba qué versiones la recibieron, quién eligió la fecha o qué apoyo tendrá un dispositivo que vuelva con una cabeza más antigua.
El protocolo añade parámetros concretos: max_ahead, max_behind, reasonable_monitoring_window obligatorio y maximum_lifetime opcional. La ventana razonable expresa la frecuencia general esperada de vigilancia y organiza puntos comunes del registro. No observa la actividad de cada persona. La vida máxima permite podar datos; no transforma la economía de almacenamiento en una autorización para abandonar clientes.
Contenido del recibo de retirada
La prueba puede ser compacta y respetar la privacidad.
Frontera antigua. Configuración e identidad de firma, instante de la última modificación aceptada, tamaño y raíz finales, modo de despliegue y coherencia con la cabeza pública previa.
Regla de migración. Identificadores de ambos registros, destino de Search, Update y Monitor, semántica de la lápida y versiones del cliente que la aplican. Redirigir no significa borrar el deber de verificación.
Distribución. Canales autenticados por los que viajó la cabeza final y evidencia separada por versión, plataforma, flota gestionada, cuenta dormida y restauración de copia. Las descargas agregadas no sirven como cierre.
Estados de finalización. Contacto con el registro nuevo, validación de la etiqueta migrada, Monitor final del antiguo y prueba de recuperación ocupan columnas distintas.
Ausencia y pérdida de estado. Periodo máximo de regreso que el servicio admite, reinstalación, multidispositivo, antigüedad de copias, cuentas inaccesibles y vía de excepción. Las estimaciones deben declararse como tales.
Decisión y reversión. Seguridad certifica el cierre criptográfico; el dueño del servicio acepta el riesgo de disponibilidad; privacidad o asesoría jurídica delimitan la retención; una autoridad nombrada aprueba el apagado. Una cabeza incompatible o un cliente que no puede tender el puente exige ampliar, restaurar o investigar.
Conservar el estado real del estándar
La revisión 09 sigue siendo un Internet-Draft, con destino Informational y solicitud de publicación ante el IESG. El informe del shepherd recoge consenso y ausencia de objeciones importantes en una comunidad especializada relativamente pequeña. Es progreso institucional, no un RFC publicado ni una orden de despliegue.
El protocolo compañero continúa abierto. Las actas de IETF 126 reflejan una propuesta de formato nuevo para UpdateRequest porque el anterior no era implementable, y una advertencia de un implementador sobre formatos de transporte que podrían impedir la interoperabilidad. La discusión no es consenso normativo. Sí es evidencia de que el borrador arquitectónico, la revisión del protocolo, el código que funciona y la decisión local de retiro tienen relojes distintos.
La capa común puede ser pequeña y firme: una caída del nuevo registro no debe revivir una clave vieja; retirar el registro antiguo no debe destruir sin justificación el camino de vigilancia que todavía conserva un usuario. Determinar cuánto dura ese camino es una obligación atribuible, no una propiedad mágica de la lápida.
Fuentes
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance