Resumen

  • draft-ietf-acme-pop-00 propone declarar la clave del certificado en newOrder y demostrar su posesión mediante una autorización pop específica de esa orden.
  • newOrder_hash se calcula sobre los bytes decodificados del payload JWS, no sobre un JSON vuelto a serializar.
  • La prueba de clave y la validación de DNS, correo u otros identificadores siguen siendo autorizaciones distintas que deben resultar válidas.
  • En modo ML-KEM, la respuesta demuestra posesión al servidor, pero el servidor también puede producir el MAC esperado; no hay prueba independiente de no repudio.
  • La revisión 00 es un Internet-Draft activo del IETF, no un RFC ni evidencia de soporte, emisión o despliegue.

El objeto que parece igual puede no ser la misma orden

Dos representaciones JSON pueden expresar campos semejantes y, aun así, no contener los mismos octetos. Una implementación también puede interpretar mal claves duplicadas o normalizar datos antes de conservarlos. Si la prueba se calculara sobre una reconstrucción, el sistema tendría que confiar en que cliente y servidor reconstruyeron exactamente la misma intención.

El borrador evita ese atajo. Define raw_newOrder como el resultado exacto de decodificar el payload JWS antes del análisis. Luego calcula SHA-256 y conserva newOrder_hash como parte de la orden. Si el JSON no tiene una interpretación única, el servidor rechaza la solicitud. La prueba nunca se cambia a una serialización “equivalente”.

Para claves de firma, el cliente firma un prefijo de dominio, un nonce nuevo de 32 bytes y ese hash. Para ML-KEM, el servidor encapsula hacia la clave pública propuesta, entrega un ciphertext fresco y deriva una clave MAC; el cliente que posee la clave privada puede decapsular y responder con HMAC-SHA-256 sobre el hash de la orden.

La consecuencia es concreta: cambiar la clave, los identificadores, el perfil o cualquier otro octeto del payload cambia el contexto de la prueba.

La clave entra antes, pero la autoridad no se adelanta sola

El cliente incluye popKey como SubjectPublicKeyInfo DER codificado en base64url y añade exactamente un identificador pop con valor vacío. Debe haber también al menos un identificador de certificado. El servidor almacena de forma atómica la clave, el hash, una autorización pop y un único desafío pop-01.

El identificador vacío no representa una identidad. No contiene la clave ni su huella y no debe aparecer en el certificado. Solo solicita una comprobación independiente de posesión.

Un desafío DNS-01 puede demostrar el control que la política del servidor reconoce sobre un nombre. pop-01 puede demostrar que el participante poseía la clave privada declarada. Ninguno responde la pregunta del otro. La orden queda lista únicamente cuando ambas clases de autorización son válidas.

Esa separación impide el lavado de evidencia. “Controló el dominio” no significa “poseía esta clave”. “Poseía esta clave” no significa “tenía derecho al dominio”. Y ninguna de las dos frases decide por sí sola qué extensiones debe firmar la autoridad certificadora.

La cuenta ACME y el certificado no comparten el mismo papel

La clave de cuenta firma los mensajes ACME. popKey será la clave del certificado. El borrador exige que sean diferentes después de comparar sus SPKI DER canónicos.

La regla conserva dos planos de recuperación. Una rotación o pérdida de la clave de aplicación no debería alterar automáticamente el control administrativo de la cuenta. Una persona capaz de operar la cuenta no debería obtener, por esa sola razón, la clave privada que usará el servicio final.

También aparece una dependencia nueva. RFC 8555 admite revocar con la clave de cuenta o con la clave privada del certificado. Una clave KEM no puede firmar, por lo que la segunda opción desaparece. Si se pierde la clave de cuenta, puede no quedar ningún método de revocación dentro de ACME.

Un canal del prestador, certificados de vida corta, CRL u OCSP externos pueden reducir el riesgo. Son controles distintos y deben probarse antes de que haya un incidente.

Un MAC KEM sirve al verificador que lo creó

El servidor genera el ciphertext ML-KEM y conoce el secreto derivado. El cliente demuestra que puede obtener el mismo valor al devolver el HMAC correcto. Ese intercambio es suficiente para que el servidor decida si emite.

No es una firma transferible. Un tercero o auditor externo no puede concluir que solo el cliente generó la respuesta, porque el servidor también podía hacerlo. El borrador reconoce expresamente que no hay no repudio.

La operación exige un manejo estricto del material efímero: ciphertext distinto por desafío, ninguna reutilización entre órdenes, HKDF antes del HMAC y destrucción de secretos al terminar. Una prueba inválida lleva el desafío, la autorización y la orden a estado inválido; no abre una sesión indefinida de intentos.

La finalización vacía contiene decisiones anteriores

Cuando todas las autorizaciones están vigentes, el cliente finaliza con {}. Ya no puede introducir un CSR distinto al final. La autoridad debe emitir con una clave criptográficamente equivalente a popKey y con los identificadores autorizados.

Los demás campos continúan bajo la política de la CA o un perfil seleccionado. El diseño no habilita extensiones arbitrarias aportadas por el cliente. Después, la instalación, la correspondencia con la clave privada, la entrega en cada réplica y la aceptación por el usuario siguen siendo hechos independientes.

La ausencia del CSR reduce un punto de enlace tardío. No prueba la continuidad de custodia ni el resultado del servicio.

STAR concentra la palanca de parada

En una orden STAR, el popKey inicial puede reutilizarse en renovaciones automáticas sin repetir pop-01. Cambiar la clave exige una nueva orden. Los certificados STAR no se revocan individualmente mediante STAR; la clave de cuenta cancela la orden y detiene futuras emisiones.

Al combinar STAR con una clave KEM, la cuenta es la única palanca prevista por el protocolo para parar la cadena. Perderla puede dejar renovaciones activas hasta la intervención del proveedor o la fecha final. Una arquitectura criptográfica más moderna no elimina este punto operativo; lo hace más visible.

La revisión 00 fue publicada el 1 de septiembre de 2026 y puede cambiar o caducar. No se verificó soporte de ninguna CA o cliente nombrado, ni interoperabilidad, emisión, incidente o adopción.