Resumen

  • El W3C publicó el 24 de septiembre el primer borrador público de Bitstring Status List v1.1; la versión 1.0 sigue siendo una Recomendación.
  • La novedad es una entrada abreviada con URL base e índice de 32 bits: para reconstruir la consulta, el verificador aporta la finalidad del estado.
  • Una referencia compacta no demuestra por sí sola privacidad, actualidad de la lista ni autoridad para cambiar el estado.

Una credencial puede contener una dirección correcta y aun así dejar sin resolver qué se pretende comprobar. El primer borrador público de Bitstring Status List v1.1 hace visible esa separación. Su nueva TerseBitstringStatusListEntry conserva una URL base y un número; un algoritmo convierte esos datos en la entrada completa con la que se busca un estado. El propósito —revocación, suspensión u otro previsto por el sistema— no viaja en la entrada abreviada. Lo aporta quien verifica.

La noticia no es que existan listas de bits. El W3C convirtió Bitstring Status List v1.0 en Recomendación en mayo de 2025. Esa versión ya planteaba agrupar estados para evitar una consulta individual que pudiera revelar al emisor dónde y cuándo se usó la credencial. También permitía que el emisor de la lista no fuera el mismo que emitió la credencial. El documento 1.1, fechado el 24 de septiembre de 2026, está en una fase anterior: un borrador de trabajo que puede cambiar y que no equivale a la aprobación de sus miembros.

Su novedad técnica sí es concreta. El índice abreviado debe poder representarse como entero sin signo de 32 bits. Para convertirlo, el borrador fija 2²⁶ posiciones por lista y 2⁶ posibles números de lista. Una división obtiene el número de lista y el resto ubica el estado dentro de ella; la URL final combina la base, la finalidad aportada por el verificador y ese número. Son parámetros del procedimiento, no un censo de 64 listas efectivamente publicadas.

El texto indica que normalmente se firma la entrada abreviada y que conviene comprobar esa firma antes de convertirla. Eso protege el puntero que recibió el verificador, no resuelve cuál de las finalidades debe utilizar para un caso concreto. Tampoco sustituye la comprobación criptográfica de la lista recuperada. Una organización que acepte la credencial necesita una política inteligible sobre el estado que consulta y sobre la entidad facultada para publicar ese estado.

Incluso una lista firmada plantea una decisión temporal. El titular puede presentarla junto con su credencial y evitar una petición al servidor en ese momento; el verificador puede preferir obtener una copia posterior. El ttl opcional orienta la renovación de caché, pero no altera el periodo de validez. Y la amplitud de la lista no basta para ofrecer privacidad colectiva si solo existen unas pocas credenciales reales: el propio borrador advierte de ese límite.

Fuentes