Resumen

  • La revisión 05 del perfil Authority Token para JWTClaimConstraints trata la restricción DER como una cadena opaca para el cliente y el servidor ACME: se transporta y se coteja octeto por octeto, pero no se interpreta.
  • La Autoridad de Tokens evalúa el significado bajo las reglas del dominio. El ecosistema que despliega decide qué certificados de esas autoridades incorpora a la confianza del servidor.
  • token-authority solo orienta al cliente hacia un lugar donde obtener el token. El servidor no usa esa dirección para validar y exige un certificado x5u o x5c que ya esté configurado como confiable.
  • El documento sigue siendo un Internet-Draft en el grupo de trabajo. Superar sus pruebas no demuestra por sí solo identidad legal, veracidad de una llamada ni un derecho universal.

La revisión convierte una ambigüedad en reparto de responsabilidades

La revisión 05 se anunció el 5 de septiembre de 2026. Llegó tras una revisión del presidente de ACME que preguntó a quién iban dirigidas las normas y cómo debían interpretarse varios pasos. En su respuesta sobre los cambios, Chris Wendt señala aclaraciones sobre audiencia, confianza del emisor y función de token-authority.

El perfil está pensado para autoridades certificadoras de Secure Telephone Identity. Usa ACME para demostrar autoridad sobre una extensión JWTClaimConstraints, que limita las afirmaciones admitidas por una credencial. RFC 9448 define esa extensión, mientras RFC 8226 y RFC 9118 aportan las reglas de certificados y restricciones sobre las que trabaja la propuesta.

La versión 05 del texto asigna tres tareas. El cliente ACME presenta el identificador y consigue el token. El servidor comprueba la respuesta al desafío. La Autoridad de Tokens analiza antes si la restricción solicitada tiene sentido conforme a la política aplicable y firma la autorización.

Cliente y servidor no abren la restricción para inspeccionar sus elementos. Ven el valor DER, codificado en base64url, como una secuencia opaca. Lo llevan de un punto a otro y exigen igualdad exacta. La interpretación de mustInclude, permittedValues y mustExclude queda fuera de ACME y dentro de la evaluación semántica de la Autoridad de Tokens.

Esta renuncia es una virtud arquitectónica. RFC 8555 da a ACME reglas para automatizar certificados; no convierte al servidor de desafíos en el órgano que gobierna los derechos sobre restricciones telefónicas.

El lugar para conseguir un token no es la fuente de autoridad

El parámetro opcional token-authority es una pista para el cliente. Puede decirle dónde intentar adquirir el token, pero no ordena al servidor qué autoridad debe aceptar. La revisión aclara que el servidor ignora ese parámetro durante la validación.

El certificado del emisor aparece por x5u o x5c dentro del token. Uno de los dos debe estar presente. El servidor obtiene el certificado, verifica la firma y comprueba que su propia configuración lo reconozca como emisor de Authority Tokens para el ecosistema. La referencia permite encontrar una clave; no crea confianza por el mero hecho de existir.

El borrador deja a cada ecosistema sus anclas y sus requisitos para esos certificados, y menciona la gobernanza STIR como ejemplo. No prescribe una única institución mundial ni el procedimiento para admitir, limitar, suspender o retirar una delegación.

RFC 9447, ya publicado en Standards Track, partía de la misma realidad. Supone relaciones anteriores entre autoridad certificadora y Autoridad de Tokens, y entre cliente y Autoridad de Tokens. Si esas relaciones no pueden darse por sentadas, el desafío no resulta aplicable. El nuevo perfil modifica qué se autoriza, no de dónde nace la institución que autoriza.

El resultado técnico es fuerte y deliberadamente estrecho

El servidor revisa formato y tipo del token, verifica la firma, exige exp vigente y jti, y enlaza la respuesta con la clave de la cuenta ACME que abrió el pedido. También comprueba que el indicador ca coincida con la clase de certificado solicitada.

Después coteja exactamente el valor de restricción del token y el del identificador. Cualquier fallo coloca el desafío en invalid; el servidor debería acompañarlo con un documento de problema ACME, generalmente unauthorized. Así se evita reutilizar con facilidad un token para otra cuenta, otro pedido o una restricción distinta.

No obstante, una firma correcta solo identifica la clave firmante; exp solo aporta una frontera temporal; la igualdad solo conecta dos secuencias. Estas pruebas no cuentan quién incorporó al emisor a la lista confiable, qué política delimitó su competencia, por qué el juicio semántico fue correcto o dónde reclamarlo.

El registro de Datatracker continúa mostrando In WG Last Call y, en el IESG, I-D Exists. No figura document shepherd, Area Director responsable ni fecha de teleconferencia. Como la convocatoria previa anunció el 25 de julio como cierre, la etiqueta no permite afirmar que siga abierto el periodo de comentarios. La revisión puede cambiar y todavía no es un RFC, una implementación o un informe de despliegue.

La propuesta limita además cada pedido a un identificador JWTClaimConstraints y uno TNAuthList. Recomienda que la URL x5u del certificado emitido siga accesible mientras los terceros puedan necesitarla, habitualmente hasta su caducidad. Conservar el certificado facilita la comprobación futura, pero no conserva por sí mismo la causa política de su aceptación.

Hace falta un recibo mínimo de la decisión de confianza

El ecosistema podría emitir un recibo de autoridad de restricción que sea enlazable con la decisión ACME sin publicar números telefónicos ni el valor privado. Incluiría identificador y versión de política, identidad de la Autoridad de Tokens, huella del certificado confiable, familia de restricciones, clase de alcance delegado y un hash del pedido y la restricción.

También registraría momentos de emisión, decisión y vencimiento; resultado y clase acotada de error; vigencia o revocación de la entrada de confianza; y un contacto de corrección, incidente o apelación. Una advertencia aclararía que la validación no es un veredicto general sobre identidad legal, verdad del llamante o derechos fuera del ecosistema.

Ese recibo es una propuesta de Daniel Kade, no un requisito del IETF. Debería generarlo el sistema efectivo de políticas, no una bitácora manual decorativa. Su función es conservar quién controló la autorización sin exponer el contenido sensible que ACME trató como opaco.