Resumo

  • O Key ID do OpenPGP é um seletor de 64 bits sujeito a colisão; sozinho, não identifica um pacote de chave pública único nem a pessoa que o controla.
  • Um comprovante auditável guarda todos os candidatos, pacote e impressão digital escolhidos, procedência, certificações, estado de vida, resultado criptográfico e autorização separada.

Quando uma ferramenta mostra uma única chave depois de receber dezesseis caracteres hexadecimais, o usuário vê singularidade. O que talvez tenha ocorrido foi apenas uma decisão de ordenação: havia uma lista, mas a interface exibiu o primeiro item. A diferença desaparece da tela e, logo depois, do registro de auditoria.

O identificador curto não é um defeito. Ele reduz o espaço de procura e funciona bem como pista. O defeito aparece quando o sistema permite que a pista herde conclusões sobre pacote, pessoa, validade e poder institucional.

Jon Callas participou da história técnica desse limite. O registro do IETF lista cinco RFCs associadas a ele, entre elas as RFCs 2440 e 4880. Uma biografia da ACLU descreve experiências em criptografia, software e design; os cargos ali mencionados são contexto histórico, não prova de ocupação atual. A RFC 9580, sucessora da RFC 4880, tem outro conjunto de autores.

Um índice menor que o objeto

A RFC 4880 define o Key ID como oito octetos e alerta que implementações não devem pressupor unicidade. Para uma chave RSA versão 3, são os 64 bits inferiores do módulo. Para versão 4, os 64 bits inferiores da impressão digital.

A atual RFC 9580 preserva tanto o tamanho quanto o alerta. Na versão 4, o valor continua vindo da parte baixa da impressão SHA-1; na versão 6, vem da parte alta da impressão SHA-256. O nome do campo é constante, mas a derivação depende da versão.

Projetar um objeto maior em 64 bits admite que pacotes diferentes compartilhem o mesmo resultado. Isso não é, por si só, uma quebra da assinatura ou prova de fraude. É ambiguidade de descoberta. Ela se torna risco quando a consulta descarta correspondências adicionais, um cache usa Key ID como chave única ou uma importação substitui silenciosamente um candidato.

A versão também distingue o que foi realmente examinado. O mesmo material matemático RSA, embalado como chave versão 3, 4 ou 6, pode produzir impressões digitais e IDs diferentes. Sem pacote e versão, a auditoria não consegue reconstruir o objeto sobre o qual a decisão foi tomada.

Impressão digital precisa de procedência

A impressão digital completa é uma referência muito mais forte para um pacote público serializado. O verificador pode calculá-la localmente e compará-la mecanicamente a um valor esperado. A chance de colisão é muito menor que a de um recorte de 64 bits.

Mesmo assim, a RFC 9580 questiona a comparação humana de sequências longas. A solução é transferir a impressão por um canal autenticado e automatizar a comparação, não regressar ao ID curto. Por isso o comprovante registra se o valor esperado veio de configuração controlada, diretório assinado, canal independente ou página mutável. Uma comparação exata contra a referência errada continua errada.

Depois vem a ligação com uma pessoa. O pacote User ID carrega texto UTF-8, em geral nome e email, mas não testa a veracidade do que foi escrito. Assinaturas de certificação qualificam essa ligação: generic não declara o rigor da checagem; persona declara ausência de verificação; casual e positive expressam verificações progressivamente mais fortes.

Nome e email ao lado de uma impressão correta não demonstram vínculo empregatício, função presente ou delegação. A parte que confia precisa definir certificadores aceitos, escopo, época e finalidade.

Assinatura válida não é mandato

O subpacote Issuer Key ID continua sendo uma pista de oito bytes dentro da assinatura. A RFC 9580 não permite seu uso com chaves posteriores à versão 4 e recomenda Issuer Fingerprint em todas as assinaturas. Quando ambos aparecem para versão 4, o ID deve coincidir com os 64 bits baixos da impressão. A consistência ajuda, mas não substitui a resolução do pacote.

A verificação criptográfica responde se a assinatura funciona com aquela chave sobre aqueles bytes exatos. Revogação, expiração, momento relevante, algoritmos permitidos e key flags são testes separados. Capacidade técnica de assinatura não é permissão universal de uso.

Autorização organizacional exige outra fonte. Uma assinatura válida em um manifesto não prova que o controlador da chave é o responsável atual pelo release, que o manifesto descreve o artefato correto ou que a política permite a publicação. Posse, identidade certificada, cargo vigente e poder específico precisam convergir sem serem confundidos.

Registrar o caminho completo

O comprovante preserva o conteúdo assinado e o pacote de assinatura. Usa o Key ID como sugestão, enumera todos os candidatos por repositório e guarda, para a escolha final, o pacote público completo, a versão e a impressão digital recalculada. Fonte e horário de obtenção ficam ao lado do objeto.

Em seguida entram o User ID avaliado, certificações e regra de confiança, expiração e revogação no instante pertinente, key flags, política algorítmica e resultado criptográfico. Só então uma regra externa decide se aquela pessoa podia praticar aquele ato.

Se houver dois candidatos, ambos permanecem. Se a origem da impressão for fraca, a fragilidade não é apagada. Se identidade ou permissão não estiverem demonstradas, os campos ficam em aberto. Um bom registro preserva incerteza suficiente para que outra equipe consiga repetir a decisão.

Fontes