Resumo

  • A revisão 05 do perfil Authority Token para JWTClaimConstraints trata a restrição DER como uma sequência opaca para cliente e servidor ACME: eles transportam e comparam octeto a octeto, sem interpretar o sentido.
  • A Autoridade de Tokens faz a validação semântica segundo as regras do domínio. O ecossistema que implanta decide quais certificados de emissores o servidor deve confiar.
  • O parâmetro opcional token-authority apenas orienta o cliente até um local de aquisição. O servidor o ignora ao validar e exige um certificado x5u ou x5c previamente aceito em sua configuração de confiança.
  • O texto continua sendo um Internet-Draft do grupo de trabalho. Passar nas verificações não prova identidade jurídica, veracidade da chamada nem competência universal do emissor.

A nova redação distribui o trabalho em três planos

A revisão 05 foi anunciada em 5 de setembro de 2026. Ela responde a uma análise do presidente do ACME sobre o público das exigências e pontos que poderiam gerar implementações diferentes. Na resposta sobre as alterações, Chris Wendt destaca as explicações sobre audiência, confiança no emissor e uso de token-authority.

O perfil se destina a autoridades certificadoras de Secure Telephone Identity. Por meio de ACME, ele busca provar autoridade sobre uma extensão JWTClaimConstraints, que restringe as alegações permitidas a uma credencial. A extensão vem do RFC 9448; o RFC 8226 e o RFC 9118 fornecem as regras de certificados e restrições que formam o contexto.

Na revisão 05, o cliente ACME apresenta o identificador e obtém o token. O servidor ACME verifica a resposta ao desafio. Antes disso, a Autoridade de Tokens decide se a restrição é admissível sob a política do domínio e assina a autorização.

Para cliente e servidor, o valor DER representado em base64url é apenas uma sequência de octetos. Eles o preservam e exigem igualdade exata entre identificador e token. Não abrem mustInclude, permittedValues ou mustExclude para julgar sua adequação. A decisão semântica pertence à Autoridade de Tokens.

Esse limite impede uma promoção silenciosa de competência. O RFC 8555 automatiza a gestão de certificados, mas não transforma o servidor ACME na instituição encarregada dos direitos sobre restrições ligadas à telefonia.

Descoberta para o cliente e confiança do servidor são caminhos distintos

token-authority pode sugerir ao cliente onde buscar o token. É uma indicação opcional de aquisição. A revisão 05 afirma que o servidor não usa esse parâmetro durante a validação do desafio.

O certificado do emissor aparece via x5u ou x5c no token; os dois não podem faltar. O servidor lê ou recupera o certificado, verifica a assinatura e confirma que sua configuração já o reconhece como emissor confiável de Authority Tokens naquele ecossistema. Uma referência localiza o material criptográfico, mas não concede autoridade.

As âncoras e os requisitos específicos para os certificados ficam com o ecossistema de implantação, tendo a governança STIR apenas como exemplo. O rascunho não define uma instituição global para admissão, delimitação, suspensão, revogação ou recurso.

O pressuposto também consta do RFC 9447, que já está em Standards Track. Ele parte de relações existentes entre CA e Autoridade de Tokens e entre cliente e Autoridade de Tokens. Onde elas não podem ser presumidas, o desafio não se aplica. O novo perfil amplia o tipo de restrição, sem criar a base institucional ausente.

O servidor produz uma prova mecânica forte, mas limitada

Depois de receber a lista confiável, o servidor verifica estrutura, tipo e assinatura do token. Exige exp ainda válido e jti, confere o vínculo com a chave da conta ACME que abriu o pedido e compara o indicador ca com o certificado solicitado.

Também exige igualdade exata entre o valor da restrição no token e no identificador. Uma falha torna o desafio invalid; o servidor deve, em geral, responder com um documento de problema ACME do tipo unauthorized. Isso dificulta o reaproveitamento do token em outra conta, formato de pedido ou sequência de restrição.

O alcance da conclusão não pode crescer por conveniência. exp fala de tempo, a assinatura fala da chave e a igualdade fala de representação. Nenhum desses testes informa quem confiou no emissor, que versão de política delimitava seu mandato, se a avaliação semântica estava correta ou como contestá-la.

O registro atual no Datatracker mostra o documento ativo e In WG Last Call, com estado IESG I-D Exists. Não há document shepherd, Area Director responsável nem data de telechat. A chamada anterior indicava encerramento em 25 de julho; a etiqueta atual não permite dizer que comentários continuam abertos. A revisão 05 ainda não é RFC, implantação ou resultado de interoperabilidade.

O texto limita cada pedido a um identificador JWTClaimConstraints e um TNAuthList. Recomenda ainda que o x5u do certificado emitido permaneça disponível enquanto as partes dependentes puderem precisar dele, normalmente até o vencimento. Isso preserva material para uma futura verificação, não a justificativa da confiança.

Um recibo de autoridade preservaria a decisão sem abrir os dados

O ecossistema pode gerar um recibo de autoridade da restrição ligado ao resultado ACME. Ele reuniria identificador e versão da política, identidade da Autoridade de Tokens, impressão digital do certificado confiável, família admitida, classe de escopo delegado e hash do pedido e da restrição.

Também guardaria momentos de emissão, decisão e expiração, resultado e classe limitada de erro, vigência ou revogação da entrada de confiança e contato para correção, incidente ou recurso. Uma ressalva diria que a validação técnica não julga identidade legal, verdade da chamada ou direito fora do ecossistema nomeado.

Esse recibo é uma proposta editorial de Daniel Kade, não uma exigência do IETF. Deve sair do sistema que realmente aplica a política, em vez de depender de cópia manual. Não há necessidade de publicar números ou o conteúdo bruto da restrição: o objetivo é tornar identificável a autoridade que entrou no processo.