Resumen

  • La revisión 20 del borrador RATS incorpora un ejemplo de recuperación de avales y valores de referencia. La URL de consulta funciona como identificador implícito y permite reutilizar una entrada de caché.
  • El proveedor firma el resultado junto con la consulta y su caducidad. El verificador examina por separado la evidencia reciente del dispositivo y decide según su propia política.

La consulta se repite; el resultado caduca

Un dispositivo puede entregar evidencia sobre su estado; esa evidencia necesita una señal de frescura que entienda quien la evalúa. Los avales y valores de referencia son otra clase de material. Pueden servir a muchas evaluaciones hasta que el productor cambie su contenido. La arquitectura RATS asigna papeles distintos al dispositivo, al proveedor de esos materiales, al verificador y a la entidad que usa el resultado final.

El documento actualizado el 28 de octubre sigue siendo un Internet-Draft del grupo RATS, con intención de norma propuesta. Su apéndice B añade un ejemplo, no la noticia de una implantación. La pregunta del ejemplo es concreta: ¿cómo pedir avales sin introducir un identificador nuevo en cada petición y arruinar la reutilización de la caché?

CoSERV deja fuera de sus consultas los sellos de tiempo y otros campos volátiles. Los mismos identificadores de entorno y la misma selección de afirmaciones producen los mismos bytes codificados. La URL resultante permanece estable y sirve de clave de caché. Cada verificador que pregunta por el mismo conjunto puede recibir una copia dentro de su plazo, en lugar de provocar una nueva respuesta del productor. Si se añadiera un identificador único a cada petición, ese ahorro desaparecería incluso cuando los valores de referencia no hubieran cambiado.

El apéndice convierte esa URL de GET en una «manija» implícita. attEnvIDs y claimSelection forman la consulta por entorno y marcan, en el ejemplo, el comienzo de una época. La respuesta lleva los avales y valores de referencia firmados junto con la consulta y un vencimiento que cierra el periodo. El texto presupone una fuente de tiempo fiable para ese papel y menciona una Epoch Bell como posibilidad. La URL identifica la petición reutilizable. La firma y el vencimiento delimitan los datos concretos que el verificador puede usar.

El borrador CoSERV pone límites operativos al truco. Cada conjunto de resultados tiene fecha de caducidad y el consumidor deja de aceptarlo después. La frescura anunciada por HTTP no puede sobrepasar esa fecha. Si hay intermediarios no fiables, la firma vincula resultado y consulta. El consumidor que necesita volver al origen puede pedir Cache-Control: no-cache. Cuando una actualización de firmware cambia el valor de referencia, ignorar el vencimiento permite evaluar el equipo con un objetivo ya retirado. El resultado puede ser técnicamente coherente con un documento viejo y operativamente equivocado para la versión actual.

El productor controla el material que firma y el plazo de esa respuesta. El verificador decide qué referencias admite y cómo evalúa con ellas la evidencia del dispositivo. La entidad que recibe el resultado toma la decisión práctica. La nueva ilustración del borrador hace visible esa cadena de responsabilidades; una URL repetible facilita el transporte, sin asumir el puesto de juez.

Fuentes: RATS -20; RATS -19; estado del borrador; CoSERV -07; Epoch Markers -06; RFC 9334.