Resumo

  • A revisão 06 propõe classificar JWS none e JWE RSA1_5 como Deprecated, não Prohibited: aplicações devem desativá-los por padrão, mas podem abrir exceções apenas para objetos ou operações específicos.
  • Em 29 de setembro de 2026, o registro JOSE da IANA ainda não refletia a proposta; uma futura mudança de rótulo tampouco provará que uma capacidade foi removida da biblioteca ou que uma requisição concreta foi recusada.
  • Um recibo de retirada precisa ligar o objeto e a operação ao alg e ao enc, à lista de permissão efetiva, à capacidade compilada, ao responsável e vencimento da exceção, ao resultado e à autoridade concedida.

Imagine duas telas abertas durante um incidente. A primeira mostra o registro público com a palavra “Deprecated”. A segunda mostra um gateway aceitando o token de um parceiro porque uma exceção de compatibilidade continua ativa. As duas telas podem estar corretas ao mesmo tempo. É justamente esse intervalo que uma governança séria precisa administrar.

A revisão 06 de “JOSE: Deprecate 'none' and 'RSA1_5'” foi publicada em 25 de setembro de 2026. O registro no Datatracker mostra um Internet-Draft em Last Call da IETF até 9 de outubro, ainda sujeito a revisão da IANA. O histórico do documento registra a evolução normativa; não é um inventário de implantações.

Os dois identificadores não representam o mesmo risco técnico. No JWS, none cria um objeto sem assinatura e sem MAC. O RFC 7515 define o formato JWS, e o RFC 7518 já determinava que implementações não aceitassem JWS desprotegido por padrão. Quando o alg fornecido pelo próprio emissor escolhe o caminho de verificação, uma declaração não confiável pode desligar a autenticação.

No JWE, RSA1_5 identifica o mecanismo de gestão de chaves RSAES-PKCS1-v1_5 dentro do modelo do RFC 7516. Não é o mesmo que RS256, RS384 ou RS512, que são algoritmos de assinatura JWS. Uma regra que bloqueie qualquer nome contendo “RSA” pode interromper fluxos legítimos e ainda deixar a rota vulnerável intacta. O RFC 8017 descreve os esquemas RSA; a orientação atual do CFRG reforça que tratamento uniforme de falhas e resistência a oráculos dependem da implementação.

O texto proposto distribui responsabilidades com precisão. Desenvolvedores de bibliotecas deveriam tornar o suporte obsoleto. Desenvolvedores de aplicações devem desativar as duas escolhas por padrão. Uma necessidade específica pode justificar a ativação para determinados objetos ou operações, nunca de modo global. Novas especificações baseadas em JOSE não devem permitir nenhuma das duas.

Isso preserva uma ponte de migração, não declara uma remoção. O pedido à IANA é por Deprecated, não Prohibited. Na captura desta análise, o registro JOSE da IANA ainda apresentava none como Optional e RSA1_5 como Recommended-. Se o registro mudar, o metadado compartilhado mudará; configurações de locatários, gateways, SDKs, módulos criptográficos e arquivos de exceção continuarão precisando de ação local.

A prova operacional deve acompanhar a decisão inteira. Para cada tentativa, registre a classe do objeto JOSE e a operação de negócio; o alg protegido e, no JWE, o enc; emissor, audiência, locatário e rota; a lista de permissão depois que esses seletores forem resolvidos; a versão da biblioteca e as capacidades realmente compiladas; origem, aprovador, escopo e vencimento de qualquer exceção; tipo de chave; aceitação ou rejeição final; e qual identidade ou ação ganhou autoridade com o resultado.

Nos fluxos JWE, registre também a forma da falha. Diferenças de mensagem, tamanho ou tempo podem transformar um endpoint em oráculo mesmo quando um painel diz que RSA1_5 é excepcional. O NIST SP 800-131A, revisão 2 oferece contexto de transição, mas não comprova que um serviço local uniformizou seus erros.

O RFC 8725 recomenda verificação explícita do algoritmo em JWT e rejeita a dependência de escolhas controladas pelo atacante. Em termos práticos, o cabeçalho apresenta uma solicitação de processamento; ele não autoriza escolher o verificador. A autoridade vem da lista efetiva da aplicação.

O rascunho também propõe critérios para futuras entradas. Assinaturas e MACs JWS devem alcançar EUF-CMA; o processo completo de criptografia JWE deve alcançar IND-CCA2; a criptografia de conteúdo deve oferecer AEAD conforme o RFC 5116. São critérios úteis de avaliação, não resultados de teste para uma versão implantada nem proteção contra erros de composição de chaves, análise e política.

A primazia do código em execução de Heng Lu coloca o evento de aceitação acima do rótulo de inventário. As camadas da realidade separam o símbolo “obsoleto” do fato operacional de uma mensagem obter autoridade. A especificação inicial mínima permite que a regra comum estabeleça o padrão seguro, sem retirar do sistema local a responsabilidade por cada exceção.

A retirada só termina quando todos os caminhos relevantes recusam por padrão e cada “sim” restante é específico, atribuído, medido e temporário. Antes disso, Deprecated é uma placa na entrada, não um recibo emitido no ponto de decisão.

Fontes