La atestación de CSR entra en Last Call, pero el certificado no es el registro de prueba

Resumen

• El IESG abrió el 2 de septiembre de 2026 el Last Call de draft-ietf-lamps-csr-attestation-29, con comentarios hasta el día 16. Se estudia como Proposed Standard; aún no es un RFC aprobado.
• El texto define estructuras ASN.1 para transportar una o varias Evidence, Endorsements o Attestation Results en solicitudes PKCS#10 o CRMF. El contenedor no equivale a un dictamen común.
• La CA/RA puede evaluar las declaraciones para aplicar su política de emisión o descartarlas. Si las utiliza, debe comprobar la unión con la clave, la plataforma y la frescura.
• No se recomienda copiar al certificado público datos de hardware, parches o propiedad. Por eso el certificado, aun siendo válido, no explica qué evaluación privada tuvo lugar.
• Un recibo protegido de la decisión de emisión conservaría esa procedencia sin publicar el inventario del dispositivo. Es una propuesta de Daniel Kade, no un requisito de IETF.

El certificado no muestra el expediente que lo precede

Un tercero puede abrir un certificado, verificar la firma de la autoridad, examinar sus extensiones y seguir la cadena de confianza. Esa inspección no revela necesariamente si la solicitud llegó con atestaciones, si un Verifier las valoró, qué política aplicó la CA o si el material fue descartado sin procesarlo.

El anuncio del IESG puso el 2 de septiembre la revisión 29 en Last Call y fijó el 16 de septiembre como fecha límite para comentarios. La ficha del Datatracker la mantiene In Last Call, con revisión de IANA pendiente. El historial registra el 6 de septiembre la asignación de una revisión ARTART. Son hitos de escrutinio, no una aprobación ni una noticia de despliegue.

La revisión 29 define un AttestationBundle capaz de llevar múltiples declaraciones y certificados auxiliares. Las declaraciones pueden ser evidencia generada por un Attester, respaldos o resultados producidos por un Verifier. Los formatos pueden estar normalizados o ser propietarios.

PKCS#10 y CRMF siguen siendo los recipientes de solicitud. El borrador añade una forma interoperable de adjuntar información, no una política universal para aceptarla. Tampoco convierte la presencia de bytes en una afirmación de que una CA los comprendió.

La revisión 28 y la comparación oficial 28–29 evitan exagerar la novedad. La última entrega aclara redacción y actualiza referencias; el límite entre transporte y decisión ya existía. Lo nuevo para la agenda pública es el Last Call.

Tres salidas compatibles con el mismo contenedor

La CA/RA puede no requerir atestación. Puede exigirla y evaluarla. O puede recibir declaraciones opcionales y descartarlas. El borrador autoriza expresamente a verificar el material para determinar qué política de emisión se satisface y también a desecharlo sin procesar. Una CA que lo acepte o lo exija debería documentar sus requisitos en su Certification Practice Statement.

Estas tres rutas no producen necesariamente perfiles de certificado distintos. El certificado demuestra que la CA firmó bajo su marco de confianza; no enumera cada condición interna. Un informe posterior que diga atestación verificada necesita evidencia del flujo concreto, no una inferencia a partir de la firma.

La separación coincide con RFC 9334. El Verifier aplica una política de evaluación a la Evidence y produce Attestation Results. El Relying Party aplica otra política, propia de su decisión, a esos resultados. La validez criptográfica de un mensaje y la decisión de emitir son estados consecutivos, no sinónimos.

Las reglas de firma de código del CA/Browser Forum ofrecen un motivo real para preguntar por la protección de claves y varios métodos para verificarla. Sin embargo, una página de requisitos no identifica el método usado para un certificado concreto. El borrador de IETF tampoco actúa como auditor de una CA.

La parte difícil es demostrar que las afirmaciones hablan del mismo sistema

El ejemplo del documento reúne tres afirmaciones: una clave nació en un HSM, una plataforma pertenece a la empresa y esa plataforma se encontraba en un estado conocido como bueno. Cada una podría ser auténtica y referirse a un objeto distinto.

La CA/RA debe comprobar la composición: la primera declaración tiene que vincularse con la clave pública del CSR; las otras dos, con la plataforma que contiene ese HSM. Contar firmas válidas no prueba la unión. El borrador dice además que al menos una declaración debería contener una atestación ligada criptográficamente a la clave objeto de la solicitud. Al menos una no extiende por magia el vínculo al resto.

La frescura también depende de una decisión. La CA/RA puede ignorar material caducado o cuya frescura no pueda determinarse. El borrador complementario de frescura, revisión 08, permite pedir un nonce mediante CMP, EST o CMC. Deja fuera de alcance cuántos nonces exige una solicitud, cómo llegan al Attester, quién los genera y otros métodos. Un nonce presente no es un veredicto completo.

Un registro serio debe conservar qué declaración consumió qué desafío, el intervalo aceptado, el resultado de las uniones y la política que decidió. De lo contrario, los componentes pueden ser correctos y la conclusión quedar sin fundamento reproducible.

Privacidad y trazabilidad no son opciones opuestas

Publicar todo sería una solución torpe. Las atestaciones pueden incluir modelo de hardware, nivel de parche o propiedad del dispositivo. La revisión 29 desaconseja copiarlas en el certificado; si una CA decide hacerlo, debería revisar el contenido y retirar información sensible. También desaconseja usar la variante de extensión CRMF en certificados X.509 por sus implicaciones de privacidad.

Un certificado se replica, se archiva y circula fuera del contexto de inscripción. Incluir un retrato técnico del dispositivo haría persistente una observación que quizá solo era válida durante unos minutos y frente a una política concreta.

El control proporcionado es un recibo de emisión con capas. La parte protegida enlaza el hash del CSR, el número de serie o huella del certificado, los identificadores de formato y hashes del material, los roles del Attester, Verifier y CA/RA, la unión clave-plataforma, la frescura, las versiones de las políticas, la disposición de cada declaración, la decisión, el responsable y la hora.

La parte pública puede reducirse a un identificador, la referencia al certificado, una afirmación acotada, la política aplicable y el canal de corrección. No necesita exponer medidas, parches ni documentos de propiedad. Los auditores autorizados acceden al detalle bajo reglas de retención.

Ese recibo es mi propuesta, no una extensión prevista por el borrador. No demuestra que una atestación sea cierta, no obliga a usarla y no acusa a ninguna CA de haberla ignorado. Solo mantiene unida la decisión a su evidencia cuando el certificado, por diseño, no debe transportar el expediente.

The Policy Mirror sitúa la gobernanza en el punto donde una política transforma una evaluación privada en autoridad pública. Running Code Primary exige observar esa ejecución. La CPS dice lo que debería pasar; el certificado dice que hubo emisión; el recibo muestra qué pasó en ese caso.

Fuentes

1. Last Call del IESG
2. Ficha del Datatracker
3. Historial del documento
4. Revisión 29
5. Revisión 28
6. Comparación oficial 28–29
7. Arquitectura RATS, RFC 9334
8. PKCS#10, RFC 2986
9. CRMF, RFC 4211
10. Frescura de atestaciones, revisión 08
11. Code Signing Baseline Requirements
12. Lu Heng — The Policy Mirror
13. Lu Heng — Running Code Primary