Resumen

  • El IESG aprobó draft-ietf-acme-device-attest como Proposed Standard el 30 de julio de 2026. La revisión 10 está en la cola del RFC Editor; aún no hay número RFC final ni prueba de adopción.
  • device-attest-01 puede enlazar el identificador del Order, la clave atestada y la clave del CSR. Su alcance depende del formato, de la autoridad y de si se firma sólo el token o la key authorization ligada a la cuenta.
  • La evidencia autoriza una emisión puntual. No informa continuamente del estado del dispositivo, y el certificado puede omitir por privacidad todo identificador físico.

El momento de emisión tiene límites

Un certificado válido suele llegar acompañado de un adjetivo: “dispositivo atestado”. El adjetivo comprime demasiadas preguntas. ¿Qué desafío completó? ¿Quién respaldó la declaración? ¿Qué clave quedó cubierta? ¿Qué atributos se evaluaron? ¿El certificado cuenta algo de ello a quien lo recibe?

La extensión aprobada añade dos identificadores. permanent-identifier suele representar una identidad asignada por el fabricante; hardware-module identifica el tipo y número de serie del procesador criptográfico. device-attest-01 permite probarlos durante el flujo ACME. IANA ya muestra las entradas con una referencia RFC-to-be. El registro no demuestra que un producto las implemente.

El servidor entrega un token nuevo. Normalmente, el cliente crea con él y con la huella de su clave de cuenta la key authorization, y obtiene una atestación específica del formato. El servidor comprueba el valor cubierto, el identificador del Order y la cadena de confianza aplicable.

Para emitir, la autoridad necesita una unión triple: una autoridad de atestación aceptada, la misma clave pública en atestación y CSR, y el mismo identificador en atestación y Order. Si ese identificador llega al CSR y al certificado, debe coincidir byte por byte. No basta con que “parezca” el mismo número de serie.

Algunos formatos externos, sin embargo, firman antes de disponer de la clave de cuenta ACME. Cubren el token, no la key authorization completa. Obtienen frescura, pero no la unión con la cuenta. Ambos resultados no deben compartir un único campo de éxito.

El desafío disponible puede no ser el elegido

Una autorización puede ofrecer device-attest-01 junto con otro desafío. Completar cualquiera de los ofrecidos puede bastar. Es una salida razonable para flotas donde sólo parte del parque tiene hardware de atestación, pero obliga a guardar el camino real.

Que la CA ofrezca atestación no significa que esa solicitud la haya usado. Que la cuenta esté preautorizada mediante External Account Binding tampoco prueba la pertenencia de la clave al dispositivo. Son controles complementarios, no intercambiables.

Si un servicio concede permisos distintos a certificados atestados, necesita un recibo autenticado con el desafío realizado, el formato, la autoridad, el tipo de enlace y el resultado. El certificado común no transporta automáticamente ese expediente.

La identidad física puede quedarse dentro de la CA

La revisión 10 permite omitir estos identificadores del CSR. Un servidor orientado a privacidad puede rechazar incluso un CSR que los incluya. Así, la CA valida el hardware para autorizar la emisión, pero el certificado entrega a los servicios una identidad lógica de carga de trabajo.

Es una separación deliberada. Un identificador permanente publicado en certificados o en Certificate Transparency permite relacionar renovaciones y presentaciones durante años. Esa exposición no se corrige rotando la clave. También puede atar indebidamente una carga migrable a una unidad física.

La otra cara es probatoria: si el identificador no está en el certificado, el relying party no debe inventarlo. Tampoco puede inferir qué autoridad, formato, firmware o política aceptó la CA. Necesita un canal definido para el recibo de emisión o una afirmación explícita con semántica propia.

La postura no hereda la validez del certificado

Una atestación puede contener versión de firmware, estado de arranque, sistema operativo o nivel de protección. La CA puede denegar la solicitud por esos datos, pero el documento no unifica los procedimientos de verificación. Un TPM, un TEE y un almacén protegido por el sistema operativo ofrecen garantías diferentes.

Además, todos esos atributos se observaron en un instante. El certificado puede seguir vigente cuando cambie el firmware, la custodia, la cuenta o el trust store. La revocación atiende algunos casos; no convierte la credencial en telemetría continua.

Las capas de realidad de Heng Lu permiten decirlo sin rebajar el estándar: aprobación, registro IANA, desafío superado, certificado emitido, postura presente y autorización del servicio son recibos distintos. La precisión aumenta su utilidad.

Fuentes