Resumen

  • El IESG abrió el 2 de septiembre de 2026 el Last Call de la revisión 29 de Use of Remote Attestation with Certification Signing Requests, hasta el 16 de septiembre. Aspira a Proposed Standard, pero sigue siendo un Internet-Draft, no un RFC aprobado ni evidencia de implantación.
  • Una solicitud PKCS #10 o CRMF puede transportar varias atestaciones. El CA/RA debe probar, sin embargo, que la clave pública, el HSM, la propiedad de la plataforma, su estado y el contexto de frescura pertenecen a una sola transacción atribuible.

La revisión 29 plantea un caso que debería convertirse en prueba obligatoria para cualquier sistema de emisión. Una declaración afirma que la clave nació dentro de un HSM. Otra atribuye una plataforma a la empresa. Una tercera considera sana una plataforma. Las tres pueden ser correctas y, aun así, describir tres equipos distintos.

El borrador ofrece un recipiente común. AttestationStatement combina un OID de tipo con el contenido de la declaración. AttestationBundle agrupa una o más declaraciones y, de forma opcional, certificados. La solicitud porta un bundle de nivel superior bajo id-aa-attestation, como atributo PKCS #10 o extensión CRMF.

El recipiente resuelve el traslado, no la relación. Los certificados opcionales pueden servir para construir una ruta de validación. No indican por sí mismos un orden vinculante, el ancla de confianza correcta ni la política de emisión aplicable. Analizar el paquete, validar una cadena y autorizar un certificado son decisiones diferentes.

Tampoco define el borrador los formatos de las declaraciones ni crea un registro nuevo. Otros estándares o proveedores determinan formato y OID. El OID es, por tanto, una etiqueta de encaminamiento, no una garantía de verdad. Poder decodificar no equivale a verificar la firma; una firma válida no elige la confianza; y confiar en el firmante no vincula automáticamente la afirmación a la clave del CSR.

Hay incluso una ambigüedad operativa cuando varios Verifiers aceptan el mismo OID. El texto propone OID distintos o una pista de envoltorio definida por el formato. Esa pista debe quedar autenticada. Si se deja fuera de la protección criptográfica, un error o una manipulación puede derivar la evidencia hacia el Verifier menos estricto.

La unión parte de la clave pública. La proof of possession acredita control de la clave privada dentro del protocolo de solicitud. No dice dónde fue creada, si puede exportarse, quién posee el equipo, qué estado tiene la plataforma ni si el solicitante merece el certificado.

La afirmación del HSM cubre sólo uno de esos pasos. Hace falta un identificador estable que una ese HSM a la plataforma de la que habla el registro de propiedad. La vigencia de dicho registro debe incluir el momento relevante. La medición ha de referirse a esa misma plataforma, con una época y valores de referencia identificables. Coincidencias de nombre o fabricante no bastan.

La frescura reduce el margen de repetición, pero no crea identidad. El borrador complementario mantiene el nonce y el CSR dentro de un contexto de operación: CMP puede utilizar la transacción; EST puede conservar la misma sesión TLS o estado HTTP. Si el CA/RA no consigue asociar la solicitud con el intercambio previo, no debe tratarlos como unidos.

Cuando se pide frescura, el nonce mide entre 8 y 64 octetos; longitud cero significa que no se solicita. Un Attester principal puede distribuir un mismo desafío a varios subordinados. Así se acerca la época de varias Evidence, pero no se demuestra que todas describan la misma clave, el mismo HSM o el mismo equipo.

RFC 9334 impone otra cautela: la frescura limita la incertidumbre de replay, no congela la plataforma. Después de producir la prueba, pueden cambiar el software, la propiedad o el estado de compromiso. Una medición pertenece a un instante; el certificado puede permanecer años.

Por eso la responsabilidad vuelve al CA/RA. Debe elegir formatos admitidos, anclas de confianza, valores de referencia, reglas de valoración y perfil de emisión. Puede contrastar las pruebas con una de varias políticas o descartarlas cuando no sean relevantes. El borrador aconseja documentar los requisitos en la certification practice statement.

La versión de esa política forma parte del recibo. Una auditoría reproducible conserva el hash y la clave del CSR, bytes de las declaraciones, firmantes, versiones de Verifier, referencias, nonce y contexto, título de propiedad, valoración, política seleccionada y actor que autorizó el resultado.

El certificado público no debe convertirse en ese expediente. Identificadores de hardware, firmware, parches, propiedad y cadena de suministro pueden ser sensibles. La revisión 29 desaconseja copiar la atestación al certificado, aunque el riesgo subsiste en logs de alta, bundles archivados y registros de Verifiers.

Las capas de realidad de Heng Lu ordenan la conclusión. Existencia del borrador, sintaxis válida, firma verificada, valoración favorable, emisión, despliegue y aceptación posterior son hechos separados. Un estándar mínimo puede coordinar el sobre y exigir vínculos verificables. La realidad operativa sólo aparece cuando el CA/RA conserva la cadena exacta y responde por la decisión.

Fuentes