Summary

  • Un Internet-Draft individual propone que un Identity Document Service compatible con RATS convierta un Attestation Result aceptable en una clave, un token o una credencial ordinaria para partes dependientes que no entienden RATS.
  • La compatibilidad deja una brecha temporal después de emitir: la credencial puede seguir siendo aceptable por sus reglas habituales aunque cambien la Evidence, las políticas de evaluación, la ubicación o una afirmación material.
  • Daniel Kade propone un arrendamiento de atestación a credencial que vincule vida útil y revocación con épocas de evidencia, versiones de política, clases de afirmaciones, clave de la carga y desencadenantes. Es orientación editorial, no consenso del IETF.

Una mudanza que divide el veredicto

No hace falta imaginar un atacante para encontrar la debilidad. Una carga entrega Evidence, un Verifier la evalúa y un Identity Document Service (IDS) acepta el resultado. La clave privada permanece dentro de la carga, el canal está protegido y se expide una credencial que el servicio de destino ya sabe validar. Después, un orquestador ejecuta una migración legítima.

El draft-bdnr-rats-trustworthy-credentials-02 ofrece una distinción precisa. Si la carga se mueve de Alemania a Francia, Country=Germany puede dejar de ser verdad mientras Region=Europe continúa siéndolo. Para un permiso regional, quizá nada tenga que cambiar. Para una autorización condicionada a Alemania, el mismo movimiento puede obligar a reducir alcance o revocar. La respuesta depende de qué capacidad descansaba sobre qué afirmación.

El servicio heredado no puede hacer esa pregunta. Recibe un certificado o token aún vigente y firmado correctamente. El diseño lo mantuvo deliberadamente al margen de RATS para reducir cambios. La responsabilidad debe quedar, por tanto, en el actor que vio la decisión original y generó el objeto que aún circula.

La compatibilidad resuelve un problema real

Muchos servicios existentes no pueden procesar Evidence ni Attestation Results. Un binario puede pertenecer a un tercero; la tecnología puede no disponer de una biblioteca adecuada; una modificación puede activar otra revisión de seguridad o regulación; distintos propietarios pueden bloquearse entre sí. Si todo cliente y servidor tuviera que adoptar RATS antes de empezar, el componente más rígido fijaría el calendario.

El borrador interpone un Credential Broker, Key Broker o Credential Authority que actúa como Relying Party de RATS y como IDS. La carga demuestra su estado una vez ante ese intermediario. Cuando el resultado satisface la política, recibe un Identity Document que sus colaboradores ya reconocen. El término abarca claves, tokens y credenciales, de corta o larga duración. Entre las variantes figuran la intermediación de claves, una credencial de prueba de posesión preaprovisionada y la emisión de una nueva credencial de posesión o un token portador breve.

Reducir el radio de impacto es una ventaja, no una carencia moral. Conserva protocolos de autenticación asentados y permite que la clave privada permanezca con la carga. Tampoco obliga a trasladar Evidence sensible a todos los consumidores.

Pero la complejidad cambia de dueño. El IDS hace invisible la atestación en el trayecto de entrada. En el trayecto de salida debe convertir una nueva evaluación en caducidad, estado o revocación que el servicio sin RATS pueda aplicar. Sin esa traducción, la compatibilidad se convierte en una desconexión permanente.

La autorización funciona con tres relojes

RFC 9334 distingue el Appraisal Policy for Evidence aplicado por el Verifier del Appraisal Policy for Attestation Results aplicado por la Relying Party. El primer juicio interpreta la Evidence y produce un resultado; el segundo decide si dicho resultado sirve para una finalidad concreta. Un resultado auténtico no concede por sí mismo autorización.

Ambos juicios tienen límites temporales. La Evidence necesita frescura adecuada y el resultado no debe utilizarse más allá de su periodo de validez. El propio RFC reconoce una carrera inevitable: el estado o la política pueden cambiar inmediatamente después de generar el resultado. La validez acota el uso, pero no promete que la realidad quede congelada.

Una credencial crea un tercer reloj. Un certificado trae fechas de comienzo y fin; un token, expiración; un sistema de estado, su propio ritmo de actualización. Es el reloj que conoce la aplicación antigua. Si la credencial dura ocho horas y una afirmación esencial solo merece cinco minutos de confianza, la conversión no alarga de forma lógica la afirmación. Solo oculta la diferencia.

Acortar la credencial reduce, pero no define, la brecha. Un token de diez minutos todavía puede cruzar un límite de cinco. La atestación continua descubre cambios con mayor rapidez, pero necesita una regla para actuar sobre credenciales ya entregadas. Y la revocación únicamente cierra el intervalo cuando el emisor puede localizar todos los objetos dependientes y los consumidores consultan el canal de estado.

Criptografía válida, premisa caducada

RFC 7515 permite verificar que un objeto JWS no fue alterado y fue firmado con la clave correspondiente. RFC 5280 establece comprobaciones de ruta, emisores, restricciones, fechas y revocación para certificados. La prueba de posesión demuestra control de una clave privada. Ninguna operación vuelve a evaluar la Evidence que motivó la emisión.

Por eso, el servicio heredado puede comportarse impecablemente y aceptar autoridad obsoleta. Desde su perspectiva, un objeto no caducado y no revocado debe pasar. No sería coherente mantenerlo ignorante de RATS y, a la vez, responsabilizarlo por no observar una migración o un cambio de política.

El IDS no deja de ser parte de la cadena al terminar la emisión. Ha creado una dependencia entre un mundo de Evidence, valores de referencia, Endorsements, Verifiers y políticas variables, y otro de expiración, rotación e introspección. Esa dependencia debe persistir como estado operativo capaz de producir acciones. Una anotación histórica que nadie consulta durante la autorización no es suficiente.

Cada afirmación pierde vigencia de manera distinta

País y región muestran por qué no conviene reducir el resultado a un semáforo. La plataforma de alojamiento puede cambiar sin alterar el componente medido. Una configuración puede degradarse mientras el arranque seguro permanece. Una nueva versión de política puede retirar un algoritmo pero aceptar el resto de atributos. No todas las variaciones justifican la misma consecuencia.

Cada capacidad de la credencial debe enlazarse a la afirmación mínima que la sostiene. Un derecho europeo puede sobrevivir a la frontera nacional; un derecho limitado a Alemania no. Si ambos viven en una credencial indivisible, cualquier corrección será excesiva por un lado: conservarla mantiene más poder del debido, retirarla interrumpe también la parte aún justificada.

El mapa de dependencias evita dos incentivos nocivos. Revocar todo ante cualquier cambio convierte la atestación en una fuente de caídas y anima a silenciar señales. No revocar nunca hasta la expiración deja que la firma preserve una decisión envejecida. Un régimen gobernable puede explicar qué afirmación cambió, qué alcance controlaba y por qué se eligió reemplazar, reducir, suspender o no actuar.

La identidad no procede del mensajero

El borrador contempla un cliente EST ubicado en un hipervisor u orquestador, fuera de la base de computación confiable de la carga. Dicho cliente puede autenticarse para proteger la comunicación. Esa autenticación opcional no debe establecer qué identidad de carga merece la credencial; eso corresponde a Evidence y attestation. La clave privada, además, debería permanecer con la carga.

Tras emitir, una migración o reevaluación debe unirse al objeto mediante la identidad y la clave atestadas, no mediante la sesión del orquestador que transportó la solicitud. De lo contrario, cada canal podría estar bien autenticado mientras se renueva o revoca la credencial equivocada.

El borrador LAMPS sobre atestación de CSR ilumina una obligación cercana. Si una CA o RA utiliza attestation, es responsable de ligar las distintas declaraciones entre sí y con la clave pública de la solicitud; debería documentar sus requisitos en el Certification Practice Statement. Esto ayuda a ubicar la responsabilidad de la unión, pero no demuestra que el mecanismo pos-emisión ya esté resuelto.

WIMSE, por su parte, separa la credencial que representa la identidad de carga de la prueba de posesión. Controlar la clave responde quién presenta. No demuestra que sigan siendo ciertas la ubicación, la medición o la política que habilitaron la expedición.

Un arrendamiento entre atestación y credencial

Daniel Kade propone que el IDS mantenga un arrendamiento de atestación a credencial. No es un formato público nuevo ni obliga al servicio antiguo a interpretar RATS. Es un registro mínimo y una ruta de control que conservan la relación entre dos regímenes de validez.

El arrendamiento identifica la credencial y su tipo, la identidad de la carga, su clave pública y la unión de prueba de posesión. Registra la época y el límite de frescura de la Evidence, el Verifier y la versión de su Appraisal Policy for Evidence, además de la versión de política con la que el IDS aceptó el Attestation Result. Un cambio de política o Verifier puede así encontrar los objetos que requieren revisión.

Después vincula cada alcance a clases de afirmación. País, región, software medido, protección de clave y entorno operativo no deberían mezclarse. Una dependencia puede ser obligatoria, informativa o usada solo para fijar menor duración. No es necesario almacenar toda la Evidence: una referencia protegida, la época y un resumen del resultado pueden mantener la unión con límites de privacidad y retención.

El horizonte de la credencial no debe rebasar sin explicación la dependencia material más corta. La observación continua y un canal de estado probado pueden ofrecer control equivalente. La propuesta no exige siempre la duración mínima; exige justificar qué cierra el intervalo cuando el perfil de la credencial es más largo.

Por último, cada desencadenante tiene una traducción. Migración, rotación de clave, nueva política, retirada de un valor de referencia, cambio de software, remediación fallida o Endorsement modificado pueden exigir reatestación. El resultado puede generar reemplazo, reducción de alcance, suspensión, revocación o una decisión motivada de no actuar. El IDS debe demostrar que emitió la señal nativa y que las clases de consumidores podían recibirla.

Revocar no es escribir una fila

Marcar una credencial como revocada en una base de datos no prueba que haya dejado de funcionar. Algunos consumidores almacenan estados en caché, otros consultan solo al abrir conexión, otros esperan a que venza un token corto. Una sesión ya establecida puede continuar. El arrendamiento tiene que especificar el trayecto real y su demora máxima.

La auditoría empieza con el origen del evento: quién informa la migración, cuánto tarda el IDS en reevaluar, qué mecanismo de certificado o token utiliza, cómo trata sesiones existentes y partes desconectadas, y en qué orden invalida el objeto antiguo y habilita el sustituto. El éxito de la petición de revocación mide el comienzo, no el final.

Las excepciones también caducan. Durante una caída del Verifier, un responsable podría aprobar treinta minutos de continuidad con alcance reducido y observación adicional. Deben quedar autoridad, motivo, término y disposición final. Una tolerancia repetida sin cierre se convierte en una ruta de confianza alternativa.

Una propuesta, no un despliegue demostrado

El borrador de trustworthy credentials reconoce asuntos pendientes. El camino del token portador necesita otro protocolo o extensión y /serverkeygen requiere más detalle. Exige canales con autenticación mutua, confidencialidad e integridad y aborda la custodia de claves, pero no presenta una gobernanza completa del periodo posterior a la emisión.

En la fecha de corte es un Internet-Draft individual sin posición formal del IETF. Los documentos de LAMPS y WIMSE también siguen en elaboración. Las fuentes no establecen ningún despliegue concreto, duración habitual, incidente de migración, incumplimiento, cifra de adopción o resultado de rendimiento. La escena inicial prueba un límite señalado por el propio texto, no atribuye una conducta a un proveedor. El arrendamiento es una propuesta editorial.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-bdnr-rats-trustworthy-credentials-02
  5. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/
  6. https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/history/
  7. https://author-tools.ietf.org/iddiff?url1=draft-bdnr-rats-trustworthy-credentials-01&url2=draft-bdnr-rats-trustworthy-credentials-02
  8. https://www.rfc-editor.org/rfc/rfc9334.html
  9. https://www.rfc-editor.org/rfc/rfc9711.html
  10. https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-29
  11. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02
  12. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08
  13. https://www.rfc-editor.org/rfc/rfc7030.html
  14. https://www.rfc-editor.org/rfc/rfc5280.html
  15. https://www.rfc-editor.org/rfc/rfc7515.html