Resumo

  • A revisão 03 de um Internet-Draft do grupo LAMPS, publicada em 14 de setembro, atualizaria o RFC 5652 e proibiria id-data em novos usos de CMS SignedData.
  • Ela classifica um uso pela data em que uma especificação define pela primeira vez a aplicação, a partir da futura publicação do documento, e não pela implementação ou implantação do software.
  • Usos existentes recebem orientação de migração e verificação, em vez da mesma proibição absoluta, porque uma mudança indiscriminada pode romper a interoperabilidade com remetentes já implantados.
  • O texto pretende tornar-se uma Best Current Practice, mas continua sendo um projeto ativo: não é RFC, regra adotada, evidência de exploração nem prova de vulnerabilidade de um produto.

Uma linha com data ainda inexistente

A revisão 03 acrescenta ao cabeçalho e ao resumo uma proposição importante. Se aprovada, ela atualizaria o RFC 5652, padrão atual de Cryptographic Message Syntax, para proibir o tipo id-data em novos usos de CMS SignedData.

A definição nova determina o alcance. É novo o uso cuja especificação, a partir da data de publicação do futuro documento, define pela primeira vez como SignedData será construído ou processado para uma aplicação. Não importa se essa especificação posterior é um RFC ou registra um identificador de tipo de conteúdo na IANA. O uso anterior à publicação é existente.

É uma linha formal nítida, mas prospectiva. O Datatracker registra um Internet-Draft ativo de grupo de trabalho, com status pretendido de BCP. O RFC 2026 trata Internet-Drafts como documentos de trabalho. A revisão pode orientar a análise de hoje; seu envio não altera sozinho o STD 70.

Tempo de especificação não é tempo de implantação

A comparação oficial põe em cena dois relógios.

A definição classifica pela primeira especificação. Outra frase afirma que a proibição para usos novos não muda retroativamente a conformidade de implementações já implantadas. As ideias são compatíveis, mas descrevem evidências diferentes. Um protocolo pode estar especificado sem implantação relevante. Um programa pode surgir anos depois do texto fundador. Um remetente antigo pode continuar operando depois de uma especificação sucessora.

O projeto não publica um censo que conecte esses estados, nem diz que o fez. Seus apêndices identificam RFCs que usam id-data e analisam aplicabilidade, mas referência normativa não mede base instalada. Uma linha de IANA identifica objeto e referência sem demonstrar o caminho de código usado, a fiscalização de signedAttrs pelo destinatário ou o compartilhamento de uma chave entre protocolos.

O problema de segurança depende do comportamento. O RFC 5652 permite omitir signedAttrs quando o tipo encapsulado é id-data. O projeto explica como uma assinatura pode então validar uma estrutura que o signatário não pretendia assinar expressamente. Também apresenta limites: há protocolos que exigem atributos assinados; a verificação correta pode impedir o ataque; a forma da mensagem pode restringir sua aplicabilidade; e existem outras mitigações. “Existente” não é sinônimo de “vulnerável”, assim como “novo” não comprova implementação segura.

Compatibilidade integra a decisão

Para usos novos, a revisão diz que id-data MUST NOT ser empregado. Com conteúdo MIME, o tipo proposto mimeData SHOULD ser usado, salvo justificativa para um identificador mais específico. O texto solicita três ações da IANA, mas os números permanecem TBD. Os registros atuais de números SMI e tipos internos CMS não convertem marcadores de projeto em alocações.

Os usos existentes seguem outro caminho. Quando o protocolo é atualizado, deve-se abandonar id-data. Se ele for mantido, a revisão pede uma justificativa para que os revisores avaliem o compromisso de segurança. Uma extensão retrocompatível pode ser um péssimo momento para impor quebra; uma versão principal ou outra mudança já incompatível pode ser a janela adequada.

Isso não é uma brecha escondida. É a avaliação de interoperabilidade expressa no projeto. Remetentes implantados talvez não produzam signedAttrs como espera uma regra mais rígida. Um MUST universal levaria destinatários novos a rejeitar tráfego antigo legítimo antes de existir migração. A questão de governança é registrar onde a flexibilidade foi usada, por quem, com que evidência e até quando.

Chaves, bibliotecas e aplicações

A revisão 03 cria uma seção sobre separação de chaves. Exigir atributos assinados em um protocolo não basta se a mesma chave também assina em outro protocolo ou versão antiga onde eles não são obrigatórios. O texto propõe chaves distintas ou uma mitigação uniforme para todas as operações feitas com a chave.

Ele também divide o trabalho com bibliotecas CMS genéricas. Em usos novos, o destinatário precisa verificar o tipo esperado e a presença obrigatória dos atributos. Se a biblioteca não aplica a regra específica, deve expor o tipo recebido à camada de aplicação.

Autores de especificação escolhem tipo e transição. Mantenedores de biblioteca preservam dados e pontos de verificação. Donos de aplicação aplicam a expectativa do protocolo. Custodiantes de chaves decidem o alcance. A IANA registra identificadores. Nenhum ator isolado demonstra que toda a implantação migrou com segurança.

Inventário de transição, não veredicto em massa

Um inventário público curto tornaria a linha auditável. Para cada uso conhecido de CMS SignedData, registraria: primeira especificação e data; tipo de conteúdo e regra de signedAttrs; classe da evidência de implantação sem inventar volume; possível reutilização de chaves; próxima oportunidade de mudança incompatível; motivo para manter ou substituir id-data; responsável pela especificação, próxima revisão e histórico de correções.

Esse registro é uma proposta de Daniel Kade, não uma exigência do projeto. Ele não declararia todo uso antigo inseguro. Separaria uma especificação antiga com verificação obrigatória, uma implantação antiga de comportamento desconhecido e uma especificação nova sujeita à regra prospectiva.

A publicação pode continuar como fronteira formal. O inventário oferece o mapa operacional ao redor dela.

Fontes