Resumo

  • O draft-ietf-lamps-rfc6211-update-01 troca o OID 1.2.840.113549.1.9.52, impresso na RFC 6211, por 1.2.840.113549.1.9.16.2.52, que sempre constou no registro da IANA para id-aa-cmsAlgorithmProtect.
  • Uma política segura não resume a transição a “aceitar os dois”. Ela distingue reconhecimento, validade para a política, nova emissão, preservação de objetos assinados e o momento comprovado de encerrar a compatibilidade.

A divergência nasceu dentro do material oficial

O registro da IANA para atributos S/MIME tem como raiz 1.2.840.113549.1.9.16.2. A entrada 52 identifica id-aa-cmsAlgorithmProtect. A RFC 6211, publicada em 2011, suprimiu os arcos 16.2 em sua definição e no módulo ASN.1, chegando a 1.2.840.113549.1.9.52.

Não são duas maneiras de escrever a mesma coisa. São identificadores diferentes. O novo rascunho relata que dois implementadores escolheram fontes diferentes e seus sistemas não interoperaram. A evidência publicada não diz quantos produtos foram afetados, nem registra ataque ou perda. O caso comprovado é menor e suficiente: uma inconsistência entre duas superfícies oficiais produziu uma divisão real.

Copiar um módulo ASN.1 fornecido por uma RFC é uma conduta normal. Conferir um número na IANA também é. Quando essas rotas legítimas terminam em codificações distintas, a resposta não pode ser apenas pedir mais atenção ao programador. O sistema de publicação precisa tratar texto, registro e artefato executável como partes da mesma entrega.

O controle de segurança precisa de um identificador comum

CMS é a sintaxe usada para conteúdos assinados, autenticados ou cifrados. A RFC 6211 criou um atributo para proteger os identificadores dos algoritmos utilizados no processamento. O propósito é dificultar a substituição de algoritmo ou parâmetro por um atacante antes da validação.

Mas o validador só consegue aplicar a proteção se reconhecer o atributo. Quando o produtor usa um OID e o consumidor procura outro, eles podem discordar sobre a própria presença do controle. A seção de segurança do rascunho é clara: a proteção não funciona corretamente sem o mesmo OID ASN.1 entre implementações.

Isso não autoriza declarar vulnerabilidade em qualquer produto. Um parser pode rejeitar a mensagem, ignorar o atributo desconhecido ou aplicar regras adicionais. A afirmação responsável é que o nome codificado do controle faz parte da sua eficácia. Sua divergência exige teste, e não suposição.

O apêndice entrou na cadeia de produção

Um leitor de política enxerga prosa. Uma equipe de engenharia enxerga um módulo que pode ser compilado. Um gerador transforma esse módulo em tipos e constantes; testes cristalizam os bytes; dependências levam o resultado a produtos que sobreviverão a várias revisões documentais.

A IANA detinha a autoridade de alocação. A RFC detinha autoridade normativa. O módulo possuía uma força operacional própria porque podia alimentar automação. O registro correto não alcançou todos os consumidores da mesma forma que o módulo incorreto.

A revisão 01 também adiciona COUNTS MAX 1. A RFC dizia em prosa que o conjunto incluiria somente uma instância do atributo; agora a limitação aparece na definição ASN.1. É uma melhoria importante: ferramentas compatíveis podem verificar uma regra que antes dependia da leitura humana.

Ainda assim, esquema não é sinônimo de verdade. Um esquema errado distribui um erro em escala. O requisito institucional é conferir juntos o texto normativo, o registro, o módulo, os exemplos e os vetores de teste antes de publicar ou corrigir.

O relógio do documento não é o do software

As erratas 9144 e 9145 foram relatadas em 19 de agosto de 2026, cobrindo o apêndice A e a seção 2. Em 13 de setembro ainda apareciam como Reported, não como correções verificadas. O rascunho de atualização também continua em processo: a versão 00 entrou na última chamada do grupo LAMPS em 1º de setembro e a 01 foi enviada em 9 de setembro UTC.

Esses marcos organizam o registro comum. Não alteram uma constante já compilada, um equipamento sem atualização ou uma mensagem assinada guardada para auditoria futura. A conclusão documental e a migração instalada precisam de indicadores separados.

Uma organização pode agir enquanto o IETF trabalha. Deve apenas declarar que sua escolha é uma política local e revisável, baseada no estado atual da evidência, não uma antecipação artificial do consenso final.

Ler, confiar e produzir são ações diferentes

Durante uma transição, a frase “suportamos os dois OIDs” revela pouco. Um leitor de arquivo pode reconhecer o OID antigo para explicar um objeto. Um gateway pode registrá-lo e localizar o produtor. Um validador pode decodificá-lo sem considerá-lo suficiente para cumprir uma regra de proteção. Um emissor deve conseguir ler o passado sem voltar a criar novos objetos incorretos.

Essas capacidades precisam de controles distintos. Compatibilidade dupla e silenciosa tende a eternizar o erro. Rejeição imediata, por outro lado, pode destruir acesso a provas históricas ou interromper sistemas que não têm atualização sincronizada.

O desenho mais prudente é assimétrico: cessar a emissão legada primeiro, manter detecção limitada, medir o resíduo por produtor, corrigir as origens e estreitar gradualmente as exceções. Não se deve normalizar a entrada em silêncio. Reescrever bytes de um objeto assinado pode apagar a procedência e invalidar a evidência.

O registro de precedência e retirada

O operador precisa de um registro pequeno e verificável. Ele começa com os dois OIDs completos, suas fontes e uma decisão de precedência: o valor da ramificação S/MIME é o alvo para novas emissões; o valor curto recebe um estado legado explícito e uma data de revisão.

Depois vêm os componentes: assinador, validador, gateway S/MIME, módulo de hardware, leitor de arquivo, ferramenta de inspeção e serviço de reserialização. Para cada versão, registra-se o que reconhece, o que aceita como proteção válida, o que emite e se preserva exatamente os bytes ao ler e gravar.

Um corpus de conformidade deve conter um objeto com cada OID, um sem o atributo, um com duas instâncias e casos em que os algoritmos declarados não combinam com a estrutura CMS. Cada resultado se liga ao hash do objeto, à versão de software e à política. O COUNTS MAX 1 merece teste em execução, pois nem toda biblioteca aplica automaticamente cada restrição do esquema.

O plano de retirada impede primeiro novas emissões incorretas. Mantém a observação para encontrar produtores remanescentes. Exceções têm responsável, justificativa e prazo. Objetos históricos ficam intactos; metadados externos podem explicar sua situação. A rejeição final só ocorre quando a medição mostra que a produção antiga cessou ou está isolada sob responsabilidade conhecida.

Um recibo para a correção

Uma entrega corrigida deveria responder: qual fonte definiu o OID-alvo; qual módulo ou constante mudou; qual teste comprova os novos bytes; como objetos existentes são tratados; quem aprovou o fim da janela de compatibilidade.

Sem esse recibo, “RFC 6211 corrigida” pode significar que apenas o emissor mudou e o arquivo quebrou. Pode significar que ambos são aceitos para sempre e o antigo continua sendo produzido. Pode até esconder uma reescrita que destruiu a possibilidade de explicar uma assinatura histórica.

Não é preciso guardar chaves ou mensagens no registro. Hashes de casos de teste, versões, resultados, exceções e datas bastam para documentar como a autoridade saiu da página e chegou ao comportamento.

Especificação mínima, decisões localizadas

O rascunho pode continuar enxuto. O nível comum precisa corrigir um identificador, expressar a cardinalidade e explicar a consequência de segurança. Não precisa impor a mesma janela de migração a arquivos jurídicos, clientes de correio e dispositivos embarcados.

Isso corresponde ao princípio de Heng Lu de especificação inicial mínima e decisões futuras localizadas. A interoperabilidade recebe uma verdade compartilhada. O tratamento de legado permanece perto de quem arca com risco e custo, desde que não altere o significado comum no fio.

O Policy Mirror exige precisão nas frases. “A IANA registra o valor correto”, “este leitor reconhece o antigo”, “esta política confia nele” e “este produtor emite o novo” não são sinônimos. Uma única marca de conformidade apaga justamente a informação necessária para governar a transição.

O registro correto mostra para onde convergir. O conserto só termina quando código, testes, objetos novos e regras sobre o passado chegam lá de forma demonstrável.

Fontes