Resumo

  • Se crit citar uma extensão que o verificador não entende e suporta, a JWS é inválida mesmo quando a operação de assinatura confere.
  • A lista cria uma barreira de compatibilidade: implementações antigas não podem ignorar uma mudança semântica obrigatória e continuar sob as regras anteriores.
  • Resultado criptográfico, processamento JOSE e decisão da aplicação são veredictos independentes e precisam permanecer identificáveis.

O êxito que não autoriza prosseguir

Um serviço recebe uma JWS, localiza a chave, reconstrói a entrada assinada e confirma a assinatura. Esse é um resultado importante. Mas o cabeçalho protegido contém uma extensão desconhecida cujo nome também aparece em crit. O serviço sabe que o envelope é íntegro e, ao mesmo tempo, não sabe interpretar uma regra que o emissor declarou indispensável.

A RFC 7515 manda rejeitar. Não há licença para apagar a extensão, manter o sinal verde da criptografia e executar o comportamento conhecido. A assinatura responde por determinados bytes e uma chave. Ela não responde se o receptor aplicou o significado correto a todos os campos cobertos.

O valor de crit é um array de nomes de parâmetros de extensão presentes no cabeçalho JOSE. Cada nome tem de ser compreendido e suportado. A lista não pode ser vazia, repetir nomes nem apontar para um parâmetro ausente. Também não é um lugar para reenunciar parâmetros já definidos por JWS ou JWA. Sua função é marcar dependências semânticas introduzidas por extensões.

O próprio crit só pode ficar no cabeçalho protegido. Se a declaração do que é obrigatório pudesse ser alterada fora da assinatura, um intermediário retiraria um nome e induziria um verificador antigo a aceitar a mensagem. Já parâmetros desconhecidos e não críticos podem normalmente ser ignorados. É essa diferença que conserva extensibilidade sem sacrificar o sentido.

Uma regra para ecossistemas que não atualizam juntos

Nat Sakimura é um dos três autores identificados na RFC 7515, com Michael B. Jones e John Bradley. Sua trajetória nos padrões de identidade e na liderança da OpenID Foundation ajuda a iluminar o problema, embora o desenho deva ser atribuído corretamente ao trabalho conjunto: formatos de identidade atravessam fornecedores e sobrevivem a várias gerações de software.

Uma extensão não pode esperar que todos os consumidores sejam atualizados no mesmo instante. Mas uma mudança que altera a interpretação também não pode ser oferecida a quem a tratará como metadado descartável. crit distribui a responsabilidade. Quem produz declara a capacidade necessária; quem recebe comprova essa capacidade ao processar a extensão ou encerra a validação.

“Crítico” aqui não é sinônimo de secreto, perigoso ou prioritário. Um campo de grande interesse comercial pode ser apenas informativo. Um pequeno indicador de codificação pode mudar a sequência exata de bytes assinada. O teste é saber se ignorar a extensão mantém o mesmo significado e a mesma propriedade de segurança.

A ordem de validação descrita na RFC 7515 reflete essa pluralidade. O receptor examina a codificação do cabeçalho protegido, verifica campos e valores exigidos, constrói a entrada de assinatura e executa a operação criptográfica. Uma biblioteca que expõe somente um booleano chamado valid pode esconder qual dessas condições foi realmente satisfeita.

A prova concreta de b64:false

A RFC 7797 introduz a opção de payload não codificado. No comportamento comum de JWS, o payload entra na construção assinada em base64url. Quando o parâmetro protegido b64 vale false, o payload é usado sem essa codificação. Isso altera a entrada da assinatura e afeta as condições de algumas serializações.

Por isso, uma JWS com b64:false deve incluir b64 em crit. Um verificador que conheça o formato original, mas desconheça a extensão, encontrará um nome crítico não suportado e rejeitará o objeto. Não tentará impor a construção usual a bytes que seguem outra regra. O fracasso fechado evita uma falsa concordância entre duas interpretações.

Mesmo um receptor que implemente a extensão ainda enfrenta a política do perfil. A RFC recomenda consistência na escolha da codificação dentro de um uso, e certos payloads exigem cuidado na serialização compacta. Mais decisivo: JWT não pode utilizar b64:false. Uma biblioteca JWS genérica pode verificar o recurso com perfeição, enquanto a aplicação JWT deve recusá-lo.

Surgem três perguntas que não devem compartilhar a resposta. A assinatura confere sobre a entrada construída? Toda extensão crítica foi entendida e aplicada? Aquele tipo de mensagem admite a combinação naquele contexto? O primeiro “sim” não decide os demais.

Capacidade algorítmica não é política criptográfica

A RFC 7518 reúne os algoritmos e identificadores empregados por JOSE. Reconhecer um algoritmo ou possuir código para executá-lo não significa aceitá-lo em toda aplicação. A RFC 7515 deixa a seleção de algoritmos aceitáveis para cada contexto. Uma assinatura correta pode ser recusada porque o algoritmo, a chave ou os parâmetros não pertencem à política local.

A RFC 8725 transforma essa distinção em orientação para JWT. O sistema deve restringir algoritmos permitidos e não deixar que a entrada controlada pelo remetente escolha sozinha o método de verificação. Deve conferir emissor, sujeito, público e outras regras do perfil. Tipos de JWT destinados a usos diferentes podem exigir regras mutuamente exclusivas, impedindo que um token salte de um contexto para outro.

crit não atesta a confiança no emissor, não confirma o público e não concede acesso a uma operação. Também não aprova automaticamente uma extensão só porque o software conhece seu nome. Entender é uma condição anterior ao julgamento, não o próprio julgamento.

Várias assinaturas exigem saber qual venceu

A serialização JSON de JWS comporta múltiplas assinaturas. Na descrição geral da RFC 7515, pelo menos uma precisa ser válida, mas cabe à aplicação escolher uma condição mais estrita. Cada assinatura pode ter seu próprio cabeçalho protegido e, portanto, sua própria lista de extensões críticas.

Esse detalhe se torna importante em migrações. Uma assinatura nova pode introduzir algoritmo ou semântica mais moderna, enquanto outra mantém compatibilidade. Se a regra “qualquer uma basta” não tiver prazo, a assinatura antiga vira uma rota permanente de rebaixamento. Se a organização exigir todas de imediato, consumidores legítimos que ainda não entendem a extensão ficam indisponíveis.

É preciso definir assinaturas exigidas, chaves, extensões, públicos, período de convivência e condição de retirada. O registro de validação deve indicar qual caminho satisfez a política. Um sucesso agregado não mostra se a migração funciona ou se todo o tráfego continua dependente da exceção antiga.

Três registros para três responsabilidades

O plano criptográfico registra algoritmo, referência de chave, construção da entrada e resultado da assinatura. O plano JOSE registra o cabeçalho protegido, nomes críticos observados, componente que processou cada extensão e falhas de compreensão. O plano da aplicação registra perfil, emissor, público, restrições de claims, decisão de autorização e ação solicitada.

Não é necessário expor segredo ou token integral. Identificadores de correlação e motivos específicos já evitam diagnósticos falsos. Dizer “assinatura inválida” quando a assinatura bateu, mas a extensão não era suportada, manda a equipe procurar uma chave errada. Dizer “token válido” quando a política de público negou o uso esconde a decisão que realmente protegeu o sistema.

O mérito institucional de crit é obrigar honestidade sobre conhecimento. Um receptor não pode alegar que compreendeu uma mensagem só porque autenticou seu contêiner. A regra associada a Sakimura e seus coautores transforma “não sei processar isto” numa resposta válida e necessária do protocolo.

Fontes