Resumo

  • O token-authority opcional serve para o cliente descobrir onde obter o token. O servidor só confia no emissor conforme a política configurada para o ecossistema e o certificado apresentado por x5u ou x5c.
  • O servidor ACME transporta JWTClaimConstraints como uma cadeia opaca e compara o valor do pedido original com tkvalue octeto por octeto, sem decodificar, recodificar ou normalizar.
  • A autorização reúne recibos independentes de emissor, assinatura, tipo, bytes, exp, jti, chave da conta ACME e papel CA da CSR. Emissão bem-sucedida ainda não prova verificação JWS posterior nem resultado telefônico.

O endereço orienta o cliente, não governa o servidor

O desafio tkauth-01 pode trazer uma URL token-authority. Quando ela existe, o cliente ACME pode usá-la para localizar a autoridade que fornecerá o JWTClaimConstraints Authority Token. Sem esse campo, espera-se que o cliente conheça a localização por configuração fora de banda.

A revisão 05 afirma explicitamente que o servidor ACME não usa a URL para validar a resposta. A informação que facilita a descoberta do cliente não inclui o signatário no conjunto confiável do servidor.

Essa decisão ocorre em outro plano. O Authority Token precisa ser assinado por um certificado que o servidor esteja configurado para reconhecer como emissor no ecossistema. Um x5u HTTPS pode referenciar o certificado; x5c pode carregar a cadeia. Se nenhum existir, ou se o certificado não tiver a função confiável configurada, a validação falha. O claim opcional iss pode declarar um nome, mas não transforma autodeclaração em confiança.

Separar os planos permite mover um endpoint de descoberta por disponibilidade sem alargar a autoridade. Também permite retirar um emissor sem fingir que a rota do cliente mudou. Uma única configuração para ambos faria uma alteração operacional de URL assumir efeito silencioso sobre autorização.

O significado fica com quem possui o contexto

O identificador JWTClaimConstraints da nova ordem contém base64url sem padding de um objeto ASN.1 JWTClaimConstraints ou EnhancedJWTClaimConstraints codificado em DER. O token devolve o mesmo valor em atc.tkvalue.

O conteúdo interno define restrições de claims no ecossistema STIR. Token Authority avalia se o solicitante pode representar esses recursos e claims segundo as RFCs 8226 e 9118. O servidor ACME não repete essa decisão. Para ele e para o cliente, a cadeia é opaca.

A tarefa do servidor é provar que o valor autorizado semanticamente foi exatamente o valor solicitado no pedido original. O contrato compartilhado permanece mínimo: formato canônico, igualdade direta e ligações explícitas com emissor, assinatura, tempo, conta e função. A política STIR continua localizada no ator que possui os dados para exercê-la.

Não negociar equivalência dentro da autorização

DER e base64url sem padding definem uma representação única. A comparação ocorre diretamente entre as duas cadeias recebidas. O servidor não pode decodificar e recodificar, canonizar, normalizar ou transformar qualquer lado antes do teste.

Padding =, caracteres fora do alfabeto base64url, espaço, alfabeto alternativo, BER não DER ou qualquer octeto divergente produzem falha. O texto também recomenda comparação em tempo constante, embora os valores não sejam secretos.

Cada transformação permissiva cria um árbitro adicional sobre quais diferenças “não importam”. Esse comportamento pode mudar com linguagem, biblioteca e versão. A igualdade exata retira a equivalência do caminho de autorização e oferece evidência simples: hash seguro e comprimento das cadeias originais, validação do alfabeto e resultado da comparação.

Oito comprovantes por trás de um resultado

Primeiro, atc deve conter tktype, tkvalue e fingerprint. Segundo, o certificado do signatário deve ser um emissor configurado. Terceiro, a assinatura deve validar. Quarto, o tipo deve ser JWTClaimConstraints. Quinto, tkvalue deve ser idêntico ao valor retido do pedido original.

Sexto, exp precisa existir e continuar válido segundo o relógio do servidor e a pequena tolerância local; jti também precisa existir. Sétimo, fingerprint deve corresponder à chave da conta ACME que apresentou a resposta. Oitavo, ca deve concordar com o booleano CA de Basic Constraints na CSR.

Token Authority não usa a impressão digital para provar o controle da conta. Ela a assina no token para que o servidor ACME faça essa associação depois. A autorização semântica e o controle da conta vêm de verificadores diferentes.

Qualquer falha torna o desafio inválido e pode gerar erro de autorização ACME. Uma métrica única de “token inválido” apaga o mecanismo: emissor, busca do certificado, assinatura, identidade, relógio, transação, conta ou papel CA.

A disponibilidade que começa após a emissão

Autorizar não é emitir. Depois, a CA pode incluir um x5u opcional na resposta de ordem bem-sucedida para que o titular referencie o certificado emitido em objetos JWS. A URL deve continuar recuperável enquanto partes verificadoras precisarem dela, em geral pelo menos até o certificado expirar.

Esse x5u posterior não é o mesmo que apresentou o certificado do emissor do Authority Token. As referências pertencem a fases e obrigações de vida útil distintas. A emissão não demonstra que um verificador futuro encontrará o certificado, confiará nele ou aceitará qualquer afirmação de chamada.

Limites desta leitura

A revisão 05 foi publicada em 5 de setembro de 2026 como Internet-Draft de grupo de trabalho e expira em 9 de março de 2027 se não for atualizada. Ainda pode mudar e não é RFC. Nenhum cliente, servidor, CA, Token Authority, runtime, repositório, operadora ou caminho de chamada foi testado.

As fontes não comprovam adoção, conformidade, interoperabilidade, emissão, autoridade sobre números, autenticação de chamadas ou redução de fraude. Elas descrevem um contrato proposto, não sua execução.

Fontes