Resumen

  • RFC 9578 permite emitir tokens privados o públicamente verificables sin revelar al emisor el token final; la comprobación solo vincula el autenticador, la entrada y una clave emisora.
  • La condición del reto, el estado de canje, la política de acceso y el resultado de la aplicación se deciden fuera de esa prueba y deben dejar recibos distintos.

Un torno puede leer una credencial auténtica y, aun así, abrir la puerta equivocada. Privacy Pass plantea la misma disciplina en un sistema mucho menos visible: la autenticidad del token no contiene la razón por la que una solicitud merece pasar.

RFC 9578 lo expresa con una franqueza útil: estos tokens no prueban nada salvo que un servidor determinado los creó en el pasado. El registro del RFC Editor, la página de Datatracker, el historial y la consulta de erratas acreditan qué documento es y cuál es su estado. No acreditan una sesión concreta, una instalación ni una decisión de negocio.

Dos protocolos, una afirmación limitada

La modalidad privada usa un VOPRF sobre P-384 y SHA-384. La comprobación exige la clave privada del emisor. La modalidad pública emplea RSA ciego con módulo de 2048 bits y admite verificación con la clave pública. RFC 9497 define el mecanismo VOPRF y RFC 9474 el esquema de firma ciega RSA.

Antes de emitir, el cliente obtiene una configuración: tipo de token, nombre del emisor, endpoint de solicitud y, cuando procede, clave pública. Crea un nonce nuevo de 32 bytes, calcula el SHA-256 de un reto opaco, añade el identificador de clave y ciega la entrada. El emisor valida formato y tipo, evalúa o firma el elemento cegado y responde. El cliente finaliza el resultado hasta formar el autenticador.

Ese diseño impide que el emisor observe directamente el token que después circulará. No convierte en invisibles el momento de la conexión, la cuenta, el attester, la dirección de origen, la distribución de configuraciones ni la entidad que controla varios roles. La ceguera del mensaje es una propiedad fuerte pero local; medir la desvinculación del despliegue es otra tarea.

El hash conserva bytes, no significado

El reto entra en el token como un resumen. Puede proceder del flujo de canje de RFC 9577. La operación asegura que los bytes formen parte de la entrada, pero no demuestra que el texto que una consola asigna a esos bytes sea cierto.

Si la política dice «CAPTCHA superado», «dispositivo atestado» o «cuota pagada», la fuente de esa condición debe aportar su propio comprobante. RFC 9578 no observa ese proceso; solo ejecuta la emisión sobre el valor recibido. Confundir ambos planos permite que una etiqueta operacional se convierta en una afirmación criptográfica que nunca existió.

La arquitectura de RFC 9576 distingue cliente, origen, attester y emisor y estudia metadatos y colusión. Es la referencia correcta para diseñar las fronteras. No demuestra que una empresa haya separado realmente esos papeles. La cobertura de BTW sobre RFC 9614 conserva su pregunta propia sobre separación y desvinculación; este análisis sigue otra ruta: emisión, verificación, canje, autorización y resultado.

Un verificador no es el dueño de la política

En la variante privada, el emisor recalcula la salida VOPRF con su secreto. En la pública, el verificador comprueba la firma contra la clave. El resultado responde si el autenticador concuerda con la entrada bajo esa clave. No responde si la configuración era la correcta para todos, si el token es reciente, si ya fue gastado, si queda cuota ni si la operación solicitada está permitida.

El registro IANA de Privacy Pass coordina tipos y formatos. No es un inventario de despliegues y tampoco adjudica permisos. Los borradores actuales sobre coherencia de claves y tokens de limitación hacen visible lo que falta: distribuir una vista coherente de las claves y expresar cuotas son problemas separados. Siguen siendo borradores, no consenso de RFC ni prueba de adopción.

La evidencia operativa debería enlazar la procedencia y hash de la configuración, el ID de clave, el reto y su versión de política, el nonce y hash de entrada, la respuesta del emisor, la finalización del cliente, el verificador elegido, la decisión del almacén de canje, el estado de repetición, la razón de autorización y la respuesta útil de la aplicación. La privacidad obliga a limitar correlaciones; no obliga a ocultar dónde cambia la autoridad.

Las capas de realidad de Heng Lu impiden que un símbolo válido herede autoridad ajena. Running-Code Primacy exige comprobar lo que hacen los sistemas y no solo lo que permite el texto. Por qué existe BTW Media completa el criterio: publicar el alcance real del recibo, incluso cuando sea menor que el relato institucional.

Fuentes