Resumen

  • El borrador vigente de CoSERV permite que, si no puede satisfacerse por completo una consulta RIM-ID, el receptor devuelva un subconjunto; un conjunto vacío sigue siendo un resultado válido en el caso límite.
  • La codificación determinista, la vinculación criptográfica, la firma y la caducidad acreditan propiedades de la respuesta entregada, no la cobertura de la colección que había detrás.
  • Hace falta un recibo operativo que una la consulta exacta con la generación del conjunto de datos, lo solicitado, lo devuelto, las omisiones, la procedencia, el caché, la verificación y la decisión local.

Cinco preguntas que no caben en una luz verde

La arquitectura de atestación remota separa funciones porque ninguna de ellas debe apropiarse de las conclusiones de las demás. Un atestiguador presenta evidencia; un verificador la evalúa; una parte dependiente decide si concede una capacidad. La RFC 9334 evita así que una prueba técnica se convierta, sin transición visible, en una declaración universal de confianza.

Antes de evaluar evidencia, alguien debe obtener los avales y valores de referencia aplicables. El borrador de grupo de trabajo Concise Selector for Endorsements and Reference Values, CoSERV, propone consultas y resultados compactos para esa tarea. La revisión 07 es un Internet-Draft activo de RATS, no una RFC ni una posición final del IETF.

CoSERV permite responder con precisión a cuatro preguntas. ¿Pertenecen estos bytes a la consulta realizada? ¿Proceden del firmante indicado? ¿Han cambiado? ¿Siguen dentro del intervalo declarado? La consulta usa CBOR determinista; su representación estable sirve para una URL GET y una clave de caché. La respuesta firmada queda ligada a la consulta. El conjunto de resultados tiene caducidad obligatoria, no puede sobrevivir a los RIM que contiene y no incorpora RIM inválidos.

La quinta pregunta es diferente: ¿se examinó toda la población pertinente y se devolvió todo lo aplicable? No se resuelve añadiendo otra firma. Exige conocer qué población afirma cubrir el proveedor, en qué generación se encontraba, qué filtros intervinieron y qué elementos faltaron.

Un objeto puede ser auténtico sin ser exhaustivo. Una respuesta puede ser fresca y venir de una colección atrasada. Un selector puede ejecutarse exactamente y describir un ámbito equivocado. Son combinaciones normales, no paradojas.

La validez del vacío

El pasaje operativo central de la revisión 07 se refiere a la consulta por identificadores RIM. Si el destinatario no puede satisfacerla en su totalidad, puede devolver solo un subconjunto. En el peor caso, el conjunto vacío constituye un resultado válido.

Esa flexibilidad tiene sentido. Un servidor con información parcial no debería inventar material ni fingir que la sintaxis es incorrecta. Puede responder honestamente con lo que está en condiciones de proporcionar. Pero la honestidad de esa respuesta no prueba la exhaustividad de su colección.

Imaginemos una petición de cinco claves que recibe tres. Las tres pueden estar correctamente firmadas, corresponder a la consulta y no haber caducado. Para las otras dos siguen abiertas explicaciones incompatibles entre sí: nunca llegaron a la colección; existen, pero la política de acceso las oculta; no coinciden con el selector; una importación está retrasada; su formato no se admite; el índice falló. La verificación de las tres presencias no determina la causa de las dos ausencias.

Con una respuesta vacía, el salto indebido es aún más tentador. “El servidor devolvió válidamente cero resultados” no equivale a “no existe ningún aval o valor de referencia pertinente”. Puede haber material en otra fuente, en una generación posterior, bajo otra autorización o detrás de una consulta distinta.

También debe acotarse la palabra “último”. Para etiquetas con contador entero, el mayor contador representa la revisión más reciente entre las disponibles para la clave. Si la colección todavía no ha recibido una revisión publicada aguas arriba, el máximo local se calcula sin error y, sin embargo, no es el máximo que existe.

Toda consulta dibuja su propio mapa

Las consultas de entorno eligen una sola clase de identidad: instancia, grupo o clase. La instancia o el grupo no se mezclan con una selección de clase en la misma consulta. Varios selectores del mismo tipo funcionan como alternativas. Dentro de un selector de clase, los campos presentes deben coincidir en conjunto y los ausentes actúan como comodines. Las mediciones de un entorno con estado pueden introducir más restricciones.

Estas reglas aportan reproducibilidad. También convierten la consulta en una decisión de alcance. Seleccionar una instancia en vez de una clase, rellenar un campo o dejarlo abierto altera qué material puede aparecer. El resultado no es una fotografía natural de todo lo relevante, sino la vista producida por una construcción concreta.

Por eso no basta con archivar una huella de la consulta. La huella permite comprobar que los bytes no cambiaron, pero no explica quién eligió el alcance ni por qué era adecuado para la decisión. Una consulta demasiado estrecha puede excluir justo la referencia que habría cambiado una autorización. Una demasiado amplia puede mezclar contextos o revelar identificadores sensibles.

El borrador advierte que los selectores de instancia pueden comprometer privacidad. Una pista de auditoría responsable no debe publicar el identificador de un dispositivo para demostrar que se consultó. Puede conservar los bytes exactos en un almacén de evidencia restringido y dejar en el registro operativo una huella protegida, el tipo de selector y la aprobación de su alcance.

La procedencia comienza antes del paquete

Un proveedor puede entregar artefactos de origen y artefactos recopilados o agregados. La firma de un paquete recopilado prueba quién lo ensambló y que sus bytes llegaron intactos. No prueba que se consultaran todas las fuentes, que todas las recolecciones terminaran, que cada formato fuera compatible o que ninguna política de licencia y acceso apartara material.

Es posible verificar una carpeta sellada y seguir desconociendo si el archivo perdió un cajón. El sello protege la carpeta; no inventaría el cajón ausente.

La misma cautela distingue confianza superficial y profunda. La parte dependiente puede verificar el envoltorio CoSERV, después un CoRIM incluido, después la autoridad de un aval y, por último, decidir si la afirmación se aplica a la evidencia concreta. Cada paso tiene autoridad y errores propios. El éxito del primero no hereda silenciosamente todos los demás.

La caducidad tampoco corrige la cobertura. Limita cuánto tiempo puede reutilizarse una respuesta como actual, y el resultado no puede durar más que los RIM que transporta. Una respuesta recién emitida puede seguir reflejando una colección incompleta. Frescura y exhaustividad son ejes independientes.

Cuando el caché conserva una ausencia

El CBOR determinista permite usar una consulta estable como clave HTTP. Así un caché puede reutilizar un resultado firmado y reducir trabajo repetido. El precio es otra cronología: cuándo cambió la colección del proveedor, cuándo obtuvo el caché la respuesta y cuándo actuó la parte dependiente.

Un caché puede servir correctamente, una y otra vez, un subconjunto válido. El problema nace si el registro conserva solo el resultado de la firma. Después no podrá saberse qué caché respondió, qué antigüedad tenía, qué reglas de frescura aplicó ni si el proveedor había cambiado de generación durante el intervalo.

Lucas Pardue calificó como “Not Ready” su revisión temprana de HTTPDIR del 15 de agosto de 2026 y planteó cuestiones sobre caché, privacidad, HEAD, tamaño de consulta, validadores y frescura. Es la evaluación de un revisor, no un consenso del grupo ni un rechazo del IETF. La tesis de este artículo descansa en la propia regla de subconjunto y conjunto vacío; la revisión solo muestra que el transporte añade más estados que conviene registrar.

El recibo que falta

No hace falta convertir el mensaje CoSERV en un certificado imposible de toda la realidad. Hace falta conservar, a su lado, un recibo de recuperación y cobertura. Ese recibo debe reunir:

  • los bytes deterministas de la consulta, o una huella protegida que permita acceder al original;
  • el perfil, el tipo de resultado y la semántica exacta de los selectores;
  • las claves RIM o ramas solicitadas;
  • el proveedor, la generación del conjunto de datos y una declaración acotada de su cobertura;
  • las claves y artefactos devueltos;
  • las omisiones conocidas y su razón: no disponible, no autorizado, sin coincidencia, inválido, no compatible o error de recuperación;
  • la diferencia entre material de origen y material recopilado, con su cadena de procedencia;
  • la validez de los RIM, la caducidad del resultado, la hora de recuperación y la ruta de caché;
  • los resultados de verificación; y
  • la valoración local, la acción y el evento que obligará a consultar de nuevo.

No debería resumirse todo en otro semáforo. La cobertura es una afirmación del proveedor. Una razón de omisión firmada acredita que el proveedor la declaró, no que sea objetivamente cierta. La decisión de aceptar, limitar o aislar es un hecho de la parte dependiente.

Así, el expediente podría mostrar que se pidieron cinco claves, se devolvieron tres, una fue denegada por autorización y otra no estaba disponible en esa generación; que los tres objetos superaron la verificación; y que el sistema limitó capacidades hasta una segunda fuente o una nueva generación. Esa historia permite revisar el juicio. “CoSERV OK” no.

Fuentes