Resumen

  • La revisión 01 de un borrador individual de ACME elimina el perfil estricto de la revisión 00, que exigía firmas poscuánticas o híbridas para el servidor TLS y la solicitud JWS y rechazaba el retorno a la autenticación exclusivamente tradicional.
  • El nuevo texto propone que un servidor pueda prescindir de ES256, hoy obligatorio según RFC 8555 §6.2. Si mantiene ES256, puede aceptar firmas JWS tradicionales durante un periodo de transición que él mismo elija.

El certificado nace donde se acepta la firma

Una empresa instala un cliente ACME para renovar certificados sin intervención humana. Cambia el intercambio de claves de la conexión por uno poscuántico o híbrido y cree haber terminado. Pero la orden de emisión viaja firmada con la clave de su cuenta. Si el servidor acepta todavía una firma tradicional falsificable en el escenario que preocupa al borrador, la modernización del túnel no decide quién puede pedir el certificado. Esa decisión está en el verificador de JWS.

La versión de junio separaba un perfil estricto: tanto la identidad del servidor TLS como la petición del cliente debían usar firmas poscuánticas o híbridas, sin salida hacia algoritmos tradicionales solos. La versión de octubre suprime esa sección. Conserva un mecanismo cuyo canal TLS usa intercambio de claves poscuántico o híbrido y que admite autenticación nueva, pero permite firmas tradicionales durante una transición expresamente limitada. El documento deja la selección del mecanismo a la política de despliegue.

También cambió el catálogo obligatorio. Junio enumeraba variantes ML-DSA y una firma compuesta que los servidores del perfil debían implementar; ES256 seguía siendo requisito. Octubre dice que el servidor puede admitir cualquier algoritmo JWS registrado y que no impone uno concreto. Incluso propone retirar la obligación de ES256 de RFC 8555. Quien lo conserve puede seguir admitiendo solicitudes tradicionales durante el plazo que defina. Dos autoridades de certificación podrían llamar «preparado» al mismo mecanismo y tratar la misma firma de manera opuesta.

Hay una frase incómoda dentro de la propia revisión. La introducción habla de firmas poscuánticas e híbridas obligatorias de implementar; el apartado 4.2 utiliza «MAY» y declara que no prescribe ningún algoritmo JWS específico. No es una minucia editorial para quien tenga que escribir pruebas de interoperabilidad. El texto necesita resolver qué debe aceptar un servidor y qué puede rechazar.

La ficha oficial identifica una propuesta individual, actualizada el 28 de octubre, sin aprobación de estándar. No presenta instalaciones ni una fecha universal de retirada. La prueba decisiva sería publicar una política concreta y demostrar con peticiones reales cuándo un servidor acepta firmas nuevas y cuándo rechaza las tradicionales.

Fuentes: revisión de octubre; revisión de junio; RFC 8555; estado IETF.