Resumo

  • A RFC 3657 atribuiu identificadores CMS diferentes à Camellia para cifrar conteúdo e encapsular chaves. A cifra CBC exige um IV presente de 16 octetos; o identificador do algoritmo de encapsulamento exige que os parâmetros estejam ausentes.
  • A capacidade S/MIME usa uma terceira forma: parâmetro NULL. O OID de encapsulamento indica o tamanho da chave de cifragem de chaves (KEK), não necessariamente o tamanho da chave de conteúdo (CEK) encapsulada.

O mesmo nome não descreve a mesma operação

Em um envelope CMS, “Camellia” não basta para identificar o que o emissor fez. O destinatário precisa saber se o algoritmo protegeu o conteúdo ou encapsulou a chave de cifragem do conteúdo (CEK), e interpretar o identificador conforme essa função. Publicada em janeiro de 2004 como documento Standards Track, a RFC 3657 definiu essas convenções para Camellia: uma família de OIDs para a cifra CBC do conteúdo e outra para o encapsulamento de chaves. RFC 3657

A diferença aparece nos parâmetros. Para id-camellia128-cbc, id-camellia192-cbc e id-camellia256-cbc, os parâmetros de AlgorithmIdentifier DEVEM estar presentes e conter o vetor de inicialização de 16 octetos. O IV integra a descrição da cifra do conteúdo; não se deduz esse valor pelo nome do algoritmo. A RFC também determina que o preenchimento do texto claro siga a regra do CMS. RFC 3657 RFC 5652

No encapsulamento de chave, a expectativa se inverte. Os três OIDs de encapsulamento Camellia incluem um arco que indica tamanho, mas os parâmetros de seu AlgorithmIdentifier DEVEM estar ausentes. A construção de encapsulamento define como usa o valor inicial interno; o campo não carrega um IV. O tamanho indicado pelo OID se refere à chave de cifragem de chaves (KEK), não garante que a CEK encapsulada tenha o mesmo tamanho. As implementações DEVEM aceitar KEK e CEK de tamanhos iguais; se aceitarem tamanhos diferentes, a KEK DEVE ser igual ou maior que a CEK. Assim, a RFC define uma fronteira de codificação e compatibilidade, não um tamanho único para todas as chaves do envelope. RFC 3657 RFC 3394

Uma terceira codificação para anunciar capacidade

A RFC 3657 também define como um cliente S/MIME anuncia suporte à Camellia em SMIMECapabilities. O OID da capacidade vem acompanhado do parâmetro NULL. Isso não contradiz a ausência de parâmetros no identificador de encapsulamento: são estruturas ASN.1 com funções diferentes. Na codificação transmitida, NULL tampouco equivale a parâmetro ausente. A RFC inclui as codificações DER para os três tamanhos, permitindo comparar exatamente a forma anunciada. RFC 3657 RFC 2633

A lista de capacidades é assinada, ordenada por preferência e descreve apenas parte do que o emissor suporta. Ela alimenta uma decisão posterior, junto com acordos privados, preferências do usuário e restrições legais. Não é uma negociação em tempo real, um teste da configuração atual do destinatário nem prova de que uma mensagem usou Camellia. Para saber qual operação foi escolhida, é preciso examinar os campos de cifra do conteúdo e de gestão de chaves do envelope, não somente uma declaração anterior de capacidade. RFC 3657

A interoperabilidade depende de separar as fronteiras

Uma análise de interoperabilidade deve comparar os três contextos separadamente. Na cifra CBC do conteúdo, confira o identificador, o tamanho da chave e a presença do IV de 16 octetos. No encapsulamento, confira se os parâmetros foram omitidos e se os comprimentos reais de KEK e CEK cabem no suporte declarado pela implementação. Na capacidade, compare o valor DER assinado — inclusive o NULL — e a ordem de preferência. Confundir os contextos pode produzir divergência de interpretação ou seleção mesmo quando todos declaram suporte à mesma cifra.

A RFC 3657 determina que o encapsulamento Camellia siga a construção da RFC 3394, substituindo AES por Camellia; ambas usam blocos de 128 bits. O valor inicial de integridade padrão é a constante A6A6A6A6A6A6A6A6. Se o procedimento de desempacotamento não recuperar esse valor, o destinatário devolve erro e não retorna dados da chave. A RFC também permite valores iniciais alternativos para atender a escopos de integridade próprios de uma aplicação. Essa verificação se refere aos dados da chave encapsulada pela construção especificada; ela não autentica o emissor, o conteúdo CMS nem a autoridade do usuário para agir sobre o conteúdo decifrado. RFC 3657 RFC 3394

Esta é uma reconstrução histórica de um contrato de codificação, não um endosso de segurança nem um levantamento de implantação. O registro de algoritmos do CMS e perfis posteriores ajudam a dar contexto, mas não demonstram quais produtos implementaram a RFC 3657 ou com que frequência. A lição é mais restrita: o identificador de algoritmo é um campo tipado do protocolo. OID, presença de parâmetros e estrutura externa precisam ser interpretados em conjunto. RFC 3370 RFC 8419

Fontes