Resumo

  • Em 6 de setembro, o Working Group JOSE enviou ao IESG a revisão 05 do rascunho que depreca none e RSA1_5. “Publication Requested” ainda não é aprovação, RFC nem alteração concluída no registro da IANA.
  • A proposta desativa os dois algoritmos por padrão e os exclui de novas especificações, mas permite habilitação para objetos ou operações específicos. Essa liberdade local só é controlável se a exceção tiver responsável, evidência de uso e prazo.

A regra ainda está atravessando o processo

O histórico do Datatracker marca uma mudança real em 6 de setembro de 2026. O documento passou a “Submitted to IESG for Publication”, o estado IESG virou “Publication Requested” e Deb Cooley assumiu como Area Director responsável. A mesma data recebeu o document shepherd write-up.

Isso não encerra o processo. A revisão 05, de 23 de junho, continua sendo um Internet-Draft. O IESG pode pedir mudanças e a IANA ainda não executou as instruções propostas. No corte da pesquisa, o registro JOSE mostrava none como Optional e RSA1_5 como Recommended-. A diferença entre o texto pretendido e a linha atual é estado de processo, não recusa.

Se aprovado, o rascunho atualizaria o RFC 7518 com quatro comandos distribuídos. Desenvolvedores de bibliotecas JOSE DEVERIAM depreciar o suporte. Desenvolvedores de aplicações DEVEM desativá-lo por padrão. Uma aplicação com necessidade específica PODE reabilitar um algoritmo somente para os objetos ou operações que exigem isso, nunca de forma global. Novas especificações baseadas em JOSE NÃO DEVEM permitir nenhum dos dois.

O documento escolhe Deprecated, não Prohibited. Aplicações e especificações existentes ainda podem usar esses identificadores enquanto são incentivadas a adotar alternativas. Também deixa claro que RS256, RS384 e RS512 não mudam: esses são algoritmos de assinatura; RSA1_5 é o gerenciamento de chave RSAES-PKCS1-v1_5 de JWE.

Logo, “o algoritmo foi banido” não descreve a proposta. Registro, biblioteca, configuração e transação são superfícies independentes. Uma pode mudar sem que as outras tenham mudado.

Segurança forte, compatibilidade concreta

none produz um JWS sem assinatura ou MAC. O RFC 7518 já proibia sua aceitação padrão, mas o rascunho aponta várias vulnerabilidades em implementações que o aceitaram por engano. RSA1_5 usa criptografia RSA com padding PKCS #1 v1.5, associada a ataques conhecidos desde Bleichenbacher em 1998. O texto cita OAEP e opções de curva elíptica como substitutos e usa a orientação federal do NIST como parte do contexto.

O legado também tem uma história documentada. OpenID Connect Core prevê casos de ID Tokens não assinados protegidos no transporte por TLS e request objects não assinados. Segundo o shepherd, a discussão em IETF 124 foi seguida por uma chamada de consenso de duas semanas em fevereiro de 2026. A solução reconheceu esses usos históricos sem abandonar a depreciação.

O Working Group Last Call, estendido para colher mais opiniões, teve apoio e nenhuma oposição, relata o shepherd. Uma enquete em IETF 126 registrou 27 a favor da publicação, zero contra e oito sem opinião. É suporte suficiente para a decisão de encaminhar. Não mede a base instalada nem as dependências locais.

O registro central não é o inventário da aplicação

A IANA consegue publicar a semântica do identificador, sua referência e recomendação. O rascunho também acrescenta testes mínimos para futuros registros: EUF-CMA em algoritmos de assinatura e MAC para JWS, IND-CCA2 no processo JWE completo ao avaliar gerenciamento de chave e AEAD em criptografia de conteúdo. Inscrições feitas como Deprecated ou Prohibited ficam fora desses novos testes.

A IANA não consegue observar um serviço que ligou none para um tipo legado de objeto, nem o parceiro que ainda exige RSA1_5. O texto não cria telemetria, banco de exceções ou protocolo de migração. O shepherd é explícito: não há novo mecanismo de protocolo a implementar.

Manter esse dado fora da IANA é correto. Um registro interoperável não deve acumular nomes de aplicações privadas, objetos protegidos ou parceiros comerciais. Mas a decisão local precisa produzir prova local.

Um registro de exceção deveria conter o algoritmo exato, uso JWS ou JWE, objeto ou operação permitidos, serviço, dono, dependência bloqueadora, controles compensatórios, teste de que a opção global permanece desligada, primeiro e último uso observados, destino de migração, data de revisão e vencimento. Essa é uma proposta editorial, não uma obrigação do rascunho, RFC 7518, IANA, NIST ou OpenID Connect.

Duas contagens regressivas

O relógio público acompanha Area Director, IETF Last Call, avaliação do IESG, eventual RFC e posterior atualização da IANA. A página-resumo do Datatracker ainda mostra intenção de Internet Standard, enquanto o shepherd pede Proposed Standard e chama a primeira metadata de incorreta. É uma divergência documental a resolver, não status final.

O relógio local nasce quando a aplicação reabre deliberadamente o caminho. Sem vencimento, a necessidade específica continua depois da dependência. Sem último uso, o time não sabe se preserva interoperabilidade real ou superstição operacional. Sem dono, qualquer atualização de biblioteca força uma escolha tardia entre indisponibilidade e permissão ampla.

A especificação inicial mínima de Heng Lu oferece a arquitetura certa: a camada comum define o padrão seguro e o limite das novas especificações; decisões futuras ficam locais. A primazia do código em execução define a prova: publicação altera o livro de regras, enquanto configuração e transações observadas mostram o que roda.

O rascunho acerta ao preservar essa divisão. Para fazê-la funcionar, cada exceção local deve ser nomeada, estreita, observada e finita.

Fontes

  1. IETF Datatracker — depreciação de none e RSA1_5
  2. Histórico e document shepherd write-up
  3. Internet-Draft, revisão 05
  4. RFC 7518 — JSON Web Algorithms
  5. IANA — registro JOSE
  6. RFC 5116 — criptografia autenticada
  7. RFC 8017 — PKCS #1 versão 2.2
  8. NIST SP 800-131A, revisão 2
  9. OpenID Connect Core 1.0
  10. Repositório-fonte do rascunho
  11. Heng Lu — Minimum Initial Specification
  12. Heng Lu — Running-Code Primacy