Resumen

  • La revisión 08 define un lote VOPRF amortizado con una sola prueba para varios elementos y un lote genérico con respuestas opcionales posición por posición.
  • 200, 206 y una prueba correcta no contestan cuántos tokens terminaron la finalización, quedaron grabados sin duplicados y siguieron disponibles para un canje posterior.
  • La operación necesita conciliar cantidades en cada etapa sin convertir el registro del lote en una llave estable de seguimiento.

Hay un detalle revelador en el diseño genérico: si el emisor entrega algunos tokens y rechaza otros, debe responder 206 Partial Content. No disimula la incompletitud. La coloca en el protocolo.

El riesgo aparece después, cuando un sistema convierte cualquier 2xx en “lote entregado” y suma el tamaño de la solicitud al saldo. El emisor puede haber dejado una posición vacía. El cliente puede fallar al deserializar otra. La finalización de una tercera puede no pasar. El almacén puede caerse antes de confirmar la transacción. El 206 era honesto; la contabilidad dejó de serlo.

draft-ietf-privacypass-batched-tokens-08, publicado el 4 de mayo de 2026, sigue siendo un Internet-Draft. El grupo Privacy Pass lo envió al IESG como propuesta para Standards Track, pero el estado vigente en el corte de esta investigación es AD Evaluation::Revised I-D Needed. Tampoco existe todavía la asignación 0x0005 en el registro público de IANA; aparece como valor sugerido en el borrador.

Dos maneras de agrupar, dos maneras de fallar

El lote amortizado trabaja con varios mensajes cegados de un tipo de token privado compatible. El emisor evalúa cada uno y genera una única prueba sobre el conjunto. El cliente verifica esa prueba antes de construir los autenticadores individuales. Si la prueba falla, la finalización no produce un conjunto parcialmente confiable: aborta.

El lote genérico no comparte esa atomicidad. Encapsula solicitudes ordinarias, incluso de tipos distintos. La respuesta contiene una lista de valores opcionales. Una ausencia significa que el emisor no quiso o no pudo servir esa solicitud, pero las posiciones posteriores pueden seguir vivas.

Por eso “el lote pasó” carece de precisión. Puede significar que el cuerpo fue aceptado, que todas las entradas eran válidas, que una prueba colectiva pasó, que algunas posiciones llegaron, que cada respuesta se finalizó o que el inventario fue confirmado. Son eventos diferentes.

El operador debe conservar la semántica original. La ruta amortizada tiene un punto colectivo de verificación. La ruta genérica tiene un mapa de resultados parciales. Un único indicador verde borra justo la información necesaria para recuperar el sistema.

Cada token nace con un nonce nuevo, no con un asiento contable

En la variante amortizada el cliente crea un nonce aleatorio de 32 bytes para cada token. Lo combina con el tipo, el resumen del desafío y la clave del emisor antes del cegado. La misma solicitud transporta muchas entradas, pero estas no son copias de una sola identidad criptográfica.

Sin embargo, el cliente tiene que recordar qué salida corresponde a qué nonce. La posición importa. Si una implementación reordena respuestas o usa la misma porción de autenticador dos veces, la validez abstracta de la prueba no corrige el error local.

Después de la finalización comienza otro sistema: el inventario. Allí hacen falta unicidad, escritura transaccional, cuarentena, consumo y restauración. Un reinicio entre “prueba válida” y “commit completo” puede dejar al emisor convencido de que trabajó y al cliente sin activos utilizables.

El nonce fresco impide una clase de repetición en la construcción del token. No demuestra que la base de datos no duplicó filas, que una copia de seguridad no resucitó un token gastado o que dos procesos no seleccionaron el mismo registro.

El ahorro no es mágico ni gratuito

El borrador es claro: BlindEvaluateBatch sigue siendo lineal en el número de evaluaciones. Lo que se reparte es la prueba. A medida que crece Nr, el coste práctico puede acercarse a la mitad del de emitir Nr tokens uno por uno.

La afirmación no cubre todos los recursos. Persisten el análisis del cuerpo, las evaluaciones, la red, la política de admisión, la finalización y el almacenamiento. La emisión genérica también conserva un coste lineal y permite al emisor ignorar solicitudes más allá de un límite.

El lote grande cambia rendimiento por radio de fallo. Un elemento cegado que no se puede deserializar provoca 422 en la ruta amortizada. Un tipo no soportado, una clave truncada desconocida o un número por encima del máximo tienen el mismo resultado. Del lado cliente, un fallo de prueba afecta al conjunto.

El tamaño óptimo no sale de una curva de CPU. Sale del coste de perder o reintentar el grupo entero. Una aplicación de bajo riesgo puede preferir lotes amplios. Un servicio donde cada token habilita una operación sensible puede preferir grupos pequeños y trazabilidad más fuerte.

El inventario debe usar seis contadores, no uno

Una política práctica puede comenzar con seis cifras: solicitados, respuestas presentes, finalizados, confirmados en almacenamiento, disponibles y consumidos. Añadir “ambiguos” evita forzar una mentira cuando hay un corte en medio.

En un 206, “respuestas presentes” se calcula recorriendo el vector, no copiando la longitud de la solicitud. “Finalizados” cuenta sólo los valores que pasan el procedimiento del tipo correspondiente. “Confirmados” aumenta dentro de una transacción durable. “Disponibles” descuenta cuarentena y expiración local. “Consumidos” requiere un resultado de presentación suficientemente claro.

La igualdad esperada depende del momento. Justo tras un 206 es normal que solicitados sea mayor que presentes. Es anormal que el tablero no pueda explicar la diferencia. Tras un crash es aceptable tener una cola ambigua; no lo es volver a sumar todo el lote sin reconciliación.

El lenguaje también importa. “Emitido” puede significar que el emisor produjo bytes o que el cliente obtuvo un token utilizable. Los reportes deberían nombrar al observador: issuer_returned, client_finalized, store_committed.

Reintentar puede multiplicar el problema

Una pérdida de red no indica si el emisor trabajó. Un 422 indica rechazo de la solicitud amortizada, pero un 206 contiene resultados aprovechables. Un fallo del almacén después de la finalización no se repara automáticamente repitiendo la emisión.

La organización debe definir la unidad de reintento. En la ruta genérica puede reconstruir sólo las posiciones vacías, siempre que preserve la asociación y la política lo permita. En la amortizada, la atomicidad de la prueba puede favorecer una nueva solicitud completa, pero eso puede consumir otra cuota y crear nuevos tokens.

Cada decisión necesita un recibo. Guardar temporalmente un hash de solicitud, tipo, época de clave, posición, presencia de respuesta, finalización y commit permite reconstruir la operación. El recibo no debe viajar luego al origen ni quedar unido indefinidamente a la telemetría de canje.

Sin esta separación, la solución de auditoría termina siendo el mecanismo de correlación más potente del sistema.

El límite del lote distribuye poder

El emisor decide cuántos tokens acepta en un lote amortizado. También puede limitar solicitudes genéricas por cliente y clave. Ese parámetro determina cuánto inventario puede acumular un cliente con una sola interacción y cuánto depende de volver a estar en línea.

Un límite alto mejora la tolerancia a desconexiones y favorece el prefetch. También concentra valor portador y amplía el daño de una filtración. Un límite bajo reduce stock, pero acerca al emisor a cada uso y puede aumentar información temporal. Durante una rotación de claves, límites desiguales pueden producir 206 y vacíos inesperados.

Esta es política de operación codificada, no sólo implementación. Debe tener dueño, versión, monitorización y un camino de excepción. El estándar puede coordinar la señal; no debería fingir que una cuota universal sirve a todos los modelos de abuso.

Un número de IANA no demostraría la cadena completa

El texto propone 0x0005 y nuevos media types. El registro congelado para esta investigación aún no contiene esa fila. La revisión del Security AD pidió aclaraciones sobre la asignación y referencias, además de una revisión temprana del HTTP Directorate.

No hay que exagerar el episodio. El mensaje dice que los comentarios deberían ser fáciles de resolver. Pero sí conviene mantener el orden probatorio: propuesta, asignación, implementación, interoperabilidad, intercambio, finalización, inventario y resultado son recibos distintos.

El shepherd habla de implementaciones y de consenso fuerte en un grupo pequeño. No publica un censo ni resultados comparables. La etiqueta correcta es “trabajo con implementaciones reportadas y evaluación IESG”, no “estándar desplegado”.

Auditar sin deshacer la privacidad

RFC 9576 separa los contextos de atestación, emisión y canje porque la posibilidad de combinar observaciones define la privacidad real. El lote añade tamaño, hora, clave y endpoint a la superficie observable.

Un identificador estable de lote, unido a cada token local y luego al canje, puede enlazar actividades futuras. El registro debe demostrar que los saldos cuadran sin conservar un mapa de comportamiento.

Conviene guardar agregados y hashes unidireccionales, acortar la retención del mapa posición-solicitud, separar permisos de emisión y canje y prohibir que el identificador operativo aparezca en peticiones al origen. En una investigación excepcional, el acceso debe ser específico y auditable.

El recibo que falta tiene tres niveles: datos del lote, estados temporales por posición y libro transaccional de inventario. No necesita convertirse en un pasaporte permanente del token.

La cadena queda así:

desafío -> admisión -> lote -> respuesta -> finalización -> commit -> selección -> canje -> autorización -> efecto.

La prueba común gobierna una sola flecha. No puede apropiarse de las demás.