A importação de chave pública do servidor de chaves faz com que minha chave secreta perca seu recurso de assinatura

Question

Estou um pouco intrigado com o comportamento que vejo no GnuPG 2.0.30.

Por algum motivo, notei recentemente que minha chave havia perdido sua capacidade de assinar documentos. Então eu investiguei um pouco e com certeza eu encontrei isso:

pub  4096R/0xDEADBEEF0000F00D  created: 2000-01-01  expires: never       usage: C
                               trust: ultimate      validity: ultimate
sub  4096R/0xFEEDFEEDFEEDF00D  created: 2000-01-01  expires: never       usage: E

Como você pode ver, nem o primário nem a subchave têm o S de uso ativado.

Tudo bem, então decidi excluir meu par de chaves e reimportá-lo de um backup anterior que sabia ser bom.

Isso funcionou bem e com certeza eu vi um SC como uso para a chave primária.

pub  4096R/0xDEADBEEF0000F00D  created: 2000-01-01  expires: never       usage: SC
                               trust: ultimate      validity: ultimate
sub  4096R/0xFEEDFEEDFEEDF00D  created: 2000-01-01  expires: never       usage: E

No entanto, sempre que atualizo a chave pública de um servidor de chaves (estou usando eu.pool.sks-keyservers.net ), acabo recebendo o uso de S da minha chave primária.

Então, eis a questão: como posso reativar o uso de S (assinatura) para uma chave primária?

E pontos de bônus para aqueles capazes de apontar porque atualizar a chave pública afeta as capacidades da minha chave secreta como essa.

    

Answer 1

And bonus points to those able to point out why updating the public key affects the capabilities of my secret key like that.

A chave secreta não sabe nada sobre recursos. Esses são definidos em uma configuração especial de armazenamento de assinatura em sua chave, enquanto o par de chaves pública / privada é tecnicamente capaz de fazer assinaturas e criptografia. Isso é geralmente válido apenas para as chaves RSA amplamente difundidas: tanto o DSA quanto o ElGamal, bem como a maioria dos algoritmos de criptografia de curva elíptica mais recentes têm chaves separadas para as diferentes operações.

Mas como pode uma chave "perder" a capacidade de assinatura já configurada apenas porque você buscou uma atualização da rede do servidor principal? Mensagens OpenPGP, assim como arquivos de chaves, são construídos a partir de entidades menores, pacotes OpenPGP. Uma chave, por exemplo, consiste em pacotes que definem as chaves reais (os números pelos quais a chave é definida), juntamente com IDs de usuário, certificações e assinaturas de configuração especial já mencionadas. Quando você atualiza uma chave, esses pacotes individuais são mesclados. Em caso de conflitos (por exemplo, diferentes assinaturas de configuração), o mais novo ganha.

O que eu suspeito no seu caso é que você tem um pacote de configuração com o registro de data e hora mais recente na rede do servidor principal, enquanto houver um antigo no seu computador. Isso deve ter sido gerado por alguém ter acesso à sua chave privada, então provavelmente (e espero) deve ter sido você. Você pode tentar verificar minha suposição executando gpg --export <key-id> | gpg --list-packets antes e depois de buscar as atualizações e procurar por linhas que contenham a definição de key flags . Estes são um campo de bits como definido por OpenPGP, RFC 4880, 5.2.3.21. Bandeiras de chaves . Por exemplo, minha própria chave possui um sinalizador de chave 3 (binário 11 ), o que significa que possui capacidade de certificação (binário 01 ) e assinaturas (binário 10 ).

0x01 - This key may be used to certify other keys.
0x02 - This key may be used to sign data.
0x04 - This key may be used to encrypt communications.
[snip]

Você observará um desses pacotes para cada ID de usuário que tiver.