Resumo

  • A composição padrão assinava os dados literais, compactava assinatura e conteúdo, criptografava o resultado com uma chave de sessão, antepunha uma cópia criptografada dessa chave para cada destinatário e, opcionalmente, aplicava ASCII Armor.
  • CTB e comprimentos tornavam o arquivo navegável; CRC e verificações de chave acusavam erros estreitos. Nenhum desses sinais, isoladamente, autenticava uma pessoa ou uma decisão.
  • A assinatura cobria bytes definidos, não todos os metadados visíveis. Nome de arquivo, horário confiável, vínculo entre chave e pessoa, autorização e recebimento dependiam de evidência adicional.

A ordem cria o alcance da verificação

No fluxo normal de RFC 1991, a assinatura é produzida primeiro e colocada antes do pacote de dados literais. Se houver compactação, esse par entra em um pacote compactado. Uma chave convencional temporária criptografa o conjunto. Para cada destinatário, um pacote de chave pública transporta a chave de sessão criptografada. Só depois o objeto binário pode ganhar uma capa ASCII adequada aos caminhos de correio da época.

Não é simples convenção de embalagem. O que veio antes determina o que pode ser verificado depois. Ao abrir as camadas externas, o receptor encontra os bytes que foram assinados. A assinatura não passa a cobrir retroativamente o cabeçalho do Armor, o trajeto da mensagem ou a escolha feita pelo aplicativo. Da mesma forma, descriptografar prova que uma transformação funcionou com uma chave; não prova a assinatura interna.

O pacote literal contém modo, nome sugerido, data e dados. Somente o campo de dados literais participa do resumo de uma assinatura de documento. Uma interface que reúne todos esses campos sob a legenda “assinado” amplia a conclusão sem ampliar a evidência.

Assinaturas separadas e aninhadas revelam outro cuidado. A separada é calculada sobre o arquivo externo, sem o cabeçalho literal. Vários autores podem assinar independentemente. Na forma aninhada, uma assinatura posterior inclui a anterior. Um registro auditável precisa informar a extração exata e a relação entre assinaturas, não apenas contar marcas verdes.

CTB é endereço estrutural

O Cipher Type Byte abre cada pacote, codificando seu tipo e a forma do comprimento. Assim o software sabe se encontrou assinatura, compactação, criptografia convencional, chave pública ou dados literais, e onde começa o próximo pacote. Uma forma sem comprimento explícito para dados compactados se estende até o fim da estrutura que a contém.

Essa gramática transformou uma sequência binária em um objeto composto que implementações diferentes podiam percorrer. Mas um tipo válido é uma afirmação sintática. Um comprimento que fecha é uma afirmação de fronteira. Eles não dizem quem criou o conteúdo, se todo o invólucro chegou, se o algoritmo é aceitável hoje ou se a aplicação está autorizada a agir.

A extensão indefinida mostra a dependência: seu fim só existe se o limite externo estiver estabelecido. O parser pode estar correto localmente e ainda operar sobre uma suposição errada acerca do objeto maior.

ASCII Armor transportava; não autenticava

Para sobreviver a sistemas que alteravam bytes binários, o Armor mapeava três bytes em quatro caracteres imprimíveis e acrescentava cabeçalho, campos opcionais, corpo, CRC de 24 bits e rodapé. O CRC era calculado sobre o binário antes da conversão radix-64.

O bloco parece um documento selado, mas RFC 1991 avisa que os cabeçalhos da armadura não pertencem à mensagem e podem mudar no transporte. Por isso não devem carregar informação importante. Um campo desconhecido, desde que bem formado, é relatado e o processamento prossegue.

O recibo correto é restrito: os caracteres reconstruíram uma sequência binária compatível com a verificação de erro. O CRC ajuda contra corrupção acidental, mas não identifica o remetente. Um bloco inteiro pode ser substituído com um novo CRC. A assinatura interna, quando presente, é outra pergunta.

Chave encontrada não é pessoa comprovada

O texto cifrado convencional começa com material aleatório e bytes repetidos usados para verificar a chave. O pacote de chave pública também traz uma soma sobre a chave de criptografia dos dados. Essas conferências permitem abandonar rapidamente uma chave errada. Não demonstram quem acionou a chave privada, se o dispositivo estava íntegro ou se havia autorização organizacional.

O Key ID de 64 bits apenas orienta a busca. O próprio RFC registra que chaves podem compartilhar o identificador por acaso ou por ataque. Uma trilha séria deve preservar a chave efetivamente resolvida, candidatos, critérios de seleção, certificados aceitos, revogação, comprometimento e política de uso.

O horário de uma assinatura comum também não é um relógio confiável. O documento diz que ele costuma ficar perto do momento de criação, mas pode ser escolhido pelo usuário. Tempo confiável exige uma assinatura notarial separada sobre o pacote de assinatura. Integridade criptográfica, identidade, autoridade e temporalidade continuam sendo fatos distintos.

O valor histórico da separação

O RFC Editor registra RFC 1991 como Informational, de agosto de 1996, depois tornado obsoleto por RFC 4880. As versões texto, HTML e a ficha do IETF preservam o que foi especificado, sem provar que toda implantação real o executou da mesma forma.

A entrada do IETF no diretório oferece apenas navegação institucional; não prova que a organização endosse a interpretação deste artigo.

Os textos de Lu Heng sobre primazia do código em execução, especificação inicial mínima e decisão local e camadas da realidade entram como lente editorial, não como prova histórica sobre PGP. A lente pede que o registro técnico permaneça fiel ao que observou, sem receber autoridade emprestada de uma identidade ou política externa.

Esse é o legado operacional: camadas pequenas podem cooperar sem fingir que compartilham a mesma jurisdição.