Summary

  • A RFC 2440 definiu muitas etiquetas de pacote OpenPGP, mas não criou um processo normal para acrescentar outras permanentemente: a interação entre recursos poderia reduzir a segurança do protocolo como um todo.
  • Haver espaço numérico no cabeçalho não era autorização. Os valores 60 a 63 ficaram reservados para uso privado ou experimental; novos pedidos deveriam ser encaminhados aos diretores de segurança do IESG ou a um grupo de trabalho apropriado do IETF.
  • Em assinaturas, subpacotes desconhecidos normalmente eram ignorados. O bit crítico permitia ao signatário preferir um erro à perda silenciosa do significado. Reconhecer não era implementar, e metadados não hasheados não eram prova definitiva.
  • Versões posteriores formalizaram registros e revisão. Um número alocado, uma análise bem-sucedida ou uma assinatura válida não comprovam composição segura nem implantação.

A lacuna não decidia por ninguém

Imagine uma desenvolvedora encontrando uma etiqueta livre num pacote OpenPGP. Dois clientes novos escrevem o valor e conseguem lê-lo de volta; o teste passa. Os bytes cabem. Mas o que fará um verificador antigo? Uma negociação poderá reduzir o recurso? Outro pacote poderá alterar seu significado? A assinatura continuará matematicamente válida se a nova semântica for ignorada? O teste local não responde.

Essa preocupação aparece na nota do IESG à RFC 2440, de novembro de 1998. O documento definiu muitas etiquetas, mas não estabeleceu um mecanismo normal para acrescentar outras. Embora o cabeçalho do formato novo pudesse representar etiquetas até 63, a especificação advertiu que interações sutis entre recursos novos e existentes poderiam reduzir bastante a segurança geral. Pedidos de novos valores — por exemplo, para algoritmos de criptografia — deveriam ir aos diretores da área de segurança do IESG ou a um grupo de trabalho apropriado. Os valores 60 a 63 continuavam privados ou experimentais.

O espaço existia; um processo seguro de extensão não surgia automaticamente.

OpenPGP não era uma coleção de algoritmos independentes. Pacotes são combinados em chaves, assinaturas e mensagens cifradas. Um recurso novo pode mudar como um software antigo analisa uma sequência, como um software novo interpreta um campo legado ou o que o destinatário acredita estar coberto pela assinatura. A sintaxe pode aceitar uma etiqueta enquanto suas interações seguem sem análise. A RFC 2440 separou capacidade de codificação de permissão no protocolo.

As assinaturas tornaram a fronteira visível

Os subpacotes de assinatura mostravam a mesma tensão em escala menor. Ignorar um subpacote desconhecido favorecia a compatibilidade futura: uma implementação antiga ainda podia processar uma assinatura com metadados novos. Por isso, a RFC 2440 recomendava ignorar tipos não reconhecidos. Mas esse silêncio também podia apagar um recurso importante para quem assinou.

O bit 7 do tipo do subpacote oferecia uma escolha. Se um subpacote desconhecido fosse marcado como crítico, o avaliador deveria considerar a assinatura errônea. O signatário podia preferir uma falha visível a uma aceitação que descartasse o significado. Não era garantia universal: o avaliador precisava conhecer a regra; mesmo reconhecendo o tipo, poderia não implementar sua semântica. A especificação distinguia explicitamente esses estados.

Um dado reconhecido junto de uma assinatura válida tampouco ganhava automaticamente a autoridade da assinatura. Subpacotes podiam ficar na seção hasheada ou na não hasheada. A RFC 2440 alertava que informações não hasheadas não eram definitivas porque não faziam parte da assinatura propriamente dita. O leitor podia vê-las e o verificador podia analisá-las, mas isso não as tornava cobertas criptograficamente. Presença, análise, reconhecimento, implementação e cobertura são estados diferentes.

Da cautela ao registro

A RFC 4880, que substituiu a RFC 2440 em 2007, criou registros explícitos na IANA e exigiu consenso do IETF para novos tipos de pacote, tratados como recursos importantes. Também apontou riscos de downgrade e cross-grade em extensões ligadas à detecção de modificações. O processo ficou mais legível, mas interoperabilidade, implementação e análise de segurança não viraram uma única caixa de seleção.

Publicada em 2024, a RFC 9580 substituiu a RFC 4880 e manteve procedimentos de alocação distintos. Alguns registros OpenPGP usam “Specification Required”; tipos de pacote e certos espaços de versões ou identificadores exigem “RFC Required”. Especialistas devem avaliar as propriedades de segurança esperadas e a interoperabilidade com implementações existentes. É uma resposta institucional à lacuna anterior, não a prova de que toda extensão aprovada seja segura em qualquer ambiente.

Esses documentos não afirmam que toda extensão seja nociva, nem que todos os implementadores tenham seguido uma única prática. Revelam algo mais delimitado: num protocolo criptográfico, acrescentar significado pode alterar o comportamento dos caminhos existentes. Um inteiro disponível é apenas um endereço no formato; não prova compatibilidade, cobertura criptográfica, entendimento do usuário ou segurança operacional.

Fontes