Resumen

  • token-authority es una pista opcional para que el cliente descubra una ubicación. La confianza del servidor nace de una relación configurada con el certificado emisor presentado mediante x5u o x5c.
  • El servidor ACME no interpreta JWTClaimConstraints: compara directamente y octeto por octeto el valor del pedido original con tkvalue, sin decodificar, volver a codificar ni normalizar.
  • La luz verde exige recibos separados de emisor, firma, tipo, identidad exacta, exp, jti, clave de cuenta y función CA de la CSR. Ni siquiera entonces queda demostrada una verificación JWS posterior o el resultado de una llamada.

El mapa no concede autoridad

El parámetro token-authority puede aparecer en el desafío tkauth-01. Si aparece, el cliente ACME puede usar su URL para localizar el servicio que expedirá el token JWTClaimConstraints. Si no aparece, el cliente debe disponer de una ubicación configurada fuera del protocolo.

Hasta ahí llega el poder del campo. La revisión 05 afirma que el servidor ACME no lo utiliza al validar la respuesta. Una dirección suministrada para facilitar el viaje del cliente no incorpora al firmante en el conjunto de confianza del servidor.

La confianza sigue otro recorrido. El token debe estar firmado por un certificado que el servidor tenga configurado como emisor de Authority Tokens para ese ecosistema. El material puede ser referenciado por un x5u HTTPS o presentado en x5c. La ausencia de ambos, un fallo de recuperación o un certificado no autorizado para ese papel obliga a fallar. iss puede nombrar al emisor, pero una afirmación dentro del propio token no sustituye la decisión local de confianza.

Separar descubrimiento y confianza permite cambiar una ubicación por razones operativas sin ampliar autoridades. También permite revocar o añadir un emisor sin fingir que la topología del cliente ha cambiado. Un único selector para ambos convertiría una edición de servicio en una decisión de seguridad invisible.

Semántica en Token Authority, identidad en ACME

El identificador de la nueva orden lleva el base64url sin relleno de un objeto JWTClaimConstraints o EnhancedJWTClaimConstraints codificado en DER. El Authority Token inserta el mismo valor en atc.tkvalue y declara JWTClaimConstraints como tipo.

Para Token Authority, el objeto expresa límites de afirmaciones dentro del ecosistema STIR. Esa autoridad verifica que las restricciones concuerdan con los recursos y claims que el solicitante puede representar bajo las RFC 8226 y 9118. El servidor ACME no repite ese análisis ASN.1.

Su obligación es distinta: demostrar que el valor semánticamente autorizado es exactamente el valor solicitado. La revisión 05 lo describe como una cadena opaca para cliente y servidor. Así se conserva un contrato mínimo común sin trasladar política STIR a un componente que no posee el contexto para decidirla.

Un byte distinto es una identidad distinta

DER y base64url sin relleno definen una sola forma canónica. El servidor compara las cadenas tal como llegaron. No debe decodificarlas, recodificarlas, canonizarlas, normalizarlas ni aplicar otra transformación previa.

Relleno =, caracteres fuera del alfabeto base64url, espacios, alfabetos alternativos, BER que no sea DER o cualquier octeto diferente invalidan la comparación. El borrador recomienda tiempo constante aunque los valores no sean secretos.

La rigidez reduce superficie de autorización. Un decodificador permisivo introduce su propia regla sobre qué diferencias considera equivalentes. Esa regla puede variar entre lenguajes y versiones. Al exigir identidad directa, el servidor puede mostrar un recibo reproducible con la longitud y el hash seguro de cada cadena, además del resultado exacto.

La validación tiene ocho causas posibles

Primero, atc debe ser un objeto bien formado con tktype, tkvalue y fingerprint. Segundo, el certificado firmante debe pertenecer al conjunto de emisores configurados. Tercero, la firma debe verificar. Cuarto, el tipo debe ser JWTClaimConstraints. Quinto, tkvalue debe coincidir con el identificador guardado del pedido original.

Sexto, exp debe existir y seguir vigente según el reloj del servidor y una pequeña tolerancia local; jti también debe existir. Séptimo, fingerprint debe corresponder a la clave de la cuenta ACME que presenta la respuesta. Octavo, ca debe corresponder al booleano CA de Basic Constraints en la CSR.

Token Authority no emplea la huella para verificar el control de la cuenta. La firma dentro del token para que el servidor ACME haga más tarde esa unión. La autoridad semántica y el verificador de la cuenta aportan pruebas diferentes a una misma decisión.

Si falla una etapa, el desafío queda inválido y puede aparecer un error de autorización ACME. Contabilizarlo todo como “token inválido” impide distinguir una confianza mal configurada de un byte cambiado, un reloj adelantado, una cuenta sustituida o una CSR con función contradictoria.

La obligación que comienza después de emitir

Una autorización correcta todavía no es un certificado. Tras la emisión, el borrador permite que la CA añada un x5u opcional a la respuesta de orden exitosa. El titular puede referenciar ese certificado en objetos JWS posteriores. La CA debería mantener la URL recuperable mientras las partes verificadoras la necesiten, normalmente al menos hasta que expire el certificado.

No debe confundirse ese x5u con el que permitió verificar al emisor del Authority Token. Uno participa en la autorización previa; el otro sostiene verificaciones posteriores. Un registro de emisión no prueba que el segundo enlace siga vivo ni que un tercero acepte el certificado o una afirmación telefónica.

Estado y límites

La revisión 05 se publicó el 5 de septiembre de 2026 como Internet-Draft de grupo de trabajo y caduca el 9 de marzo de 2027 salvo actualización. Puede cambiar y no es un RFC. Este análisis no probó clientes, servidores, autoridades, CA, repositorios, operadores ni flujos de llamadas.

Las fuentes no demuestran adopción, conformidad, emisión, autoridad sobre números, autenticación de llamadas ni reducción de fraude. Describen una propuesta normativa; la realidad operativa solo aparecerá en recibos de ejecución e interoperabilidad.

Fuentes