Summary

  • El borrador individual publicado el 2 de noviembre propone ampliar EST para inscribir una credencial nueva o recuperar una ya guardada mediante atestación remota.
  • El servidor EST no puede crear claves ni pruebas, evaluar la atestación o autorizar la entrega. Una autoridad de credenciales decide la emisión; una bóveda decide qué paquete existente puede salir.

Una ventanilla rápida tiene una ventaja peligrosa: acaba pareciendo la oficina que aprueba. El nuevo borrador sobre EST y atestación corta esa confusión en cuatro puntos. Cliente y servidor EST no generan claves, solicitudes de certificado ni pruebas; tampoco acuñan los valores de frescura, califican los resultados de atestación o autorizan credenciales. Relacionar una respuesta con una solicitud anterior sirve para seguir el trámite. No concede derechos.

La primera ruta crea una credencial. La carga de trabajo genera una clave de firma, una solicitud de certificado y la evidencia que las vincula. Un verificador examina esa evidencia. La autoridad de credenciales comprueba que el solicitante posee la clave privada de la solicitud y aplica su criterio al resultado recibido. Solo entonces emite el identificador nuevo. EST transmite cada pieza sin convertirse en emisor por el hecho de tocarla.

La segunda ruta entrega una credencial ya existente. La carga de trabajo prepara una clave de cifrado y mete su parte pública en la evidencia. La bóveda usa el resultado de atestación para seleccionar, con su propia política, el grupo de credenciales permitido. Sella el paquete para esa clave pública. El cliente y el servidor EST deben mantener opaco el contenedor. El receptor comprueba destino, frescura e indicación antes de abrirlo. Esa indicación ayuda a elegir dentro del conjunto autorizado; no puede ampliar el conjunto.

Aquí aparece el precio de la comodidad. El borrador reconoce que compartir una credencial entre réplicas impide atribuir una acción a una instancia concreta. Si esa atribución importa, plantea claves por instancia con las mismas afirmaciones de identidad o un servicio de firma central. Una bóveda puede repartir acceso con eficiencia y, aun así, dejar una investigación sin el nombre de la réplica que utilizó la clave. Esa decisión debe tomarse antes del incidente.

El registro de la IETF sitúa el documento como propuesta individual; incluye ejemplos de intercambio, no una prueba independiente de interoperabilidad. La prueba que falta es concreta: un emisor y una bóveda que rechacen un atajo del servidor, una vinculación de clave alterada y una indicación fuera de la política. Hasta entonces, la propuesta deja la responsabilidad donde puede auditarse: en quien evalúa la prueba y en quien decide entregar la credencial.