Resumen

  • La revisión 02 permite que una CA compare el registro persistente con la huella JWK SHA-256 de cualquier clave pública utilizada durante la vida de la cuenta ACME.
  • La clave privada retirada ya no autentica solicitudes nuevas, pero su huella puede seguir respaldando la autorización. Borrar el TXT, agotar las cachés, cambiar persistUntil y vencer la validación son acontecimientos distintos.
  • La desactivación de la cuenta es el freno inmediato para todo el ámbito de la cuenta. Antes de confiar en la retirada, el operador necesita un recibo con la generación de clave, la observación DNS, CAA, estado de cuenta y vencimiento de reutilización.

Un equipo de seguridad puede rotar una clave y borrar un TXT antes de terminar el café. El inventario de secretos confirma que la clave anterior ya no firma; una consulta autoritativa confirma que el registro desapareció. Sin embargo, una CA que validó el dominio antes de esos cambios todavía puede conservar una autorización reutilizable.

Ese desfase es la aportación operativa del ACME DNS Persistent Challenge. La revisión 02, publicada el 20 de septiembre de 2026, convierte una prueba DNS en estado con memoria. Según el historial del Datatracker, sigue siendo un Internet-Draft activo en I-D Exists: no es RFC, Last Call ni evidencia de producción. Aunque el encabezado diga Standards Track, el Datatracker aún no asigna intended status, shepherd, director de área o fase del IESG.

La propuesta usa un TXT bajo _validation-persist. Su valor incluye dns-persist-01, una huella JWK SHA-256 de 43 caracteres en base64url sin relleno y un hash sobre dominio, huella y URL de la cuenta. RFC 7638 define la huella; RFC 6920 aporta la forma del identificador basado en hash.

La CA intenta primero con la clave actual. Si no hay coincidencia, recorre en orden inverso las claves públicas históricas de la cuenta. El cambio entre 01 y 02 exige conservar la huella de cada clave pública durante toda la vida de la cuenta. El repositorio del grupo ACME deja visible la evolución, no una adopción final.

La lógica protege una propiedad útil de ACME: la cuenta puede cambiar de clave sin obligar al operador DNS a reconstruir una autorización pensada para durar. Solo se guarda material público. La huella vieja no puede firmar una orden ni recuperar la clave privada; sirve para reconocer el origen de la concesión.

Ahí aparece la autoridad residual. Si la validación se obtuvo cuando K1 era vigente y después la cuenta pasó a K2, K1 pierde autenticación pero la autorización continúa asociada a la cuenta válida. Incluso una consulta nueva puede casar con el TXT de K1 porque el servidor retiene su huella. Rotar al actor que firma no equivale a retirar lo que DNS ya concedió.

Borrar el registro tampoco produce simultaneidad. Una caché recursiva puede responder hasta que expire el TTL. El borrador distingue de forma expresa ese TTL de la ventana de reutilización: uno limita una respuesta almacenada por DNS; la otra limita cuánto tiempo una CA puede apoyarse en datos ya validados. persistUntil puede poner un techo, pero reducirlo después o quitar el registro no acorta retroactivamente una autorización que la CA ya obtuvo.

Hay, por tanto, cuatro relojes: clave activa de la cuenta; publicación autoritativa y cachés DNS; vencimiento de la autorización ACME; y techo persistUntil capturado durante la validación. Un control que marque solo “clave rotada” o “registro ausente” describe el presente y puede ocultar la autoridad heredada del pasado.

La desactivación de la cuenta sí actúa de inmediato en todo su ámbito. La CA debe comprobar que la cuenta sigue válida antes de usar la vía persistente. Desactivarla vence la ventaja del historial de claves, aunque también paraliza todos los dominios asociados. Una respuesta a incidentes necesita conocer tanto el retiro específico del TXT como esta palanca amplia.

Por defecto, el dominio forma parte del hash. La opción domain_name=* permite reutilizar el mismo valor entre dominios para una cuenta y una clave. Reduce mantenimiento, pero amplía correlación y radio de daño. También obliga a registrar la cobertura exacta de identificadores y comodines que cada emisión aceptó.

CAA conserva su propio papel. El accounturi de RFC 8657 contiene la URL real de la cuenta; el TXT persistente incorpora esa URL dentro de un hash. Una coincidencia no sustituye el procesamiento de CAA, ni CAA demuestra la prueba persistente. Ambos resultados deben acompañar la orden.

DNSSEC puede autenticar la respuesta observada. El borrador recomienda validarlo cuando esté disponible y fallar si se intenta y la validación no pasa. RFC 4033 delimita esas garantías. No decide si una respuesta en caché sigue siendo deseada, ni si la cuenta debería continuar activa.

La preconfiguración puede delegarse. Tras un POST-as-GET autenticado que confirma una cuenta válida, un tercero puede recibir URL pública y huella para crear el TXT, sin acceso a la clave privada. La separación entre operador DNS y controlador ACME es segura solo si aprobación, instalación y retirada quedan atribuidas.

Los registros ACME de IANA aún no enumeran dns-persist-01. La votación SC-088v3 del CA/Browser Forum muestra apoyo sectorial a un método TXT persistente ligado a cuenta. No demuestra que este borrador esté desplegado ni que ambos contratos sean idénticos.

La pieza que falta es un recibo de vida completa: FQDN y alcance; hash, hora y vistas autoritativa y recursiva; TTL y horizonte de caché; emisor; uso de domain_name=*; identificador protegido de cuenta; generación actual o histórica que coincidió; estado vivo; CAA y DNSSEC; persistUntil; caducidad de autorización; orden y emisión que consumieron el resultado.

Con esa evidencia, una auditoría distingue rotación con coincidencia histórica, supresión con caché superviviente, ausencia de una validación nueva con reutilización legítima, o desactivación anterior a la emisión. Sin ella, se intenta explicar un certificado gobernado por el estado de ayer mirando únicamente el DNS de hoy.

La redacción puede cambiar antes de llegar a estándar. La conclusión de gobierno no depende de ese desenlace: persistir una autorización desplaza control desde una comprobación puntual hacia una historia custodiada. Rotar mantiene credenciales sanas. Revocar exige alcanzar la concesión que todavía conserva efecto.

Fuentes