Resumo

  • O RFC 3058 atribuiu identificadores e regras de parâmetros diferentes à cifra de conteúdo IDEA e ao encapsulamento de chaves IDEA. A representação ficou exata, mas o suporte continuou opcional e o contexto ainda decidia entre parâmetros ausentes, NULL ou um IV de oito octetos.
  • Uma capacidade S/MIME assinada era uma declaração ordenada do cliente, não um recibo de execução. O uso real ainda dependia das duas pontas, da preferência local, de acordos privados, de restrições legais, do acesso às chaves e do processamento completo.

Um nome não basta para dois trabalhos

Software criptográfico não consegue interoperar apenas com a instrução “use IDEA”. Uma mensagem CMS precisa do identificador, dos parâmetros e da posição de cada valor. Também precisa separar a cifra do conteúdo da cifra que protege a chave desse conteúdo. Publicado como Informational em fevereiro de 2001, o RFC 3058 trouxe essa precisão.

Um OID identificava IDEA-CBC para conteúdo; outro identificava o encapsulamento de chaves IDEA. O primeiro usava chave secreta de 128 bits e blocos de 64. O segundo recebia uma chave de conteúdo de 16 octetos, juntava uma verificação de oito e produzia 32 octetos encapsulados. “Suporta IDEA” apagava duas funções distintas.

Os OIDs ficavam sob um ramo de empresa privada associado à Ascom. Seu valor era coordenar implementações independentes. O registro não dizia que todo cliente S/MIME continha o código, que qualquer usuário podia ativá-lo ou que a mensagem chegara a uma pessoa. Tornou a escolha legível; não a tornou disponível.

Ausente, NULL e IV não são o mesmo vazio

O identificador de conteúdo admitia IDEA-CBCPar, com IV opcional de exatamente oito octetos. Presente nos parâmetros, ele era usado e não aparecia no início do texto cifrado. Ausente, os primeiros 64 bits do texto viravam o IV, embora o RFC dissesse que essa forma não deveria ser usada em CMS ou S/MIME.

O identificador de encapsulamento seguia outra regra: os parâmetros tinham de ser NULL. Os dois anúncios de capacidade seguiam uma terceira: os parâmetros tinham de estar ausentes. Em documentação imprecisa, os três parecem “nada”; em ASN.1, são bytes e instruções diferentes.

Esse é o centro discreto do documento. Um identificador só vira instrução completa com contexto e convenção de parâmetros. Um analisador que troca ausência por NULL pode rejeitar uma estrutura válida ou aceitar uma semântica não acordada. Um painel que salva apenas “IDEA” perde a evidência necessária para reproduzir a mensagem.

A errata 5913, mantida para atualização futura, reforça a divisão: o símbolo ASN.1 IDEA-CBC deveria ser id-IDEA-CBC para começar com minúscula, sem alterar o OID numérico. Rótulo humano, identificador no código ASN.1 e número registrado estão ligados, mas não são o mesmo objeto.

Aleatoriedade dentro, constante fora

O encapsulamento era definido passo a passo. Uma verificação de oito octetos era anexada à chave de conteúdo de 16. Um IV aleatório de oito cifrava os 24 octetos com IDEA-CBC. Depois o IV aleatório era prefixado, os 32 octetos invertidos e tudo cifrado de novo com o IV externo fixo 4adda22c79e82105. A operação inversa rejeitava uma verificação incorreta.

Isolado, o IV fixo pode enganar: ele não elimina o IV novo da camada interna. Da mesma forma, aleatoriedade e verificação correta não provam autorização, vontade do destinatário nem utilidade do conteúdo. A verificação responde apenas a uma pergunta estreita sobre a chave recuperada.

O CMS separava camadas porque cada uma tinha um trabalho. A chave de conteúdo protegia o corpo; a chave de cifragem protegia aquela chave; o formato a transportava; o envelope identificava algoritmos e destinatários. Sucesso em uma camada não era recibo das demais.

Capacidade assinada, ordenada e parcial

O cliente podia publicar SMIMECapabilities como atributo assinado. O RFC 3058 fornecia bytes DER exatos para IDEA-CBC e para o encapsulamento, em categorias distintas; a ordem podia expressar preferência. Especificações posteriores mantiveram que a lista era parcial e não precisava enumerar tudo.

Uma assinatura válida atribuía a declaração naquele contexto, com checagens de certificado e horário. Ela não interrogava o processo atual do destinatário. Atualização, reconfiguração, provedor ausente, chave inacessível ou política local podiam separar declaração de execução. Suporte real também podia não aparecer na lista.

O RFC deixou a seleção fora do registro. Citou capacidades recebidas, acordos privados, preferências e restrições legais. Se o usuário exigisse IDEA, os dois clientes precisavam suportá-lo e a preferência precisava ser configurada. O OID removia ambiguidade dos bytes; não exercia essas autoridades.

A licença permanecia ao lado do formato

O aviso histórico dizia que a Ascom detinha patentes, oferecia licenças não exclusivas em condições razoáveis e não discriminatórias e permitia uso não comercial gratuito. Isso documenta a fronteira apresentada em 2001; não é opinião jurídica atual. A padronização não eliminava a camada de licença então declarada.

Uma implementação podia reconhecer o OID sem conter o algoritmo. Um desenvolvedor podia ter o código e uma organização recusar as condições. O destinatário podia anunciar suporte e a política do remetente escolher outra coisa. O registro técnico não absorvia essas decisões.

O RFC 3370 separou convenções de algoritmos do núcleo CMS; o RFC 5652 definiu uma versão posterior; o RFC 8551 atribuiu níveis a AES e ChaCha20-Poly1305, preservando capacidades e decisões externas. Essa evolução não prova implantação de IDEA, nem a ausência numa lista moderna apaga seus OIDs.

A lição duradoura não é vitória ou derrota do IDEA. Padronização pode tornar uma decisão reproduzível sem torná-la universal. O número identifica, os parâmetros ensinam a ler, a capacidade assinada atribui a afirmação, e política e direito condicionam a seleção. Só uma troca real mostra se ambas as pontas concluíram o trabalho.

Fontes

Lu Heng não escreveu nem aprovou o RFC 3058. Seus ensaios são usados apenas como lente analítica declarada para separar registro simbólico de comportamento executável.