Resumen

  • draft-ietf-rats-epoch-markers-05 permite que una Epoch Bell emita marcadores reutilizables para compartir una referencia de frescura sin exigir que cada attester disponga de un reloj civil confiable.
  • Una firma válida autentica el marcador y la clave de su Bell; no acredita entrega simultánea, unicidad de sesión, exactitud del reloj ni que la evidencia se midiera en ese instante.
  • El verificador debe conservar un recibo de unión con identidad y tipo de Bell, ruta de entrega, recepción local, nonce, ventana, estado antirreenvío y versión de la política aplicada.

Frescura sin convertir el contador en calendario

Preguntar si una evidencia es suficientemente reciente parece una comparación de tiempo. En una atestación real intervienen varios momentos: medición del dispositivo, producción de la evidencia, transporte, valoración y decisión del relying party. Un reloj fiable puede situarlos; un nonce puede vincular una respuesta con un desafío concreto. Los dispositivos restringidos no siempre tienen ese reloj, y los flujos con intermediarios no siempre permiten un desafío directo.

La Epoch Bell responde a esa carencia emitiendo Epoch Markers. El attester inserta el marcador o un handle en su evidencia protegida. Más tarde, el verificador lo compara con una posición que todavía admite. El borrador contempla desafío-respuesta puntual, emisión espontánea por broadcast o multicast y suscripción solicitada.

El resultado es una coordenada común, no tiempo absoluto. Si la marca contiene fecha POSIX, depende del reloj y la administración de esa Bell. Si contiene un contador, ordena emisiones sólo dentro del contexto que mantiene ese contador. En ambos casos, la frescura sigue siendo una relación entre la marca, el camino y la ventana del decisor.

El formato cambia las premisas

La revisión 05 enumera etiquetas temporales CBOR, el TSTInfo de RFC 3161, una variante CBOR, Epoch Tick, Tick List, contador monotónico y epoclet. Las formas basadas en tiempo requieren un reloj confiable en la Bell. El contador requiere continuidad de estado. El tick puede reutilizarse entre muchos consumidores. La lista ayuda a recuperar posiciones recientes, pero exige memoria y reglas de resincronización.

El epoclet ocupa aproximadamente entre 44 y 64 bytes y combina tiempo POSIX, identificador de clave del despliegue y HMAC. Su eficiencia no borra el coste: desplaza la confianza hacia la custodia de una clave compartida, su rotación y la sincronización de los servidores que emiten.

Una firma prueba que la clave prevista autenticó determinados bytes bajo un formato. No prueba que el reloj acertaba, que el contador sobrevivió a todos los reinicios o que cada receptor vio el mismo avance a la vez. COSE, CWT, CBOR y las estructuras conceptuales de RATS permiten proteger y enlazar declaraciones. No convierten la salud operacional en una verdad física.

La misma emisión no tiene la misma llegada

Colas, replicación multicast, enlaces intermitentes y procesamiento intermedio producen latencia y skew. Un marcador auténtico puede llegar tarde. Si un verificador cercano recibe el tick 820 y otro sitio aún acepta el 818, tomar 820 como frontera universal puede rechazar evidencia honesta del sitio lento. Mantener 818 sin caducidad permite que una captura antigua siga circulando.

La diferencia aparece tanto en Passport como en Background-Check. En el primer patrón, el attester transporta la evidencia hacia el relying party. En el segundo, otro servicio hace la valoración y devuelve un Attestation Result. La política debe considerar el camino del decisor, y el resultado tiene que conservar el vínculo con el marcador o su handle.

Una ventana de aceptación amplia tolera redes lentas, suspensión y procesamiento, pero alarga la vida útil de evidencia buena ya capturada. Una ventana estrecha reduce el reenvío y aumenta falsos rechazos. El cálculo necesita recepción local, canal esperado, presupuesto de transporte, procesamiento y una caducidad explícita. No hay una cifra universal escondida en el protocolo.

Compartido no significa irrepetible

Un Epoch Tick se diseña para reutilizarse. Esa propiedad permite atender a muchos attesters sin generar un desafío para cada uno. También significa que el tick no sustituye al nonce cuando una sesión necesita exclusividad.

El borrador exige al menos 64 bits de entropía para el nonce, obtenidos con un generador criptográficamente seguro, y admite hasta 512 bits. El nonce contesta si la respuesta pertenece a esa petición. El marcador señala una posición aceptada de la Bell. Para evitar trasplantes, la evidencia debe unir ambos valores con la identidad o clave del attester y con el digest de la medición.

La política también fija Bell, clave, dominio, alcance y tipos permitidos. Si una parte no confiable puede cambiar una marca temporal por un contador más débil o seleccionar otro algoritmo, la negociación se convierte en downgrade. Alterar el tipo cambia las premisas de auditoría; no es sólo ahorrar bytes.

La elección de estado distribuye los rechazos

Comparar ticks requiere memoria. Guardar un único valor máximo para todo el dominio es barato, pero hace que el camino más rápido marque la frontera de todos. Los attesters lentos pueden quedar fuera aunque produjeran evidencia legítima. Mantener estado por attester cuesta más, aunque separa historiales y patrones de conectividad.

Un centro de datos homogéneo puede aceptar un máximo global y una tolerancia pequeña. Una flota industrial con periodos sin conexión puede necesitar estado individual, suspensión declarada y reglas de recuperación. Ninguna opción surge automáticamente de la criptografía. Son decisiones sobre quién soporta el coste y quién asume el falso rechazo.

La resincronización debe conservar su causa. Una Tick List ayuda a ponerse al día, pero aceptar un miembro anterior todavía requiere un criterio. La pérdida de un contador puede parecer rollback. La rotación de una clave inaugura otro periodo de confianza aunque el tiempo POSIX continúe. La operación debe guardar frontera previa, época de clave, motivo y autorización de la transición.

Una Bell puede firmar correctamente y estar equivocada

Si la Bell está comprometida o mal configurada, puede emitir marcas criptográficamente perfectas con hora desplazada, contadores repetidos o vistas diferentes para destinatarios distintos. La validación de la firma seguirá en verde mientras falla la premisa de frescura.

Por eso hacen falta operador identificado, custodia, rotación y revocación de claves, vigilancia del reloj o del estado, medición de distribución y tratamiento de incidentes. Varias Bells no crean por sí solas un reloj consensuado. La política tiene que decir si son alternativas, ámbitos separados o participantes en un quórum.

Los ticks previsibles además pueden correlacionar mensajes protegidos al agrupar tráfico cerca de cada emisión. Variar intervalos, incrementos o alcance puede reducir esa señal, pero obliga a revisar ventanas y estado. Privacidad y frescura comparten el mismo diseño.

Un recibo para la unión decisiva

El recibo comienza con identidad, clave y época de la Bell; tipo, bytes o digest del marcador; dominio, alcance y momento declarado de emisión si existe; recepción local, canal y latencia medida o presupuestada. Después añade attester, digest de evidencia y contexto de medición. Conserva nonce y sesión cuando los haya.

También registra si el estado era global, individual o particionado de otra forma; la frontera previa; el resultado de reenvío o reordenación; la resincronización; la versión exacta de la política; decisión, caducidad, revocación y revisión. Así, un incidente posterior puede localizar decisiones afectadas sin reescribir la historia.

Este suplemento no debe inflar el marcador interoperable. El estándar mantiene pequeño el objeto común; cada despliegue hace explícitas sus elecciones futuras y conserva una imagen comprobable de lo ocurrido. Es una manera más rigurosa de usar la coordinación sin confundirla con autoridad universal.

En la fecha de corte, la revisión 05 era un Internet-Draft activo del grupo RATS, actualizado el 3 de julio de 2026 y con vencimiento el 4 de enero de 2027. Datatracker mostraba «WG Document Doc Shepherd Follow-up Underway» y «I-D Exists», sin area director responsable ni telechat. La cabecera decía Standards Track mientras el campo de estatus RFC previsto estaba vacío. El dato describe el proceso; no acredita adopción.

Fuentes